/
Archive: TAC Notes 2019-2022

Archive: TAC Notes 2019-2022

Jan 14, 2023

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

2022-12

2022-12-12 - Jen presenting on Dev Stages & how TAC can help with review process, so we can give more recognition to members  

2022-10

2022-10-24 - Cancelled

Attendees: Daniel, Burke, Mike

2022-10-17

Attendees: Grace, Burke, Mark G, Mike S, Daniel, Ian, Eudson

Recording:

  1. Formally confirm the backporting policy for Platform as described here. Example context: Fix for this is really affecting O3 code; but if it's not backported, then the same code that runs against 2.5 won't work against 2.4. Support = continuing to care for the code. 

    1. Agreement in principle. Something like “The OpenMRS Community strives to support the last 3 releases. Support for older releases is handled on an ad-hoc basis.”

    2. But: Does not mean every change is being backported. eg. someone making a commit for 2.5 because their org needs it, shouldn't be forced to also backport to other last 2 versions.

    3. Criteria for "Need to Backport":

      1. Priority Security Fixes & Major Bugs

    4. "Consider to Backport - but not required"

      1. If people you flagged who may be affected express clear reasons for needing a backport to up to 3 versions back

      2. Case-by-Case Discussion: An API endpoint or behavior update that could have an impact (API changes should be backported only when necessary because they're breaking changes; but also, improvements to API are reasonable to simply add to the latest/current release)

      3. When you want people running older versions to be able to use your code

    5. Not about the anonymous downloader - because we need to be realistic. 

 

  1. 5-Whys Retrospective on how this drug-order bug was missed until now, and how we can improve accordingly.

    1. Why was this not caught for 2 yrs?

      1. Not used in production, not iterated on until recently

      2. Bug wasn't visible because ordering was broken/blocked in demo until recently

      3. Not enough quality demo metadata (drug metadata not possible to connect well until recently)

    2. Why does this seem "ready" when it's not? (i.e. it's a 0.0.1 release but seems like a 1.x, ready to consume)

      1. Bundled into monorepo with more ready stuff

    3. Why were the requirements not clear? 

      1. Not clearly documented

      2. Ownership role over feature was not maintained

      3. Meds should be treated as a special, don't-mess-up case. 

    4. Why not given more attention over time, no one "owning" the quality of it?

      1. No clear, regularly done O3 release process. 

    5. Why did `${strengthQuantity * doseNumber} ${strengthUnits}` seem like a reasonable formula?

      1. Quantity vs Dose vs Strength are confusing to people. 

        1. strengthValue and doseValue would probably be more clear as objects. 

  2. Agree on vision and next steps for the O3 Release process and “Quality Gates” (see diagram & discussion here).

    1. 2 key takeaways:

      • @next makes sense as the esm-version-source for dev3, but @latest makes most sense for o3, not test3, because marking an esm with @latest implies to the whole world on npm that the app is stable / ready for the real world. And this is not necessarily true for all stuff in test3.

      • I’d like devs to indicate “I have tested X feature in dev3 and it works as expected” somehow - maybe through a label of some kind? Then test3 could pull in those specific updates; things that are basically halfway between @next and @latest.

2022-09

2022-09-19

  • Reviewing core apps, UI commons, and appointment scheduling build issues

  • Multifactor authentication support

  • Dispensing updates

