In part one, we explored how interoperability is crucial not only in exponentially-growing digital societies, but specifically within healthcare to ensure better care coordination and service delivery. In part two, we included a walkthrough of the first steps in building interoperability between health systems and the CHT.
In part three, the final blog of this series, we explore how Open Health Information Exchange (OpenHIE) provides a modular framework for developing interoperable, scalable, and sustainable health information systems (for systems to successfully exchange data, a standard format of this data must be adhered to). We also explore key terminologies, discuss the implementation details, and highlight potential improvements for the CHT with the interoperability configuration.
To achieve interoperability, we utilised a middleware that converts the CHT data into a standardised format. Fast Healthcare Interoperability Resources (FHIR) and Open Health Information Mediator (OpenHIM) were utilised to implement a Loss to Follow-Up (LTFU) system in cht-interoperability that is designed for the CHT.
Terminology
OpenHIE is a framework for building health information systems that are interoperable, scalable and sustainable. The reference technology behind the OpenHIE framework is OpenHIM. This is an open-source middleware technology that provides a central point for managing and monitoring health information exchange activities. OpenHIM has three main layers.
Architecture Components Layer
This layer includes 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. The Registry Services component supports registries with data used by other health exchange components.
Interoperability Layer
Data exchange between the CHT and any other external system happens in this layer utilising FHIR standards and OpenHIM. It provides a standardised way for healthcare systems to exchange data, regardless of the underlying technology or data formats used by each system.
Point of Service Layer
Healthcare providers and other users can access the system through the point of service layer. This layer typically consists of applications, such as electronic medical record systems (EMR) systems, clinical decision support tools, and mobile health applications.
Implementation
The sequence diagram below highlights the interaction between the requesting system, OpenHIM mediator, and FHIR resources such as Endpoint, Organization, Patient, Encounter, and Service Request. The implementation of the LTFU system builds upon these five information exchange resources. The requesting system in our sequence diagram is any system capable of making HTTP requests to the Mediator with authentication access. The OpenHIM mediator handles data translation and processing before forwarding a request or carrying out a request’s intent on FHIR or CHT.
Below is a description of the process:
- Create Endpoint: The sequence begins with creating an Endpoint, representing the callback location for future notifications. This Endpoint is necessary for successful Service Request creation.
- Create Organization: An Organization is created, utilising the previously established Endpoint. This step ensures that each requesting system has an associated Organization with a valid Endpoint.
- Create Patient: Patient creation is automatically handled by CHT via the Mediator. It requires essential details such as a unique identifier, name, gender, and birth date.
- Loss to Follow-Up Workflow: The actual LTFU workflow begins with sending a Service Request document to the Mediator. This request includes the intent, subject (Patient), and requester (Organization). The Mediator processes the request, validates the patient and organisation, and creates a Subscription on the FHIR Subscription resource.
- CHW Task Creation: The Mediator assigns a task to the Community Health Worker (CHW) responsible for the patient. When the CHW syncs with CHT, they receive the notification, complete the task, and sync it back to CHT.
- Triggering Subscription: CHT performs an outbound push to the Mediator with the patient identifier, triggering the Subscription listening for the LTFU event. The Encounter and Subscription details are returned to the requesting systems callback endpoint.
You can test the LTFU workflow on these instances:
Improvements and Iteration
While the current LTFU workflow is functional, there are potential areas for improvement:
- Subscription Cancellation: The current workflow lacks the ability to cancel subscriptions or LTFU requests. A proposed improvement suggests implementing a mediator-based solution that enables cancellation and better management of LTFU requests.
- Requesting System Interactions: Enhancements can be made to facilitate interactions between the requesting system, the community health information system, and a CHW. This includes cancellation of requests, checking the status of LTFU requests, and handling retries for unreachable callback URLs.
Conclusion
The CHT database reflects the CHT documents structure that required translation into FHIR standards. There were two approach options to ensure adherence to FHIR standards during data exchange with external systems. The first approach meant building an interoperability layer based on the OpenHIE standards allowing other FHIR compliant systems to exchange data with the CHT. The second meant rebuilding the CHT data structure to comply with the FHIR standards. The first approach meets the interoperability requirements and ships out faster than the second option. The second approach would have a protracted shipping period as the entire data structure would have been rebuilt in its entirety, hence we built an interoperability layer.
The implementation of the LTFU workflow – utilising these standards – demonstrates the power of interoperability in healthcare systems; CHWs and caregivers at the facility level can use this interoperability feature between the CHT and other external systems including facility based systems such as EHRs and EMRs. Users of these systems can access and use this data to make data driven decisions while interfacing with other systems as well.
OpenHIE provides a robust framework for building scalable and sustainable health information systems within the digital health ecosystem. These systems, with an architecture based on this framework, are easier to ship and maintain at a lower cost, while FHIR ensures the standardization and flexibility necessary for data exchange.
As we close this blog series, we encourage readers to review our Github repository and send comments, questions, and feedback on the repository or via the CHT forum.