Meeting Notes
Goal of this meeting: Review technical/platform/product decisions; response to issues coming up from community and help set/endorse clear technical direction.
Zoom link: https://om.rs/zoomtac
Detailed Table of Contents
2023-02
2023-02-16
Attendees: Burke, Daniel, Grace, Herman, Jen, Joshua, Mike, Sarguroh Tasmiya, Suruchi, J Thembo, Vineet
- Standups
- Ian, Jayasanka, Grace: Operation Stabilize
- Suruchi: ANC User Research, CQL Engine unblocking, ANC User Guides, mf'd (non-OWA) OCL Subscription module release - decision: Daniel will create additional links for module
- Daniel: Cmty support, CDS CQL Engine - optimizing CQL-API Module (was 200MBs, reducing libraries; now 30MBs)
- Vineet: Drug Order Basket wrap up, Patient Registration; next: Address Hiearchy component
- Raf: Best practice dockerization of pipeline & stack; getting close
- Vision: In next 2-3 mos, complete O3 refapp MVP as out-of-the-box, ready to go Outpatient EMR, w/ adequate metadata for primary/walk-in care
- AMA :+1:
- Review of Ethiopia Hackathon technical objectives - Grace, Eudson
- Platform Roadmap
- In 3 weeks will have update
- O3 Admin UI vs placeholder
- To discuss in more detail on O3 design call this coming monday
2023-02-09
Attendees: Burke, Daniel, Nicholas, Antony, Bett, Simon, Derrick, Ian, MSeaton, Nathan, Samuel,Andrew, Jacinta, Suruchi...
Recording: https://iu.mediaspace.kaltura.com/media/t/1_70h8i3i1
Interoperability Layer for OpenMRS

AMPATH, Palladium and Health IT teams from Kenya have a requirement to extract registration and visits data from openmrs and share with the Ministry of health by sending to a HL7/Fhir based SHR.
This was initially shared in a talk post here This meeting together with discussions on the thread aims to discuss how to build a robust and scalable integration platform to do the following:
(1) Detect and extract data changes from OpenMRS
(2) Translate extracted data to an agreed formart eg Fhir
(3) Aggregate data into a sharable message with participating systems within an integration
Two debezium data extraction stategies were sugested
a. Inbuilt within OpenMRS as a module
b. Independent service outside OpenMRS
The team agreed that both approaches are valid and best suited for different use cases, while building the integrations pipelines, the team to focus more on abstracting logic into libraries that can easily be used with both strategies.
While low level changes extracted by Debezium is well suited for a data warehouse, while integrating with systems such as lab and pharmacy, we need to construct customized messages from these low level records streamed by Debezium;
there were suggestions to use windowing mechanisms to help consolidate individual related DB messages into a complete message which will then be converted to Fhir bundle which is shared with an external system
Useful links
- OpenMRS EIP module - uses debezium with pache Camel, independent service outside OpenMRS
- DBEvents module by PIH - uses debezium to detect and emit db events. Built as a module in OpenMRS
- OpenHIM - middleware for data exchange
- Meeting Recording
2023-02-02
Attendees: Daniel, Grace, Hadijah, Anjula, Rafal, Romain, Juliet, Vineet, Burke, Mike, Mark, Piumal, Dennis, Ian, Eudson, Fred, Jayasanka, Pius, Joshua, Herman, Joshua
Form Engine Discussion
- 90% of what's in React Engine is what Angular Engine already supports, with a few additional features that Angular Eng didn't have. If we stop needing to support Angular out of the box, we can reduce the app shell file size ++ (b/c we currently embed ++ files we need to run Angular) - would no longer need this in all distros!
Decisions:
- TAC Blessing: Approved
With following requirements: - Not Block O3 RefApp Releases: For now we will continue using Ampath in the RefApp.
- Schema: Need definition people can reference and make comments/PRs to. E.g. HFE Schema tag references has proven ++ valuable: HTML Form Entry Module Reference
- Technology Audit: e.g. formik has died off (was major react library for years) - if we're using assets like this we should test running w/ alternative(s) like React Form Hooks (& a few hours refactoring if needed) → UCSF will start looking at the cost of changing, next week
- Next steps: UCSF team will start this work; tickets will be created on what needs to be done, including work to generic-ize some of the Fx originally made specific for OHRI
- Start creating roadmap & tickets & MVP definition on dedicated call - e.g. O3 backlog review
Encounters Modelling given O3 Components
- Bahmni addressed this by having time-outs for Encounters; if same provider does an action on a patient in a location within the time limit, all those actions they took get bundled within the same encounter. Mekom finds this does not work well. Agreement that this is not the approach we'd like.
- Or: Chart tracks some encounter-context → Burke's proposal to add "Encounter Session"
2023-01
2023-01-26
Attendees:
Recording: ______
- Standups:
- Vineet - fixes on Patient Summary, enforcing visits to order drugs, fix to Address Hierarchy bug that was clearing fields
- Suruchi - CQL & ANC project work
- Ian - Rest authentication issue i.d.'d by Bahmni, fix for recent Security issue reported, pr reviews
- Dennis - releases on esm repos, cohort builder app, improvement to how obs grabbed from encounter get displayed in
- Vision for 1 Form Engine: Intro & Heads up for next week’s deep dive - @grace & @eudson
- MedicationRequest blockers: Mapping MedicationRequest.validityPeriod.start and MedicationRequest.authoredOn from an OpenMRS order, see Duration and auto-expire date on orders - #14 by mogoodrich - @mogoodrich
- We will move forward with the suggestions in this ticket:
FM2-552
-
Getting issue details...
STATUS
- order.dateCreated maps to MedicationRequest.authoredOn (and vice versa)
- order.dateActivated maps to MedicationRequest.dispenseRequest.validityPeriod.start (and vice versa)
- Empty Encounters - Vineet
- Concern: Each clinical encounter should ideally be attached to a single OMRS encounter, so everything a clinician does for a patient is documented in the same encounter. Should be clear which encounter they're working within.
- Plan:
- Design Call: This encounter issue is something we need to bring up on a design call, because I’m unsure what the UI flow should be, but we need something similar to what we do with starting a visit.
- TAC Call f/u and confirm technical plan
- FHIR valueSets: Best practice ways to tag and refer to FHIR Value Sets? Global properties that reference uuids? ESM configs that reference uuids? some sort of tags? - @mogoodrich
- questions about the current mapping of concept sets to value sets (FM2-450) - resolved
- New O3 Release Cadence Kick-Off: what we want to include in the first new release this year for O3 → Deferred to O3 Planning call (1hr after this call)
2023-01-19
Attendees: Jayasanka, Grace, Burke, Suruchi, Rafal, Dennis, Daniel K (all OMRS), Ian (Brown), komit (?), Steven Wanyee (intellisoft), Eudson Bambo, Wamz, Amos (all UCSF/OHRI), jonathan thembo (vol), Mark G (PIH), Joshua N (vol), Vineet (Mekom), Fred (ICRC Service Centre), Hadijah (Mekom), Kenneth Ochieng (IntelliSOFT)
Recording: https://iu.mediaspace.kaltura.com/media/t/1_2pkc25tb
Share recording w/ all, inc. Amos
- Release Dockerization - Raff
- OSV-Scanner decision - Grace & Daniel
- O3 Release flow - getting to Beta
- Config separation → Ian to look into splitting off config from distro
- O3 Performance issues - Dennis & Jayasanka
- Bundlesize analysis of esm-core:
- esm-patient-chart:

- The good news: We have bundle size monitoring set up for all our repos. Big question now is how to tackle this problem. This is Dennis' next focus.
- Date Config - Grace