2022-09-12

  • Deployment process

  • Build issues – Bamboo agent issues

    • yu issues

      • Having some issues with terraform process

    • Builds running out of disk space

      • Ian disabled a misbehaving job (2.x RefApp E2E tests not cleaning up after themselves)

  • Issues with Dispensing

    • See Questions about Pharmacy designs

    • Dispensing Design Components

    • Probably want to avoid tackling multiple tabs in MVP and focus on one or two filters: (1) prescriptions that need to be processed (e.g., today's prescriptions) and (2) completed.

      • Avoid showing all prescriptions by default (list will be WAY too long)

      • Other filters (e.g., RETURN) still need to be defined

      • Status is more about dispensing status than order status.

  • JIRA Graveyard quarterly cleanup

2022-08

2022-08-08

  • Possible topic: Provider Messaging

2022-08-01

  • DevOps skills – do we need dedicated effort?

    • Overlaps with CI/CD, tooling for QA, etc.

    • It might help to recognize this as a separate discipline

    • Similar to QA, in having leadership to help wake up thinking about the discipline for the community, bringing the expertise and helping lead the big tasks, and raise devops awareness & skills amongst community devs

  • Announcement

2022-07

2022-07-25

  • Computed observations

    • UCSF is using stored procedures to compute observations

      • Storing all computed observations in a "computed" encounter

    • Issues

      • When is a computed observation recomputed?

        • TTL

        • Dependent values change

      • Tracking dependencies across observations

        • Definition should include all dependencies

      • Would like to get away from building our own BRMS (business rule management system)

2022-07-18

  • Discussion Board (real-time messaging) feature (Slide deck)

    • Requirements

      • Search and add users to a discussion

      • See who is online

      • Send notifications to participants

      • Ability to remove participants

      • Ability to add files/attachments

    • Challenge

      • Using web sockets via Spring WebSocket API and STOMP messaging protocol, but running into issues

2022-06

2022-06-06

  • Leveraging drug formulary for drug orders widget

    • "As far as the opportunity to make urgent progress with UCSF and drug ordering for OpenMRS 3.x, any work to pull drug formulation information from the drug table (instead of frontend JSON config files) would be a step in the right direction." -talk

  • Adding "category" to forms (tags?)

    • Use case is to be able to limit a list of forms (or default) based on categorization (label/tag) of forms.

    • Why use tags instead of configuring an explicit list of forms (e.g., within configuration)?

      • A single UI element needing a specific list would favor configuration; whereas, if there are multiple UI elements or areas of the application that want the same grouping of forms, tagging might be more appropriate.

      • If there are context-specific needs, then a backend (tagging) solution might be preferable.

    • Would it be more appropriate to associate forms with programs? Are tags actually a workaround for the lack of relationships between forms and other resources (e.g., programs)?

      • A program may still have 50+ forms and being able to group forms in smaller groups would be useful (which would favor tagging)

    • Distinction between categories & tags?

      • Categories would be a pre-defined set of "buckets" and forms could be placed in one or more buckets

      • Tags would be a "folksonomy" where removing the last use of a tag would remove the tag

    • Next steps?

      • @Ian Bacher will make some tickets for this

  • Feedback of deployment (experience from @Grace Potma's recent travel

    • "I wish we could have just grabbed OpenMRS as a Docker image."

    • "Is it possible to deploy KenyaEMR and whatever system together so they could deployed at once" ... "Yes, we're exploring Docker for this."

    • "Your 3C approach makes sense, but could you add 'D' for deployment? It would help if Docker was included to make deployment easier."

    • Existing materials

  • Ability to jump from form into patient chart

    • Use case: when using a form with a lot of data, we'd like to be able to show the data in the patient's chart and then take you to that relevant part of the patient's chart while completing a form. For example, while form is being edited in the right panel, being able to click on something to navigate the patient's chart (left side of the screen) to specific data within the patient's chart (i.e., navigate the patient's chart without having to leave the form). In a tablet view, this might mean providing a way to get back to the form.

  • Design for notifications/alerts and how will they be supported

    • Not enough time to discuss today, but we should think about how we will support Ciarán's designed for notifications on the backend

2022-05

2022-05-23

  • How to handle needs for data migration  - OpenMRS Talk

    • For Ethiopia, they have data in FHIR format for >100 resources and only ~30 are currently supported by the OpenMRS FHIR module

    • Current goal is to migrate to OpenMRS database

    • While OpenMRS is strategically aiming to migrate toward full FHIR support, adding new resources (e.g., MedicationDispense) is non-trivial and includes the need for new Platform releases.

    • What is driving the data migration? Reporting vs. clinical use?

      • Primary driver is to have MVP containing existing data and for clinical use.

    • Could focus on how could each resource be represented in OpenMRS and focus on how to migrate existing data into OpenMRS model

      • Enumerate each piece of data and how it would be represented in OpenMRS

      • Manually migrate those that have a clear equivalent in OpenMRS

      • Focus on alternatives for those that are not currently handled by OpenMRS (e.g., Care Plan)

    • Example of PIH migration code

  • Emergency Department stuff (a little bit)

  • Sync-something becomes a core part of platform

    • @Grace Potma will be posting to Talk soon about this

2022-04

2022-04-25

  • Inpatient vs outpatient care

    • Care Settings will need design

      • Ideally would allow for bed management to be coordinated with external systems (e.g., ERP)

      • Look at Bahmni for successes in inpatient setting and learn from workflows

    • Could start with simple bed management

      • Bed management module provides backend support for bed management metadata/configuration

      • Bahmni contains features that leverage bed management to provide inpatient features

    • Are there near-term implementation needs for inpatient?

      • Steven Wanyee shared that IntelliSoft has three cases that could use inpatient support (e.g., work in Botswana is beginning as outpatient, but will have inpatient needs soon)

      • Mekom has some work in late 2022 or in 2023 that could use inpatient features

  • MAR - Medication Administration Record

    • There's some demand for this feature

  • Update on Reporting & Analytics

    • Mike & Burke have been using Analytics Engine Squad calls to work through a way forward

      • We've divided the problem into four areas: (1) Change Data Capture (CDC), (2) ETL, (3) Data storage, and (4) Reporting & Analytics tools. Each of these areas has a variety of options in tooling.

      • We'd like to see if we can align community efforts/energy around a shared approach to CDC.

  • Reference ranges

    • OpenMRS historically has defined reference ranges within a concept; however, ranges vary by context, patient demographics, etc.

    • LIVD (within the SHIELD project) on lab interoperability is debating where knowledge of references ranges should be – with the concept vs. with the result.

      • Would want to align with these kinds of efforts

2022-04-18

2022-04-11

2022-04-04

  • Backend support for draft forms/encounters

    • How/where should draft forms be persisted?

      • In a draft table, linked to patient/encounter

    • Should we allow draft of anything?

      • Probably better to handle separately as a approach for persisting application state

    • How long are drafts persisted?

      • Forever?

      • If we can distinguish between draft and voided draft, then business rules can drive it.

      • Need to include last updated time.

    • Who can access drafts? Can they be shared?

      • Permissions can be applied on top of draft feature as long as we know who created the draft.

    • Making forms uneditable is a separate issue.

      • Would use permissions to control this

    • Design ideas

      • Form content

      • Link to encounter? We wouldn't have encounter in common use case (not created until form validated/submitted/saved).

      • User

      • Date updated

      • Patient

2022-03

2022-03-28

  • Modeling for Drug Orders in 3.x (Formulary vs Prescription vs ?)

    • Example

      • Concept: amoxicillin

      • Drug: amoxicillin 500 mg tablet

      • Order template: amoxicillin (500 mg or 1000 mg) (orally or per gastric tube) (two or three times daily)

      • Order set: (1) amoxicillin 500 mg orally three times daily, (2) amoxicillin 1000 mg orally three times daily

    • Formulary informing vs enforcing orders

    • Formulation chosen by ordering provider or by pharmacist

  • Draft encounters (saving them in the backend)

    • Would love to have these. Needs design work.

  • Any synergies with ICRC project? 

    • Patient search? Quick forms?

    • Viewing tables of data?

2022-03-21

2022-03-14

2022-02

2022-02-21

  • Cancelled for OpenMRS Holiday

2022-02-14

Attendees: Burke (OMRS), Mike (PIH), Mark (PIH), Namanya, Daniel (OMRS), Grace (OMRS), Romain (Mekom), Tendo (Vol), Zak (Mekom), Ian (Brown)

  • Mentally walking through adding a “package” with an ESM, module, and concept to OMRS 3. What are the steps we expect to happen?

    • We walked through build process

    • Would like to improve build process of frontend so we don't have to re-download assets each time we assemble the frontend and so we can deploy frontend in different locations without having to re-assemble the frontend (preferably without having to search & replace variables within index.html)

2022-02-07 - recording

  • Continuing the discussion on OpenMRS Packaging conventions (Draft Schema for Packaging)

    • "A package is a definition of what artifacts are that make it up" -Mike Seaton

    • What string format convention do we use when referring to an asset (ESM, omod, metadata, etc.)?

      • Can take existing conventions and document them (e.g., what we're doing in distro.properties)

    • Which versioning format do we use? Are there libraries for this?

      • Prefer to adopt a well-established convention instead of our own custom syntax

      • Look for library to convert between npm <=> maven

    • For modules, do we organize by asset type (omod, esm) or build tool (maven, npm)?

      • Defer

    • Mentally walking through a simple build process. What are the steps we expect to happen?

      • Ability to refer to config or metadata by URL in properties file

      • Do frontend modules declare what backend modules they depend upon? If not, we'll want a convention for this. Can we add these data to packages.json?

      • Mike would like to have distro.properties that refers only to versioned artifacts (e.g., in maven). So, we would list all ESMs; rather, we would refer to a pre-built frontend artifact that contains the built artifact.

        • This may be a fundamental difference between distro & package definitions: distro refers to built artifacts, while a package definition will need to refer to ESM source.

        • PIH uses a pom.xml like this to generate a frontend artifact (turning a definition like this into a maven artifact like this), so changes to non-frontend parts of the distro (e.g., bumping an omod version) doesn't require re-building the frontend.

2022-01

2022-01-31

Attendees: Burke (OMRS), Allan (Ampath), Amos (UCSF), Daniel (OMRS), Emmanuel (Mekom), Eudson (UCSF), Grace (OMRS), Ian (Brown), JJ (Ampath), Juliet, Lars (UCSF), Mark (PIH), Michael (PIH), Jonathan Odora, Romain (Mekom), Stephen (UCSF), Tendo

Agenda: Reporting Strategy

We would like approach(es) that leverage existing tools to provide a standalone solution for reporting/analytics that can be scaled, when needed, to separate server(s) or into the cloud:

We want to focus on the four areas of (1) change data capture, (2) transform, (3) data store, and (4) reporting/analytics and want to keep in mind that a primary consumer of analytics will be the EMR itself:

  • CDC (Change Data Capture) solution

    • Debezium

      • Debezium is lightweight, but requires Java for integration into pipeline, listening to log files and manually marking changes.

      • Haven't tested with large dataset.

    • Kafka/Connect behind Debezium

      • Kafka with Zookeeper & Kafka/Connect doesn't require programming, but needs lots of RAM (8GB+)

      • Newer Kafka (3.0.0) may not need Zookeeper

    • Debezium and Camel

      • Still need to write some code to listen to changes, but not as much

  • Data processing

    • SQL

    • FHIR data store

    • Spark

      • Can use SQL or Python. Also supports R, Java, and Scala. SQL is probably most widely known in our community.

    • Flink

      • Can use SQL. Relatively simple to use.

      • Has its own optimizer engine for queries.

      • Flink/CDC is a wrapper around debezium, but may not configure debezium optimally.

      • Requires Zookeeper (but this might change in the future). We'd need to figure out how to configure to avoid needing lots of RAM.

      • Can run as application mode (as a single jar without clustering)

  • Data store

    • Cassandra

      • Dependent on proper partitioning.

      • Frequent writes (e.g., CDC) might slow down reads.

    • Parquet

      • Much more efficient than CSVs