Here’s a complete summary of the blueprint:

1. The committee and its members

The committee was chaired by J. Satyanarayana, former UIDAI Chairman and former MeitY secretary, its other members were:

  1. Director of eHealth, Ministry of Health, Convenor
  2. Sanjeeva Kumar, Additional Secretary, Ministry of Health
  3. Special Chief Secretary for Health, Government of Andhra Pradesh
  4. Additional Chief Secretary for Health, Government of Madhya Pradesh
  5. M. S. Rao, lAS, President & CEO, National e-Governance Division
  6. Alok Kumar, Advisor for Health, NlTl Aayog
  7. Lav Agarwal, Joint Secretary for eHealth, Ministry of Health
  8. Nominee of Secretary, MeitY
  9. Nominee of CEO, National Health Agency, Ministry of Health
  10. Dr. Neeta Verma, Director-General, National Informatics Centre
  11. Gaur Sunder, Joint Director, Centre for Development of Advanced Computing (C-DAC), Pune
  12. Dr Pallab Saha, Chief Architect, The Open Group (Co-opted by the Chairman)
  13. Dr Manoj Singh, Professor, AIIMS (Co-opted by the Chairman)

The blueprint constituted subgroups to deal with its four mandates, the sub-groups relate to:

  1. Scope of NDHB, Overarching Principles and Target Digital Services
  2. Building Blocks of NDHB, including Universal Health Id
  3. Standards and Regulations, and
  4. Institutional Framework

Here’s details on the sub-groups:

2. Objectives of the Blueprint

  1. Establishing and managing core health data, and the infrastructure for its exchange
  2. Establishing National and Regional Registries to create “Single Source of Truth”
    relating to clinical establishments, healthcare professionals and health and pharmacies;
  3. Adopt open standards
  4. To create Personal Health Records based on international standards, which are easily accessible to citizens and services providers, based on consent
  5. To promote enterprise-class health application keeping in mind Sustainable Development Goals related to health
  6. To ensure private sector participation
  7. To ensure national portability in the provision of health services;
  8. To promote the use of Clinical Decision Support (CDS) Systems by health
    professionals and practitioners;
  9. To leverage health data analytics and medical research for better management of the health sector
  10. To enhance Governance digital tools in the area of Performance Management.
  11. To support steps taken for ensuring quality of healthcare.

3. Building blocks

The NDHM document lays out 5 horizontal and 2 vertical building blocks for implementing the document. The Government Community Cloud infrastructure defined by MeitY should be adopted for implementation of building blocks in Layer 2 and Layer 3. A hybrid cloud environment is recommended for other layers.

Layer 1: Infrastructure

1. Secure Health Networks:

  • Blueprint should be built to work on public networks by default.
  • Secure connectivity like MPLS or VPN may be used wherever access to sensitive or aggregated data is involve
  • High bandwidth network systems may be specially designed for applications like tele-health, tele-radiology that require strong data links to systems like PACS low latency

2. Health Clouds builds on the MeitY initiative of Government Community Cloud (GCC) with stronger security and privacy policies and infrastructure, key data hub management services must be on it.

3. Security & Privacy Operations Centre: All events on the Health-Cloud and the Health Network need to be under 24×7 security surveillance ensuring “every data byte is highly secure”.

  • This will be done via a Security Operations Centre (SOC), the Committee recommends setting up a dedicated Privacy Operations Centre (POC) to drive compliance on privacy requirements.
  • POC will monitor access to private data, review consent artefacts, audit services for privacy compliance, etc.

Layer 2: Data Hubs

1. Personal Health Identifier (PHI):

The PHI system must collect demographic and location information, family/relationship information, and contact details. FHIR specification must be followed; contact info can be updated easily as India has a large churn in mobile numbers. Further elaborating in a later section, the blueprint says that “uniqueness is a key attribute of PHI” and the algorithm that issues a PHI must try to return the same identifier for the individual in all cases. It continues:

“While Aadhaar assures uniqueness of identity and provides an online mechanism for authentication, it cannot be used in every health context as per the applicable Regulations,” the PHI design must allow for multiple identifiers for the design the structures and processes relating to PHI.

The Committee recommends that the design of the PHI may be finalized by the Ministry of Health, in consultation with MeitY and UIDAI after taking into consideration the “regulatory, technological and operational aspects”. The Committee suggests the following preliminary mechanisms for identification of persons:

2. Personal Health Record (PHR): A federated system with multiple players working on a interoperable standard for sharing of health data is preferred.

  • PHR content should allow for evolution, from basic content with very little metadata to a strongly structured content that meets the standards laid out in the blueprint.
  • PHR will capture data only relating to significant medical and health episodes and events of types to be identified and notified. Digilocker design should be adopted with modifications.

