Interoperability is a consent problem before it is a data format problem

CTO and Chief Architect, RatnaGlobalTech, LinkedIn profile

A patient walks up to reception and shows an ABHA number. She was treated at another hospital last month and wants her consultation today to see those records. In the radiology room down the corridor, a CT scanner that has never been on the internet is writing studies to a workstation from 2015. Across the wall, the lab’s analyzers speak HL7 version 2 and nothing else. In Texas, a sister product is asking an insurer whether a session is authorized before the clinician walks in.

Four protocols, one platform. This post is about how HealthPlex handles them, and why the hardest part turned out to be consent, not mapping.

Inside, one domain model. At the boundary, projections.

HealthPlex does not store FHIR. It stores a clinical domain model: patient, encounter, order, result, medication, document, consent. The services own that model and change it when the clinical work needs it to change.

FHIR R4 is a projection of that model at the boundary. A versioned mapping layer turns an internal encounter into a FHIR Encounter, an internal result into an Observation or DiagnosticReport, an internal document into a DocumentReference, and back again on the way in. Profile packs select which constraints apply on each edge: ABDM’s NRCeS profiles for the Indian edge, US Core for the American one, tenant-specific profiles where a partner has its own. Every bundle is validated on the way out and on the way in.

The same pattern holds for the other protocols. HL7 v2 ADT, ORM and ORU messages have their own adapter with a message store and replay. X12 270/271 eligibility, 278 prior authorization and 837P/835 claims have theirs. DICOM has the bridge described below. A protocol change lands in the mapping layer. A clinical model change lands in the services. Neither knows about the other.

We arrived at this the hard way. An earlier design stored FHIR resources directly, on the theory that it would make integration free. It made integration expensive. Every clinical feature had to be expressed as FHIR extensions, the UI had to reason about resource references instead of a patient’s chart, and the first partner with a different profile broke the storage layer. Projections cost a mapping. Storage as FHIR costs everything else.

ABDM is a consent architecture with a data format attached

Most interoperability writing treats consent as a checkbox at registration. Under India’s Ayushman Bharat Digital Mission, consent is the protocol.

HealthPlex participates in two roles. As a Health Information Provider it links care contexts to a patient’s ABHA at the end of a visit and serves those records when a valid consent artefact arrives. As a Health Information User it asks for records from other providers on behalf of a clinician who has a reason to see them.

The fetch, step by step:

1. HealthPlex raises a consent request through the ABDM gateway: purpose of use, date range, the types of health information wanted, and who is asking.
2. The Consent Manager notifies the patient in her PHR app. She sees who is asking, for what, and for how long.
3. She approves or denies, and the approval is granular: which providers, which record types.
4. The Consent Manager issues a signed consent artefact with an expiry. HealthPlex stores it and, from that point, enforces it.
5. HealthPlex sends a health information request to the other provider carrying the artefact and an ephemeral public key.
6. The provider validates the artefact, encrypts the FHIR bundle with a key derived through ECDH, and pushes it through the gateway.
7. HealthPlex decrypts, validates the bundle against the NRCeS profiles, and links the care context to the patient’s chart.
8. When the artefact expires or the patient revokes it, further reads are refused and each refusal is logged.

Step 8 is the one that separates a compliant implementation from a demo. The artefact is not a token that unlocks a door once. It is a policy the platform checks on every read, and stops honouring the moment it expires. That check lives in the same policy decision point that evaluates roles and purpose of use for every other request, which is why it could not be bolted on later.

The same consent registry holds 42 CFR Part 2 disclosure consents for substance use records in the United States, and the purpose-bound consents that the DPDP Act requires. Different rules, one registry, one enforcement point.

The DICOM bridge: a small agent for old rooms

Radiology rooms are where cloud platforms go to fail. The modality is on an isolated network. The workstation runs an operating system that no longer receives updates. There is no one on site who can install a build toolchain. The link to the outside world drops twice a week.

The Ratna DICOM Bridge is a small Java agent built for those rooms. It sits beside the modality or the PACS, on hardware the hospital already has, and does four things:

• Serves a Modality Worklist so the scanner picks up the patient and accession number from HealthPlex, instead of a technician retyping them.
• Receives studies over C-STORE, or watches a folder where the PACS drops them.
• Matches each study to its order by accession number, so the report is filed against the order the clinician placed.
• Uploads over TLS to tenant-prefixed object storage and emits a study.received event, then stores and forwards when the link is down.

We built a variant that installs on a decade-old macOS release with no developer tools present, because that was the machine in the room. The requirement is not exotic. It is what a diagnostics centre in a tier-two city actually runs, and a platform that cannot meet it is not a platform for that centre.

Once the study lands, the radiologist reports in HealthPlex, the report becomes a DiagnosticReport on the FHIR edge, and the ordering doctor sees it against the order. The abnormal-result loop described in an earlier post picks it up from there.

Coexistence is the normal case

A hospital rarely replaces everything at once. The lab keeps its LIS. The incumbent HIS keeps registering patients for six months while modules move over. The insurer’s portal is not going anywhere.

So the HL7 v2 adapter does not just receive results. It handles ADT feeds in both directions so the incumbent HIS and HealthPlex agree on who is admitted where. The message store keeps every inbound message for replay, because the day the lab restarts its interface engine and re-sends a week of results is not the day you want to discover your adapter is not idempotent.

On the American edge, the pattern is the same with different payloads. Eligibility is checked at scheduling with a 270/271 exchange. Prior authorization goes out as a 278 and the units come back into the authorization ledger. Claims leave as 837P and remittances return as 835, and the claim status changes flow onto the event backbone where the finance team’s dashboards read them.

Four questions to ask any vendor

Interoperability claims are cheap. These four questions are not.

• Where does the consent artefact live, and what happens on a read after it expires?
• If your internal clinical model changes, which integrations break?
• Show me the study you received on a machine with no internet for six hours.
• Replay yesterday’s HL7 feed. What changed?

If the answers involve a checkbox, a shared database, a cloud-only agent, or duplicated results, the interoperability is a slide.