Skip to main content
INTEROPERABILITY
PRANA · 2026
I.HEALTHCARE INTEROPERABILITY INFRASTRUCTURE

Healthcare interoperability infrastructure for India.

Prana is building the interoperability layer that connects hospital management systems to India's national digital health ecosystem. Consent-governed. FHIR-native. Designed for the systems that healthcare actually runs on.

ABDM-alignedConsent-awareFHIR-compatibleInteroperability-first
Architecture diagram showing HMS systems connecting through Prana's interoperability layer to the ABDM digital health ecosystemEXISTING SYSTEMSHospital HMSClinic HMSLab LIMSPharmacy PMSPRANA MIDDLEWAREFHIR TransformConsent EngineData NormalizerEvent BusABDM NETWORKHIP / HIUHIE-CMABHA RegistryENCRYPTED · CONSENT-GATED · AUDITED · FHIR R4 · EVENT-DRIVEN
II.THE FRAGMENTATION PROBLEM
THE CHALLENGE

India has over 1,500 HMS vendors. Most hospitals operate in data silos.

Patient records don't travel between systems. Each HMS stores clinical information in its own format. A discharge summary at one hospital is invisible to the specialist receiving that patient at another. The information exists, but it cannot move.

ABDM creates the national infrastructure for health data exchange. But bridging existing hospital systems to these new standards without forcing hospitals to rebuild what already works requires an integration layer designed for this purpose.

Before and after: fragmented healthcare systems connected through Prana to ABDMCURRENT STATE: FRAGMENTATIONHospital AClinic BLab CPharmacy DHospital E×××WITH PRANA: INTEROPERABILITYHospital AClinic BLab CPharmacy DPranaABDMNetwork
III.WHY INTEROPERABILITY REMAINS DIFFICULT
OPERATIONAL REALITY

Why interoperability remains difficult.

Legacy systems designed for billing, not data exchange

Most HMS systems were built to manage appointments, billing, and internal records. Sharing structured clinical data with external systems was never part of the original design.

No standard data formats across 1,500+ HMS vendors

A prescription in one system looks nothing like a prescription in another. Without a common structure, records cannot move between providers with meaning preserved.

Hospitals cannot pause operations to upgrade

A hospital seeing hundreds of patients daily cannot shut down its HMS for migration. Any path to interoperability must work alongside existing systems, not replace them.

Clinical workflows are high-volume and time-sensitive

Doctors in busy OPDs see over 100 patients a day. Any additional step, however small, multiplied across every encounter becomes a significant operational burden.

Compliance requirements without operational support

ABDM mandates and DPDPA requirements add regulatory surface. Healthcare systems need infrastructure that handles compliance without adding to the daily workload.

Five operational barriers to healthcare interoperability: incompatible formats, no standard exchange, continuous operations, high-volume workflows, and regulatory surfaceINTEROPERABILITY BARRIERSHMS Format Apatient_nm, visit_dtHMS Format Bpt_name, enc_date×1,500+ PROPRIETARY FORMATSHospital AHospital B×NO RECORD TRANSFERHospital OperationsOPD · IPD · BILLING · LAB · PHARMACYCONTINUOUS · CANNOT PAUSE FOR MIGRATIONDaily OPD Volume100+ PATIENTS / DAY × EXTRA STEPS = OPERATIONAL BURDENABDMDPDPANMCCOMPLIANCE SURFACE WITHOUT OPERATIONAL SUPPORT
IV.INTEROPERABILITY INFRASTRUCTURE
PRANA'S ROLE

Healthcare interoperability layer.

Prana operates as the integration layer between existing hospital systems and the ABDM ecosystem. FHIR transformation, consent orchestration, and registry integration, handled as infrastructure so healthcare systems don't have to build it themselves.

Your hospital's existing HMS continues to operate as before. Prana connects alongside it, translating clinical records into interoperable formats, managing consent workflows, and communicating with the ABDM gateway. No rebuilds. No migration.

L1Identity LayerABHA, HPR, HFR registries
L2Consent LayerConsent Manager orchestration
L3Interoperability LayerPrana FHIR transformation
L4Data Exchange LayerEncrypted health record transfer
L5Application LayerHMS, PHR, and clinical systems
V.THE INTEGRATION JOURNEY
HOW IT WORKS

From identity to exchange.

1
Identity
Patient ABHA creation and KYC verification at registration.
2
Linking
Health records organized into care contexts and linked to ABHA identity.
3
Consent
Patient-controlled consent lifecycle governing every data exchange.
4
Exchange
Encrypted FHIR bundles shared between systems under consent governance.
VII.SECURITY & CONSENT INFRASTRUCTURE
GOVERNANCE

Security & consent infrastructure.

Every health data exchange in ABDM begins with patient consent. The consent lifecycle (REQUESTED, GRANTED, DENIED, REVOKED, EXPIRED) creates an auditable governance record. Prana is designed around consent-first architecture, aligned with DPDPA data protection principles.

SEC-01
Consent-Governed Access
Every data exchange begins with explicit patient consent. No access without authorization.
SEC-02
End-to-End Encryption
Health data encrypted in transit using ECDH with Curve25519. Unique nonce per exchange.
SEC-03
Audit Trail
Every consent decision timestamped and traceable. Complete governance record maintained.
SEC-04
Patient Revocation
Patients can revoke access at any time. Consent artefacts scoped to provider and time period.
SEC-05
Data Residency Control
Choose platform-managed or self-managed storage. Full control over data governance.
SEC-06
Standards Compliance
FHIR R4 compliant data structures. ABDM gateway integration following national specifications.
VIII.THE ABDM TRANSITION
NATIONAL INFRASTRUCTURE

India's healthcare infrastructure is entering a new interoperability era.

Ayushman Bharat Digital Mission defines how patient records move between systems , governed by consent, structured by open standards. ABDM establishes a unified ecosystem where patients, hospitals, laboratories, and health applications exchange data securely.

Four foundational registries underpin the system: ABHA for patient identity, HPR for healthcare professionals, HFR for facilities, and a Consent Manager that orchestrates every data exchange. Compliance is structured across four progressive milestones , from identity creation to full ecosystem participation.

ABDM protocol layer stack showing five layers from ABHA Identity to ABDM GatewayPROTOCOL LAYER STACKLAYER-01ABHA Identity LayerPatient digital health identityLAYER-02HFR / HPR Registry LayerFacility & professional registrationLAYER-03Consent Management LayerHIE-CM orchestrationLAYER-04FHIR Data Exchange LayerR4-compliant record bundlesLAYER-05ABDM GatewayEncrypted routing & delivery
IX.CURRENT FOCUS
WHERE WE ARE

Current focus.

Prana is currently focused on building interoperability infrastructure for India's healthcare ecosystem: the systems, standards, and integration architecture that reliable health data exchange requires.

  • Interoperability architecture and systems design
  • Healthcare workflow research across Indian hospital operations
  • FHIR transformation pipeline development
  • Consent orchestration and governance design
  • ABDM ecosystem integration and standards alignment
X.CONNECT

Building healthcare systems in India? Let's talk.

Whether you are a hospital navigating ABDM compliance, an HMS vendor enabling interoperability for your clients, or a health platform exploring integration, we are building the infrastructure layer designed for your systems.