Personal Health Records, Electronic Health Records Key to India’s National Digital Health Mission Comment Letter

The HIMSS India Chapter provided public comments based on National Digital Health Mission (NDHM) stakeholder discussion. The NDHM aims to develop the key building blocks supporting the unified digital health infrastructure in the country that will provide seamless and secure access, exchange, and use of electronic health information (EHI).

The implementation of national EHR is a complex task and it requires serious well thought out planning backed with strong global healthcare informatics expertise. A badly designed national EHR system will not only be a pain for clinicians for but also could endanger patients as we have seen in other countries where the cost of redesign is significant. We strongly feel that there are significant gaps and opportunities for improvement in the current approach laid out by National Health Authority (NHA) and it requires serious reconsideration.

In this regard, the HIMSS India Chapter would like to provide recommendations to ensure a well-defined plan to address the gaps based on the National Digital Health Blue Print final version of the document and NDHM stakeholder discussion.

Overview of Key HIMSS India Chapter Public Comments

The Basics of PHR vs. EHR

As Minster of State Health & Family Welfare Hon’ble Shri. Ashwini Kumar Choubey has mentioned that the implementation of NDHB would ensure the interoperability of data, creation of standardized “EHR” and providing continuum of care. The NDHM architecture shared in the stakeholder discussion has mentioned building only a “PHR.” However to achieve the key objectives of NDHM we need to ensure that we have both EHR as well as PHR as part of the minimum viable architecture.

Electronic Medical Record (EMR)—An electronic record of health-related information on an individual that can be created, gathered, managed, and consulted by authorized clinicians and staff within one health care organization.

Electronic Health Record (EHR)—An electronic record of health-related information on an individual that conforms to nationally recognized interoperability standards and that can be created, managed, and consulted by authorized clinicians and staff across more than one health care organization.

Personal Health Record (PHR)—An electronic record of health-related information on an individual that conforms to nationally recognized interoperability standards and that can be drawn from multiple sources while being managed, shared, and controlled by the individual.

Swasthya Account

Unique identification of persons, facilities, diseases and devices is a key requirement as well as a challenge in the National Digital Health Ecosystem (NDHE).

The Blueprint handles this requirement through two building blocks, viz. Unique Health Identifier (UHID) and the Health Locker.

The minimum viable architecture of NDHM doesn’t have any mention of Master Person Index (MPI). The ability to automate the process of matching records and maintaining cross reference index of identifiers for individuals and organizations is seen as a key enabler for efficient and accurate UHID. The UHID matching logic should support both deterministic and probabilistic matching algorithms, using multiple attributes with agreement and disagreement weight. The UHID matching logic should support techniques like person name and address standardization and phonetic encoder to increase the accuracy and effectiveness.

HIMSS has long been involved in leading private sector efforts to improve patient matching. HIMSS strongly supports the use of matching algorithms as part of an overall patient matching strategy, which should include work to create a benchmark measurement for algorithms that have already been developed and to be developed in future.

The HIMSS India Chapter strongly recommends to allocate an independent identifier as the UHID. The independent identifier can be linked to identifiers from other national person identifier systems. This approach will enable the flexibility of UHID data stewardship. For a patient or an organization registry in particular, the ability to support standards-based APIs that allow it to be seamlessly integrated and to support Personal Health Record, is seen as a key enabler of health information exchange. We strongly recommend to leverage the Integrating the Health Enterprise (IHE) based profiles for the patient, provider and facility registry. Globally National EHR systems have adopted the IHE. IHE produces Profiles using FHIR R4 for core functionality.

Some of the solutions that address the requirements of Patient Registry include additional functionality that enables implicit and explicit creation of Family Taxonomies, Provider Organization Member/Employee Taxonomies, Care Team taxonomies, etc., as a side effect of registering patients, family members, beneficiaries, doctors, providers, etc. It is suggested that considering a solution that includes this functionality would be advantageous.

Digi Doctors

The EHR has two key dimensions i.e. the physician view and patient view. The Health Locker addresses the ability to store PHR but how the doctors will be able to access patient’s family history, allergies, vital signs, etc. need to be mentioned in detail. In addition to the Health Locker there is a need to have unified portal for clinicians and citizens to access their health records.

Patient/Person/Doctor/Provider Registries are in production used as part of EHRs at national and regional level, and independently in hospital and hospital group contexts in many countries in the world including Australia, Canada, Norway, UK, United States and elsewhere. Support for standards-compliance, vendor product compliance, availability of practical industry experience and international health systems experience could be drawn upon from the lessons learnt and best practices.

Health Facilities Registry

HIMSS India recommends NDHM to evaluate standards based registries compliant with IHE and FHIR R4. In particular, IHE Profile - Healthcare Provider Directory (HPD) can be looked at to harmonize healthcare provider and facility registries. The Healthcare Provider Directory (HPD) profile supports management of healthcare provider information in a directory structure. HPD directory structure is a listing of the following two categories of healthcare providers that are classified by provider type, specialties, credentials, demographics and service locations:

• Individual Provider: A person who provides healthcare services, such as a physician, nurse, or pharmacist.
• Organizational Providers: Organizations that provide or support healthcare services, such as hospitals, counseling organizations, healthcare information exchanges (HIEs), nursing homes, diagnostic laboratories etc.

Typical provider information maintained by the directory is demographics, address, credential and specialty information as well as electronic endpoint to facilitate trusted communications with a provider. The directory can also maintain relationship.

Approach on Single Central Registry vs. Multiple Registries

National Health Registries are expected to be the single source of truth for master data pertaining to various health-sector stakeholders.

This process would, over time, build and maintain a cross-reference index of all identifiers associated with each entity (e.g., Aadhaar, Jan Dhan, driver's license number, etc.), a history of all source records associated with the unique identifier and a history of all changes to the entity master record and its corresponding source records.

A single central person registry may not be optimal for the population of India. It may be advantageous to consider a 2-/3-level hierarchy of person registries, with central registry consolidating registrations from existing registries such as ROHINI, state-based registries and perhaps these consolidating registrations from smaller administrative divisions or groups of healthcare organizations.

This model would permit the lookup of person details across the geographic and administrative boundaries while localizing the search and improving the retrieval efficiency, and distributing the maintenance burden amongst operators of registries. We suggest this on the basis that most patients will receive services in their local areas and seek services elsewhere only on relatively few occasions.

Consent Manager

It is important that NDHM leverages well defined consent management frame work. There are several consent models used by HIEs and the consent management framework should be flexible to adopt varying needs of the citizens.

• No consent: Patient health information at a participating healthcare organization is automatically included in and available through the HIE (Note: This is not recommended, and is rarely used).
• Opt-out: All or some pre-defined data sets are qualified to be included and available for exchange, after patients are given the opportunity to opt out in full.
• Opt-out with exceptions: All or some pre-defined data sets are qualified to be included and available for exchange after patients are given the opportunity to:
  • opt out in full,
  • selectively exclude categories of data or specific data elements from the exchange,
  • limit exchange of their information to specific providers or provider organizations, and/or
  • limit exchange of their information only for specific purposes.
• Opt-in: No patient data sets are made available for electronic exchange until patients actively express whether they would like to make all, or a pre-defined set, of their information available.
• Opt-in with restrictions: No patient data sets are made available for electronic exchange until patients actively give their consent to participate. Patients have the option to:
  • make all of their information available for exchange,
  • include only specific categories of data or data elements,
  • allow information to flow only to specific providers, and/or o allow the exchange of their information only for specific purposes.
• The stakeholder discussion has a specific mention about opt-in model for voluntary citizen participation in the NDHM. There are several countries globally tried opt-in model and their adoption is very limited and very recently Australia has moved to Opt Out model and since then their adoption rate has increased significantly.
• HIMSS India recommends NDHM to explore Opt Out based model which will increase the adoption of EHR. The Consent Management framework envisaged by NDHM should have adequate flexibility to change Opt-In to Opt Out or with/ without restrictions as the need arises in future. At this point NHA is trying to retrofit the consent framework developed for the financial services industry in NDHM and it may not be a best approach given the complexities involved in healthcare consent model.

Data Exchange vs. Health Information Exchange

The minimum viable architecture of NDHM shared in the stakeholder discussion has a specific mention of “data exchange.” There is a significant difference between “data exchange” and “health information exchange.”

The HIE is the cornerstone of any national EHR implementation. The National Digital Health Blue Print (NDHB) has specially called out “HIE” as a critical capability to be a part of the key building blocks. In similar lines Health Domain Metadata and Data Standards document released by Ministry of Health & Family Welfare has clearly called out the need for “Health Information Exchange.”

The data exchange is one of many capabilities in HIE. Health information exchange offers many benefits that EHRs, in general, do not, such as:

• Care coordination—This is a dynamic process that requires data movement across platforms and among service providers in real time. Many EHR systems, in spite of being developed by the same company, do not talk to each other, creating delays and decreasing the value of the system.
• Record Locator Services/Master Patient Indexes—Enable creation of one continuous community record, facilitating patient identification across multiple provider settings.
• Data exchange—HIE provides support for vocabulary and code sets including content mapping, terminology normalization and enable data transactions to occur automatically across multiple providers and settings.
• Data aggregation and analysis—This includes clinical data aggregation across health information exchange partners, as well as data analytics and warehousing.
• Clinical messaging—Standard HIE services often include laboratory results, emergency room notes, medication lists, discharge summaries, progress notes, radiology results and surgical notes.
• Secure messaging between providers—HIEs can be used for generalized communication between physicians in different healthcare entities and/or using different EHRs.
• For instance, providers needing to send transition of care documents for consultations or referrals can use HIE services to eliminate sending paper documents, and to expedite the patient's treatment.
• HIE Workflows
  • Patient intake—Using an HIE's query and response process, the patient's summary clinical record can be pre-fetched and available immediately when the provider wants to look at it.
  • Patient exam—A physician can utilize an HIE to access the appropriate patient data from other sources, such as other providers and hospitals. The physician can then select certain patient documents (such as medication lists and reconciliations, allergy lists or lab reports) that they want to have filed in their local EHR for access during a patient visit.
  • Query services—Physicians may want to obtain more information about a patient that is referred to their office. They can query their local HIE and, using the record locator services profile, the local HIE can query other HIE service providers to assemble a full PHR.
  • Transitions of Care (TOC)—As patients make the transition from one care setting to another (such as from hospital to clinic), HIE services allow the documentation from one care setting to be easily accessed from the next.
  • Referrals—Organizations have the ability to send referrals directly through the HIE/HIO, along with all the appropriate documentation.
  • Lab results—HIE services provide physicians with the ability to get results directly through the HIE.

Adoption of Standards in NDHM

Compliance to agreed Industry standards makes any system more universal, adaptable and interoperable. The National Digital Health Blueprint clearly mandates the use of EHR Standards recommended by MoHFW and FHIR Standards by HL7.

In addition Ministry of Health & Family Welfare has invested significant effort to promote SNOMED-CT in India. Bureau of India Standards (BIS) & National Resource Center for EHR standards have played a key role in defining healthcare standards in India.

It is important that the NHA leverages the standards as mandated in the NDHB. We therefore urge the NDHM to uphold this commitment.

Terminologies and code sets standardized by the industry bodies or Standards organizations, may change over time, may be versioned and perhaps may be cross-mapped to other terminologies where terminology domains overlap to a significant degree, making it possible for the user to use one or another terminology for coded data for the same subject entities.

Terminology normalization would typically be required when semantic interoperability of clinical information is desired. The PHR would require terminology normalization if, for example, different laboratories use different medical terminologies to code the same laboratory tests. Terminology normalization can be externalized as an Enterprise Terminology Service, which would both serve as a terminology/code registry for the various standard and local terminologies and as a service that provides transformation between semantically equivalent codes in different terminologies or different versions of the same terminology.

It seems advantageous to implement the terminology registry as not just the registry for code lookups but also as a terminology transformation service.

The health information exchange should have the ability to handle terminology normalization. Clinical and Business Data Dictionaries may be standardized by standards bodies, industry bodies and the government entities. The structure may vary but is likely to include the code and its definition, perhaps temporal validity and similar system attributes that would aid in search and determination of the applicability and validity.

Transparency and Competitive RFP Process for NDHM Implementation

The HIMSS India Chapter strongly feels that there should be an open, transparent and competitive RFP process to implement all the key building blocks of NDHM. Indian Software Products Industry Round Table (iSPIRT) has developed National Health Stack and they had conducted series of webinars to promote their health stack.

We ask NHA to clarify the reasons for allowing iSPIRT to develop these solutions while there was a formal RFP for PMJAY 2.0 in place. We believe that iSPIRT being an advisor and moderator should have facilitated the process instead of building their own health stack.

Based on the architectural and skillset requirements as highlighted above in the document, a transparent discussion on Build vs. Buy should happen giving chance to Health IT vendors to compete and present the best solution. We ask NHA to consider an open and transparent RFP process and select vendors with proven expertise to implement key building blocks of NDHM.

Regulatory Framework

The draft data protection bill was submitted to the Electronics and IT Minister Hon’ble Shri. Ravi Shankar Prasad by the BN Srikrishna Committee. The proposed legislation is being reviewed by the Joint Parliamentary Committee. An initiative on personal health records should ideally succeed this bill, so that the health records are compliant with all the regulatory requirements.

HIMSS India Chapter strongly supports the focus on advancing interoperability, supporting the access, exchange, and the use of Electronic Health Information (EHI) and will continue to emphasize the need for the well-defined architecture, adoption of healthcare standards and strategic roadmap in implementing a successful national EHR and a transparent RFP process to enable NDHM building blocks across the entire stakeholder community.