The National Health Authority (NHA) under the Ministry of Health and Family Welfare, recently published a consultation paper on the Health Facility Registry (HFR). This registry is being introduced as a singular database on healthcare facilities, as opposed to the current system, where data on hospitals, clinics, and so on are scattered across several verticals under the health ministry. The system is currently operational on a pilot basis in six Union Territories of the country.
Main principles of HFR
- Voluntary opt-in and opt-out
- Facility ID that will ensure contents are unique and that there is only one entry for each facility
- Entities in the registry will be maintaining their information themselves
- Verification trail for changes made in the registry
- Linkages to existing databases
This consultation paper comes nearly a year after the Indian technology lobby group iSPIRT, as part of the National Health Stack, proposed a system of consented sharing of health information between healthcare providers (such as hospitals, pathology labs) and healthcare users (such as doctors). The present paper has many similarities in this regard; for instance, the introduction of registries that will ‘store master about entities — users, organisations or systems’, consented data sharing, and so on. The Health Facility Registry also finds a mention in the draft implementation strategy of the National Digital Health Mission (NDHM) which was released recently. In the draft, the government describes HFR as one of the core blocks of the NDHM.
It is important to note that the system is operational in the 6 UTs of the country. Now, this consultation paper was prepared after taking responses from those involved in the pilot project, and they raise concerns regarding the efficacy of the proposed system. These concerns are —
- Involvement of the private sector and how they can be effectively engaged in the project without compromising security and safety considerations of data usage
- Current status of lack of internet connectivity and penetration in certain parts of the country
- Resistance to the adoption of technology by stakeholders
Apart from being a database repository of healthcare facilities, the HFR consultation paper gives an insight into the overarching system that the National Health Authority is proposing for the integration of healthcare facilities into the system. We will touch on the main components that are being proposed under the HFR, before going into it a little deeper later.
- HFR Data refers to the consented information or data attributes given by each health facility.
- Health Facility Verifier refers to a government or a private entity which will verify the data attributes put in by health facilities.
- HFR Organisation/Programme refers to entities that will grant licenses, certifications, and so on for health facilities
- Open APIs, integrated through the National Digital Health Mission (NDHM) Sandbox, will help entities in the HFR ecosystem interact with the registry.
Minimum identification data required for all
The HFR Data refers to the information or data attributes for each health facility. These attributes include administrative information that can be used to uniquely identify and locate a facility. While facilities will have the option to choose if they want to provide data such as financial details, a minimum dataset is compulsory. They include —
- Facility contact person details
- Facility details
- Type of service
- Ownership type and others
Detailed information, which the healthcare facilities may opt-out of providing in the registry, includes information on departments and services, medical and civic infrastructure, quality metrics and accreditation, and so on.
Health Facility Verifier will have a separate platform
A ‘Health Facility Verifier’(HFR) refers to an independent, third-party legal entity enrolled in NDHM that is responsible for the verification of data in the HFR. Currently, in the pilot which is being done in the six UTs, the registry is verified by the UT administration. For one to be eligible to become an HFR, the entity can be a —
- Government entity
- Partnership under the Limited Liability Partnership Act
- Societies incorporated under Indian Societies Registration Act
- A trust
- A private company registered under Indian Companies Act
The HFR may enter data, collect evidence, verify the data in the HFR. The verification process can either be taken up by using a platform developed by NDHM or the entity may build its own alternate platform and integrate with NDHM with the help of APIs.
“Under this alternative, NDHM may build the technology portal as a common building block and then allow other players in the market to replicate the platform; individual organisations eligible to become a Health Facility Verifier and enrolled in NDHM have the freedom to develop independent data verification platform for verification of Health Facilities, provided that the platform complies with the guidelines set by NDHM and is integrated with HFR using NDHM APIs,” the consultation paper said.
‘HFR Organisation can verify data for business purposes’
HFR Organisation/ Programme Entities are entities engaged in activities including but not limited to granting licenses and certification to health facilities, implementing the government health and insurance programmes, empanelling hospitals as insurance companies and third-party administrators, and actively utilising a health facility’s data in the aforementioned activities.
They can be a —
- Body recognised by central or state government
- Body that has been entrusted with the implementation of government health programmes or schemes.
- Body that has been entrusted to implement activities pertaining to government health insurance programmes or schemes.
- Any private or autonomous body involved in granting empanelments or certifications to health facilities
This particular entity can integrate with the HFR either by using APIs developed by NDHM or by conducting “independent verification of HFR data for their business purpose”. If they choose to do so, the consultation paper says that the matter has to be notified to the HFR via the API.
Information to be made available using Open APIs
The National Digital Health Blueprint plans to, with the consent of health facilities that will be onboarded, open-source some of the information held in the registry. This information will be made accessible via Open APIs and NDHM sandboxes, where stakeholders may choose to integrate and test their solutions.
The consultation paper lists stakeholders who can integrate with the HFR using Open APIs and Sandboxes —
● Consumer Healthcare/Technology Organisations
● Development Organisations and NGOs
● Financial Institutions
● Pharmaceutical and Medical Equipment Industry
● Academia and Research Institutes
● Industry Organisations
How will the data be managed in HFR?
All data in the HFR, unless verified by a Health Facility Verifier or an HFR Organisation/Programme, shall be presumed as ‘self-declared’ by the health facility, the consultation paper said. Once the verification has been undertaken and the final data has been communicated to HFR, the status of that particular data field shall be updated to ‘Verified’ or a blue tick will appear next to the field, signalling that the field is verified, the consultation paper said.
Reliable data standards —
- HFR Data once created cannot be deleted or modified without following due process
- Any data in HFR may be ‘amended’ with a new version number of the same data with any changes
- All data created and submitted in HFR must be traceable to its creator
- All creation, amendments, and access of data should be audit logged in a manner that is verifiable and reliable.
- The Facility Manager will be able to access/view their own data anytime, and control the access of others by sharing their consent at every instance of data sharing with other stakeholders
iSPIRT proposed this system a year ago
In 2020, as part of the National Health Stack, which iSPIRT describes as ‘foundational building blocks which be built as SHARED digital infrastructure, usable by both public sector and private sector players’, iSPIRT touched on the creation of a registry for healthcare facilities. The present form of HFR proposed in this consultation paper has many similarities to the iSPIRT version.
> Registry: The very concept of creating an electronic registry system wherein both healthcare providers and healthcare facilities was first proposed by iSPIRT in their ongoing discussion regarding the National Health Stack. Although most of the discussions that iSPIRT has had regarding the topic, details of which are available on its website, are around the healthcare providers’ registry, at one point, iSPIRT says, “these registries allow for efficient discovery and authentication of doctors, hospitals, and other healthcare providers.”
>Insurance: While talking about the benefits of the National Health Stack, iSPIRT had emphasised faster settlement of insurance claims and easier empanelment. This finds a mention in the consultation paper, in a section which is titled ‘incentives for government insurance schemes’. The consultation paper says that the HFR registry will help in creating ‘transparency in the empanelment process’ and will facilitate ‘time-bound’ processing of all applications.
Open APIs: The reliance on APIs was extensively discussed in iSPIRT in open house discussions that were comprehensively covered by MediaNama. Although the area of discussion regarding APIs by iSPIRT was mostly regarding Health Information Providers and Health Information Users, the usage of open APIs for the Health Facility Registry prompts the question: was this also proposed by the lobby group?
Also read
