An overview of NDHM's Technology

National Health Authority (NHA) has been working on a new-age ecosystem for healthcare data for India, one which allows seamless availability and interoperability of Personal Health Records to authorized people, they started designing the new ecosystem network such that data is available always to the patient all the time. Further, patients can choose to share their data with their health care providers securely.

Since the implementation was envisioned to be in a mission mode, the initiative was named, and is currently referred to as the National Digital Health Mission (NDHM). 

NDHM Architecture

NDHM is employing a federated architecture for its ecosystem. That means that management and data access occurs in a federated manner where different entities or systems will manage the health data.
There is no central data storage controlling and storing data.

Using the Federated Health Records Framework (FHR), patients can access and view their health records, and provide consent to any HIPs and HIUs to access their data.

To ensure smooth consented data sharing and time-bound data access, it is necessary to make the data traceable and auditable. Therefore the FHR Framework architecture leverages MeitY's Data Empowerment and Protection Architecture (DEPA) electronic consent framework, which is already being used in the financial sector.

Here are some interesting technical features of the NDHM ecosystem

FHIR for all Medical Data

One of the prevalent problems in the healthcare software landscape is that software providers have their own proprietary data structures and way of dealing with medical data. Despite having various standards available in the industry, very few providers use them correctly. This affects interoperability between systems. That is why it was required that all the systems on the ecosystem use the same standards for medical data so that data is interoperable. This is why the FHIR(Fast Healthcare Interoperability Resources) Specification was chosen as the data exchange format.

Asynchronous APIs

All the APIs(Application Programming Interfaces) of NDHM are asynchronous APIs. That means that you do not get the response of your requests synchronously but the response is sent back to your endpoints as a callback once your request is processed. This is a pretty standard technique in large distributed systems, and its use is expected and welcomed.  As things start moving forwards, more providers will join and the number of transactions will grow exponentially. This model allows them to scale the network easily as we move forward.

It is also important to know that plenty of interactions happen between Health Information providers (HIPs) and each HIP software may handle requests differently. So making the API calls asynchronous, helps manage the variable serving capabilities of different HIP software graciously.

Patient Privacy & Security Features of NDHM

Privacy of the Patient Data is crucial and a lot of people are not comfortable with sharing their personal health data on central servers, especially sharing them with the government without their consent. The model that was adapted for this handles this concern very well. 

Let's see how this is handled to ensure patient privacy is ensured,  and it's the patient who owns the data.

HIPs can only create data if authorized by the Patient:

HIPs cannot create any data against a Health ID without first being authorized by the Patient. HIP obtains an Auth Code from NDHM Gateway by one of the following authorization methods:

• Demographics Verification - Patient Demographics data supplied by HIP matches the Demographics data registered with the Health ID
• Mobile OTP - Patient shares OTP sent to registered mobile number with the given health ID
• Aadhar OTP - Patients shares OTP sent to the mobile number registered to Aadhar No associated with the given health ID
• QR Code Share - Patient has the option to share their health ID by scanning the QR code available to the registration desk and the given HIP receives Patient Information and the Auth Code.

This ensures that no health data against a patient Health ID is being created without the patient’s approval.

An HIU(Health Information User) can only get past health records of other HIPs if consented by Patient

Other HIU's do not get a Patient’s past health records generated by other HIPs without the patient’s consent. If an HIU wishes to receive the past records, HIU needs to generate a Consent request with the following information:

• Types of Health Data (OPConsultation, Prescriptions, Diagnostics Records, Discharge Summary & Immunization)
• The purpose for Requesting Data
• The date range of the data required
• Consent Expiry - On consent expiry, this health data get destroyed from HIU’s system

As soon as this request is generated, the patient is notified about this consent request and he can review the request in the PHR app. The patient will be able to see all the data requested by HIU as mentioned above. Not only can the patient review the data but the patient also has the option to modify the request data( e.g. change consent expiry or type of data he/she wish to share or even change the date range of health records requested). This data is only shared with the HIU if the patient approves the consent request. If he denies the request, HIU does not receive this data.

Not only can patients review these things, but the patient can also decide to prematurely revoke access to any HIU‘s approved requests. If a patient decides to revoke access, the corresponding data will get destroyed from HIU’s system.

This mechanism ensures that patients always have control over their data.

Peer to Peer Data Transfer Between HIP & HIU

As mentioned earlier, a lot of patients are uncomfortable about their private health records being available to and accessed by the government. To avoid this altogether, NDHM never handles the data themselves. The NDHM Gateway only coordinates the connections between HIP and HIU. The actual data transfers happen between HIP & HIU directly and it is effected using a peer-to-peer connection. It does not pass through NDHM, and so there is no way NDHM can access the data.

Data exchange between the HIP & the HIU also happens using encrypted medical records above the standard TLS connection. This adds an additional layer of encryption for medical data.

The ECDH (Elliptic-curve Diffie–Hellman) key agreement protocol is used for this. The HIP & the HIU generate their own pair of public-private keys using curve25519 elliptic curve. This curve provides 128 bits of security for the data being encrypted.

The HIP will use its own private key and the HIU’s public key to compute a session key and encrypt the content using an AES GCM cipher. The HIU can use their private key and the HIP’s public key and compute the session key to decrypt the data. So even if the encrypted data is leaked, no one except these two parties can encrypt/decrypt the data.

Final Thoughts

The NDHM is a wonderful initiative by the government to streamline the healthcare landscape in India today. At this time, all the health data is available as silos within different solutions and systems. It is very difficult, if not impossible, to make the data interoperable between systems. Consequently, it is difficult for patients to access the data across these silos and manage it properly within a system of theirs choice. This project has the ability to revolutionize the industry. This could be the UPI of Healthcare.

It is one thing to have a concept and another thing to implement and execute it. So far NDHM seems to be going in the right direction.  And there is hope that it will continue to do so. 

Technology is being given equal importance to gain the trust of all players involved in this industry.

Privacy and Security have been a prime priority in the project as you can see from the above article, this is an oft-ignored aspect in old projects. Hope it continues to stay this way.

References

https://sandbox.ndhm.gov.in/docs/architecture

https://sandbox.ndhm.gov.in/docs/data_encrypt_decrypt


This blog post has been co-authored by Kishan Gor , Aditya Patkar and Nrip Nihalani