The National Health Policy (NHP) 2017 had defined the vision of ‘health and wellbeing for all at all ages’. Continuum of care is a concept strongly advocated by the policy. Citizen centricity, quality of care, better access, universal health coverage, and inclusiveness are some of the key principles on which the NHP is founded. All these aspirations can be realized principally by leveraging the power of the digital technologies. In the Indian context, due to its size and diversity, this mammoth task requires that a holistic, comprehensive and interoperable digital architecture is crafted and adopted by all the stakeholders. In the absence of such architecture, the use of technology in the health sector continues to grow in an uneven manner and in silos.
In the above context, the Committee constituted by the Ministry of Health and Family Welfare recognized the need for creating a framework for the evolution of a National Digital Health Eco-system (NDHE) – an Eco-system and not a System. The result is the National Digital Health Blueprint (NDHB), which in addition to being an architectural vision, also provides specific guidance on its implementation. NDHB recognizes the need to establish a specialized organization, called National Digital Health Mission (NDHM) that can drive the implementation of the Blueprint, and promote and facilitate the evolution of NDHE.
The Blueprint keeps the overall vision of NHP 2017 at its core and recommends commencing with a pragmatic agenda to start with, adopting the principle of ‘Think Big, Start Small, Scale Fast’. To this end, it has been designed as a layered framework, with the vision and a set of principles at the core, surrounded by the other layers relating to digital health infrastructure, digital health data hubs, building blocks, standards and regulations, and an institutional framework for its implementation. The document also contains a High‐ Level Action Plan to put these elements into motion in a time-bound manner.
The objectives of NDHB are aligned to the Vision of NHP 2017 and the SDG’s relating to the health sector. These include:
An eco-system cannot be built – it must evolve. Given this, a set of principles - rather than specifications - have been recommended to enable the evolution of the NDHE. The key principles of the Blueprint include from the domain perspective - universal health coverage, inclusiveness, security and privacy by design, education and empowerment of the citizens, and from the technology perspective - building blocks, interoperability, a set of registries as single sources of truth, open standards, open APIs and above all, a minimalistic approach.
In the context of the evolution of a digital ecosystem, building blocks are reusable frameworks or artefacts that most stakeholder groups need to rely upon for designing, developing and delivering their services. Building blocks constitute the core of NDHB. The Blueprint identifies the minimum viable set of building blocks required for the NDHE to evolve and describes their capabilities at a high-level. It is for the NDHM, as a specialist organization, to work towards the design, development and establishment of these building blocks. Conformance to both the NDHB Principles as well as to the NDHB Standards and Regulations is critical for an efficient design and development of the building blocks.
The Blueprint has identified 35 building blocks. A few of the critical capabilities and the schematic of the NDHE that will be addressed by appropriate combinations of different building blocks are briefly explained below:
The task of developing of these building blocks is allocated under a federated model with three levels of roles delineated between centre, state and health facilities. Except for the minimum data set needed at the centre and state, the data shall primarily reside at health facility level.
A significant effort requiring high-level expertise is involved in the preparation of the detailed designs for these building blocks, which have been elaborated in Chapter 2.
The Application Layer of the Blueprint is merely a placeholder in so far as it identifies the thematic areas for development and deployment of applications but refrains from listing them exhaustively. Such an approach has been adopted not only because of the large number and variety of applications that exist, but also because applications must evolve progressively in an innovative manner that cannot be defined upfront. It is, however, necessary here to highlight the importance of leveraging some applications in the health sector that have already evolved and matured over the last few years. Taking these legacy applications on board the NDHE requires that each application is rigorously assessed with respect to its conformance to the pre-defined standards using a set of criteria like those defined by the Digital Service Standard notified by Ministry of Electronics and Information Technology. The design of NDHB enables and promotes the development of a host of innovative applications and apps by start-ups and entrepreneurs to provide value-added services to the citizens and other stakeholders.
The value of the Blueprint can be realized mainly in terms of the impact the digital health services can have for various stakeholder groups. The Blueprint provides an illustrative, but by no means an exhaustive list of digital health services, to indicate the nature of qualitative difference their implementation can make. Needless to say that the portfolio of these services must be validated and updated through a series of consultations with different stakeholder groups.
National Health Informatics Standards form the cornerstones of the NDHB. Ideally, the health sector must align with international standards in a large number of areas. However, the Blueprint has adopted a pragmatic approach and recommended only a minimum viable set of standards, to make it easier for the ecosystem players to adopt them. FHIR Release 4 (in a highly condensed form), SNOMED CT and LOINC are among the standards recommended.
A Blueprint is only as good as its implementation. An appropriate implementation framework is suggested in Chapter 4. The establishment of a new entity, the National Digital Health Mission (NDHM), is recommended as a purely government organization with complete functional autonomy while adopting some features of existing National Information Utilities like UIDAI and GSTN. The role and functions of NDHM and an appropriate organizational structure have also been recommended. A high-level Action Plan for the implementation of NDHB has been shared in Chapter 5.
Healthcare has always been central to all development efforts at a national and global level. Government of India envisages the attainment of the highest possible level of health and well-being for all at all ages as its goal and intends to provide universal access to high quality health care services without the citizens having to face financial hardship as is enunciated in National Health Policy, 2017. The most promising approach adopted by National Health Policy towards this goal is the extensive deployment of digital tools/technology to enhance health system performance. Digital health technology has a huge potential for supporting Universal Health Coverage (UHC) and the government’s commitment to make healthcare affordable, accessible, and equitable.
The Ministry of Health and Family Welfare (MoHFW) has prioritized the utilization of digital health to ensure effective service delivery and citizen empowerment so as to bring significant improvements in public health delivery.
To improve efficiency in health delivery, extend healthcare to rural areas and provide better quality services at low cost, certain eHealth initiatives using ICT (Information and Communication Technologies) were undertaken by MoHFW across the country with th following objectives:
Some of the key ongoing initiatives in digital health being implemented by MoHFW include : Reproductive Child Healthcare (RCH), Integrated Disease Surveillance Program (IDSP), Integrated Health Information System (IHIP), eHospital, e-Shushrut, Electronic Vaccine Intelligence Network (eVIN), Central Government Health Scheme (CGHS), Integrated Health Information Platform (IHIP), National Health Portal (NHP), National Identification Number (NIN), Online Registration System (ORS), Mera Aspatal (Patient Feedback System), Health Management Information System (HMIS), and National Medical College Network (NMCN). These initiatives are operational at a substantially mature level and are already generating enormous amount of data in the health sector. Since health is a state subject, states are supported under National Health Mission (NHM) for services like Telemedicine, Tele-Radiology, Tele-Oncology, Tele-Ophthalmology and Hospital Information System (HIS).
The Government of India approved the National Health Policy 2017 (NHP 2017) with the vision of providing universal health care. As a sequel to the NHP 2017, the Union Budget for the fiscal year 2018–19 announced the Ayushman Bharat Yojana, a program designed to address health holistically through a two-pronged approach:
Through Ayushman Bharat, the Government of India has taken steps to lay the foundation of a 21st century health system. It is expected that the provision of services through public and private sector under Ayushman Bharat will generate enormous amounts of health data, mostly in the digital space. To ensure that cutting-edge digital technologies are leveraged, it is crucial to focus on creating an appropriate architecture and data structures which are both pan-India. With the current system of fragmented data capture by multiple stakeholders without any standardization, there is a serious risk of compartmentalization of digital health assets.
The aforesaid challenge also presents us with an opportunity to build a state-of-the-art National Digital Health Eco-system (NDHE) that can enable us to leapfrog many of the traps that bedevil health information systems even in developed economies.
Towards this end, NITI Aayog had proposed a conceptual framework for creation of a National Health Stack - a set of core building blocks to be "built as a common public good" that helps avoid duplication of efforts and achieve convergence among the IT systems of the diverse stake holders such as the Governments, the Payers, the Providers and the Citizens. Even at the conceptualization stage, it was recognized that the issue of data safety, privacy and confidentiality will be critical for the success of the NHS and consequently, the need has arisen for a mechanism to incorporate these elements ab‐initio into the architecture.
The Ministry of Health & Family Welfare constituted a Committee chaired by Shri J. Satyanarayana, the then Chairman, Unique Identification Authority of India (UIDAI) to create an implementation framework for the proposed National Health Stack. The composition of the committee is shown in Annexure I.
Given the vastness of the Health Domain and the complexities involved in designing architecture for National Digital Health Eco-system, the committee constituted 4 Sub-Groups to deal with 4 distinct aspects of the mandate of the committee. These relate to
The composition of the Sub-Groups and terms of reference are given in Annexure II.
Based on the efforts of the 4 Sub-Groups, the committee prepared the National Digital Health Blueprint (NDHB) as a document that would act as an authoritative reference in guiding all future efforts for creation of NDHE. It is envisaged that the Blueprint will shape the path for a digitally inclusive healthcare system to be established in our country. The nomenclature of “National Digital Health Blueprint” is considered more appropriate as the document is a balanced combination of architectural principles, building blocks and an implementation framework as well, which together, provide an immediate setting for action in multiple dimensions and at multiple levels.
To complement the overall vision of government to create an enabling digital health ecosystem and prioritization of digital health by government as enunciated in the national level programs, the following vision statement is recommended to be adopted for National Digital Health Blueprint:
"To create a National Digital Health Eco-system that supports Universal Health Coverage in an efficient, accessible, inclusive, affordable, timely and safe manner, through provision of a wide-range of data, information and infrastructure services, duly leveraging open, interoperable, standards-based digital systems, and ensuring the security, confidentiality and privacy of health-related personal information."
The vision of NDHM encapsulates the goals of NHP 2017 and aims to leapfrog to the digital age by providing a wide range of digital health services.
The following specific objectives need to be achieved if the Vision of NDHM is to be realized:
The National Digital Health Eco-system is large, complex, heterogeneous, sensitive and critical at the same time. Evolution of such an eco-system can and should happen by a combination of two distinct approaches, namely, establishment/creation of core information systems on a minimalist basis, and promotion of a set of principles and standards to be adopted by all the eco-system players. The Blueprint adopts this twin approach precisely.
The NDHB has been conceptualized as a layered structure depicted in Figure 1.1 and described later.
Figure 1.1 Layered Structures
As alluded to earlier, an eco-system cannot be built, nor can it evolve on a prescriptive approach. Hence the Blueprint proposes to be evolved on the basis of a set of commonly believed principles, which again, pertain to the business (i.e. the Health Domain) and to technology. The governments, central and state, must play the role of facilitators, enablers and advocates of these principles to speed up the evolution of the National Digital Health Eco-system.
While identifying and defining the principles, the following core requirements and architectural priorities have been kept in view:
The Principles of NDHB are stated and briefly explained Table 1.1 and shown as a bird-eye view in Figure 1.2.
Business Principles (Health Domain Principles) | |||
---|---|---|---|
B1. Wellness-centric and wellness-driven. Special focus will be laid on the building blocks and applications relating to Health Education, awareness, screening, early detection and AYUSH. Wellness centres and mobile screening teams will be strengthened through access to real-time Electronic Health Records. Citizens will be encouraged to follow a well-designed referral system. |
|||
B2. Educate and empower citizens to avail a wide range of health and wellness services Mass awareness and education will be promoted through use of appropriate a MEDucation Platform and a portfolio of Health Apps targeting citizens of different age-groups and access to toll-free medical advice. Personalization and localization will facilitate higher uptake of the education and awareness services. |
|||
B3. Design to be inclusive. Specialized systems will be designed to reach out to the “unconnected”, digitally illiterate, remote, hilly and tribal areas. Telemedicine will focus on reaching out to such groups to provide them with services of experts. |
|||
B4. Ensure security and privacy by design. A National Policy on Security of Health Systems and Privacy of Personal Health Records will be developed. All the building blocks that require handling personal health records will be designed to comply with such policy ab-initio. |
|||
B5. Design to measure performance and display accountability of all providers of service. Real-time monitoring of the Service Levels and health sector KPIs will be the key driver to measure and publish performance of all health institutions and professionals. Real-time dashboards, data analytics and visualization tools will support the Performance Management. |
|||
B6. National footprint that enables seamless portability across the country. Personal Health Identifier with its supporting blocks, including adoption of Health Information Standards will play a pivotal role in the national portability. A system of incentives will be put in place for early adoption. |
|||
B7. Built basing on the principle, "Think Big, Start Small, Scale Fast". While the "Big Picture" of NDHB will be comprehensive containing all the building blocks required to fulfil the Vision, NDHB will adopt a combination of strategies like taking a minimalistic approach for designing each block, prioritizing and sequencing of the development/ launch of the building blocks, and designing a technology architecture that can scale horizontally and vertically. |
|||
Technology Principles | |||
T1. Adopt India Enterprise Architecture Framework (IndEA) The artefacts prescribed by the IndEA Standard will be prioritized and sequenced. The design
of the building blocks of NDHB will adopt and conform to IndEA by default. Other national and
international standards will be adopted in areas not covered by IndEA. |
|||
T2. Conform to open standards, be interoperable and based on Open Source Software products
and open source development The policy of MeitY on open standards and open source software shall be adopted in designing of the building blocks of the Blueprint and in all procurements relating to its implementation. Interoperability will be inherent to all the building blocks. |
|||
T3. Federated Architecture shall be adopted Only the identified core building blocks will be developed and maintained centrally. All other building blocks shall be designed to be operated in a federated model that factors regional, state-level and institution-level platforms and systems to function independently but in an interoperable manner. |
|||
T4. Open API-based Ecosystem All the building blocks will be architected adopting the Open API Policy notified by MeitY. Security and Privacy will be built into the design and development of the APIs, which should be audited for security and privacy before deployment. |
|||
T5. All major legacy systems shall be assessed for conformance to principles and leveraged to
the extent feasible. Compliance of legacy systems to the Blueprint principles and IndEA principles will be assessed through an appropriately designed Assessment Tool. Only those legacy systems that cross the bar will be allowed to operate within the eco-system. |
|||
T6. All the components, building blocks, registries and artefacts shall be designed adopting a
minimalistic approach. Easy, early and collective adoption of the Blueprint by majority shall be critical to its success. Hence every component of the Blueprint shall be designed to be minimalistic. |
|||
T7. All the registries, data hubs and other master databases shall be built as Single Source of
Truth and System of Record on different aspects and backed by strong data governance. Rigid validations shall be applied to all mandatory 'fields', clear ownership and responsibilities shall be defined for all core databases and strong, dedicated data governance structures shall be established at the state and central levels. |
Table 1.1 Principles of NDHB
Figure 1.2 Bird's eye view of the NDHB Principles
Digital technologies are playing a pervasive role in the delivery of healthcare today. The National Digital Health Blueprint (NDHB) provides an approach to establish a Federated Architecture, defined in terms of its Building Blocks. The federated architecture seeks to enable the health ecosystem by streamlining information flows across players in the ecosystem while keeping citizens, their privacy and confidentiality of data at the forefront. A good design can help accelerate the adoption and improve delivery of health services across both the public and private sectors. NDHB identifies key building blocks by looking at the most common requirements of the overall health ecosystem
Federated architecture (FA) is a pattern in enterprise architecture that allows interoperability and information sharing between semi-autonomous de-centrally organized entities, information technology systems and applications. In terms of the Technology Principle T3, specified in Table 1.1, NDHB is required to be designed using the principles of Federated Architecture. The purpose of using the Federated Architectural pattern in NDHB is essential for enhancing the security and privacy of the personal and sensitive information of the citizens while ensuring interoperability and technological flexibility and independence. Such an architectural pattern is also ideally suited to the conditions prevalent in a federal set up like India and includes both public and private health facilities and institutions.
The federated architecture presented in this Chapter is based on a set of principles. It is not prescriptive, but illustrative. The following principles are recommended for the detailed design of the federated architecture and its components:
The Figure 2.1 provides a high-level view of the federated architecture of NDHB.
The following are the salient features of the architecture:
In architectural parlance, a building block is a package of functionality defined to meet business needs. Building blocks have to operate with other building blocks. A good choice of building blocks will facilitate legacy system integration, improved interoperability, and flexibility in the creation of new systems and applications. Wherever interoperability is required, it is important that the interfaces to a building block are published and are reasonably stable. A building block is intentionally designed to be cross-functional, allowing for its generic functionality to be applied in different contexts.
Each building block must have the following characteristics:
Each building block must have a clear 'Business Owner' and 'Technology Owner'. The business owner is responsible for defining the rules and policies essential to effectively manage the building block. The technology owner would be responsible for managing the business requirements and technical implementation of these requirements efficiently.
Building blocks once identified shall be implemented using workflow-based modules and must interface with other building blocks using open APIs. The building block of Unique Health Identifier (UHID) will be centre-piece for integration with all the other components of health ecosystem and for maintaining the Electronic Health Record (EHR).
Identification of new blocks is an ongoing activity and more blocks would come up over time.
The recommended set of essential and minimal building blocks under the Federated Architecture (FA) of NDHB are represented in Figure 2.2. The salient features of the detailed architecture of NDHB are given below:
Figure 2.2 Federated Architecture of NDHB (with Building Blocks)
Based on detailed studies of the existing health systems and discussions with stakeholders, the 35 key building blocks have been identified across the 3-Level/4-layered architecture of NDHB. These have been represented in Figure 2.3. It may be noted that Figure 2.3 is a '2- dimensional representation' of the major building blocks, abstracted from the '3-dimensional representation' presented in Figure 2.3. It should not be construed from Figure 2.3 that all the building blocks would be maintained centrally at the national level.
Figure 2.3 Building Blocks of NDHB
The important building blocks are explained in the remaining part of this section:
Secure Health Networks Blueprint should be built to work on public networks by default. Wherever access to sensitive or aggregated data is involved, secure connectivity may be used. For specific applications like Tele-health, Tele-radiology that require strong data links to systems like PACS low latency, high bandwidth network systems may be specially designed. |
|||
Health-Cloud (H-Cloud) The Health-Cloud builds on the MeitY initiative of Government Community Cloud (GCC) with stronger security and privacy policies and infrastructure. Key data hub management services of the Blueprint must be deployed on the H-Cloud. |
|||
Security and Privacy Operations Centre (SOC) All events on the Health-Cloud and the Health Network need to be under 24x7 security surveillance ensuring every data byte is highly secure. This is achieved through a Security Operations Centre (SOC). The Committee recommends the establishment of a dedicated Privacy Operations Centre (POC) to help drive compliance on the privacy requirements, adherence to which is a must in the health sector. The POC will monitor all access to private data, review consent artefacts, audit services for privacy compliance, evangelize the privacy principles on which the Blueprint is being built and bring trust and strategic control in the usage of health data in the ecosystem. |
The recommendations in respect of identification of the major entities are given in the following sub-sections.
While there are several approaches to implementing an EHR system, keeping in line with the principles of NDHB, a federated system with multiple market players working on a national interoperable standard for sharing of health data is preferred. Health care providers are expected to identify the individual (through UHID) and insert a medical record into the person’s EHR after providing care. The content in the EHR will need to allow for change, from basic content with very little metadata to a strongly structured content that meets the standards specified in Chapter 3. Initially the EHR may capture, data relating to significant medical and health conditions, episodes and events to be identified and notified. The scope of EHR can be expanded in a phased manner to include other health conditions. Annexure V specifically highlights mistakes to be avoided in designing EHR.
The design of the Digi Locker system, which has multiple issuers and users who can exchange data with consent and strong non‐repudiation methods, should be adopted with appropriate modifications and enhancements for creation of EHR.
Health registries hold information about individuals, usually focused around a specific disease or condition. Some registries seek and hold information about volunteers who want to participate and contribute to a health cause, such as eye/blood/organ donation. Section 2.4 provides a recommended structure for health registries of the first type. A more structured, standards-based approach is required to derive the best benefits of health registries – ongoing and new. Table 2.1 shows the key health directories to be established in the first phase of the NDHB.
Facilities Directory |
The Facility Directory will consist of one record and a unique identifier for each Health facility in the country – Hospitals, Clinics, Diagnostic centres, Pharmacies etc. |
|
Doctors Directory | The Doctor directory will consist of one record for each doctor who has registered with the medical council after completion of their education. The directory must be designed to be kept up-to-date as doctors gain skills via fellowships and map them to the facilities they are associated with. |
|
Nurses & Paramedical Directory |
The Nurses directory will essentially include the medical support staff including Nurses, ANMs etc. and will also consist of one record for each paramedical staff that is awarded a certification by the Paramedical board, Ophthalmic Technicians, Operation Theatre technicians, etc. |
|
Health Workers Directory |
This directory will consist of Health Workers like ASHA who act as the extended work force enabling door to door healthcare related services. |
|
Allied Professionals Directory |
This directory contains the other key roles in the healthcare industry including Masters in Hospital Administration, Health IT, Disease Coders, Pradhan Mantri Arogya Mitras, etc. |
Table 2.1 Key Directories to be established in the first phase of the NDHB
Health Masters/Health Data Dictionary: There are several master data requirements in healthcare including names of drugs, diseases, lab tests, procedures, etc. The content and interoperability section in Chapter 3 outlines the various standards / code sets which need to be adopted. The Blueprint must enable easy access to developers to incorporate master data into their applications.
Anonymizer |
"Anonymization" with respect to personal data, means the irreversible process of transforming or converting personal data to a form in which a data principal (owner/ citizen) cannot be identified. For the purposes of this report, the term Anonymization has been used in a broader sense to include the related concepts like de-identification and encryption. The Anonymizer takes data from the Health Locker and/or other health data sets, removes all personally identifiable information to protect privacy and provides the anonymized data to the seeker. Tools available can anonymize both structured and un-structured data. At the same time, Anonymizer systems allow the Government or authorized agencies to access the health records of the citizens in critical cases like monitoring of notified diseases etc. This enables the government to take effective decisions to promote wellness in the country and to ensure that healthcare is provided in a timely fashion, as needed. There are 2 levels of delinking the personally identifiable information from the related health record(s), namely, de-identification and anonymization. Deidentification process is reversible, whereby re-identification by the competent authority is possible for specified purposes. Anonymization, on the other hand, is a one-way process, whereby the data once anonymized, cannot be related to any person subsequently. It is necessary to identify the use cases for these 2 processes, depending upon the degree of privacy required. Though combined as a single building block, Anonymizer shall have all the capabilities required, namely, anonymization, De-identification and reidentification including encryption and decryption as needed. Ideally, data is anonymized at the primary source of its capture and retention, mostly at the facility level, so as to minimize its leakage while in transit. However, not all facilities may have the infrastructure and capacity to handle the task efficiently. NDHB, therefore, proposes an additional building block, namely, Anonymizer-as-a-Service, positioned at the intermediate (state) layer which will define the principles of anonymization. The NDHM will facilitate the anonymization of data through appropriate software, utilities, hardware etc. ensuring conformance to the aforesaid principles. |
|||||||||||||||||||||||
Consent Manager | Health records are personal for an individual and every access to each record requires explicit consent of the individual (data principal). The electronic consent framework specifications notified by MeitY should be used in all aspects relating to the information processing requirements. The goal of the Consent Management Framework and the Consent Manager should be to ensure that the citizen/patient as the data principal, is in complete control of what data is collected, and how/with whom it is shared and for what purpose, and how it is processed. The framework should apply not only to the data collected at each touch point and each encounter but to the data relating to the entire Electronic Health Record, both longitudinal (over a period of time) and vertical (relating to an episode). The IT systems envisaged under the NDHB shall be designed and the existing IT systems enhanced suitably to meet the requirements specified in the Data Protection Bill, in addition to the provisions of IT Act 2000 and the Aadhaar Act 2016 and the rules and regulations notified thereunder. Such a course of action would ensure that the systems are compliant to the existing regulatory provisions, as well as potential future requirements. The Privacy Operations Centre, envisaged as an independent building block that draws its inputs from the various consent management systems, shall play a proactive role in monitoring privacy, consent and access of health data so as to predict and prevent breaches and to notify the concerned data principals and entities in the event of a suspected breach. A combination of data protection techniques like anonymization, deidentification, encryption and strong responsibilities on the data fiduciaries and data processors in addition to consent manager is recommended, as no single technique could take care of all eventualities. Consent shall be obtained at the primary source of its capture and retention, mostly at the facility level, before collection of data and before its processing and /or sharing. However, not all facilities may have the infrastructure and capacity to handle this task efficiently. NDHB, therefore, proposes an additional building block, namely, Consent Management-as-a-Service, positioned at the Intermediate (State) Layer which will define the principles of Consent management. The NDHM will facilitate implementation of consent framework through appropriate software, utilities, hardware etc. ensuring conformance to the aforesaid principles. |
|||||||||||||||||||||||
Health Locker |
The Health Locker is a standards-based interoperability specification that can be implemented by multiple players to enable the creation of an Electronic Health Record ecosystem. When a medical record needs to be issued, only a reference link is shared with the locker ecosystem. Small clinics / hospitals are expected to subscribe to the authorized repository providers who can integrate with the Health Locker to be able to participate in this ecosystem. The health lockers enable creation of a longitudinal health record from the various links it stores and provide the EHR to the providers who need the same. The EHR is created only after consent is sought from the user. The design will factor uptime, network, storage and security considerations. The Health Locker system should enable processing the requests for correction of health data and also for the citizen to exercise his/her 'right to be forgotten', i.e. the right to restrict or prevent continuing disclosure of personal data by a data fiduciary related to the data principal where such disclosure (a) has served the purpose for which it was made and is no longer necessary; or (b) was made on the basis of a consent which has since been withdrawn. |
|||||||||||||||||||||||
Health Information Exchange |
All actors in the health ecosystem would in some way or the other be generating or accessing health information, using one or more access applications. The exchange of information needs to be enabled as realtime data exchange by implementation of Open APIs and other data exchange mechanisms. From a flow perspective, each access application, to submit or retrieve/access any information from/ via the Blueprint, needs to be registered with the Health Information Exchange (HIE). The HIE would be responsible for authentication and authorization of all data exchange requests and, if authorized, for routing the request to the providing applications. The design of this component should support implementation of multi-channel solutions by participating applications, to ensure cross channel capabilities and a seamless user experience and for enabling an open market ecosystem. |
|||||||||||||||||||||||
Health Analytics |
This building block has the objective of providing decision support to the stakeholders on a wide variety of themes, by analysing the aggregated datasets. The Blueprint design must ensure that analytics data is created / collected at source when the medical record is being prepared to be issued to the EHR. 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. Policies for access to the aggregated health data need to be setup. Figure 2.3 indicates that health analytics component should be available both at the national and state levels. While the building block of health analytics can have very large scope in terms of the number and nature of themes for analysis, the following initial set of themes is recommended with the corresponding benefits, as shown below:
|
|||||||||||||||||||||||
GIS/Visualization |
This building block provides GIS / Visualization services that can be used by the application layer to answer queries such as finding the nearest hospital with a required specialty? Or plotting of disease incidence in a geographic area etc. The building block must take data sets from the health analytics system and produce outputs that can be consumed by the application layers. The GIS services will help in regional/state level planning and monitoring of health services. |
Table 2.2 Technology Building Blocks
Government Managed Health Applications e.g.: Reproductive and Child Health (RCH), NIKSHAY (Online TB Patients monitoring application), e-Raktkosh, Health Management Information System (HMIS), National Programme for Control of Blindness (NPCB), Ayushman Bharat, Hospital Information System (HIS), Integrated Disease Surveillance Program (IDSP) etc. Telemedicine should be given a high priority given the low Doctor‐Population ratio, especially in the rural areas. The Ministry of Health and Family Welfare, with the support of WHO, had launched one of the world’s largest web-enabled, near real-time electronic information system – the Integrated Health Information Platform (IHIP). IHIP provides for public health surveillance for 33 major outbreak-prone diseases (IDSP), malaria and Health Management Information System. |
Call Centre(s) |
Provide telephonic support to all actors of the ecosystem, principally the citizens. |
|
India Health Portal | A multi‐lingual national portal enabling access to digital health services and data |
|
Social Media |
For emergency management, health awareness / education and community-based services like Blood/ Organ Donations. |
|
MyHealth Apps |
A wide range of Apps can be built by open market, including Start‐ups and existing Health IT companies of all scales besides Government organizations. The end user thus has the choice of selecting the app that suits their needs best. |
Table 2.3 Access & Service Delivery Points
Given the prospects of a near universal coverage of all families in the country with smart phones, all the digital services are to be designed to be delivered through smart phones adopting the Mobile First principle.
The Smart Phones should the preferred medium / channel for dissemination of appropriate content, information, alerts and updates to the large force of health workers, predominantly, the ASHA workers, given that a significant thrust has to be given to the MCH and NCD programs and related field activities. Smart phones can also be the preferred channel for online education of citizens and the field force.
Specific efforts shall be made to launch voice-based services using appropriate tools customized to work in spoken Indian Languages, in collaboration with the OEMs. In addition to the above 5 horizontal layers, the Blueprint also identify the following two vertical layers cutting across all the horizontal layers:
Registries can provide healthcare professionals and researchers with first-hand information about people with certain diseases, both individually and as a group, and it can increase our understanding of the disease over time.
Broadly, disease registries are based on information gathered during community screening and in the hospitals. Screening-based registries are concerned with recording information about diseases for population at large for different age groups based on well-defined parameters and invoke referrals. Hospital-based registries are concerned with recording of information on the patients seen in a particular hospital.
National Cancer Registry being maintained by ICMR and the other disease registries currently maintained in India are not interoperable and not integrated with Hospital Management Information System (HMIS). Disease registries need to be standardized following the NDHB to make them integrated and interoperable. Table 2.4 depicts generic structure of recommended registries.
Type |
refers to type of registry viz. community screening or hospital based |
|
Purpose | refers to the purpose of maintaining the registry |
|
Size |
refers to the number and complexity of data points, the frequency of data collection, and the enrolment of investigators and patients |
|
Person Identifier |
includes all parameters given under Unique Health Identifier (UHID) |
|
Family Identifier |
includes detailed information about family members from UHID |
|
Locational Parameters |
includes location to which patient belongs, facility where person has been screened and/or referred to |
|
Screening Parameters |
include the disease specific parameters to be recorded |
|
References/Pointers |
defines the pointers to diagnosis, referrals, treatment, education, adherence to using Electronic Health Record (EHR) |
Table 2.4 Generic Structure of Registries
There is a strong need to uniquely identify health facilities and ensure that any health data is correctly tagged with the facility ID to ensure traceability, accountability and reliability of the health information. The Government needs to create a strong facility registry for use by several actors in the ecosystem.
After a comparative analysis of the ongoing initiatives for creation of facility registries (details in Annexure III), the Committee recommends the following:
In the health domain, the need for Unique Health Identifier (UHID) has been recognized for the purposes of uniquely identifying persons, authenticating them and threading their medical records across multiple systems and stakeholders.
UHID contains demographic details like name, father's / mother's/ spouse's name, date of birth/age, gender, mobile number, authentication route, email address, location, family ID and photograph, in line with the person resource defined by FHIR (please refer to Chapter 3 for relevant details of FHIR).
Uniqueness is a key attribute of UHID, and the algorithm that issues a UHID must try to return the same identifier for the individual in all scenarios. The design of UHID may leverage existing multiple identifiers including Aadhaar, PAN card, Ration Card, Electors Photo Identity Card (EPIC) etc., for designing the structure and processes relating to UHID, subject to conformity with the regulatory requirements.
The existing identifiers may be utilized to generate various 'levels of confidence' to uniquely identify the patient duly following the 2 principles:
As an identity system, UHID can opt for one of the three system archetypes – centralized, federated and decentralized. A comparative analysis of the three archetypes is shown Annexure IV. It is recommended that the centralized approach is adopted for the following benefits:
The National Digital Health Blueprint envisages the evolution of an entire eco-system in the health sector to provide a wide range of services to the stakeholders in a digitally enabled manner. Creation of such an eco-system, in a heterogeneous and multi-level environment that exists in India, can happen only through a multi‐pronged approach through the efforts of many actors acting in sync. The Building Blocks of NDHB defined in Chapter 2 need to work in unison in an interoperable manner if all the digital services must be realized for the benefit of all the stakeholders, especially the citizens. Such seamless and boundary‐less interoperability is possible only if all the building blocks and the digital systems are built using the defined standards.
The objective of this Chapter is to define the standards required for ensuring interoperability within the National Digital Health Eco-system. Adoption and implementation of standards in the health domain is a relatively slow process, as observed from the experiences of some of the countries that embarked on the same. Given this, it is proposed to recommend a set of minimum viable standards in the initial stages.
Given the sensitivity of personal and health- related data, appropriate recommendations are made with respect to the regulations to be complied with by the actors in the digital health eco-system.
The scope of National Digital Health Initiative, the digital services envisaged by it, its guiding principles and Building Blocks have all been identified and defined in the earlier Chapters. The scope of the standards is defined keeping the foregoing in view. Table 3.1 depicts the areas chosen to define the standards for the NDHB.
Consent |
The consent from patient need to be covered from two aspects – consent for data collection and data use through NDHE. |
|
Content & Interoperability | Standards related to exchange of healthcare data. |
|
Privacy & Security |
Standards related to data privacy (through access control) and Security of data at-rest and at-motion. Also, aspects such as data immutability and non‐repudiation with audit trail. |
|
Patient Safety & Data Quality |
Standards related to ensuring patient safety while collecting data and quality of data captured. |
Table 3.1 Areas chosen to define Standards for NDHB
Appropriate recommendations are also made on the aspects relating to adoption and implementation of the Standards.
RECOMMENDED STANDARDS
The consent of the citizen plays a major role in ensuring that collection of data is done in a manner consistent with legal rights of the patient. It is also important to ensure that once collected, the data captured is used and disclosed (in an identifiable or anonymized form) in a manner appropriate in law and preserving the citizen-directed constraints. Towards these, the standards shown in Table 3.2 are recommended for designing the systems and workflows required for consent management:
Purpose | Recommended Standard | ||
---|---|---|---|
Consent Management |
ISO/TS 17975:2015 Health Informatics ‐ Principles and data requirements for consent in the collection, Use or Disclosure of personal health information |
||
Consent Framework | Electronic Consent Framework (Technology Specifications v1.1) with its subsequent revision(s) published by MeitY. |
Table 3.2 Recommended standards for Consent Management
The above standard should be implemented in a way consistent with the applicable laws such as Information Technology Act 2000 (and its amendments), various directions, and rules of National Medical Commission and its State counterparts regarding patient consent and protecting patient privacy.
Data content plays a major role in availability of appropriate medical information to be used in healthcare, policy formulation and health analytics. The interoperability standards should support the major clinical artefacts used globally. The standards should additionally support extensions to it for any national needs such as country specific clinical data elements, fields, records and value sets.
Interoperability in the context of digital health is of two types, viz. technical interoperability and semantic & syntactic interoperability. This section defines the minimum requirements of interoperability of both the types.
a. Technical Interoperability
Technical Interoperability is substantially defined in IndEA and its basic requirements are mentioned briefly here:
b. Semantic & Syntactic Interoperability (Content)
Apart from technical interoperability, required for seamless exchange of clinical records, semantic interoperability standards shall be adopted for health-related terminology and formats
The Fast Healthcare Interoperability Resources (FHIR) R4 Specification is the latest standard for exchanging healthcare information electronically. It is built upon the HL7 series of standards and is considerably rationalized and simplified. Adoption of FHIR ensures that the electronic health records are available, discoverable, understandable, and structured and standardized to support automated Clinical Decision Support (CDS).
The building blocks of FHIR are Resources. FHIR specification defines a set of 13 modules with 143 resources, and the infrastructure for handling the resources.
The following recommendations are made in respect of adoption of semantic interoperability:
A set of 8 essential and minimum classes of health record artefacts should be notified for data capture in NDHB. The list of health record artefacts prioritized and mapped to the suggested corresponding FHIR resources is shown in Table 3.3. Depending on health record Table 3.3 Health record artifacts mapped to FHIR resources artefact requirement, other relevant FHIR Resources (not explicitly mentioned here) may also be used.
Sr. No. | Information Record Purpose | Corresponding Resources in FHIR | |
---|---|---|---|
Category | FHIR Resource | ||
1 | Patient Demographics Care Provider Details | Administration | Patient Practitioner Person |
2 | History, Problem & Diagnosis | Summary | Family Member History Condition Clinical Impression |
3 | Vitals, Results, Assessments(incl. Pregnancy, Death), Wellness parameters | Diagnostic | Observation Diagnostic Report |
4 | Adverse Event, Alert | Summary | Adverse Event Allergy Intolerance |
5 | Medication / Wellness Lifestyle / Diet / Vision | Medication | Medication Request Immunization |
Care | Nutrition Order Vision Prescription Care Plan Goal |
6 | Procedure | Care | Procedure |
7 | Admission / Discharge / Transfer / Order | Administration/Care | Appointment Encounter Episode of Care Service Request |
8 | Insurance | Financial | Coverage Eligibility Request/ Response Claim/Claim Response |
Table 3.3 Health record artifacts mapped to FHIR resources
c. Content & Interoperability Standards
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. These standards are specified in Table 3.4.
Purpose | Recommended Standard |
---|---|
Structured Clinical Information Exchange | FHIR Release 4 (subject to section 3.4.2)(with any future errata(s)) |
Still Images / Documents Audio / Video |
Still Image: JPEG Document/Scan: PDF A-2 Audio: MP3/OGG Video: MP4/MOV (embedded as binary content in relevant FHIR resource) |
Diagnostic Images (Radiology including CT, MRI, PET, Nuclear Medicine / US / Pathology), Waveforms (e.g. ECG) | DICOM PS3.0-2015c (embedded as binary content in relevant FHIR resource) |
Terminology/Vocabulary | SNOMED CT (for all clinical terminology requirements in health records) |
Coding System | WHO ICD-10 (for statistical classification of diseases and related health problems) LOINC (for observation, measurement, test-panels, test items and units) |
Table 3.4 Content & Interoperability Standards
Preservation of privacy of patient’s healthcare is an important consideration that needs to be incorporated in the overall design and implementation of the Blueprint. The standards and various operational requirements for privacy and data security are specified in Table 3.5.
Purpose | Recommended Standard |
---|---|
Security | Digital Certificate, TLS / SSL, SHA-256, AES-256 |
Access Control | ISO 22600:2014 Health informatics - Privilege Management and Access Control (Part 1 through 3) |
Table 3.5 Privacy & Security Standards
In addition, it is important to ensure that data is reliable and verifiable. Provisions and guidelines related to the following should be incorporated in operational aspects of the blueprint:
Immutability | Record once created cannot be deleted or modified without following due process. |
Versioning | Any record created may be 'amended' with new version number of same records with any changes (previous records to be marked inactive) with only highest version considered active. |
Non-Repudiation | All created records must be traceable to its creator unambiguously. |
Audit Log | All creation, amendments, access of records should be audit logged in manner that it is verifiable and reliable |
Patient Control | Patient should be able to access/view own health records anytime, and control access by others. |
Table 3.6 Attributes of Reliable and Verifiable Data
In regards of above, provisions, guidelines, standards prescribed in EHR Standards for India 2016 should be incorporated.
Quality in healthcare services and safety of electrical‐medical equipment are of utmost importance in the NDHB. Electrical-medical equipment used in the NDHE should be safe for the patient and para‐medical personnel and against safety hazards like electric shock, harmful radiation, excessive temperature, implosion, mechanical instability and fire. Bureau of Indian Standard has published 38 standards in this area. These standards are either an adoption or technical equivalent of the related IEC standard. The 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.
Delivery of standardised care / treatment provided to patient can go a long way in ensuring safety of patient throughout treatment and instil confidence in patient and care provider towards diagnosis and treatment, among other benefits. The Standard Treatment Guidelines (STGs) issued by public health authorities should be incorporated into clinical treatment and IT system workflow for standardisation of treatment / care given to Patient and reporting to public authorities where required.
Most of proposed standards except FHIR are already part of EHR Standards for India 2016 notification. All proposed standards are open specifications from respective Standards Bodies and are internationally supported. The ISO/BIS standards are readily available. Use of SNOMED CT is free as India is already a member country.
Other than standards, various architectural, design and operational recommendations are shown in Table 3.6 to ensure cohesiveness of the Blueprint:
MDDS & EHR Standards for India 2016 |
Meta Data and Data Standards solve the problems of common data dictionary at the semantic level. The EHR Standards for India 2016 is overarching set of recommendations for creating, interoperating and using health record systems within an enterprise and external ecosystem at various levels. Inter-operability at the technical level would require specific integration solutions. Inter-operability at the institutional level would require a dialogue between public health organizations, to understand information needs, as well as barriers to better quality and use of information. Solving the semantic and technical barriers brings interoperability much closer. |
Hub & Spoke Model | As there are glaring incongruities between health systems at various levels of governance and delivery, the hub and spoke model may play a vital role in designing the components of NDHB, especially referring to the health data storage and operations management. The clinical establishments particularly in rural areas where sufficient infrastructure (servers, storage and bandwidth) is lacking, face a problem. In such cases, health data may be stored in a bigger facility equipped with necessary infrastructure. In this model, all the smaller clinical establishments will act as a spoke and the location where this data is stored will act as a hub. In such a model, Hubs will also act as spokes for larger hubs maintained at state, regional or national level. |
eSign | eSign is an online electronic signature service which can be integrated with service delivery applications via an API to enable the user to digitally sign a document. Considering the requirements of health data like nonrepudiation and trusted access / transfer for various medical workflows such as advices or referrals NDHB can leverage the eSign services in a cost effective manner. |
Table 3.7 Architectural, design and operational recommendations
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:
An ambitious initiative like NDHB can materialize only if the right institutional framework is put in place. The following factors should be considered in suggesting the right organizational structure:
An evaluation was done of the existing organizations such as CHI and CBHI which are handling health data and housed within the Ministry of Health and Family Welfare, Government of India. A comparative analysis has also been done of all the national organizations handling large data. Additionally, focus has also been on reviewing the international experience in creating Electronic Health Record (EHR) structures (especially studying the South Korean model of EHR structure). It is observed that any new organization will need to have certain attributes by design:
At the outset, it is proposed that the entity to be charged with the responsibility of implementing NDHB be called ‘National Digital Health Mission’ (NDHM), to connote the missionary approach required for its successful implementation.
In a nutshell, it is important to underscore that the success of NDHM is dependent on its wide adoption by both Centre and State, public as well as private entities. Its adoption rests heavily upon the clear definition of the role and responsibilities of NDHM. To establish a clear mandate for the NDHM, the following key components, roles and responsibilities are envisaged:
National Health Electronic Registries | to establish the standards and core infrastructure required to create a single source of truth for and manage master health data of the nation; |
A Federated Electronic Health Records (EHR) 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; |
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; |
Other Horizontal Components | including, and not restricted to, Unique Digital Health ID, Health Data Dictionaries and supply chain management for drugs and information exchanges and gateways, shared across all health programs. |
Enabler & Facilitator | NDHM as an organization shall combine twin capabilities, namely, the architectural and design capabilities for creating the core components and the coordinating abilities to enable and facilitate the implementation of the NDHB by all other stakeholders in a concerted way. |
Table 4.1 Key Responsibilities of NDHM
The role of the NDHM will be to provide information and data to different components of the health eco-system to work together. It will also provide the technological infrastructure for collection and storage of core/ master data through the various registries.
The responsibilities of the NDHM will include:
The Institutional Framework of the NDHM will have to operate at two levels, namely the Governance level and the Implementation level.
The Governance architecture of NDHM should comprise of the following elements for it to be a successful enterprise:
The implementation architecture of NDHM must incorporate key elements such as a clear leadership structure, convergence between core ministries and departments, citizen-centric approach and services, conductive policies, legal and regulatory frameworks, appropriate technology architecture, information management and security, infrastructure expansion, planning, monitoring and evaluation in a comprehensive manner.
Over the past two decades there have been several Digital Health initiatives that were launched globally to improve the quality of health care and bring down the healthcare costs. While some countries like the United States are ahead of the curve in terms of the availability of Information and Communication Technology (ICT) infrastructure, other countries are in the process of reforming their respective health care sector using IT as a key component of the process.
In England, the National Health Services-Digital (NHS Digital) is the national provider of information, data and IT systems for commissioners, analysts and clinicians in health and social care. It provides digital services for the NHS, including the management of large health informatics programmes. They deliver national systems through in‐house teams, and by contracting private suppliers. These services include managing patient data, the NHS Spine, which allows the secure sharing of information between different parts of the NHS, and forms the basis of the Electronic Prescription Service, Summary Care Record and Electronic Referral Service.
In South Korea, the Ministry of Health and Welfare (MOHW) created a specialized organization to maintain EHR. Several advisory committees were created for providing policy directions and expert opinions. Two centres were created for carrying out system development and the related researches: Implementation Centre for Development and Research, and Development Centre for EHR. South Korea has been successful in developing their digital health infrastructure due to reliable and cost‐effective IT platform, user-friendly application systems, standards, laws, budgets, and strong support from various stakeholder groups such as the Korean Medical Association and citizens’ groups.
The experiences of NHS Digital in England, Canada and the South Korean Model are particularly relevant for India and what we intend to achieve through the proposed NDHM.
India has made remarkable progress in the Information & Communication Technology (ICT) space over the past two decades. The IT revolution in India has also had a positive impact on the public sector governance architecture in India which led to some transformational initiatives like Unique Identification Number (UID-Aadhaar) for almost all the residents of India, IT enabled platform for GST, IT systems integration in banking sector and IT‐enabled public service delivery.
While India has pockets of IT excellence within the public sector the application of IT enabled systems has not been uniformly adopted across the entire governance system. The IT initiatives in the health sector in particular, have been fragmented and compartmentalized hindering the realization of the full potential of ICT.
To develop a robust Institutional Framework for the National Digital Health Infrastructure it is imperative to understand and analyse the institutional framework of existing organizations that have been successful in implementing IT-enabled services for the citizens. A detailed analysis of 8 existing organizations implementing IT enabled services (namely, NSDL, UIDAI, GSTN, NIHFW, NPCI, NIC, CHI and NHA) (Annexure: VI) has been done along 3 different dimensions, namely
Following the analysis of the organizations it is concluded that none of the organizations in its current form can take on the responsibilities of such large-scale implementation of the specialized task of realizing NDHB. However, it is instructive to pick up some specific features of these organizations, which are relevant and essentially required for implementation of NDHB.
Given the federal nature of Indian government and the fact that (a) Health is a state subject, and (b) it is necessary to incorporate private sector (both service providers and insurance), it is felt that an institutional framework which is a hybrid of GSTN, UIDAI and NPCI should be considered. The following factors weighed with the committee in this regard:
Following the analysis of existing Indian organizations and reviewing the international case studies, it is proposed that the National Digital Health Mission should be set up as a new organization. The following further suggestions are made:
Figure 4.1 Vision and Mission of NDHM Organization
The roles and responsibilities at various levels of NDHM are suggested in Table 4.2
Level | Roles | Responsibilities |
---|---|---|
Apex Level |
|
|
Board of Directors |
|
|
CEO |
|
|
Operations |
|
|
Table 4.2 Roles and Responsibilities
The administration/implementation of the NDHM will rest on the CEO and will involve coordinating with different ministries/departments of the Government of India and State Governments. Hence it is proposed that the CEO should be of the rank of either a Secretary or Additional Secretary to the Government of India. The decision related to active engagement of private sector will be managed at the level of CEO to ensure up to date technology up gradation and effective administration/implementation of the National Digital Health Infrastructure.
The value of a Mission such as NDHM will be realized through the quality of the core services it offers to the stakeholders, and facilitates the design, development and delivery of digital health services to the end users. NDHM will be shaped as the Technology Arm of the Health Sector of India. As such the focus of NDHM shall be primarily on the Core Technical Services it offers to the various organizations comprising the NDHE, in the public, private and NGO Sectors. However, given the nature of NDHB, it is necessary for the Mission also to make available to the stakeholder community certain generic/common applications relating to the health domain, to avoid duplicative efforts by multiple States/organizations. Such common services shall be reusable, multi-tenant, open source, and standards-compliant.
While an exhaustive list of the digital services to be offered or promoted by NDHM will call for a stakeholder consultation and detailed deliberations, the Committee thought it fit to provide an illustrative list of the Digital Services. The list is shown in Annexure VII.
Significant efforts are going on across the world to deploy the emerging technologies for improving the performance of the health sector. These technologies currently include artificial intelligence, machine learning, internet of things (IoT) and big data. It is essential that a major initiative like the NDHB should leverage these emerging technologies in an appropriate way at the earliest opportunity. While blockchain technology has been much talked about, its efficacy in addressing the issues of the health domain will also be explored.
There is a speedily growing innovation sector in India in the form of large number of startups, many of which are focused on developing innovative solutions for the health sector. It is essential that these creative talents are leveraged and tapped for the rapid growth of digital services in health sector that will contribute to convenience, value-added services and cost effectiveness.
To enable the same, it is recommended that
Health is a concurrent subject under the Constitution of India. Several of the recommendations made in NDHB need to be accepted and implemented by the State/UT Governments. It is therefore recommended that an appropriate structure may be designed for a concerted action by the central and state governments for the successful implementation of NDHB. This is particularly important in view of the need for a widespread adoption of health informatics standards and of the building blocks of NDHB. Such a coordinated action is also required to ensure that the fundamental premise of federated architecture adopted by NDHB succeeds at the ground level. An equally important area needing close coordination between the Centre and the States is the security and data protection obligations envisaged under NDHB.
While representation in Figure 2.2 makes an attempt to bring out the nature of responsibilities to be undertaken at the central and state level, a granular definition of these responsibilities has to be done by the Ministry, during the planning phase (see Table 5.1 - Year 1)
National Digital Health Infrastructure is a public good. Its funding model must reflect this. In the earlier years, it must have budgetary support from the Government of India to get the core components of the National Digital Health Infrastructure built and operational.
A study was conducted to understand key cost components associated with the set up and running of organizations such as GSTN, UIDAI, NHA etc. to assist in the estimation of budgets required to support successful formation and running of the National Digital Health Mission.
It was observed that development cost (capital cost), people and property (operating costs) formed the major cost components of such organizations. For the NDHM to be successful it will be important to undertake outreach activities with public and private 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, EHR, Health ID and Health Information Exchange etc. The outreach organization will have to have strong presence in all the states to ensure adoption of public utilities both by the state govt. as well as the Health ecosystem players.
If the new organization raises a part of its funding through a transaction fee, it drives a service orientation within the organization. However, it must be done without the risk of diluting the public good nature of the institution. This can be done by using the concept of toll pricing model where no profit-making is allowed.
Implementing NDHB is a gigantic matter given the size, complexity of the sector and the diversities across the country. NDHB proposes a fairly complex system that can be realized through high quality expertise flowing into the Architecture, Design and Development phases, not merely within NDHM organization but across all the stakeholder organizations, in a concerted and coordinated way. This requires a carefully designed Capacity Building Plan to be undertaken widely.
Given that significant changes would be called for in the existing processes and systems and in the mind-set of the people currently managing the same, a highly professional approach is needed in the area of Change Management. Adequate budgetary resources need to be provided for Capacity Building and Change Management.
Again, given the significant number and complexity of most of the components and building blocks of the NDHB, attempting to implement all of them at a time is fraught with a high risk of failure, not only on the technology front but also on the people side as well as on the regulatory aspects. It is therefore strongly recommended that the NDHM shall undertake a few PoC’s in respect of all the critical components, before production level designs are made. In addition, a set of environments in the form of a set of regulatory sandboxes and technology sandboxes in selected areas.
The suggested model for the implementation of the National Digital Health Mission (NDHM) is as shown in Table 4.3
Type | A new organization with a Governing Council and Board of Directors |
---|---|
Ownership | Government owned body |
Services | Unique Health ID, Health Directories and Masters, Health Information Exchange and open API’s for health informatics, insurance and health fiduciaries. |
Vision and Mission | Vision: To be a world-class health informatics organization Mission: To provide every Indian with access to high quality digital health services |
Table 4.3 Suggested model for NDHM
The recommendations are as follows:
Any blueprint is as good as the systematic way in which it is planned and implemented. Preparation of a high-level action plan is therefore considered to be an essential part of the National Digital Health Blueprint. The action plan outlined in this Chapter seeks to serve the following purposes:
This Chapter outlines the approach to address the above purposes effectively.
The NDHB described in the previous chapters indicates, at different places, the contours of the scope of work to be done if a digital health eco‐system is to be established in the country. It is necessary to identify, collate and analyse all these work items to know the precise scope of NDHM. The following requirements culled from the previous chapters help us define the Scope more precisely:
The Action Plan must be designed to ensure that the scope as above is well-served.
It is essential that clear outcomes are laid down for a major initiative like the NDHM, so that all the stakeholders can work towards achieving a common set of goals. The outcomes listed here are again culled from the previous chapters and collated for a holistic view. The various artefacts and deliverables of NDHM should be designed and developed in such a manner as to enable us to move in the direction of the outcomes.
Adoption of methods established in the health and IT domains would enable a systematic implementation of the blueprint. The following methods have been recommended by NDHB:
Parallel streams of activities need to be initiated on all the above items.
The essence of an action plan is the list of actions or deliverables, the timelines and responsibilities for the same. The Action Plan turns the Blueprint into an actionable document through these deliverables. A list of 'deliverables' is given in the Table 5.1, in the form of an indicative 5-year action plan. The following explanatory notes enable a correct appreciation of the action plan
Year 1 (Planning & stabilizing NDHM) | Year 2 (Pre-requisite infrastructure) | Year 3 (Execution) | Year 4 (Analytics & Innovation) | Year 5 (Sustenance & Research) |
---|---|---|---|---|
|
|
|
|
|
Table 5.1 Suggested Acton Plan for NDHM
Composition of the Committee on NHS
The Ministry of Health & Family Welfare, through its Office Memorandum T-21 016178/2018 eHealth dated 12th November 2018, constituted a Committee on NHS, with the following composition:
Chairman of the Committee |
---|
Shri J. Satyanarayana, (Former)Chairman, UIDAI & Former Secretary, MeitY |
Members |
---|
Shri Sanjeeva Kumar, Additional Secretary, Ministry of Health & Family Welfare |
Special Chief Secretary(Health), Government of Andhra Pradesh |
Additional Chief Secretary(Health), Government of Madhya Pradesh |
Mr. M. S. Rao, President & CEO, National eGovernance Division (NeGD) |
Shri Alok Kumar, Advisor(Health), National Institution for Transforming India (NITI) Aayog |
Shri Lav Agarwal, Joint Secretary(eHealth), Ministry of Health & Family Welfare |
Nominee of Secretary, Ministry of Electronics and Information Technology |
Nominee of CEO, National Health Authority(NHA), Ministry of Health & Family Welfare |
Dr. Neeta Verma, Director General, National Informatics Centre (NIC) |
Shri Gaur Sunder, Joint Director, Centre for Development of Advanced Computing, India |
Director(eHealth), Ministry of Health & Family Welfare |
Composition & ToRs of the Sub-Groups formed by the Committee
Sub-Groups | Chairman | Deliverables |
---|---|---|
Scope, Principles & Services | Shri Lav Agarwal, Joint Secretary (eHealth), Ministry of Health & Family Welfare (MoHFW) |
|
Building Blocks & UHID | Dr. Neeta Verma, Director General, National Informatics Centre (NIC) |
|
Standards & Regulations | Mr. Jaideep Mishra, Joint Secretary, Ministry of Electronics and Information Technology (MeitY) |
|
Institutional Framework | Shri Alok Kumar, Advisor(Health), National Institution for Transforming India (NITI) Aayog |
|
Comparative analysis of 4 Initiatives on facility registries
NIN | ROHINI | NHRR | PMJAY | |
---|---|---|---|---|
Background | Initiative by MoHFW to create a registry of Hospitals inthe country | Different stand-alone entities, each with its own trust anchor, establish trust-based interactions with each other. | Multiple entities contribute to a decentralized digital identity; user controls sharing of identity data | Multiple entities contribute to a decentralized digital identity; user controls sharing of identity data |
Process Owner | ICHI | IRDA | CBHI | NHA |
Coverage | 250,000 public facilities from sub centres upwards | 15,000 private facilities who are active in health insurance | Public and private facilities including clinics, diagnostic centres (Going on - likely to be > 10,00,000) | 14,000 public and private facilities empanelled under PMJAY |
Basic Info | YES | YES | YES | YES |
Detailed Info | NO | NO | YES | YES |
Process to Update | YES | YES | Under Development | YES |
Incentive for facilities to participate | NO | YES | NO | YES |
Trusted Data | Verified by district administration | Verified by insurer/TPA | Respondent based | Verified by district administration |
Comparative analysis of 3 archetypes for UHID
Centralized | Federated | Decentralized | |
---|---|---|---|
Definition | A single organization establishes and manages the identifiers | Different stand-alone entities, each with its own trust anchor, establish trust-based interactions with each other. | Multiple entities contribute to a decentralized digital identity; user controls sharing of identity data |
Level of Adoption & Trust | Adoption dependent on value; trust dependent on system owner and identity proofing | Adoption dependent on establishing trust relationship; trust dependent on identity proofing | Trust dependent on trust anchors and attestations |
Strengths | Can be built with specific purpose in mind; potential for organizational vetting of identity data | Users can access a wider range of services; efficiency for organizations | Increased user control and reduced amount of information collected and stored by organizations |
Challenges | Generally low usercontrol; centralized risk and liability; potential for abuse | Generally low usercontrol; high technical and legal complexity | Governance model, acceptance and participation is complex; evolving landscape; complex liability |
Mistakes to be avoided in designing EHR
Status of 8 existing IT-driven organizations
Institution/ Organization |
Type | Ownership | Services | Mandate |
---|---|---|---|---|
NSDL | For Profit Organization | Equity stake of multiple banks public and private and National Stock Exchange | NSDL provides various services in the capital market like, clearing members, stock exchanges, banks and issuers of securities | To serve the nation with technology, trust and reach and ensure that every Indian became a prudent investor |
UIDAI | Statutory | Ministry of Electronics and Information Technology (MeitY) | Unique Identification numbers (UID), named as "Aadhaar", to all residents of India | To provide good governance, efficient, transparent and targeted delivery of subsidies and benefits to residents of India through assigning of unique identity numbers |
GSTN | Not for Profit Organization | The central and state governments own 49% equity and Balance 51% equity is with non-Government financial institutions | The GST System Project is a unique and complex IT initiative that implements a uniform tax regime across the country | To become a trusted National Information Utility (NIU) which provides reliable, efficient and robust IT backbone for the smooth functioning of the Goods & Services Tax regime |
NIHFW | Autonomous organization, under the Ministry of Health and Family Welfare, Government of India | Ministry of Health and Family Welfare | NIHFW is housing the National Health Portal | The National Health Portals mandate is collecting, verifying and disseminating health and health care delivery services related information to all citizens of India |
NPCI | Not for Profit Organization | Consortium of 56 Banks public and private | Payment Gateway Services | To touch every Indian with one or other payment services |
NIC | Associated Office of Ministry of Electronics and Information Technology (MeitY) | Ministry of Electronics and Information Technology | IT services to the Government of India. Some key services managed by NIC for the Ministry of Health and Family Welfare and CHI include RCH, Mother Child Tracking System (MCTS), Online Registration System (ORS), Beneficiary Identification system (BIS) etc. | Provide the technology backbone to all Govt. departments |
CHI (NIHFW) | Autonomous organization | Ministry of Health and Family welfare | Managing IT programmes/Project under MoHFW like NHP, various dashboards of ministry, NCD-CPHC application, Mera Asptaal, NIN, HWC IT platform, PMSMA IT system, mHealth | To develop IT solutions for MoHFW and to provide authentic access to the health information for citizen of |
NHA | Authority | Chaired by Health Minister, has cross functional team for health sector | Implementing Running of PMJAY | To develop IT components important to health sector |
Illustrative list of digital services to be provided by NDHM
S. No. | Name of the Digital Service provided |
---|---|
Citizen/Patient Services | |
1 | Single, Secure Health Id to all citizens |
2 | Personal Health Record |
3 | Single (National) Health Portal |
4 | App Store |
5 | Specialized Services for Remote Areas/Disadvantaged Groups |
6 | NDHM Call Centre |
7 | Digital Referrals & Consultations |
8 | Online Appointments |
9 | e-Prescription Service |
10 | Digital Child Health |
11 | National "Opt-out" (for privacy) |
Services by / for Healthcare Providers / Professionals | |
12 | Summary Care Record |
13 | Open Platform to access Emergency Services |
14 | Technology for Practitioner (GP) Transformation |
15 | Digital Referrals, Case Transfers |
16 | Clinical Decision Support (CDS) |
17 | Digital Pharmacy & pharmacy Supply Chain |
18 | Hospital Digitization (HIS) |
19 | Digital Diagnostics |
Technical Services | |
20 | Architecture & Interoperability |
21 | Health Information Exchange |
22 | Standards |
23 | Health Network |
24 | Data & Cyber Security |
25 | Information Governance |
Indicative set of principles of governance of federated architecture
Website Policies | Terms & Conditions | Copyright 2017· All rights reserved | Last Updated On: