Expectations: share common ground and efforts, learn from each other, explore architecture options, share reusable components like routes. Context Shared interested expressed from Mekom, UCSF, MSF/Madiro, METS How to balance between backed-in development and integration with existing All looking for vertical and horizontal interoperability (hori: LAB, billing, stock, and verti: MPI, SHR, reference lab system) Samuel: UgandaEMR is using UgandaEMR Sync module to send out FHIR data, which includes a UI for profiles/resources/sync/logs. Scope: HIV surveillance, ART access, LAB requests ALIS, eCBSS, HTS, ART regimen, TB, HIV exposed infant, Client registry, SHR, Cross border Roadmap: not receiving data at the moment, only sending from facilities. Data consolidation/conflict resolution is pending too. Be careful with scoping, first with the knows, then the unknowns. Need to scope out what belongs to OpenMRS and what belongs to OpenHIE. Ex: intero with OpenMRS or others?
Romain: Using Apache Camel with XML routes, no UI at the moment, can also write JAVA routes. Questions around using OpenMRS as a start point. Ideally looking at a more centralized architecture, looking at OpenMRS as a FHIR client. Need a place to handle FHIR messages. Ex. FHIR → ODOO or FHIR → ERP Next. Approach: prioritizing Event bus (like EIP) rather than scheduler. Using API to get events + notifications. Also looking for queues services for handling flows, load of data, statuses, conflicts.
Eudson: What about more synchronous use cases like a patient needing medication → inform pharmacy in SENAITE and billing in ODOO. Be careful of the meaning of the data, ex. drug order.
Michael: Early stage, looking at common use cases and architectures Scope: lab tests requests and results (within and outside facility), referrals between facilities, sync with master patient index
Next steps |