Haiti Health Information Exchange

Owned by Taib
Last updated: Oct 30, 2024 by Beth Dunbar
3 min read

Overview

The following is an overview of the architectural foundations for the Haiti HIE. Système d’Échange d’Information Sanitaire Haïtien (SEDISH) version 2.0 has been designed and implemented using international standards and robust open source products with large international bases of support and experience. The overall SEDISH architecture allows for participating information systems to send messages of a standard clinical exchange format (e.g. HL7v2, etc.) to SEDISH v2.0, which then uses sender and message information to determine the purpose and destination of the message.

SEDISH 2.0 Architecture

Components Overview

OpenHIM: serves as the Interoperability Layer for SEDISH. Through definition of routing channels it enables requests to be forwarded to the intended recipient systems. Through extensions that can be added to it, called mediators, OpenHIM can provide more complex orchestration of requests, such as handling of the XDS.b profile. OpenHIM mediators also enable compatibility with new messaging standards, such as FHIR or CDA version 3, if the need arises.

All transactions that go through the Interoperability Layer are audited and can be inspected. Transaction that fail can be retried from within the admin interface. The IL also provides a centralized point for managing client access to SEDISH.

  1. ISantePlus EMR: Sends patient resource bundle is sent to SHR endpoint and the client registry

  2. The EMR sends lab request to OpenELIS.

  3. OpenELIS: A lab FHIR bundle is sent from from the laboratory information system to the SHR endpoint.

  4. SHR saves the patient and lab bundle : The SHR endpoint accepts the lab bundle and immediately saves it to the HAPI FHIR server. If the save is successful, the request is considered successful, and a success response is returned.

  5. Client Registry: The client compares and matches the patient as received.

  6. SHR Processes the Lab Bundle: The save operation triggers asynchronous workers synchronized via Kafka topics. These workers modify and enhance the lab bundle through several tasks:

  7. Service Request Translation: Codes for service requests are translated to CIEL/standard libraries/IPMS codes through communication with OCL (Open Concept Lab) for proper translation into IPMS HL7 messages.

  8. Location Mapping: Location information is mapped to IPMS locations with associated metadata for later translation into HL7 messages.

  9. Validation: The lab bundle is validated to ensure all required information is present.

  10. HL7 Translation: The enhanced lab bundle is sent to an HL7 translator to be translated into an ADT (Admit, Discharge, Transfer) message for patient registration.

  11. SHR Sends ORM Order Message to IPMS: The ORM message is sent to IPMS (Information Processing Management System) using a MLLP (Minimal Lower Layer Protocol) HL7 client built into the SHR.

  12. SHR Handles Message Results: IPMS processes the order and sends back an ORU (Lab Result) message with the results. These results are handled similarly to the previous steps, ensuring the right patient, task, and service requests are updated with diagnostic requests and observations.

  13. EMR Retrieves Results The ISante Plus EMR queries the HIE for owned tasks that have a status indicating the results are available.