What Does UHI Stand for in ABDM? Unified Health Interface Explained

This does not mean UHI is exactly the same technology or architecture as UPI or ONDC. The comparison is useful for understanding the broader idea of an interoperable network.

What Is UHI in ABDM?

The Unified Health Interface is an open digital health network concept intended to connect healthcare service providers with applications through standardized protocols.

The objective is to allow users to discover and access healthcare services through different digital applications without requiring every application to establish a separate, proprietary integration with every healthcare provider.

For example, imagine a patient wants to find a doctor for an online consultation.

Without an interoperable network, an application may need individual integrations with numerous healthcare providers.

With a UHI-based ecosystem, the application can interact through the standardized network to discover participating providers that match the patient’s requirements.

A simplified model is:

Patient

↓

End User Application

↓

UHI Network / Gateway

↓

Healthcare Service Provider Application

↓

Doctor / Hospital / Diagnostic Provider

The actual technical architecture and protocol flows are more detailed, but this model captures the basic concept.

Why Was UHI Introduced?

Healthcare is highly fragmented.

A patient may use:

• One app for doctor appointments
• Another app for teleconsultation
• A hospital’s own application
• A separate diagnostic platform
• A separate ambulance service
• Another application for health records

Healthcare providers also use different:

• HMIS systems
• EMR systems
• Hospital applications
• Appointment systems
• Telemedicine platforms
• Laboratory systems

When these systems operate independently, healthcare services can become difficult to discover and access across platforms.

ABDM aims to build an open and interoperable digital health ecosystem. The official ABDM FAQ describes the mission as promoting healthcare digitization and creating an open interoperable digital health ecosystem through common health data standards and core modules that allow different digital health systems to interact.

UHI addresses an important part of this challenge:

How can different digital applications and healthcare service providers interact through an interoperable network?

How Does UHI Work?

At a conceptual level, UHI connects two major sides of the digital health ecosystem:

1. End User Applications

These are applications through which users search for and access healthcare services.

For example, an application may allow a user to:

• Search for doctors
• Find hospitals
• Book appointments
• Book teleconsultations
• Find diagnostic services
• Discover ambulances
• Access other digital healthcare services

2. Health Service Provider Applications

These applications represent healthcare service providers offering services through the network.

They may include systems used by:

• Hospitals
• Clinics
• Doctors
• Diagnostic centres
• Telemedicine providers
• Ambulance providers
• Other healthcare service providers

The official ABDM description specifically describes UHI as an open network of End User Applications (EUAs) and participating Health Service Provider (HSP) applications.

What Is an End User Application in UHI?

An End User Application (EUA) is the application through which a user interacts with digital healthcare services.

For example, a user might enter:

“Find a cardiologist available for teleconsultation tomorrow.”

The application can send the search request into the UHI ecosystem.

Participating healthcare service provider applications can respond with matching services.

The EUA can then present relevant options to the user.

The ABDM UHI hackathon documentation demonstrates this concept through appointment-booking workflows where a user searches using parameters such as:

• Doctor name
• Doctor HPID
• Hospital/clinic
• Specialty
• System of medicine
• City
• Language
• Availability date
• Appointment type

The UHI Gateway can broadcast the search, while participating HSP applications return matching results.

What Is a Health Service Provider Application?

A Health Service Provider Application (HSPA) is the application/system through which a healthcare service provider participates in the UHI ecosystem.

For example, a hospital could have an application or healthcare software that manages:

• Doctor availability
• Appointment slots
• Teleconsultations
• Hospital services
• Diagnostic services
• Booking information

If integrated appropriately with UHI protocols, the provider can make eligible services discoverable through participating applications.

This creates a two-sided network:

EUA → discovers healthcare services

HSPA → provides healthcare services

What Is the UHI Gateway?

The UHI Gateway plays an important role in the network architecture.

It facilitates communication between participating applications using the applicable UHI protocols.

For example:

User searches for a doctor

↓

EUA sends search request

↓

UHI Gateway receives/broadcasts request

↓

Participating HSP applications respond

↓

UHI Gateway forwards responses

↓

EUA displays available options

The official ABDM hackathon documentation provides examples of this type of workflow, including /search and /on_search interactions for discovering healthcare services.

The NHA states that it intends to adopt major versions of the UHI open protocol and deploy them on a UHI Gateway operated and maintained by NHA.

