On July 6, the NITI Aayog released a proposal for the National Health Stack (NHS) which is envisioned as a digital infrastructure meant to serve as the backbone of the two-component Ayushman Bharat Scheme, as announced in the Union Budget 2017-18. NHS will set up a holistic electronic system for beneficiaries, doctors, hospitals, and insurance companies from the private and public sector alike.
Ayushman Bharat’s first component is setting up of 1.5 lakh health and wellness centres to deliver primary healthcare in the country. The second component is the National Health Protection Scheme (also being called Pradhan Matrix – Rashtriya Swasthya Suraksha Mission) to provide an annual health insurance cover of Rs. 5 lakh per family to 10 crore families, or 50 crore people. The NHS will be “built for NHPS but designed beyond NHPS” to enable development of “diverse solutions in health and their adoption by states.”
National Health Stack is a collection of cloud-based services. Each service provides just one capability across multiple health services, “accessible via simple open APIs compatible with global standards.” It is designed “to leverage India Stack”. According to the proposal, data collected through the NHS “will not only allow policy makers to experiment with policies, detect fraud in health insurance, measure outcomes and move towards smart policy making.”
1. Components, design and scope of the National Health Stack
- Five key components:
–National Health Electronic Registries: will create a single source of data for both beneficiaries and provider, incorporating existing registries, and overcome data duplication and redundancy
–Coverage and Claims platform: Meant to support expansion of NHPS via claims engines and fraud detection service;
–Federated Personal Health Records (PHR) Framework: to make health profiles of individuals for own access and for “medical research”;
–National Health Analytics Platform: to provide anonymised and aggregated health data for targeted policy-making, “for instance, through improved predictive analytics”;
–Other horizontal Components: includes among other things creation of a unique Digital Health ID, Health Data Dictionaries and Supply Chain Management for Drugs, payment gateways, etc.
- Built on two “layers”
-National Health Registries Layer – forms the base of the Stack and includes services to manage the data for all health programs and
-Software services and platforms Layer – additional software built on the registry for “operationalizing programs.” It includes a Coverage and Claims Platform, a Federated Personal Health Records (PHR) Framework and a National Health Analytics Framework (NHAF) amongst others.
“Induction of Private Hospitals and Private Practitioners into the Primary and Secondary healthcare ecosystem; Focus on Non-Communicable Diseases (NCD); Disease Surveillance; Health Schemes Management Systems; Nutrition Management; School Health Schemes; Emergency Management; e-Learning Platform for health, LMS, Telehealth, Tele-radiology; Diagnostic Equipment; Health Call Centre(s) etc.”
2. Designing the National Electronic Health Registry
- Provider Registry
The provider registry will build and manage data for all healthcare providers i.e. public and private hospitals, clinics, diagnostic labs and other clinical establishments.
-Incorporation of existing provider registries: existing registries such as National Health Resource Repository (NHRR) and the Registry of Hospitals in Network of Insurance (ROHINI) will be able to publish provider information securely to the NHS registry, on a per-provider basis or in bulk.
-The registry will provide self-maintainability, non-repudiability and consented access of data.
-Validation of providers: a surveyor will be tasked with physically visiting providers and validating registry data; “interfaces for surveyors and data validators will be defined and their role scoped out in detail.”
- Beneficiary Registry
-Suggests Aadhaar-linked registration of beneficiaries, for the creation of a Health ID to enable a “holistic view of the different programs that beneficiaries participate in” and to search any details of a beneficiary.
-Will capture and store important beneficiary-to-beneficiary linkages e.g, information about a beneficiary’s family will be available from the record corresponding to that beneficiary.
-Specifies that the NHS registry “will not assign any group IDs (e.g., family IDs) to beneficiaries although such attributes may be added by individual NHS applications.”
3. Claims and Coverage Platform
This consists of three sub-components: a policy engine, a claims engine, and a fraud management service.
- Policy Engine
a. Unified Multi-Policy View: will provide beneficiaries with a unified view of all the health insurance policies they have purchased, government-funded or from private insurance companies.
b. Policy Markup Language: “a machine-readable language designed for describing, updating, accessing and communicating policies between software programs.” It will have to consist of essential information typically required from any health insurance policy: list of empanelled hospitals, list of procedures covered, costs for each procedure, and so on.-Health insurance policies have to be uploaded and validated in the repository with a digital signature, linked to the entity that is providing the coverage (e.g., insurance company or a health trust set up by the state). Policies will be activated when premiums are transferred to the insurance company/trust.
–Suggests use of blockchain to process claims:
“There could be a possibility for policies to be developed based on Smart Contracts, a derivative of Blockchain Technology. Smart contracts will enable policies to have intelligence embedded in them, which will allow each policy to directly interact with the Claims Engine (or other parts of the Stack). So, for example, policies would automatically be able to trigger insurance payments once certain conditions in the claims process are met.”
- Claims Engine
The Claims Engine will manage the way claims flow in health insurance schemes and ensure ease of filing and settling claims, it will:
1. Ensure auto-adjudication of claims: automates the claims process via a machine-readable description of policies, to speed up claims processing
2. Orchestrate the payment flow: it will send payment triggers and notifications to ensure that Service Level Agreements (SLAs) are adhered to and claims processing times are accurately reported to the authorities.
3. Provide data points: will serve as a data-bank to which will be a key input to the Fraud Management Service (FMS).
4. Receive requests for audit: claims engine may also receive requests for audit on past claims from the FMS. In such situations, claims would be re-assessed and the resulting analyses provided back to the FMS. With better data, suspicious claims can be detected and analysed in this manner.
- Fraud Management Services:
“Engines will be incentivized to report fraud events and will compete with each other in the process. This approach will boost the rates of true positives as well as the rate of true negatives in fraud detection. The data feed into the fraud management system will be anonymized to protect patient and provider privacy.”
-When a fraud is reported, all pending claim settlements and any new claim settlements for a hospital are placed on hold until the fraud raised can be investigated.
-Personal Health Records (PHR) are a core requirement to avoid fraud and bring greater trust into the claim handling process, as most fraud is based upon either unwanted or redundant tests and procedures, or claims made by patients/providers on false procedures.
4. Creation of Digital Health ID
-It will create a unique system-wide identifier called the Digital Health ID for each user, possibly Aadhaar-based although the document says others such as PAN Card, Election ID can be used as well, followed by a KYC process
-Allows for creation of Virtual Health ID to “preserve users’ privacy when interacting with other users or stakeholders in the system.”
–Suggests Aadhaar Authentication in lieu of Health ID: “The Health ID may also be looked up in a secure manner if the beneficiary does not have her identifier handy. For example-a beneficiary visiting a provider, in the absence of NHS Health ID, may authenticate against Aadhaar.”
5. Federated Personal Health Records (PHR)
Personal Health Records (PHR) has been defined as an “integrated view” of all data related to an individual across various health providers comprising of “medical history, medication and allergies, immunization status, laboratory test results, radiology images, vital signs, personal stats, demographics and billing information, and multiple health apps.” PHR will paint a “complete picture of the patient.”
–Suggests a framework for protection of medical data: “PHR is maintained in a secure and private environment, with the individual determining rights of access. This will be made possible through Health Data Fiduciaries (trustees) that shall facilitate consent-driven interaction between those that generate the health data and those who use PHR data.
-“the federated structure of PHRs (with pre-authorizations built in) can facilitate the access to this valuable data in a consented manner for the purposes of medical research.”
6. National Health Analytics Framework
A framework to enable the use of anonymised and aggregated data to “present the overall direction of health of the country/state/district leading to data-driven decisions and targeted policymaking” in alignment with the National Data Sharing & Accessibility Policy (NDSAP). Data collected will be statistics such as an average number of patients treated in a day, epidemiological data, the percentage of claims accepted/rejected, the average time of claim settlement, years of experience of doctors, and so on.
-Will provide for “horizontal expansibility” with the potential to cover “disease surveillance, predicting epidemics, classifying and clustering population segments for proactive care, nutrition, health schemes, and national health infrastructures such as telemedicine, teleradiology, and the enhancement of process controls.
-Can provide insights into the healthcare workers’ shortage at various governance levels and “enable the implementation of skill development initiatives at a very granular level (for instance, through ASHA workers).”
Some notable guidelines for NHS:
- Mandated PHR: Every citizen has a right to not just her/his health data but also right to access to structured data. All service provider EHRs and stand-alone PHRs which include wearables, mHealth devices and health apps etc should have APIs compatible to NHS PHR.
- Separating the consent layer from data flow: Patients may consent to archive their data in meta-directories that will then allow (or restrict) automated access for clinical, research, quality improvement, or marketing purposes. The document also states that this guideline has been incorporated into India Stack.
- Open APIs: NHS must be built using open standards, absent dependence on specific platforms or software frameworks to ensure interoperability.
- Privacy and security “by design”: Mandates use of APIs to “ensure centralised management of security controls.” NHS will disseminate data to “authenticated and authorised stakeholders only.” User consent is guided by the MeitY Electronic Consent Framework.
- Strong data governance: Data about any individual (patient, doctor, etc) in the system must be under the control of that individual, using the MeitY Electronic Consent Framework. The entity holding the data “must first obtain legitimate consent from that individual before sharing the data or processing it in other ways.”