In this paper, the NHA lays out its objectives with respect to the UHI, along with information on the interface’s stakeholders, design, management, functioning, and data policy.
The National Health Authority (NHA) has released its consultation paper inviting comments on the Unified Health Interface (UHI) till August 23. The UHI is a part of the NHA’s National Digital Health Mission (NDHM) which was launched in August 2020 and includes other services like the Healthcare Professionals Registry, Health Facility Registry, Unique Health ID, National Digital Health Blueprint, and so on.
Comments on the consultation paper can be submitted through the form on NDHM’s website or via email to email@example.com. The last date to submit comments is August 23.
Why does this matter? Since the NDHM was proposed in August 2020, privacy experts and activists have raised concerns about the possibilities of cyber-attacks, surveillance, profiling, as well as exclusionary consequences of such a system. The mission was first rolled out as a pilot project in six Union Territories. In January, the Ministry of Health and Family Welfare had also allowed the creation of the Unique Health ID upon voluntary authentication through Aadhaar by beneficiaries of various “Health IT applications” (for example, CoWin). It has also been mandatory for receiving benefits under the government’s Aayushman Bharat program.
The UHI is the first part of the health services component of the NDHM on which a consultation paper has been released, thus providing a glimpse of how the final ecosystem will look like and the conditions under which it will be governed.
Salient features of the NDHM
The NDHM has four core registries, namely:
- Health ID: A health ID is a unique identifier that is linked to a person’s health records, their Aadhaar card, and phone number.
- Healthcare Professionals Registry (HPR): This is a recognised registry of healthcare professionals operating within India’s healthcare ecosystem.
- Health Facility Registry (HFR): A single database of all healthcare facilities in India such as hospitals, clinics, etc.
- Health Information Exchange and Consent Manager (HIE-CM): According to NDHM’s data management policy a consent manager will interact with the user and obtain their consent for access to personal or sensitive personal data “where the role of the consent manager will be provided by the NHA or any other service provider”.
Along with this, it has two key entities engaging with NDHM:
- Health Information Providers (HIP) such as hospitals, diagnostic centres, public health programs, and health lockers.
- Health Information Users (HIU) such as citizens, hospitals, public health programs, and health lockers.
Overall architecture of NDHM
According to the paper, the NDHM will have three layers, apart from UHI:
1) JAM and Existing Digital Public Goods:
This layer provides for the NDHM to tie in with other “public health goods” like Aadhaar, Jan Dhan Bank Accounts, and Mobile (JAM), UPI, DigiLocker, eSign, etc.
2) Health Data exchange layer
This layer consists of multiple registries that are a part of the digital health infrastructure –
- Health ID
- Health Information Exchange & Consent Manager
- Health Data Standards (based on FHIR),
- Coding terminology and data aggregation specifications.
3) Health Services Interface
This is the layer that features the Unique Health Interface which will enable interactions between the patients and providers of digital health services, the consultation paper said.
4) User Applications
This is the end-user layer wherein government or private sector apps interact with patients, hospitals, etc. who would like to use or provide data.
“While NDHM may create certain reference applications to demonstrate the capabilities of these layers, it is expected that ecosystem participants from the private and public sector will take a lead in providing diverse user experiences and developing innovative solutions.” — the UHI consultation paper
How will the UHI be built?
Open Network Protocol
The paper said that an Open Network Protocol could be used for dispensing digital health services that are based on shared technical standards which will allow health services providers as well as patients to use one platform. It also added that this is aligned with the strategy paper on National Open Digital Ecosystems (NODE) by the Ministry of Electronics and Information Technology (MeitY).
The paper identifies three building blocks for UHI:
1) UHI Gateway – The NDHM will manage a UHI gateway that service providers can use to deliver services. They can then use the Health Data Exchange layer as, the paper notes, some digital service providers require it. The NDHM will also use registries that are already part of the health data layer to identify entities who could participate in the NDHM. Initially, one gateway will be operational and once the initial stages are completed, scaling to multiple gateways will be considered.
2) Registries: This includes registries like Health ID, HPR, and HFR for identification and verification of entities.
3) Health Information Exchange and Consent Manager (HIE-CM): The HIE-CM building block is for the exchange of health records between the patient and healthcare providers.
To make the software for the gateway, the paper lays out two potential options:
i)Provide a software agency with specifications to do it
ii) Making it open source in case there is strong industry backing
Overall, the paper says that the NDHM will manage two instances for UHI Gateway:
- Sandbox instance for testing, like the NDHM sandbox
- Production instance to deliver a wide variety of health services
Design of the UHI
According to the paper, the Open Protocol of the UHI will be designed through a four-step process involving multiple expert consultations. The paper, however, does not mention how these experts will be chosen or any criteria set in place for them.
- Design by Specification Committee: A committee of ‘technical experts’ with an in-depth understanding of the domain will design, formulate, and publish the initial protocols.
- Expert consultation: Experts from ‘government’, ‘academia’, ‘industry’, and ‘independent’ ones will be invited to be a part of an expert consultation committee that will review and revise the Specification committee’s proposal.
- Public consultation: The UHI specifications will be published and public comments will be invited and considered by the specifications committee.
- Adoption: NDHM will notify the final version to all “UHI players”.
Stakeholders under UHI
The NDHM identifies three stakeholders in the UHI.
- End-Users/ Patients: The users will be able to access their health records, book appointments, get their lab reports,etc. The paper said that end-users will access the interface through End-User Applications (EUAs) built by entities in the private sector such as hospitals, clinics, or other medical aggregators.
- Health Service Providers (HSP): This list includes, but is not limited to:
- Doctors of any system of medicine
- Health service aggregators (platforms that partner with various health organisations to offer services to end-users)
- Home care providers (including home nursing care, teleconsultations, and labs offering home sample collection services)
The NDHM allows HSPs to price themselves flexibly, onboard existing customers and offers to provide them with fair discovery i.e HSPs get immediate access to demand being generated across all End-User Applications irrespective of which app they use. All HSPs that are onboarded are also verified
- Technology Service Providers (TSP) :
The paper defines TSPs as “organisations that provide software interfaces that are compatible with UHI to health service providers and patients.” TSPs can only access services on the UHI network if they satisfy all conditions laid out for the UHI (these conditions are not specified in the paper).
How will the UHI function?
The workflow of the UHI Protocol mentioned in the paper is broken up into five parts:
A user can type in their search query and receive answers related to health services, their pricing, and availability.
How this will happen:
- Users send a service discovery request with a few associated parameters to the UHI gateway.
- The UHI gateway sends this request to all registered HSP to whom this discovery request is relevant.
- HSPs can look at the incoming request and decide if they want to respond or not. If an HSP wants to take up this request, they can respond with details of their service, the price they expect for the service, how they accept payments, and by when they can deliver the service.
- The gateway collates the results and shares the same with the end-user application which presents all the choices to the user.
Some of the services UHI offers are:
- Checking the availability of your doctor
- Booking ambulances
- Discovering the closest lab
After searching through a EUA for a service, the user is shown results in the manner of their choosing i.e earliest availability, lowest price, etc., and not in an order chosen by the HSPs. Upon booking, the charge for the service is calculated as:
HSP price for service + UHI Gateway charges (if any) + EUA service charges
While the paper says that the UHI Gateway charges will be kept very low (at least initially), both the HSP and EUA have a right to set charges. At this stage, the paper says, details like the price for the service, time for service delivery, cancellation charges, and any other relevant parameter are shared.
The paper also provides details on how HSP would ensure quality control over the services it dispenses. Once a user has booked a service, it is the responsibility of the HSP to deliver the service as per its commitments of time, price, and any other parameters shared with the user during service booking.
The paper further said that:
- The HSP must report completion of service fulfillment, and this would be confirmed by the EUA.
- HSPs must take accountability for the quality of service delivered.
- UHI would be responsible for providing logs of the transaction including the time of booking, fulfillment, and payment settlement to both the EUA and HSPs. This information can be used in any dispute arbitration.
- UHI gateway does not participate in service fulfillment.
- Services on UHI may be free or priced as per the needs of the ecosystem participants.
- UHI provides flexibility on who should collect the payment, when it should be collected, and what payment methods are supported.
- Each party needs to settle transactions as per the agreed amounts that were established at the time of service booking.
The paper proposes the institution of a grievance redressal mechanism as well as a rating system for HSPs.
Rating system: All health service providers, services, and users will be covered by a rating system.
- This would be made available to all participants in the ‘ecosystem’. The paper doesn’t clarify which ecosystem: if this is the larger National Digital Health Ecosystem or the ecosystem of all the stakeholders on UHI)
- The paper notes that ‘publicly sourced ratings’ such as on ‘Google’ and ‘Practo’ may not be reliable and thus, it could put in place checks and balances like mandatory disclosure of the name of the person providing such feedback and chance of rebuttal to be given by the healthcare provider.
Grievance Redressal: The paper says that the NDHM will only handle grievances related to the digital open platform health services. It clarifies that grievances pertaining to the quality of healthcare shall continue to be addressed through existing mechanisms used in non-digital interactions.
- For grievances about the platform, the paper has said that the NDHM would digitise the process of grievance redressal.
- Entities such as HSP and EUA found to be in violation of the UHI’s policies will have their new service discovery requests/bookings suspended by the UHI Gateway. However, specific service-based UHI policy and rules for suspension, the paper says, will be formulated in discussion ‘with the ecosystem’.
Data protection and privacy under UHI
The paper said that to ensure privacy, the UHI will have:
- A UHI policy for all participants to abide
- Verification of all entities
- Rating/Reputation system
- Grievance redressal mechanism
Further, the paper said that personal data and business data will not be available to any entity without explicit consent. The UHI would not have access to any data on which HSPs / which patients participated in such teleconsultations and ensure privacy is preserved for Health Service Providers and patients at all times. However, the paper added that anonymised or aggregated data can be provided to policymakers and program managers for decision-making by the government.
What will the UHI potentially do?
The paper lists a few functionalities that UHI provides:
- Discovery of healthcare providers
- Booking an appointment (for both physical/digital consultations)
- Discovery of Hospitals and their facilities
- Discovery of Labs and their services
- Discovery of Pharmacies
- Discovery of availability of medicine
- Discovery of available critical care beds
- Booking an ambulance service
- Booking an appointment for home collection of samples
- Ordering medicines for home delivery
In a table, the paper further elaborates on the NHA’s future plans for UHI.
- Group Consult: This will emerge as a common feature in UHI, where doctors can come together in challenging cases and discuss the best treatment option for a patient.
Health Bots: Patients can sign up with Health Bots that will look at their medical history, send reminders, provide advice based on their trends, and support doctors in managing chronic care.
Full list of questions posed by the NHA for consultation
1. Please refer to section 1.6.3. The Telemedicine Guidelines were issued by The Board of Governors of the Medical Council of India (MCI) in March 2020. Stakeholders are requested to go through them and suggest changes to the policy, if any, to ensure adoption of telemedicine and e-pharmacy. Please note that NHA will act as a coordinator and only forward these suggestions to the appropriate/ concerned ministry
2. As a stakeholder in the health ecosystem, what benefits and risks do you see if an open network approach to digital health services is implemented? Please respond with details.
3. The primary stakeholders in the UHI ecosystem are mentioned in section 3.3. While the list is more indicative than exhaustive, are there any other primary or secondary stakeholders that should be considered while building the interface? If yes, please outline their role in the UHI ecosystem.
4. The proposed objectives of UHI and UHI Network have been detailed in sector 3.4. Please share your comments on the comprehensiveness of these objectives, methods to ensure these objectives are adhered to. Please comment if there are other objectives which must be included in section 3.4.
5. UHI will support a range of digital health services and is expected to evolve with time. What digital health services should the initial version of UHI focus on?
6. Have all incentives / disincentives for various stakeholders to participate been covered in chapter 4? If not, please provide the list and mention the role and description of the stakeholder.
7. For the disincentives mentioned in chapter 4 and as an answer to Question 1 of chapter 4, please provide possible mitigating measures that may be taken to minimize the impact of said disincentives.
8. In the proposed discovery model in section 220.127.116.11 EUAs are expected to present all responses returned by the Gateway to the user and allow the user to choose the HSP. Should any alternate models be allowed? If yes, provide details.
9. Are there any challenges to the proposed approach to the pricing of services detailed in section 18.104.22.168? Please suggest other alternate pricing models that must be supported by the Gateway.
10. Are there any other areas that must be supported by the Gateway for service fulfillment in section 22.214.171.124? If yes, provide details.
11. Post-fulfilment, as described in section 126.96.36.199, covers ratings and grievances. Are there any other areas that must be supported by the Gateway for post-service fulfillment in section 188.8.131.52? If yes, provide details.
12. The proposed approach for allowing users to share ratings for the HSPs as well as EUAs has been laid out in 184.108.40.206. Please comment on the same and share any other approach that might be adopted.
13. What approaches, other than the ones mentioned in chapter 6, should be considered for managing and governing the UHI gateway? Please provide details.
14. What should the UHI Gateway charge in the initial few years of operation? How can this model evolve over time?
15. Please share your views on the duration for which NDHM should manage and govern the UHI gateway, and if NDHM should open the path to multiple gateways. Please provide details on the benefits and risks of the options.
- Summary: Consultation Paper Published on Healthcare Professionals Registry, Public Comments Invited
- A sleight of hand: Understanding the government’s push for linking Co-WIN with Aadhaar