What Services Can UHI Support?

UHI is not limited to one healthcare service.

The NHA describes UHI as an open protocol for various digital health services.

The official UHI page currently lists use cases including:

• Teleconsultation booking
• Physical consultation booking
• Ambulance discovery and booking
• Blood bank discovery
• PM-JAY hospital discovery
• Laboratory test discovery and booking

Some services are listed as live while others are identified as coming soon on the current NHA UHI page.

This demonstrates that UHI is intended to become a broader digital health service discovery and transaction network, rather than merely an appointment-booking interface.

UHI for Doctor Appointment Booking

One of the easiest ways to understand UHI is through a doctor appointment example.

Suppose a patient wants to find:

Dermatologist + Noida + Female doctor + Tomorrow + Online consultation

Step 1: User searches

The patient enters the requirements in an EUA.

Step 2: EUA sends the search request

The application sends the search intent through the UHI network.

Step 3: UHI Gateway broadcasts the request

The request can be made available to participating healthcare service provider applications.

Step 4: HSP applications respond

Healthcare providers with matching doctors or services return relevant information.

Step 5: Results are displayed

The EUA presents the available options.

Step 6: Patient selects a doctor

The patient selects the preferred doctor and time slot.

Step 7: Booking workflow begins

The application initiates the appropriate booking transaction.

Step 8: Appointment is confirmed

The provider confirms the appointment.

The official ABDM UHI hackathon documentation describes an end-to-end physical OPD appointment workflow using these types of interactions.

UHI for Teleconsultation

UHI can also support teleconsultation discovery and booking.

A patient can search for an appropriate doctor through a participating application.

The application can discover doctors and available services through the network.

After selecting a provider, the patient can proceed through the teleconsultation booking workflow.

The ABDM FAQ specifically describes teleconsultation through UHI as a mechanism that allows citizens and healthcare professionals to connect digitally.

The current UHI page also lists tele-consultation booking as a live service.

This can be particularly valuable for:

• Follow-up consultations
• Specialist consultations
• Remote areas
• Chronic disease management
• Non-emergency consultations
• Second opinions where clinically appropriate

UHI and Healthcare Service Discovery

One of the biggest advantages of an open network is service discovery.

Consider the traditional model.

A patient wants a laboratory test.

They may have to:

1. Search Google
2. Open multiple websites
3. Compare locations
4. Call laboratories
5. Check availability
6. Ask for prices
7. Schedule an appointment

An interoperable digital health network can potentially simplify this workflow.

A UHI-enabled application could allow the user to search based on parameters such as:

• Test
• Location
• Availability
• Facility
• Service

The ABDM UHI hackathon documentation specifically includes laboratory discovery and booking as a UHI use case.

The current NHA UHI page also lists Lab Test Discovery and Booking among its services.

UHI and Ambulance Discovery

UHI is also being used to support ambulance discovery and booking.

In an emergency, finding an appropriate ambulance quickly can be critical.

A digital application could allow users to search for available ambulance services based on location and other relevant parameters.

The ABDM UHI documentation describes an ambulance discovery workflow in which an application sends the search request to the UHI Gateway and participating HSP applications respond with matching services.

The current NHA UHI page lists Ambulance Discovery and Booking as a live private-sector service.

UHI and Blood Bank Discovery

Another UHI use case is blood bank discovery.

The NHA currently lists Blood Bank Discovery as a live government service on its UHI page.

This illustrates an important feature of UHI:

It is not restricted to a single type of healthcare organization.

The broader network can support different categories of digital healthcare services.

How Is UHI Different From ABHA?

This is one of the most common points of confusion.

ABHA and UHI are not the same thing.

ABHA

ABHA = Ayushman Bharat Health Account

It provides a digital health identity/account for individuals within the ABDM ecosystem.

UHI

UHI = Unified Health Interface

It is an open network/protocol framework intended to enable interoperable digital health services.

A simple way to remember it:

ABHA identifies the individual. UHI helps connect digital healthcare services.

They solve different problems but can work together.

The official ABDM materials identify both ABHA and UHI as components of the broader ABDM ecosystem.

How Is UHI Different From HFR?

HFR = Health Facility Registry.

HFR is a registry containing information about health facilities.

