OpenSeva is a small but complete healthcare stack: an EMR (the clinical app), a FHIR® database (the medical record), an auth service, an insurance Payer with a Payment-Integrity engine, and supporting tools — all behind one door.
The learning goal isn't "click the app." It's to follow one patient through the system and, at each hand-off (a hop), ask two questions: which building block does the work, and where does cost enter? Roughly a quarter of denied claims trace back to problems that were cheap to fix early and expensive to fix late. By the end you should be able to point at a hop and pitch a concrete way to cut cost.
Seven hops from booking to payment, each with its cost lens. Jump to the cost journey.
Think of it as a small clinic plus an insurer. The EMR is where care is delivered and recorded; every record lives in the FHIR® database; when a bill goes out, the Payer prices it with help from a Payment-Integrity engine and returns an EOB. Here is how the data flows:
| Component | Role in the story | Open it |
|---|---|---|
| EMR | The clinical app clinicians & front desk use. | /emr/ |
| FHIR® DB | The medical record — every Patient, Encounter, Claim lives here (on Postgres). | /fhir/ |
| Auth | Logs users in and carries their role. | /auth/ |
| Payer | The insurance company — checks eligibility, adjudicates claims, writes the EOB. | /payer/ |
| Wellness | Prevention program — members share activity data; healthy habits earn premium discounts. | /wellness/ |
| Payment Integrity | Pre-payment checks: downcoding + fraud scoring. | /integrity/ |
| FHIR Admin | Browse/edit the raw records behind the app. | /admin/ |
| Swagger | Interactive OpenAPI explorer for the FHIR API. | /swagger/ |
| Dataset worker | Synthetic-data generation + the AI bridge. | /dataset/ |
This is the heart of the exercise. For each hop: who acts, the FHIR building block, where cost is incurred, and how it can be cut. Try each one live as you read.
Appointment · try: EMR → Book AppointmentCoverage, CoverageEligibilityResponse · try: EMR → patient → Insurance tab → Check eligibility (try Dana Lapsed for the failure case)Encounter, Observation · try: EMR → EncountersObservation (lab), MedicationRequest · try: EMR → Medications / PrescriptionsClaim · try: EMR (admin) → Revenue Cycle → submitPaymentReconciliation, Invoice · try: EMR → Invoicesnode simulate-visit.js generates a brand-new patient every run
and walks all of these hops — booking → encounter → dictation/orders → pharmacy → lab/imaging → claim →
adjudication/EOB → copay — writing real FHIR records and printing the cost at each step. Then verify the patient,
claim, and EOB in the UI. Run it a few times to compare a blood panel vs an X-ray vs an ultrasound cost layer.Open the EMR and sign in as any role. All URLs are relative to this page's origin
(…), so they work through whatever address you reached this page on.
| Role | Password | Sees / does | |
|---|---|---|---|
| Admin / Biller | admin@emr.local | admin123 | Everything + Revenue Cycle back office (claims, EOB, copay), users |
| Doctor | doctor@emr.local | doctor123 | Encounters, documentation, prescriptions, coding |
| Receptionist | reception@emr.local | reception123 | Registration, eligibility, copay, scheduling |
| Patient | patient@emr.local | patient123 | Own chart, booking, own invoices |
The main clinical app.
Claims & eligibility.
Prevention & discounts.
Raw records.
R4 REST.
OpenAPI explorer.
AI / data.
Every screen is just an API call. Here are the key ones; the full, clickable & testable catalog (with per-role EMR actions and an MCP export) is the API console.
| Do this | Call | Service |
|---|---|---|
| Log in (get a token) | POST /auth/api/login | Auth |
| Find / read a patient | GET /fhir/Patient · GET /fhir/Patient/{id} | FHIR |
| Insurance on file | GET /fhir/Coverage?beneficiary=Patient/{id} | FHIR |
| Real-time eligibility (270/271) | POST /payer/api/eligibility | Payer |
| List insurers & plans | GET /payer/api/payers | Payer |
| Submit a claim | POST /payer/api/claims | Payer |
| Read the EOB / claim status | GET /payer/api/claims/{id} | Payer |
| Downcoding + fraud check | POST /integrity/api/check | Integrity |
| FHIR capabilities | GET /fhir/metadata | FHIR |
Tip: open the API console → set the base URL to this origin → press Send on any row to see the live response, then Generate MCP tool catalog.
The Model Context Protocol lets Claude Desktop operate this stack in plain English — "check eligibility for patient-local", "submit a 99214 claim and show me the EOB". You run a tiny local MCP server that forwards to the URLs above.
cd mcp-server && npm install.claude_desktop_config.json
(copy):
…
The MCP server is role-gated (a receptionist gets eligibility tools; an admin gets claims/EOB) — the same permissions you see in the UI. Full details: API console → Export as MCP tools.
reception123): open a patient → Insurance → Check eligibility. Try Dana Lapsed to watch bad data become an Inactive result (Hop 2).doctor123): open Encounters, document a visit, review coding (Hops 3–4).admin123): Revenue Cycle → submit a claim (Hop 5).