Prelude
Toward the goal of implementing Central Personalized Health Information management DGHS-MIS has taken an initiative to implement Shared Health Record System, where all patient clinical data will be stored centrally to enable health data sharing in standard secured channel.The Shared Health Records (SHR) system in Bangladesh is a national initiative aimed at improving the quality and accessibility of healthcare services in the country. It was developed by the Ministry of Health and Family Welfare.
Shared Health Records – The Central HIE of Bangladesh
The SHR system comprises several modules, including the Module Master Client Index (MCI), which is responsible for creating and maintaining a unique health ID for each patient. Other modules include the Electronic Medical Records (EMR) module, which allows healthcare providers to create and manage patient records, and the Health Analytics and Reporting module, which provides insights into healthcare trends and outcomes at the national level. The MCI also helps to avoid duplication of patient records, ensures data accuracy, and facilitates patient tracking and monitoring.
One of the key benefits of the SHR system is that it enables the sharing of patient data among different healthcare providers. By enabling the exchange of clinical records among hospitals and clinics, the Shared Health Records system serves as a central health information exchange for the country. This can help to improve the quality of care, reduce medical errors, and facilitate research and public health initiatives. This means that if a patient visits multiple hospitals or clinics, their health records can be accessed by any authorized provider, regardless of where the records were originally created. This can improve the continuity of care and reduce the risk of medical errors.
Another benefit of the SHR system is that it enables public health initiatives and research. By aggregating data from across the country, the system can provide insights into disease patterns and healthcare outcomes. This information can be used to inform public health policies and programs, as well as to identify areas where further research is needed.
Overall, the Shared Health Records system is an important step towards improving healthcare in Bangladesh and achieving the goal of universal health coverage for all citizens. It has the potential to transform the healthcare landscape in the country and serve as a model for other countries seeking to digitize their healthcare systems.
SHR the central system is designed such a way that it can accommodate integration to any Electronic Medical Record Management system in global standardized protocol such as FHIR, ICD-10, Loinc etc. SHR provides Health Information Exchange API for external Facility/Community based EMR’s, so that any health system can implement and exchange data.
Standardization of Process and Prospects
The Shared Health Records (SHR) system in Bangladesh is built on top of OpenHIE (Open Health Information Exchange), which is a global framework for health information exchange.
OpenHIE provides a set of standards, tools, and processes for building interoperable health information systems. It includes several components, such as the Facility Registry, Provider Registry, and Terminology Registry, which are also part of the SHR system in Bangladesh.
The Facility Registry is a central repository of information about healthcare facilities, such as their location, services offered, and contact information. This information can be used to help patients find the right healthcare provider and to coordinate care between different facilities.
The Provider Registry is a database of healthcare providers, such as doctors, nurses, and other healthcare professionals. It includes information about their qualifications, licensure, and contact information. This information can be used to verify the credentials of healthcare providers and to facilitate the sharing of patient information between providers.
The Terminology Registry is a repository of standardized medical terminologies, such as Loinc and ICD-10. These terminologies provide a common language for describing medical conditions, procedures, and medications, which can help to improve the accuracy and consistency of patient records.
By using OpenHIE components, the SHR system in Bangladesh is able to leverage existing standards and tools to build a more robust and interoperable health information exchange. This can help to reduce duplication of effort and improve the sustainability of the system over time.
EMR System Enrolment Process
In order to participate in the Shared Health Records (SHR) system in Bangladesh, all healthcare facilities and providers need to be enrolled in the system. The Directorate General of Health Services (DGHS) Management Information System (MIS) has prescribed a process for enrolling facilities and providers in the SHR system.
Healthcare facilities can enroll in the SHR facility registry by submitting an application to the DGHS MIS. The application includes information about the facility, such as its location, services offered, and contact information. Once the application is approved, the facility is given a unique identifier, which is used to link its records in the SHR system.
Similarly, healthcare providers can enroll in the SHR provider registry by submitting their information to the DGHS MIS. The provider registry includes information about the provider’s qualifications, licensure, and contact information. Once the provider is approved, they are given a unique identifier, which is used to link their records in the SHR system.
Enrolling healthcare facilities and providers in the SHR system is an important step in ensuring that patient data is accurately and securely recorded in the system. It also helps to improve the quality and coordination of care, by allowing healthcare providers to access patient records across different facilities and settings.
Overall, the process for enrolling healthcare facilities and providers in the SHR system is a critical component of the system’s success, and it demonstrates the commitment of the government of Bangladesh to improving healthcare outcomes for its citizens.
Any EMR System needs to go through the enrolment process in order to start data exchange with SHR. First Prerequisite for System enrollment is to register the requesting facility in the central Facility Registry and get a Facility Code. Once the Facility is registered, then the System Enrolment needs to be done in the following process described below,
The Requesting organization need to Apply for enrolment in a prescribed format
Figure 1: EMR Enrolment Process
System Integration
The Shared Health Records (SHR) system in Bangladesh provides APIs (Application Programming Interfaces) that allow authorized healthcare providers to securely exchange patient data with the system. The APIs can be accessed using secure credentials that are authorized by the DGHS MIS.
Once a hospital or clinic has been authorized and given access credentials, it can integrate the SHR APIs into its own EMR (Electronic Medical Record) system. This allows the hospital to exchange patient data with the SHR system, and to access patient records that have been created at other facilities.
By using the SHR APIs, healthcare providers can securely exchange patient data in real-time, which can help to improve the quality and coordination of care. For example, if a patient visits a hospital in one part of the country and then later visits a different hospital in another part of the country, their records can be accessed by the second hospital using the SHR APIs. This can help to ensure that the patient receives appropriate care, regardless of where they are being treated.
When an EMR (Electronic Medical Record) system initiates integration with the Shared Health Records (SHR) system in Bangladesh, they are provided with technical documentation that describes how to use the SHR APIs.
By providing APIs for all the HIE registries, the SHR system enables healthcare providers to securely exchange patient data and to access information about healthcare facilities and providers in real-time. This helps to improve the coordination and quality of care, and ultimately, the health outcomes of patients in Bangladesh.
The technical documentation provides detailed information about the API endpoints, parameters, data formats, and authentication mechanisms that are used to access the SHR system. It also includes examples of how to use the APIs in different scenarios, such as retrieving patient records, submitting lab results, or updating patient demographics.
The technical documentation is typically provided by the DGHS MIS (Directorate General of Health Services Management Information System), which is responsible for managing the SHR system. It is designed to be used by software developers who are familiar with programming languages and web technologies, and who are responsible for integrating the EMR system with the SHR system.
The technical documentation is a critical component of the integration process, as it provides the necessary information for the EMR system to communicate with the SHR system and exchange patient data securely and reliably. By providing clear and comprehensive technical documentation, the DGHS MIS helps to ensure the success of the integration and the interoperability of healthcare systems in Bangladesh. The reference document is available at the Appendix A
Overall, the SHR APIs are an important component of the system, as they enable secure and interoperable exchange of patient data between different healthcare providers and facilities. This helps to improve the continuity and quality of care, and ultimately, the health outcomes of patients in Bangladesh.
Appendix – A
The Shared Health Records (SHR) system in Bangladesh provides separate APIs for all the Health Information Exchange (HIE) registries, the Master Client Index (MCI), and the Patients Medical Encounter Registry.
The HIE registries include the Facility Registry, Provider Registry, and Terminology Registry, which are used to manage and share information about healthcare facilities, providers, and clinical terms and codes. The APIs for these registries allow authorized healthcare providers to retrieve and update registry information, as well as to search for relevant data using various search parameters.
The Master Client Index (MCI) is the registry that contains individual patient records and provides a unique health ID for each patient. The MCI API allows authorized healthcare providers to retrieve and update patient records, as well as to search for relevant data using various search parameters.
The Patients Medical Encounter Registry is the registry that contains information about individual patient encounters with healthcare providers, including diagnoses, treatments, and other clinical information. The API for this registry allows authorized healthcare providers to retrieve and update encounter information, as well as to search for relevant data using various search parameters.
The Shared Health Records (SHR) system in Bangladesh provides an API for single sign-on (SSO) using the Human Resource Information System (HRIS) as the authentication source.
The HRIS is a centralized database that contains information about healthcare workers, such as their names, roles, and contact details. It is used by the Directorate General of Health Services Management Information System (DGHS MIS) to manage the workforce in the healthcare sector in Bangladesh.
The sign-in API allows healthcare workers to authenticate themselves to the SHR system using their HRIS credentials. Once authenticated, they can access the APIs for all the HIE registries, including the Master Client Index (MCI) and the Patients Medical Encounter Registry, with a single credential and token.
By using the HRIS as the authentication source, the SHR system provides a centralized and secure way for healthcare workers to access patient data across different healthcare facilities and settings. This helps to ensure the confidentiality and privacy of patient information, while also making it easier for healthcare workers to access the information they need to provide high-quality care.
Through providing separate APIs for each of these registries, the SHR system enables healthcare providers to access the specific information they need in a secure and efficient manner. This helps to improve the quality and coordination of care, by allowing healthcare providers to access and share patient data across different facilities and settings.
Location Registry
The purpose of location registry is to uniquely identify geographical locations in a country – often in terms of administrative setup. This allows to identify patients location and care services location uniquely.
-
Get Locations
Request (GET)
https://{lr_service}/locations/list/{level}?updatedSince={ISO8601 formatted date}&limit={limit}&offset={offset}
Headers :
X-Auth-Token : {auth token assigned while user registration in HRM}
client_id : {client id of requester in Identity Service Provider}
The level field can contain one of the following :
- division
- district
- upazila
- paurasava
- union
- ward
Get Single Location Information
Request
method. GET
url
http://hrmtest.dghs.gov.bd/api/1.0/locations/{geoCode}.json
Headers :
X-Auth-Token : {auth token assigned while user registration in HRM}
client_id : {client id of requester in Identity Service Provider}
Response:
{
“code”: “1020”,
“id”: “1020”,
“name”: “Example Location”,
“name_BN”: “”,
“type”: “district”,
“active”: 1,
“updatedAt”: “2016-10-02 13:19:57”,
“hierarchy”: [
{
“code”: “10”,
“name”: “Example Parent Location”,
“name_BN”: “”,
“type”: “division”
},
{
“code”: “20”,
“name”: “Example Location”,
“name_BN”: “”,
“type”: “district”
}
]
}
BHIE
For Bangladesh, the geographical codes for locations are unique for a specific hierarchy.
The code sequence
| Division
code |
Zilla
code |
Upazilla/
Thana code |
Union/
Ward code |
Mauza/
Mahalla code |
Village
code |
RMO
code |
Name |
| XX | XX | XX | XX | XXX | XX | X | XXXXXX |
Facility Registry
Context
The purpose of Facility Registry is maintain a national health facility registry. Its main job is to maintain all locations where health services are provided.
API
The api is based on Facility Registry Expansion Development (FRED) api project.
Get Facilities
Request :
GET {fr_server}/facilities/list?limit={limit}&offset={offset}&updatedSince={ISO8601 formatted date}
Headers :
X-Auth-Token : {auth token assigned while user registration in HRM}
client_id : {client id of requester in Identity Service Provider}
Sample Response :
Get Single Facility Information
Request :
GET {fr_server}/facilities/{facility_code}.json
Headers :
X-Auth-Token : {auth token assigned while user registration in HRM}
client_id : {client id of requester in Identity Service Provider}
Provider Registry
Context
In “HIE” context, provider registry describes “who provides services” to a patient.
API
The broad categories of “providers” are:
* physicians, dentists, pharmacists
* physician assistants, nurses, scribes
* midwives, dietitians, therapists, optometrists, paramedics
* medical technicians, laboratory scientists, prosthetic technicians, radiographers
* community health workers, social workers, professional home carers, official volunteers
* receptionists handling patient registration
* IT personnel in facilities maintaining patient records
* Teachers, Researchers
BHIE
In Bangladesh Context, providers are managed in HRM system. While keeping the API consistent with FHIR practitioners would have been ideal, HRM doesn’t necessarily keep the data as par FHIR resource.
For example, Provider name is a simple string, whereas FHIR Practitioner expects as HumanName format.
- Get Providers
Request :
GET {pr_server}/providers/list?limit={limit}&offset={offset}&updatedSince={ISO8601 formatted date}
Headers :
X-Auth-Token : {auth token assigned while user registration in HRM}
client_id : {client id of requester in Identity Service Provider}
Sample Response :
[
{
“name”: “Example Provider”,
“url”: “http://{pr_server}/providers/18.json”,
“id”: 18,
“active”: 1,
“createdAt”: “2014-11-27 15:23:23”,
“updatedAt”: “2014-11-27 15:23:23”,
“birthDate”: “1965-10-10”,
“gender”: “Male”,
“organization”: null,
“identifiers”: [
{
“system”: “DGHS”,
“value”: 18
},
{
“system”: “NationalId”,
“value”: null
},
{
“system”: “PDS”,
“value”: “2”
}
],
“telecom”: [
{
“system”: “phone”,
“value”: “18912”
},
{
“system”: “email”,
“value”: “drmizanur65@yahoo.com”
}
],
“address”: {
“text”: “UHC, Doctor Quater”
},
“properties”: {
“maritalStatus”: “Married”,
“freedomFighter”: “2”,
“tribial”: “Not Tribal”,
“qualification”: null,
“category”: “Physican”,
“discipline”: “N/A”,
“department”: null,
“attendanceid”: null,
“professionalDiscipline”: “N/A”,
“machineid”: null
}
}
]
Get Single Provider Information
Request :
GET {pr_server}/providers/{provider_id}.json
Headers :
X-Auth-Token : {auth token assigned while user registration in HRM}
client_id : {client id of requester in Identity Service Provider}
Sample Response :
{
“name”: “Example Provider”,
“url”: “http://{pr_server}/providers/18.json”,
“id”: 18,
“active”: 1,
“createdAt”: “2014-11-27 15:23:23”,
“updatedAt”: “2014-11-27 15:23:23”,
“birthDate”: “1965-10-10”,
“gender”: “Male”,
“organization”: null,
“identifiers”: [
{
“system”: “DGHS”,
“value”: 18
},
{“system”: “NationalId”,
“value”: null
},
{
“system”: “PDS”,
“value”: “2”
}
],
“telecom”: [
{
“system”: “phone”,
“value”: “18912”
},
{
“system”: “email”,
“value”: “drmizanur65@yahoo.com”
}
],
“address”: {
“text”: “UHC, Doctor Quater”
},
“properties”: {
“maritalStatus”: “Married”,
“freedomFighter”: “2”,
“tribial”: “Not Tribal”,
“qualification”: null,
“category”: “Physican”,
“discipline”: “N/A”,
“department”: null,
“attendanceid”: null,
“professionalDiscipline”: “N/A”,
“machineid”: null
}
}
Login API
Overall, the sign-in API is an important component of the SHR system, as it enables healthcare workers to securely access patient data using a single set of credentials. This helps to streamline workflows and improve the efficiency and effectiveness of healthcare delivery in Bangladesh.
All systems making any HIE api call (except for Terminology Service) must have an “API Token”. This token must be passed as “X-Auth-Token” header while making an API request.
To put in a very simplistic fashion, the following are the steps
The system and an user account for the system must be setup in the central Identity Provider (IdP). Please see the documentation regarding onboarding a system/facility for SHR integration.
This is an offline process: an organization will request the authority (DGHS) for access to HIE (naming the components that they want to access) with intended purpose. There will be policies that the participating organization will have to comply and upon resolution of such aspects, the authority will grant access to the organization.
Once the setup is done, the organization will be given the following details
API Token – this is a long living token and disclosed to and used only by organizations who have gone through the above procedure.
client_id – disclosed only to the organization, and this must be communicated with every API request
registered email and password for the user of that organization
Get hold of an “access_token” from the central Identity Provider (IdP)
Make an HTTP POST to the IdP login api. see below for info
an “access_token” will be returned. this access token is short lived and can be invalidated too by the user.
Make service calls with the “access_token” passed.
Subsequent API calls to any HIE services, should pass only the “access_token”. Note, at no point should you be sending your “API TOKEN” to any other service other than the IdP login service.
Authorization
Each service is responsible for deciding on authorization independently. This authorization decision depends on requesters profiles setup in IdP. For example, an organization can have rights to create a patient but not a clinical encounter. See below for more information
Additional details
Even trusted systems like SHR or MCI or other DGHS apps, must register themselves with HRM system as organizations. for example as “SHR @ DGHS MIS” or “MCI @ DGHS MIS”. An api token is created for systems and provided and configured with the system beforehand.
Any invalid request with non-matching CLIENT_ID and X-Auth-Token, will result in HTTP 401 (unauthorized) error.
IdP API details
- Login using IdP API
Request :
POST http://{IdP-URL}/api/1.0/sso/signin
Headers :
client_id = {client id of the user representing the organization}
X-Auth-Token = {Secret API Token given to the user representing the Organization}
Form Data :
email = {user email}
password = {user password}
Example response on successful login (HTTP Status code 200)
- {
“access_token”: “UXmbhELOU47hC5bA7rvvtx2lMuePIF1kOTgyVAhcAX”,
}
Example response on failed login (HTTP STATUS code 404)
- {
“error”: true,
“message”: “Not authenticated“,
“code”: 401
}
- Logout using IdP API
Request :
POST http://{IdP-URL}/api/1.0/sso/signout/{access_token}
Headers :
client_id = {client id of the user representing the organization}
X-Auth-Token = {Secret API Token given to the user representing the Organization}
content-type :application/x-www-form-urlencoded
Form Data :
email = {user email}
password = {user password}
- Get user info from access token
Request :
GET http://{IdP-URL}/api/1.0/sso/token/{access_token}
Headers :
client_id = {client id of the user representing the organization}
X-Auth-Token = {Secret API Token given to the user representing the Organization}
Accessing a service/resource provider
As explained earlier, once an “access_token” is received, you may call other HIE APIs. All API calls must accompany the following details.
with headers:
client_id = (client id of the user representing the organization)
X-Auth-Token = (access token fetched earlier)
from = (email id of the requester, one thats used for login)
More on authorization
There are 4 types of requester of a service or resource provider:
systems – facilities and other DGHS systems/apps
providers – CHWs, doctors etc
admins – administrators of services (example SHR, HRM or other DGHS apps etc)
individual users – patients
The above can be broadly categorized into human (provider, admin, individual users) and non-human users (facilities, other DGHS systems/apps)
A user can have multiple profiles; example: a user can be a provider, a patient herself. or a user can be a patient while he/she can be an administrator of a particular region.
IdP (HRM) will have such user/client information as profiles; so that each user can have multiple profiles. The service/resource provider makes its own decision to authorize a request based on user profile and groups user is associated with.
Identifying the catchment of a requester
Many services and applications like SHR, MCI, MCI admin applications need to find out the catchment of the requester to allow operations limited only to the catchment defined for the requester. For example: a facility can sync only their catchment patients, or MCI admins can approve updates only for patients in their defined catchment areas. IdP may send the catchment information as part of the profile info.
Systems (facilities, DGHS apps etc) – Each facility depending on its location and type has a catchment defined for it in facility registry. By default this is determined by the type of facility and their physical location, unless overridden.
Providers – If the requester is attached to a facility, then their catchment is that of the facility (as explained above) unless overridden.
Admins (administrators of services like SHR, HRM or other DGHS apps etc) – are associated with administrative areas.
Individual user (patient) – no catchment is defined.
For example: the following userinfo may be returned to the service provider, when they try to identify the requester (example, someone is trying to create/POST a patient). Note the profiles associated.
| {
“id”: 6, “name”: “Dr. X Y Z”, “email”: “xyz@gmail.com”, “is_active” : true, “activated”: true, “activated_at”: null, “last_login”: “2015-01-20 09:52:58”, “access_token”: “xyz_token”, “created_at”: “2014-09-04 13:26:14”, “updated_at”: “2015-01-20 09:52:58”, “deleted_at”: null, “groups”: [“MCI Admin”, “API Consumer”], “profiles”: [ { type: “provider”, id: “123”, catchment: [“302618″,”302614”] }, { type: “admin”, id: “2”, catchment: [“3026”] }, { type: “facility”, id: “10000069”, catchment: [“302618”] }, { type: “patient”, id: “10091232131”, catchment: [] } ] } Appendix B Form 1: Facility System Enrollment Form |