3. Health master directories: will hold the master data of various entities. Directories must serve as “single source of truth” and must be designed to be easily accessed and used from multiple users of the NDHB. Health apps must be able to verify a doctor using the registry and allow them to add or view authorized records.

Layer 3: Technology Building Blocks

1. Anonymizer: takes data from health locker and other health data sets and removes PII (Peronally Identifiable Information) for both structured and unstructured data. This will help government and agencies to access health records, especially for monitoring of notified diseases etc. There are two levels of delinking: deidentification and anonymisation.

  • Deidentification is reversible, whereby re-identification by the competent authority is possible.
  • Anonymization, on the other hand, is a one-way process, whereby the data once anonymized, cannot be related to any person subsequently.

2. Consent manager: electronic consent framework specifications notified by MeitY should be used to develop information sharing defined in the blueprint.

  • The goal of the Consent Management Framework and Consent Manager should be to ensure the citizen/patient, the Data Principal, should be in complete control of what data is collected, how and with whom its shared, and why and how its processed.

3. Health locker: is a standards-based interoperabilty specification which can be used by multiple players to create a PHR system.

  • Small clinics and hospitals can subscribe to the authorized repository providers to participate in the system.
  • This will health records over a period of time and provide access to those who need it.

4. Health information exchange: Real-time data exchange needs to be enabled via Open APIs and other mechanisms, says the blueprint. Each access application to submit, retrieve, access information needs to be registered with the HIE, which will authenticate and authorize all data exchange requests, and will also route the request to the providing applications.

5. Heath analytics: will provide decision support to stakeholders on multiple “themes”, like quality of care and quality of data, by analysing aggregated data from providers.

  • The blueprint design must ensure that analytics data is collected or created at the source i.e. when a medical record is being prepared for the PHR.
  • Analytics data can be aggregated using either a subscription model or a push model where the data is sent mandatorily to one or more government-controlled analytics systems.

6. Visualization: can be used to answer queries like nearest hospitals, plotting of disease incidence, it will help in regional planning and monitoring of health services.

Layer 4: Application building blocks

The above three layers will provide open APIs for use by private and public health apps.

  • Public/Government Apps: Reproductive and Child Health (RCH), NIKSHAY (Online TB Patients monitoring application), e-Raktkosh, Health Management Information System (HMIS), among others. Telemedicine should be given a high priority given the low Doctor-Population ratio, especially in rural [areas].
  • Private health apps: Hospital Management System applications, claims applications currently being used by service providers. Open Source Products may be promoted for the sharing of real-time patient data among the members of the medical/surgical/nursing teams for delivery of tertiary care

Layer 5: Access and Delivery

This layer includes call centres, India Health Portal, Social Media, MyHealthApps

Layer 6 – National Health Standards (Vertical Layer)

Governance, Strategic Control, Data Security, Privacy and Compliance to Standards would be one of the key verticals that cut across all building blocks of the Blueprint (more on this below).

Layer 7 – Command, Control and Communication Centre (CCCC) (Vertical Layer)

The goal of the CCCC is to provide a single point of contact in to manage public health emergencies. It consists of a response team and can also constantly monitor disease surveillance and outbreak response.

  • Health data coming into the NDHB should be used to monitor for various diseases working closely with the existing programs of MoHFW and the States.
  • The CCCC will consume information from all other components, will run analytics, and generate alerts and visualizations. It shall also deploy artificial intelligence and machine learning.

4. Disease Registries Structure for non-communicable diseases

They will largely be based on information gathered in screening and in hospitals. The blueprint indicates that registries are currently not linked, such as the one maintained by ICMR, and need to be interoperable and integrated. This is the structure of recommended registries. This shows the generic structure of recommended registries:

5. Harmonising current facility registry initiatives

There is need to uniquely identify health facilities and ensure that health data is can be traced to the facility to ensure traceability, accountability and reliability of the health information. After comparative analysis of ongoing initiatives for creation of facility registries, such as ROHINI, PMJAY, NHRR (National Health Resource Repository), the Committee has recommended that:

  1. National Health Resources Repository (NHRR) complimented with National Identification Number (NIN) shall be used as the main facility registry
  2. Incentive driven governance mechanisms need to be designed to ensure that facility registries are updated and made available for integration with health systems
  3. The format of the facility identifier being used by NHRR may be reviewed and enhanced considering the need for it to interoperate with other identifiers like NIN and ROHINI
  4. The format and structure of the identifier should be designed such that it does not allow deciphering of any information offline.

6. Standards

