Green dot = the service answered just now. Click a tile to jump straight into that layer. OpenSeva is many small services on purpose — a student should see each one, not a single black box.
./run.sh start,
seed demo data with ./run.sh seed, then reload this page. The dots re-check every 5 seconds.
| Two ways to travel | What it gives you |
|---|---|
| By hand (this page) | Play each persona in the real UI. Every act tells you exactly who to log in as, what to click, the FHIR resource it creates, and where money is saved. |
| Automated (script) | Run ./journey-test.sh from the repo root. It performs
the same 7 acts headlessly and asserts every dollar of the EOB is correct across the paid, downcoded
and rejected branches. This is what guarantees the walkthrough is accurate — not just a story. |
Appointment is created and linked to the patient.
Coverage = the record on file ("what plan does the patient
have?"). The button sends a CoverageEligibilityRequest to the payer, which writes a
CoverageEligibilityResponse ("is it active right now, and what are the benefits?") — the
270/271 transaction. Both live in the same FHIR DB.
patient-baddata) and click Check eligibility. Her coverage is cancelled, so the check
returns Inactive — a registration data error caught at the desk instead of becoming a denied claim later.Encounter, an Observation (the note / vitals),
and a MedicationRequest (Rx).
Observation + the MedicationRequest; there is no full
lab/pharmacy workflow.)Observation (the result) and the MedicationRequest from Act 3.
Claim (id claim-<encounterId>) is built from the accepted codes +
the patient's Coverage, then POSTed to the Payer App.
ClaimResponse — this is the Explanation of Benefits (EOB). It
carries the outcome plus the money: billed → allowed → plan pays → deductible + copay = patient responsibility.
| Outcome | Why (in this simulation) | Example money (BlueShield 85% / $25 copay) |
|---|---|---|
| Paid | Clean claim, documentation supports the code | allowed $180 → plan $128 + patient $52 |
| Downcoded | High-complexity code, thin note → level reduced | billed $300 → allowed $180 → plan $128 + patient $52 |
| Denied | Service excluded by the plan, or fraud score over the block threshold | plan $0 |
| Rejected | Missing required data (e.g. no diagnosis) — fails intake | never priced |
PaymentReconciliation (id copay-payment-<encounterId>) records the
copay and links back to the ClaimResponse it settles.
Everything above is backed by a script that runs the same journey headlessly and checks every number. From the repo root:
./journey-test.sh
It runs three patients — a paid, a downcoded and a rejected claim — creates every
FHIR resource, submits to the live Payer App, reads the EOB back from the FHIR DB, asserts the math
(e.g. allowed $180 − $0 deductible ×0.85 − $25 copay = plan $128 / patient $52), records the copay,
and prints PASS / FAIL. If it's green, the walkthrough you just did is accurate to the penny.
Role access mirrors a real EMR — the revenue cycle splits into a front end (reception) and a back office (billing/admin + providers).
| Role | Sees | Does not see |
|---|---|---|
| Patient | Own chart, book appointment, own insurance | Coding, claims, other patients |
| Receptionist | Patients, scheduling, Insurance/eligibility tab (front-end revenue cycle) | Revenue Cycle back office (coding, claims, adjudication) |
| Doctor / Provider | Clinical chart, encounters, Coding Review + claim status for their visits | Final claim submission, simulation config |
| Admin (Billing) | Everything — full Revenue Cycle: code, bill, submit, configure | — |
| Stage | Building block (FHIR / service) | Where cost is saved |
|---|---|---|
| Booking | Appointment | Self-service scheduling → less admin labor; fewer no-shows with reminders |
| Insurance | Coverage, Organization, CoverageEligibilityResponse | Real-time eligibility up front → far fewer denied claims; catches bad data early |
| Visit | Encounter, Observation | Good documentation → protects the billed level; avoids appeals |
| Lab / Rx | Observation (lab), MedicationRequest | Generics + no duplicate tests → direct spend reduction |
| Billing | Claim · Biller/Clearinghouse | Clean-claim-first-time → no rework loops |
| Adjudication | ClaimResponse (EOB) · Payer + Integrity API | Downcoding + fraud screen + plan rules → payer cost control |
| Payment | PaymentReconciliation | Price transparency → no surprise bills, faster collection |