How to build an HRP service
ABDM digital health architecture
Using the Federated Health Records framework (FHR), patients can access and view their health records, and provide consent to any HIPs and HIUs to access their data. This works in two ways:
Any HIU can request a patient’s information from an HIP, and obtain it through patient’s consent.
Any HIP can directly request the patient for consent to access their information.
Patients can also selectively share their data with any HIU or HIP through the patient’s mobile interface in the FHR Framework. FHR Framework removes the limitations faced by patients and medical practitioners, enabling all parties involved to make informed decisions and ensure better, and more seamless, quality of care.
Components
Health data consent manager (HDCM)
The HDCM helps to create or discover existing ABDM ABHA Number, manages patient linkages to providers, manages consent for access to health information, helps discover patient information and monitors information exchange between HIP and HIU. Currently all of this is done through Patient App.
Health information gateway
The gateway connects and validates the HDCMs and health repositories (servicing HIUs and HIPs) to the network. It Enables routing of information and also authenticates connected systems within the FHR Framework
Registries
Health Facility registry (HFR), Doctor or practitioner registry (DigiDoctor) and HDCM and Health Repository Provider (HRP) Registry are National level Registries that are integrated with the network
HRP
Health repository providers are software service providers who offer ABDM compliant software and long-term record storage to hospitals, diagnostic centers and clinics.
HIP
Any healthcare provider who creates health information in the context of providing healthcare related service to a patient and agrees to share the same digitally with the patient using the consent framework adopted by ABDM is called a health information provider (HIP).
HIU
Any entity that would like to access health records of an individual is called a Health Information User. This would include hospitals / doctors who would like to view medical history of patients, mobile applications that want to display health data to users including Personal Health Record applications, etc.
Health locker services
Health locker provides a personal digital storage for users/patients.
How to Implement HRP Service
Architecture
The following image depicts Architecture of HRP service.
Approach
The above diagram follows the following approach:
The HRP service would behave as a bridge between the clinic/hospitals and the gateway.
All the clinics/hospitals would need to subscribe to the HRP service and generate their unique HFR ID.
HRP service maintains a map of HRFID to instanceID/instanceURL.
Gateway would just talk to HRP service and HRP service using the map would route the calls to different instances.
On-Boarding New Facilities
ABDM support two methods to onboard health facilities:
Facility declared process – In this process, the health facility is expected to sign up on the Health Facility Registry and then link the ABDM compatible HRP software it plans to use.
HRP declared process – The HRP can declare the presence of the health facility in the Health Facility registry (HFR) via an API. The HRP can then link their software with the Facility ID obtained from the declaration.
Reference: https://sandbox.abdm.gov.in/docs/hrp_facility_add
FAQs
FAQs on ABDM and Bahmni compliance
Reference materials
ABDM On Github (NHA repository with diagrams)
https://medblocks.org/abdm-for-the-ap-government-a-honest-review/
The Bahmni documentation is licensed under Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)