UHI, on the other hand, is designed to facilitate digital health service interactions.

For example:

HFR → “Which healthcare facilities exist?”

UHI → “Which digital healthcare services can I discover/access through the network?”

The two can work together.

In the UHI appointment workflow documented by ABDM, an EUA can use information from HFR/HPR-related systems while displaying healthcare provider information.

How Is UHI Different From HPR?

HPR = Healthcare Professionals Registry.

HPR provides information about registered healthcare professionals.

UHI enables digital service interactions.

For example:

HPR → information about the healthcare professional

UHI → discovery/interaction with the healthcare service

The UHI appointment workflow can use a doctor’s HPID and retrieve relevant doctor information from HPR.

Therefore, UHI, HPR, HFR, and ABHA should not be treated as interchangeable ABDM components.

Each solves a different part of the digital health ecosystem.

UHI vs PHR: What Is the Difference?

Another common confusion is between UHI and PHR.

PHR

PHR = Personal Health Record

It focuses on an individual’s health information and the ability to access, manage, and share health records through supported applications.

UHI

UHI = Unified Health Interface

It focuses on interoperability and discovery/access of digital health services.

In simple terms:

PHR → health information

UHI → healthcare services

Both can contribute to a connected digital health experience.

UHI vs Traditional Healthcare Apps

Traditional healthcare applications often operate as closed ecosystems.

For example:

Hospital App A → Hospital A

Hospital App B → Hospital B

Telemedicine App C → Doctors on Platform C

This can create fragmentation.

An open-network approach aims to change the model:

Multiple applications ↔ Open Protocol ↔ Multiple Healthcare Providers

This can increase interoperability and give users greater choice.

The NHA explicitly describes UHI as an open network and encourages the open-source community to develop protocols for digital health services.

What Are the Benefits of UHI?

1. Greater Choice for Patients

Patients can potentially discover healthcare services through different applications rather than being limited to one closed platform.

The NHA’s ABDM materials specifically identify wider choice of healthcare providers and services as a potential benefit of UHI.

2. Interoperability

Different healthcare applications can interact through common protocols.

3. Reduced Integration Complexity

Healthcare service providers do not necessarily need to build a separate point-to-point integration for every application participating in the ecosystem.

4. Improved Service Discovery

Patients can discover healthcare providers and services based on relevant parameters.

5. Innovation

Developers can build new healthcare applications on top of an open network.

6. More Competition

An open network can allow multiple applications and providers to participate instead of creating dependence on one platform.

7. Digital Healthcare Accessibility

Patients can access healthcare services through participating digital applications.

8. New Business Opportunities for Healthtech Companies

Healthcare technology companies can develop applications and services that participate in the broader UHI ecosystem.

What Does UHI Mean for Hospitals?

UHI can create new opportunities for hospitals.

A hospital participating through an appropriate HSP application could potentially make services discoverable through multiple consumer-facing applications.

For example:

Hospital

↓

Hospital Information System / Appointment System

↓

UHI-Compatible HSP Application

↓

UHI Network

↓

Multiple End User Applications

↓

Patients

This could increase the digital discoverability of:

• Doctors
• Appointment slots
• Teleconsultation services
• Diagnostic services
• Other healthcare offerings

For hospitals, the important consideration is therefore not simply:

“Do we have an online appointment system?”

It is:

“Can our digital healthcare services participate in an interoperable ecosystem?”

What Does UHI Mean for Healthtech Companies?

For healthtech companies, UHI creates an opportunity to build applications that are not restricted to a single provider ecosystem.

A healthtech company could potentially build:

• Appointment applications
• Telemedicine applications
• Healthcare marketplaces
• Diagnostic discovery platforms
• Ambulance discovery platforms
• Healthcare service aggregators
• Specialty healthcare applications
• Patient engagement applications

The key concept is that the application can potentially interact with participating healthcare providers through standardized protocols rather than relying exclusively on proprietary integrations.

The NHA actively encourages developers and the open-source community to contribute to the development of UHI protocols.

UHI and Healthcare Interoperability

UHI should be understood as part of India’s broader move toward healthcare interoperability.

Healthcare interoperability means that different digital health systems can communicate and exchange information or service requests in a meaningful and standardized manner.

Consider a simplified ecosystem:

Patient Application

↕

UHI

↕

Hospital

↕

Doctor

