Versions Compared

Old Version 304

changes.mady.by.user Grace Potma

Saved on

compared with

New Version 305

changes.mady.by.user Erica Kigotho

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Directory

Table of Contents
maxLevel2
excludeDirectory



Tip
titleHelpful Links

Where: TAC calls at om.rs/zoomtac

When: See the Community Calendar at om.rs/cal or this GCal event

Notes: Find this page at om.rs/tacnotes


Parking Lot: Topics for Subsequent Meetings

  1. SSO & Getting Auth out of OpenMRS Platform - transition platform auth into KeyCloak or...?
  2. Outline Medication List Use Cases to inform design
  3. Briefly: Next steps for Content Templates
  4. Briefly: Next steps for CDS
  5. Any updates to vocalize re. Generalized CR/MPI Integration (DIGI)
  6. ____
  7. Age Ranges next steps: Module for Age + Gender (that doesn't require a platform release), then in meantime, incorporate deeper more flexible fix into the next platform release
  8. Med List next steps
  9. ________
  10. Plan for: If someone wants to add more FE Modules to O3 RefApp, don't have to re-build the app (Ian)
  11. Performance and Load Testing plan
  12. Immunization Modelling plan & workflow nuances
  13. Handling Relationships
  14. Community SSO & Auth Replacement (by Jayasanka, ensure Daniel, Raff)
  15. Updating the OpenMRS Contribution Policy

  16. EncounterContext plan - https://talk.openmrs.org/t/associating-data-with-the-correct-encounter/38062 & RDE Workflow Diagram (Fiona, Dave...) https://docs.google.com/presentation/d/1lk3ApZLekTYsXPhJVuUjUq3r7MVKdbhtm13Q4KF1_Eg/edit#slide=id.p  

  17. Updates to OpenMRS tech stack diagram 

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

Expand
titleDetailed Table of Contents

Table of Contents
maxLevel3
excludeDirectory

2024-05

Key Points Raised and Agreed to together in TAC (2024-05-30)

  • Attendees: Dimitri (Mekom), Romain (Mekom), Eudson (UCSF), Samuel L (METS), Mark (PIH), Stephen M (METS/UCSF), Ian (DIGI), Cliff (DIGI), Daniel (OMRS), Grace (OMRS), Burke (Regenstrief), Mwariri (UCSF), Samuel M (OMRS), Herman Muhereza, Tendo M
  • Main Topic: Creating an HIS (Health Information System) distribution.
  • Main Takeaway: There was a strong consensus on moving towards a more production-ready approach, with clear naming conventions (distro-his) and a focus on making the system usable out of the box. This will help us address the non-EMR-core needs that health sites strongly require, while avoiding cramming functionality into OpenMRS and integrating appropriately with other systems. So we will have both a RefApp (distro-emr) and a RefApp+ (distro-his).
  • Background:
    • The proposal builds upon previous discussions held in Mombasa regarding the challenges faced by implementers of health information systems.
    • The main idea is to provide a pre-configured solution that would serve as a starting point for implementers, similar to the current RefApp, but focused on interoperability and integration with other systems. (Like a “RefApp+”). A sample distribution that demonstrates how integration with external systems (such as billing and stock inventory management) can be achieved, and in such a way that allows users to customize and adapt it to their specific needs.
  • Integration with ERP Systems: The distribution is intended to integrate with ERP systems while maintaining consistency in the user interface. It will offer flexibility for both facilities using lightweight modules and those employing ERP systems.
  • Documentation and Recommendations: The distribution will come with documentation on how to integrate with different ERP systems, serving as a reference for implementers. While specific integrations may be recommended, the distribution will provide a starting point for customization.
  • Choosing Default Systems: We agreed there’s a need to select default systems (e.g., ERPNext) to showcase integration with OpenMRS, taking into consideration functionality, open-source nature, adoption, and similarity to OpenMRS’s business domain.
  • Flexibility and Integration: The proposed distribution aims to provide a flexible solution that integrates with existing systems, such as ERP and LIS, without mandating specific choices. The goal is to allow for customization based on the needs of different countries or facilities. Agreed the approach needs to enable features, or like disabling/enabling modules, without affecting the API. Integration with existing systems and standards like FHIR was emphasized. A standardized solution that can be used across different countries.
  • Compatibility with Existing Efforts: The distribution seeks to leverage existing technologies and initiatives, such as Ozone, to minimize duplication of efforts and reduce barriers to adoption. It aims to complement and converge with existing OpenMRS-based distributions rather than create new silos.
  • Production-Ready Approach: There’s a shift in mindset from this RefApp(+) being just a demo/sample to being stamped as a “production-ready system”. We discussed how this means we will need to get even tighter with our release QA community process.
  • Commitment to Quality: So, there was a commitment from the team to dedicate resources to ensure the system is increasingly well-tested, reliable, and suitable for production use.
  • Renaming and Rebranding the RefApp: The team discusses renaming the “reference application” to better reflect its purpose and renaming the new repository to indicate its production-ready status.
  • Strategic Alignment: The proposed distribution aligns with strategic goals of empowering the community to build what they need while avoiding duplication of efforts and encouraging sustainability. It aims to provide a better course strategically by addressing the need for essential functionalities without imposing rigid constraints on implementers.

Direct recording link here.

2024-05-09

2024-04

Recording: TAC call_April 25, 2024

Recording: TAC call_May 30, 2024

2024-02

Recording: TAC call_Feb 27, 2024

Recording: TAC call_Feb 29, 2024

2024-02-15

Recording: TAC call_February 15, 2024

  1. Generalized CR/MPI Integration (DIGI)
  2. Age Ranges next steps:
    1. Plan: Module for Age + Gender (that doesn't require a platform release), then in meantime, move into core via incorporating deeper, more flexible fix (to handle additional sensitivities beyond Age and Gender, like Pregnancy status, Renal Function, etc) into the next platform release.
    2. Separate problem: Qualitative: E.g. ability to set that "Reactive" = Abnormal
    3. Please all: Review modelling proposal posted by Evan: https://talk.openmrs.org/t/age-sensitive-ranges/41654/12
  3. Med List next steps

2024-02-1

Recording: TAC call_February 1, 2024

2023-12

TAC Recording: December 7, 2023

2023-11

2023-11-06

As of today: We have changed the name from "Technical Action Committee" to "Technical Architecture Committee". The TAC acronym remains the same. Community discussion and agreement here.  https://talk.openmrs.org/t/proposal-changing-name-to-technical-architecture-committee-tac/40767/6 

2023-07

2023-07-06

Attendees: Raff, Eudson, Dennis, Grace, Michael, Piumal

  • Updates from Raff:
    • Burp Suite Unblocked! Support team was able to unblock the issue with the login page though they aren't sure if it's running correctly. Trying on dev3 environment. 100,000 requests over 24hrs, so far load is being handled successfully (no crashes). Raff to share results w/ cmty when available and when he's confirmed w/ Burp Suite support team that they look as expected. 
    • FHIR Module: Issue with count not running fast enough. Solution: Cache account for subsequent queries, for all requests that return a list of resources. Whenever a response is returned, should be cached and reused. Raff needs to set docs to communicate this to implementers and change core to enable this feature by default. Already merged in FHIR module, awaiting release of FHIR module. raff to check in w/ Ian and then will lead releasing this. 
    • Docker Setup Documentation: Specific to the repos in their READMEs (core, distro repos) - raff hoping to finish this week. 
    • Running out of Memory of Bamboo Agents: Moved files around to differently partition the agents, freed up 5GB. 
  • Performance Issues:
    • Testing Upgrade: Raff to test v5 upgrade of esm-core, check for any performance issues we might have missed 
    • Pagination Slow: UCSF reports pagination component continues to be troublesome on frontend. E.g. table component here. Raff reckons Dropdown page changer on bottom right is culprit - need to replace with simple input field. Because get list of 1→1,000 if that's the # of pages! Dennis Kigen & Samuel Male to connect. Also need to check if this component performs better post-esm-core-v5 migration.
    • Benchmarking: This seems like the right time to set up. Loading times plus load testing: On backend, we test REST & FHIR API endpoints this way. Dennis Kigen to look into approaches we want to take for O3. 
  • Reviewed the Technical Architecture Diagram and made a few changes - much aesthetic improvements still required; Grace will try to get to this and will seek Cmty feedback on Talk when able. 

2023-06

2023-06-22

Attendees: Burke, Ian, Daniel, Michael, Raff, Eudson, Juliet, Grace

  1. Mitigation Strategy for known unsupported key library
    1. Approach goal is to make it easier for implementations to upgrade, avoid rewriting very large modules and avoid pulling out the rug from various implementations 
    2. Immediate Plan: Implement updated version of XStream in core - immediate security benefit - raff 
    3. Longer term plan: to migrate to Jackson, annotating classes we want to serialize; hard part will be migration path for data already saved in DB - Daniel Kayiwa 
  2. Plan to support Reference ranges for VS, Labs
    1. (neonates vs pediatrics vs adult; different ages like geriatrics, different genders...) - architecture? E.g. for Labs should it be the LIS we depend on to provide the reference range they use? (Although even then the EMR still should probably know what the reference range should be) → Discussed w/ OpenELIS; they do currently have ability to store multiple reference ranges, but if that doesn't exist for something, they defer to whatever the EMR is using. → So yes, EMR really should have some way of representing this. 
    2. Burke's proposal, leveraging how FHIR handles this: https://talk.openmrs.org/t/adding-support-for-population-based-reference-ranges-in-openmrs/39931 (means consistent syntax; hopefully less headaches for implementers who need to keep ref ranges consistent across EMR ↔ LIS ↔ etc)
    3. Next steps?
      1. Low hanging fruit (getting interpretation coded)
      2. Add these additional tables as part of next Platform Release (2.7) this year (smile)  Daniel Kayiwa  add to Platform Roadmap

2023-02

2023-02-16

Attendees: Burke, Daniel, Grace, Herman, Jen, Joshua, Mike, Sarguroh Tasmiya, Suruchi, J Thembo, Vineet

  1. Standups
    1. Ian, Jayasanka, Grace: Operation Stabilize
    2. 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
    3. Daniel: Cmty support, CDS CQL Engine - optimizing CQL-API Module (was 200MBs, reducing libraries; now 30MBs)
    4. Vineet: Drug Order Basket wrap up, Patient Registration; next: Address Hiearchy component
    5. Raf: Best practice dockerization of pipeline & stack; getting close
  2. 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
    1. AMA :+1:
  3. Review of Ethiopia Hackathon technical objectives - Grace, Eudson
  4. Platform Roadmap
    1. In 3 weeks will have update
  5. O3 Admin UI vs placeholder
    1. 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

  1. OpenMRS EIP module - uses debezium with pache Camel, independent service outside OpenMRS
  2. DBEvents module by PIH - uses debezium to detect and emit db events. Built as a module in OpenMRS
  3. OpenHIM - middleware for data exchange
  4. 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 (smile) 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

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: ______

  1. Standups: 
    1. Vineet - fixes on Patient Summary, enforcing visits to order drugs, fix to Address Hierarchy bug that was clearing fields
    2. Suruchi - CQL & ANC project work
    3. Ian - Rest authentication issue i.d.'d by Bahmni, fix for recent Security issue reported, pr reviews
    4. Dennis - releases on esm repos, cohort builder app, improvement to how obs grabbed from encounter get displayed in 
  2. Vision for 1 Form Engine: Intro & Heads up for next week’s deep dive - @grace & @eudson
  3. 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
    1. We will move forward with the suggestions in this ticket:
      Jira Legacy
      serverOpenMRS Issues
      serverId45c5771b-fa4b-3e43-b34a-c19dc45ccc95
      keyFM2-552
       
      1. order.dateCreated maps to MedicationRequest.authoredOn (and vice versa)
      2. order.dateActivated maps to MedicationRequest.dispenseRequest.validityPeriod.start (and vice versa)
    2. Empty Encounters - Vineet
      1. 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. 
      2. Plan: 
        1. 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.
        2. TAC Call f/u and confirm technical plan
  4. 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
    1. questions about the current mapping of concept sets to value sets (FM2-450) - resolved
  5. 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

      • Documentation to follow to come. Updates on Talk. And in 2 wks. Anncouncemtn of these images being available. Mark (PIH) and Fred (ICRC) and Amos (UCSF/OHRI) want to use.  

    • 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