The clinical record
FHIR is how it is stored, not how it is exported
Most systems keep clinical data in a private shape and rebuild a standard one on the way out, which is why exchange is always the part that breaks. Here the canonical FHIR R4 resource is what sits in the database, and everything else — the workspaces, the claims, the exchange surface, the agents — is a reader of it.
Seven stages
Every stage has a rule that fails loudly
A clinical system described by what it supports tells you nothing — every one of them supports everything. Described by what it refuses to do, it tells you where it will break and how you will find out.
- 01
Identify
A merge is reversible, and both directions are on the ledger
Patient matching is a jurisdiction adapter rather than one global algorithm: weighted demographic matching where there is no national identifier to lean on, and a deterministic key where there is. A merge and an unmerge each write an event carrying who did it and on what evidence, because a wrong merge puts two people’s histories in one chart and the only safe version of that mistake is one you can walk back.
- 02
Schedule
A slot cannot double-book
Appointments sit on FHIR slots with the constraint enforced where the booking is written rather than in the screen that offers the times. Check-in is what opens the ambulatory encounter, so the clinical record starts from the operational event instead of being opened by hand and reconciled later.
- 03
Admit
A bed comes from a rules engine, never from a suggestion
Wards and beds are a location hierarchy, and admission, transfer and discharge each move the patient through it against deterministic assignment rules. Every assignment is written to a ledger, so census is derived from recorded events rather than recomputed by a query that has drifted from what actually happened.
- 04
Document
A draft is not the chart
Notes are compositions with structured templates behind them, and the problem list, allergies and the core data set are first-class resources rather than free text somebody will have to parse later. Anything an agent produced lives outside the record until it is signed — the draft store is a different table, not a flag on the same row.
- 05
Order
A result belongs to the order that asked for it
Computerised order entry produces a service request; the result comes back as an observation, a diagnostic report or a pointer to an imaging study, bound to the order rather than filed loose against the patient. Results project into the encounter bundle, so the document a clinician assembles is the same data the ordering trail already holds.
- 06
Dispense
Safety checks hard-block, and they are not model output
The formulary carries the drug identifiers and the controlled-substance schedule; inventory carries lot and expiry and dispenses oldest-expiring-first; the interaction, allergy and dose-range engine is deterministic and blocks rather than warns. Refills honour the controlled-substance schedule, so the ones that may never be refilled never are. The medication administration record and reconciliation sit on the same data.
- 07
Bill and exchange
One charge, from the encounter that produced it
Charge capture is a deterministic rule engine over the encounter — item and package tariffs, pharmacy charges rolled into the same invoice, no double-invoicing. Coverage, claims and prior authorisation are adapters, so the same clinical event becomes an X12 claim in one jurisdiction and a national-exchange claim in another without the core knowing which.
Storage
What “stored FHIR-shaped” actually means
A standard you serialise into on the way out is a translation layer with a deadline. A standard you store in is a constraint you live with every day, which is the point.
The resource is the payload
Each clinical row carries the canonical FHIR R4 resource as its body. That is the record — not a derived view of one, and not a nightly rebuild of one.
Typed columns index the questions
The columns beside the payload exist because the application queries them. They are an index over the resource rather than a second, competing copy of the truth.
Validation is an adapter
The same encounter validates against the US core profiles in one facility and the Indian ones in another. Which profile applies is a property of the tenant, not a branch in the code that writes the row.
Every row is scoped and stamped
Facility and jurisdiction sit on every clinical table, applied by a shared mixin rather than remembered per model, alongside created and updated timestamps. A table that forgets the scope is the one that leaks.
Coverage
Six domains, one encounter underneath
A hospital platform that covers the clinic but not the ward, or the ward but not the pharmacy, moves the integration problem rather than solving it. These sit on one clinical model, which is what makes the revenue cycle able to read what the clinician actually did.
Clinical core
Registration, matching, scheduling, ambulatory and inpatient encounters, notes, problems, allergies and discharge.
Orders and results
Order entry through to observations, reports and imaging pointers, with results bound to the request that produced them.
Pharmacy
Formulary, inventory with lot and expiry, dispensing, the administration record, e-prescribing, reconciliation and retail point of sale.
Revenue cycle
Charge capture, invoicing, coverage, claims, prior authorisation, denials and charge-integrity checking before a bill goes out.
Exchange
Patient and population access, bulk export of the record, and the national exchange paths on the Indian side.
Engagement
The patient portal, consent-aware messaging, inbound referral routing and video visits that open a real encounter.
How it is built
Four decisions, and why they are the way they are
One migration path, no schema by side effect
Migrations are the only source of schema. Nothing creates a table on start-up, so the database in front of you is the one described by the migration history rather than by whichever model happened to import first. A deployment applies the migrations and then serves.
Queries live in one layer
Every database query sits in a repository. Routers do HTTP, controllers shape, services hold the business logic and the adapters, repositories query and return objects. The value of that discipline is not tidiness — it is that facility scoping has exactly one place it can be forgotten, so it is enforced there.
Country logic only behind adapters
There is no country conditional in the clinical core. Every jurisdictional concern is an interface with an implementation per country, resolved from the tenant. A third jurisdiction is a new implementation of a known set of interfaces rather than a search for every place the second one leaked.
Clinical rules frozen by snapshot
The deterministic engines — interactions, dosing, charge maths, bed assignment — are locked by golden tests holding their outputs. A change to a rule has to change a snapshot deliberately, so it is visible in review rather than discovered in a ward.
Enforced, not documented
The rules the build refuses to let you break
An engineering standard that lives in a document is a preference. These are checked by the pipeline, which is the difference between a rule and an intention.
- The layering guard runs in continuous integration: a query written outside a repository fails the build rather than being caught in review, or not.
- Facility and jurisdiction scoping is a dependency every clinical request passes through, so a new endpoint inherits it instead of remembering it.
- Contract tests freeze behaviour at the boundaries, and golden snapshots freeze the clinical, pharmacy and billing rule outputs.
- The sign-off boundary has its own tests, including one asserting that a rejected draft is absent from the assembled record — not hidden from a view, absent.
Integration
The standard surface is the surface
Exchange is not a module bolted to the side of this. The record is already in the shape the standards expect, so the interoperability requirements are read off the same data the clinicians are writing.
- Patient and population access over the clinical record, and bulk export of the electronic health information rather than a report that approximates it.
- Identity by token verification only — the platform validates a scoped token and never issues one, so there is no second credential system to keep in step.
- Payer-facing paths as adapters: the American claims and prior-authorisation formats in one jurisdiction, the national exchange and public-scheme pre-authorisation in the other.
- The agent seam is a durable queue with confirmed delivery, so work submitted by an integration is the same work a clinician’s click submits.
Tell us which stage is wrong
Seven stages written by people who read the domain carefully and have not run your wards. If one of them would not survive contact with your service, that is worth more to us than a signup.
Get in touch
Talk to the people building it
No chatbot and no ticket queue. Tell us what your hospital or practice actually looks like — how many beds, which departments, what the doctors are doing twice, what your billing team keeps chasing — and someone who works on the software will reply.
info@legosphere.com