↕

Diagnostic Centre

↕

Other Healthcare Services

Instead of each organization operating inside a completely isolated digital environment, interoperable networks can create connections across the ecosystem.

ABDM’s broader architecture is explicitly focused on interoperability. Its FAQ states that ABDM seeks to enable different digital health systems to interact and facilitate seamless sharing of data across healthcare providers using different digital health systems.

UHI and ABDM: How Do They Fit Together?

It is useful to think of ABDM as the broader digital health ecosystem and UHI as one of its important interoperability/service-network components.

A simplified representation is:

ABDM

├── ABHA

├── HPR

├── HFR

├── PHR

├── UHI

└── Other digital health building blocks

The official ABDM materials identify UHI among the key building blocks of the ecosystem.

UHI therefore should not be viewed as a replacement for ABDM.

Instead:

UHI is one component within the larger ABDM digital health ecosystem.

UHI and ABDM Integration for Healthcare Software

If you are a healthcare software company developing an:

• HMIS
• Hospital Management System
• EMR
• EHR
• Telemedicine platform
• Diagnostic platform
• Appointment system
• Healthcare marketplace

UHI integration can become relevant if your software needs to participate in interoperable healthcare service discovery or transaction workflows.

The implementation depends on the specific UHI use case and the protocols/version applicable to that ecosystem.

A simplified architecture could look like:

                    ABDM Ecosystem
                           │
                    UHI Gateway
                           │
              ┌────────────┴────────────┐
              │                         │
       End User Applications      HSP Applications
              │                         │
       Patient-facing apps       Hospital / Provider
              │                         │
              └────────────┬────────────┘
                           │
                    Digital Services
                           │
        ┌──────────────────┼─────────────────┐
        │                  │                 │
   Appointment       Teleconsultation   Diagnostics
        │                  │                 │
     Hospital             Doctor            Lab

The exact production architecture depends on the UHI protocol implementation, use case, security requirements, and the participating application’s role.

Example: How UHI Can Connect a Hospital With Multiple Apps

Imagine a hospital has 50 doctors.

Traditionally, the hospital may have its own:

• Website
• Appointment application
• Call centre
• Telemedicine system

Patients who use another healthcare application may not be able to discover those doctors.

With participation in an open network, the hospital could make eligible services available through an appropriate HSP application.

Multiple participating EUAs can then potentially discover those services.

This changes the distribution model from:

One hospital → One application

to:

One hospital → Multiple interoperable applications

That is one of the most important strategic ideas behind an open digital health network.

Is UHI a Healthcare App?

No.

This is an important distinction.

UHI is not simply a mobile application that patients download.

It is an open protocol/network ecosystem designed to enable digital health service interactions.

Patients interact with UHI-enabled services through applications.

The NHA describes UHI as an open protocol and the UHI Network as an open network of EUAs and HSP applications.

Therefore:

UHI ≠ mobile app

UHI = open digital health service network/protocol ecosystem

Is UHI Mandatory for Every Hospital?

UHI should not be described as a blanket mandatory requirement for every hospital.

It is an interoperability framework intended to enable digital health services through participating applications and providers.

Whether a particular organization needs to integrate with UHI depends on its use case, digital services, ABDM participation strategy, and applicable requirements.

Therefore, healthcare organizations should avoid treating UHI as simply another mandatory hospital software module.

Is UHI the Same as ABDM?

No.

ABDM is the broader national digital health mission and ecosystem.

UHI is one of its key components.

A simple analogy:

ABDM = broader digital health ecosystem

UHI = open network/protocol layer for digital health services

The official NHA materials list UHI as one of the core components/building blocks of ABDM.

UHI and the Future of Digital Healthcare in India

The long-term importance of UHI goes beyond appointment booking.

An open digital health network could potentially enable increasingly diverse services such as:

• Doctor discovery
• Hospital discovery
• Teleconsultation
• Physical appointment booking
• Diagnostic discovery
• Ambulance services
• Blood bank discovery
• Other healthcare services

The current NHA UHI page already demonstrates several of these categories.

The bigger opportunity is the creation of a healthcare environment where patients can choose the application they prefer while healthcare providers can participate without having to build separate ecosystems for every consumer application.

This can encourage:

Interoperability + Competition + Innovation + Choice

UHI vs Other ABDM Components