- 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 coresponding Fhir 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.
- OpenMRS Point of Care system
- OpenMRS FHIR2 module: This module already exists as an OpenMRS artefact and artifact and is actively under development. its sole responsibility will be to generate FHIR bundles upon request
- Source MySQL Databse .
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 POC 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.
- 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.