Introduction
This forum post will review how we used OpenHIE specification, more precisely FHIR and OpenHIM in cht-interoperability, a Loss to Follow Up system designed for CHT.
Terminologies
Let’s start by familiarising ourselves with the basic OpenHIE terminologies we’ll use throughout this post. Let’s begin by defining OpenHIE. Open Health Information Exchange (OpenHIE) is a framework for building health information systems that are interoperable, scalable and sustainable. OpenHIM has three main layers.
These are:
- Architecture Components Layer
- Interoperability Layer
- Point of Service layer.
The Architecture Components Layer comprises two sub-components, the Business Domain Services and Registry Services. The Business Domain Services component supports specific health system business domains with the potential to combine Health Exchange data from multiple point-of-care systems. Registry Services component support registries with data used by other health exchange components.
The Interoperability layer acts as a bridge between different healthcare systems, allowing them to communicate with each other and share data. It provides a standardised way for healthcare systems to exchange data, regardless of the underlying technology or data formats used by each system. The OpenHIE unique technology we used in this project lies in this layer, which is Fast Healthcare Interoperability Resources (FHIR) and Open Health Interoperable Mediator (OpenHIM).
Fast Healthcare Interoperability Resources (FHIR) is the standard format for storing interoperable health resources. FHIR prioritises flexibility, ease of implementation, and interoperability. For this project, we store all health data using FHIR and utilise the FHIR specification in our user-facing endpoints to ensure consistency across systems when exchanging data.
Open Health Information Mediator (OpenHIM) is an open-source middleware technology that provides a central point for managing and monitoring health information exchange activities. OpenHIM offers a wide range of features such as Security (access control, authentication, authorisation) and Auditing (transaction logs, audit trails, performance monitoring).
The last layer, the Point of Service Layer in OpenHIE, represents the system’s front end, where healthcare providers interact with the HIE to access patient data and submit requests for data exchange. The POS layer typically consists of applications, such as electronic health record systems (EHR) systems, clinical decision support tools, and mobile health applications. In this project, the CHT and the requesting system act as the point of service layer in the OpenHIE interoperability specifications.
Implementation
Now that we understand the terminologies of OpenHIE, we can discuss Medic’s implementation of the Loss to Follow-Up System using FHIR and OpenHIM in cht-interoperability. Let’s take a look at the system sequence diagram below:
The requesting system in our sequence diagram is any system capable of making HTTP requests to the Mediator with authentication access. The OpenHIM mediator is a mediator that handles data translation and processing before forwarding a request or carrying out a request’s intent on FHIR or CHT.
In the sequence diagram above, we use five FHIR information exchange resources. These resources are Endpoint, Organization, Patient, Encounter and Service Request. Since FHIR has a loose schema with most fields optional, we had to extend FHIR and ensure that fields critical to the Loss To Follow-Up workflow are required while the rest remains optional.
The sequence diagram starts with the “Create Endpoint” request to the Mediator; this request requires the connection type, identifier and address to be present. Please, note that these requirements are extensions and not part of the FHIR standard. This document represents the Endpoint at which the requesting system wants to receive a callback in the future. An Endpoint is required for each Organisation in the system to ensure they can create a successful Service Request.
After creating the Endpoint, the next step is to create an Organisation that utilises the Endpoint created in the last step. Creating an Organisation requires only two fields, the Organisation’s name and Endpoint reference, which ideally should’ve been created in the previous step. Once again, these field requirements aren’t part of the FHIR standard but are extensions. Service Requests require Organisations during creation, and the Organisation must have an Endpoint on which it will receive callbacks. Creating an Organisation or Endpoint is to be done once for each Organisation requesting system, and it’s not a recurring action for every Loss To Follow Up workflow.
The next step is to create a Patient. In this case, CHT automatically creates a Patient in FHIR through the Mediator on every patient creation in CHT. We utilise CHT outbound push functionality to handle the automatic creation of Patients whenever a CHW syncs CHT servers. Patient creation requires the following fields: the identifier, a unique identifier for the patient from CHT; the patient’s name, gender and birth date.
After creating an Endpoint, Organisation, and Patient, we can begin the actual Loss to Follow Up workflow. The workflow starts by sending a Service Request document to the Mediator. The following fields are required to create a Service Request: the intent of the request, the subject (Patient) of the request and the requester (Organisation). The Mediator processes the service request by extracting the patient details from the subject field and validating the patient; then, it validates the Organisation from the requester field and retrieves the Endpoint associated with the Organisation; it then creates a Subscription on the FHIR Subscription with the patient id as the matching for a future Encounter and the Organisation Endpoint as the callback.
After the Mediator has extracted the request details and created a Subscription on FHIR, the Mediator creates a record on CHT assigned to the CHW in charge of the patient. In the future, when the CHW syncs with CHT, they will be notified of the new task they are required to carry out, and once it is completed and synced to the CHT, CHT will create an outbound push to the Mediator with the identifier matching the Patient, to ensure that the Subscription listening for the Loss To Follow Up event gets triggered. Once the Subscription is triggered, the Encounter and Subscription details get sent back to the requesting system callback endpoint.
Improvements
There are some improvements to be made to the current Loss to Follow Up workflow. Cancelling subscriptions or Loss to Follow Up requests is impossible in the current workflow. A GitHub ticket on the cht-interoperability repository proposes an improvement to the LTFU workflow in OpenHIE related to intercepting the FHIR subscription request. The proposed workflow suggests using a mediator to facilitate communication between the requesting system, CHIS, and CHW. The Mediator would be able to cancel requests, and the requesting system would also be able to cancel LTFU requests and check up on them. The proposed solution includes a SubscriptionDocument interface and identifies missing features, such as verifying the requesting system for a subscription update and handling retries on the Mediator for callback URLs that aren’t reachable.
Conclusion
In conclusion, OpenHIE specification offers a framework for building interoperable, scalable, and sustainable health information systems. The OpenHIM middleware technology is critical in facilitating data exchange between different healthcare systems, providing a central point for managing and monitoring health information exchange activities.
FHIR standard format prioritises flexibility, ease of implementation, and interoperability, making it an ideal choice for storing interoperable health resources. Using FHIR and OpenHIM, Medic successfully implemented the Loss to Follow-Up system in cht-interoperability. The system sequence diagram outlined the steps and resources required to establish the loss to follow-up workflow. The system’s design ensures that healthcare providers can interact with the HIE to access patient data and submit Follow Up requests to CHT, which gets assigned to the appropriate CHW.