The architecture has been designed to support an integrated approach to patient-level indicator reporting.
In this setup, different types of point of service (POS) systems that are able to share patient-level data as FHIR can participate by sending data to a Shared Health Record.
Our focus, however, is on OpenMRS as a POS system.
High Level Architectural Diagram For Both Streaming And Batch Modes
The architecture depicts how longitudinal client data will be retrieved from an instance of OpenMRS and sent to a Shared Health Record residing on a HAPI FHIR server via an Interoperability Layer Both in Batch and Streaming Modes Using the OpenMRS Analytics Engine which supports both Streaming and Batch modes using the Streaming and Batch Apps.
- The Streaming App is built on top of Apache Camel and an embedded Debezium Engine will track DB changes in the source OpenMRS database by reading the MySQL binary log , and then fetch the corresponding FHIR Resources from the OpenMRS FHIR2 module and send the FHIR Resources through camel routes to Shared Health Record via an Interoperability Layer.
- The BatchApp is built on top of Apache Beam. This will Extract a bundle of FHIR resources at once and send that data to the Shared Health Record via an Interoperability Layer.
The HAPI FHIR server will serve as a repository for Shared Health Records as well as FHIR MEASURE resources that will be used for computing the reporting indicators (TX_PVLS in this case).
Below are the main components of the Architecture:
OpenMRS Point of Service system
- OpenMRS FHIR2 module: This module already exists as an OpenMRS artifact and is actively under development. its sole responsibility will be to generate FHIR bundles upon request
- Source MySQL Database .
This will be configured to generate Database level logs
- OpenMRS Analytics Engine.
This component will Extract Fhir resources from the OpenMRS using FHIR2 module Both in Streaming and Batch Modes and send the data to an Interoperability LayerInteroperability Layer (IOL)
- Interoperability Layer (IOL)
The interoperability layer will sit at the heart of data exchange. It will receive transactions from the OpenMRS POS instances and relay them to a longitudinal client record residing in the Shared Health Record. Open Health Information Mediator(OpenHIM), a reference IOL application, will be used for this purpose. We will leverage the OpenHIM Mapping Mediator to perform any necessary validations and transformations before sending data to the Shared Health Record.
OpenHIM will also Patient Demographic resources to a Client Registry (OpenCR) to help manage patients.
OpenCR This will act as the client registry to facilitate the exchange of patient information between the different POS systems. It will hold both patient identifiers and patient demographic information.
- HAPI FHIR Server
The HAPI FHIR server will act as both the Shared Health Record and a repository for FHIR measure resources definitions. The Shared Health record will store client longitudinal records relating to clinical encounters. The FHIR measure resources will form the basis for the calculation of the reporting indicators.