Architecture direction.
This page describes how we think about healthcare interoperability infrastructure: the design principles, architectural choices, and integration philosophy that guide Prana. This is direction, not documentation. We are sharing our thinking openly while the system is being built.
Why data movement is the design center.
A patient is discharged from a district hospital. Their discharge summary needs to reach the specialist they've been referred to at a different facility, using a different HMS, possibly in a different city.
For this to work reliably, the infrastructure must be designed around data movement between systems, not data storage within them. The discharge summary must be structured in a format the receiving system understands, shared only with the patient's consent, and traceable at every step.
This is the foundational design principle: healthcare interoperability infrastructure exists to ensure that health information can move reliably across systems when it needs to, governed by patient consent, structured by open standards.
Making health records portable.
A hospital stores patient records in its HMS: prescriptions, discharge summaries, lab orders. Another hospital uses a completely different system with different field names, different structures, different assumptions. How does information move between them?
The answer is a common language: FHIR R4. Prana's transformation pipeline takes proprietary HMS data and converts it into FHIR-compliant health records that any ABDM-connected system can read. This is not a one-time migration. It happens continuously, for every clinical encounter.
The challenge: over 1,500 HMS vendors, each with unique data models. Clinical nuance often lives in unstructured fields. The transformation layer must understand the source, map it accurately, and produce valid FHIR bundles without losing clinical meaning.
In practical terms: when a doctor completes an OPD consultation in their HMS, the transformation pipeline produces a FHIR Bundle containing the consultation record, structured, validated, and ready for consent-governed sharing through ABDM.
Who decides what gets shared.
A patient visits three hospitals over two years. Each holds different records: prescriptions, lab results, imaging reports. A new specialist needs access to relevant history. Who decides what gets shared, with whom, and for how long?
The patient decides. In ABDM, consent is not a checkbox. It is a state machine that governs every data movement. Each consent artifact specifies which records, from which providers, for what purpose, within what time window. Patients can revoke access at any point.
For infrastructure, this means consent cannot be an afterthought. Every component must respect consent boundaries: data transformation, storage, exchange, and audit trail all operate within consent governance.
Why healthcare needs event-driven systems.
A patient is referred from a district hospital to a tertiary care center. The referring doctor needs confirmation of receipt. The insurance system needs to authorize the referral. The receiving hospital needs the patient's relevant history. Multiple systems need to know, at different times, in different formats.
Point-to-point API calls cannot handle this. Healthcare workflows involve multiple parties, asynchronous processes, and long-running operations that may take hours or days to complete. An event-driven architecture allows each system to react to relevant events without tight coupling.
When a patient is discharged, that single event may trigger a care context link, notify the referring provider, update the patient's health record, and initiate a claims workflow, each handled independently by the relevant system.
Connecting existing systems without requiring rebuilds.
A hospital has used its HMS for eight years. Fifty thousand patient records. Hundreds of staff trained on the system. They cannot switch to a new HMS to become interoperable. The operational disruption would be unacceptable.
Prana's approach: connect alongside existing systems. Each HMS type gets an adapter that understands its data model and can extract clinical information in the format that system uses. The hospital's daily workflow stays unchanged. The interoperability surface appears without disrupting operations.
This is the integration philosophy: meet healthcare systems where they are. Don't ask hospitals to change what works. Build infrastructure that makes their existing systems interoperable.
Building in healthcare infrastructure?.
If you are developing healthcare systems, HMS platforms, or health technology in India, we are interested in your perspective on interoperability challenges.