The blueprint says that the Building blocks need to work in unison to realise the vision of the NDHB, or in other words need to be interoperable. Since adoption of standards in health sector is a slow process, the blueprint recommends a set of “minimum viable standards” in the initial stages. The NDHB document depicts the areas to define the standards, and subsequently (below) lays out its recommendations for the standards:

  1. Consent – for data capture and data use
  2. Consent and interoperability – standards related to exchange of healthcare data.
  3. Privacy & Security: Standards related to data privacy (through access control) and Security of data at-rest and at-motion. Also, it addresses aspects such as data immutability and non-repudiation with audit trail.
  4. Patient Safety & Data Quality – Standards related to ensuring patient safety while collecting data and quality of data captured.

Recommended Standards

1. For consent management

The above standards should be applied in way consistent with the IT Act 2000, rules and directions around patient consent and privacy from the Medical Council of India and state medical councils.

2. Standards for content and interoperability

Since the NDHE will be consolidating/linking health records generated in national and state government programs, private hospitals, labs, and others, the interoperability standards should support major clinical artefacts used globally. The standards should support integration of systems on different tech and different platforms, and should also be agnostic and to underlying infrastructure. Interoperability in the context of digital health, is of two types, namely, Technical Interoperability and Semantic & Syntactic Interoperability.

i. Technical interoperability: Interoperability Standards defined by IndEA Framework shall be adopted by all systems comprising the NDHE. The blueprint recommends that this should be a mandatory requirement for regisration of entities in the system.

Blueprint recommends a federated architecture for collecting and storing health information. Core datasets like the various registries would be managed centrally, but the bulk of the information i.e. health records would be maintained at regional centres or by service providers. The Central Repository of NDHB shall support only records conforming to standardized formats of content.

ii. Semantic & Syntactic Interoperability (Content): FHIR Release 4 should be adopted for all health related information sharing/ exchange – FHIR R4 is the latest standards for exchanging health information, is built upon the HL7 standards, and is considerably rationalized and simplified. For quick implementation, a small but necessary set of health record artefacts shall be taken up first. Other artefacts may be taken up in phased manner to ensure early roll-out, easy adherence by implementers (source of data/record), and to enable spreading of the associated costs over a period of time.

4. Content and Interoperability Standarda

Apart from standards for content, it is necessary to define the standards required in the major areas of healthcare, namely, diagnostic content, terminology and codes for statistics and laboratory tests:

5. Standards of privacy and security

To ensure that data is reliable and verifiable, the following guidelines should be followed, and also provisions, guidelines, standards prescribed in EHR Standards for India 2016 should be incorporated.

6. Standards for Patient Safety & Data Quality

Electronic equipement used in the system should be safe against safety hazards like electric shock, harmful radiation, excessive temperature, implosion, mechanical instability and fire. Bureau of Indian Standards (BIS) has published 38 standards in this area, these are either an adoption or technical equivalent of the related IEC standard. Work on some additional standards is ongoing in IEC/TC 62. At present, the certification against these safety standards is not mandatory in India. Keeping importance of safety of such equipment, safety certification of the equipment may be made mandatory for participation in NDHE.

7. Cost of Standards

All the proposed standards, apart from FHIR, are already a part of the EHR Standards of India 2016 notification. ISO/BIS standards are already available and others are open specifications from respective bodies. Use of SNOMED CT is free since India is a member country. The cost of implementation of standards will be spread on two sides; Repositories must support all the proposed standards, and source repositories will have to implement the content interoperability, terminology/codes, and transmission standards. Implementation can be facilitated by a standards support agency to be created by Ministry of Health and MeitY.

7. Enablers of NDHB

  1. MDDS & EHR Standards for India 2016
  2. Hub and Spoke model: This modeal may role an important role in designing the components of NDHB, especially in health data storage and pperations management. Health data may be stored in a bigger facilities. Smaller clinical establishments can act as a ‘spoke’ and location that the data is stored in will be the ‘hub’. Hubs will also spokes for hubs maintained at state, regional or national level.
  3. eSign: is an online electronic signature service which can be integrated with service delivery applications via an API.

Further recommended work on Standards: 

While an attempt has been made in this Chapter to deal with the core and minimal standards required in the initial phases of implementing the Blueprint, further work of creating appropriate policies is needed in the following areas:

  1. Structure of Core Health Records for AYUSH and Wellness related information and Indexes to be maintained centrally.
  2. Policy for digitization of legacy or non-standardized (free-text/paper) health record.
  3. Policy for storing heavy records (PET/MRI/CT)
  4. Policy for making the PHR System citizen-controlled.
  5. Policy for emergency access to the records
  6. Policy for use of records for research (anonymization & De-identification) and analytics
  7. Policy for record retention and archival
  8. National Safety Certification Infrastructure for Electrical-Medical Equipment.

8. Implementing body: the formation of the National Digital Health Mission

A new entity, National Digital Health Mission (NDHM), will be charged with the responsibility of implementing NDHB. The decision to create a new body was made “after detailed analysis” of 8 existing organizations implementing IT enabled services: NSDL, UIDAI, GSTN, NIHFW, NPCI, NIC, CHI and NHA. The analysis was done along three factors:

  1. Nature of legal entity, ownership, mandate and services provided
  2. Suitability of the organization/ its Model w.r.t the needs of NDHM
  3. Pros and cons of choosing an existing institution Vs Creating a New Institution.

Why the NDHM should be a new body:

The conclusion was that none of the organisations can take on the responsibility of implementing the NDHB, but it was recommended that the NDHM should be a hybrid of hybrid of GSTN, UIDAI and NPCI should be considered, given the federal structure in India, that health is a state subject, and its necessary to get private sector participation from service and insurance providers.

The committee has also recommended that:

  • NDHM should be a government owned body, so as to ensure control within central and state governments
  • It should have two arms – one for policy & regulation, and another for operations & service delivery

1. Key components of NDHM

  1. National Health Electronic Registries: to create a single source of truth for and manage master health data of the nation;
  2. A Federated Personal Health Records (PHR) Framework: to solve twin challenges of access to their own health data by patients and to healthcare service providers for treatment, and availability of health data for medical research – critical for advancing our understanding of human health
  3. A National Health Analytics Platform: to bring a holistic view combining information on multiple health initiatives and feed into smart policy making, for instance, through improved predictive analytics;
  4. Other Horizontal Components: Including, and not restricted to, Unique Digital Health ID, Health Data Dictionaries and Supply Chain Management for Drugs, payment gateways. Shared across all health programs.

2. NDHM’s responsibilities

  1. Providing technology for collection of core health data
  2. Providing a platform for interoperability of health data through a unique identifier for the provider and patient
  3. Improving the quality of health data collection, storage and dissemination for purposes of research and policy decisions
  4. Publishing national indicators for health, to measure quality of care and progress against policy initiatives and SDG Goals
  5. Capacity building on health informatics, safety and security

NDHM’s CEO will coordinate with different ministries/departments of the central and state governments. Hence, the CEO should be of the rank of either a Secretary or Additional Secretary to the Government of India.

3. Core services to be offered by NDHM

4. Financing the NDHM

Study of organisations like GSTN, UIDAI, NHA etc showed that development cost, people, and property cost are the major costs for such organisations. For NDHM to be successful, “it will be important to undertake outreach activities with public and privates sector players. The NDHM will have to co-opt market players like MedTech companies, NGOs, Foundations working in Health space as it builds the public utilities in the form of Registries, PHR, Health ID and Health Information Exchange etc.”

Action for National Digital Health Blueprint

1. Expected outcomes:

  • All citizens should be able to access their Electronic Health Records in a convenient manner, preferably within 5 clicks;
  • Citizens need to undergo any diagnostic test only once, during the course of an episode, despite taking treatment from different health service providers;
  • Citizens should get Integrated Health Services at a single point, though multiple agencies/ departments/ services providers are involved;
  • NDHM shall assure Continuum of Care to the citizens, across primary, secondary and tertiary care and across public and private service providers;
  • A framework for Unified Communication Centre will be prepared to facilitate voice-based services and outreach;
  • NDHM shall support national portability for healthcare services;
  • Privacy of personal and health data, and consent-based access of EHRs will be the inviolable norm that shall be complied by all systems and stakeholders;
  • NDHM will be aligned to the SDG’s related to health;
  • NDHM will enable evidence-based interventions in the area of public health;
  • Above all, the analytical capabilities of NDHM will support data-driven decision-making and policy analysis.

2. Methods & Instruments recommended by NDHB

  1. Federated Architecture
  2. Universal Health Id (UHID)
  3. Electronic Health Records (EHR)
  4. Metadata & Data Standards (MDDS)
  5. Health Informatics Standards
  6. Registries for NCDs
  7. Directories of Providers, Professionals and Para-medicals
  8. Legislation and Regulations on Data Management, with focus on Privacy and
    Security
  9. Data Analytics

3. Deliverables and Timelines

The deliverables are classified into 3 categories, namely,

  1. Physical Deliverables (9 items)
  2. Digital Deliverables and (15 items, with 8 sub-items)
  3. Artefact Deliverables. (12 items)

The deliverables in each category are again prioritized as Immediate (within 6 months), Short-term (within 1 year) and Medium-term (within 18 months).