Archive: TAC Notes 2019-2022

Owned by Grace Potma
Jan 14, 2023
73 min read

Directory


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

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 (smile) 

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?
  • 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

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
    • Postgres
      • Simple flattened tables
        • For example, Mekom using 4 key flattened tables: Concepts, Visits, Patients, Obs
    • Delta Lake with Parquet
      • Requires SSD for real-time processing of streamed data. Can lag 5+ minutes with peak loads.
      • Supports both batch and streaming workloads.
    • Druid
  • Reporting/analytics
    • BI tools (e.g., Power BI, Jasper Reports, Tableau)
    • Apache Superset
      • Nice metrics & calculations
      • Supports SSO
    • Kibana
      • Requires ElasticSearch (i.e., ELK stack)
      • Nice visualizations
      • Limited with heavy calculations
    • Need to have option for OpenMRS to read from reporting

Some groups using standalone OpenMRS needing some capability for simple flattening. Other groups looking for enterprise approach to analytics.

Strategy to go forward

  • Experiment and stay in touch (e.g., Slack)
  • Expand Analytics Engine Squad calls to move these forward
    • Center discussion around these four areas: CDC, ETL, Data store, and Reporting/Analytics

2022-01-24 - recording

2022-01-10

(Ian) Priority and Status are both concepts. View works well if you're in a particular clinic. Problem right now is which clinic you're in - this is what drives the "Waiting for" specifics. Might also want a view of all patients waiting for my particular service (i.e. dynamic pt list) - question of "what data is driving the particular view that this particular user is seeing" - e.g. all pts anywhere, or ... e.g. someone at triage desk might primarily want to see triage pts.

 (JJ) Goal is to see the status of all patients. MVP is that movement is manual (user adjusts where pt goes next). 

(Ian) Need agreement on general context for these queues: Encounter? Visit? ...?

Decision: Need check-in with Burke around what's required - terminology and what fields we'll capture. Not massive conceptual change. Requested at: https://talk.openmrs.org/t/backend-support-for-service-delivery-queues-workflows/35247/52 

2022-01-03

  • Notice F for Digital Square projects (technical proposals due 12 Jan)
    • ANC package
    • OCL integration
    • QA
  • GSoC 2022 planning
    • Coming up with changes for GSoC (not just students)
  • Packaging 
  • Reporting
    • Leveraging 
      • Apache Flink vs Spark for streaming
      • Apache Superset for visualization

2021-12

2021-12-20

2021-12-13

  • Log4Shell vulnerability
    • Upgrade Platform or apply mitigation to avoid anonymous attack vulnerability
    • Plan to tweet
  • Backend Support for Service Delivery Queues / Workflows
    • Do we support multiple states per Visit? Per Encounter?
    • Can we support queueing outside of Visits/Encounters?
  • Packaging for UCSF COVID package
    • Packaging draft
    • TODO: Burke to find Talk post on packaging and bring it to Eudson's attention
  • Planning for Reporting foundation
    • OpenMRS 3 (and OHRI) need an out of the box, scalable reporting solution beyond reporting framework
    • AMPATH & Google have 
    • Can analytics engine squad efforts (by AMPATH & Google) and simpler approaches (like PIH's PETL)
    • TODO: Need a planning/strategy call on way forward for community. Burke will bring to Talk and we'll use some AES call time and/or schedule a separate call to talk through ideas (needs: Eudson, Allan, Mike, Dmitri)

2021-12-06

  • Cancelled for GDHF 2021

2021-11

2021-11-29

  • Cancelled for OMRS21

2021-11-22

  • OCL updates
    • Need to address #661 (ability to delete a source even if there are references to it) before we can replace PIH dictionary
    • Add support for concept complex handler (#1114)
    • Including sources in export (#1115)
      • Could use concept_reference_source.unique_id for URI
      • For short term, when comparing sources, normalize source names by removing non-alphanumeric chars and lowercasing when comparing names
    • Including retire reason in OCL import (#1118)
    • Ability to retain/track voided (aka retired) concept names within OCL
  • Packaging Updates

2021-11-15

  • Jennifer working on unpacking (demystifying) the process of becoming a core contributing organization (e.g., how does one join orgs like PIH, AMPATH, Mekom, etc. in decision-making)
  • Connect for Life distribution demonstration - connect-fowww.connect-for-life.orgr-life.org
    • "Connect for Life™ is a tailored distribution of OpenMRS. The platform enables increased patient and caregiver engagement through the use of basic mobile phones capabilities (e.g. SMS, IVR, WhatsApp)"
    • Built upon RefApp 2.10
    • Can send messages to remind patients of visits and to take medications
    • Show messages and adherence graph on clinician facing patient dashboard
    • Can place calls to patient from dashboard
    • Messages sent or to be sent to the patient can be seen within a calendar
    • Patients can be messaged via SMS or IVR
    • Andy: Can messaging be directed to caregiver? Annik: Yes. Messaging can be customized between patient and/or caregiver.
    • Andy: Can interactive responses be returned to the patient's record? Annik: Yes. Surveys can return data into the system.
    • Burke: How is messaging being handled under the hood? Answer: Directly using APIs and can configure for various providers.
    • Andy: What is being used for data model? Answer: Using OpenMRS for core resources and added custom data model for messaging.
    • Burke: Could an existing distribution adopt this functionality? Answer: modules are largely independent. Depends on some things (e.g., phone number within registration)
    • Dmitri: How does the UI intertwine with the standard UI? Answer: Using a separate module for CFL UI, but components could be re-used in another distribution.
    • Dmitri: Which appointments module is being used? Answer: not using an existing appointment module, but built a different "visit" module to do scheduling. Could potentially leverage visits created from an appointment module.
  • Packaging
    • Updates? Still conceptual work.
    • How do packages declare what is needed?
    • Using two concrete examples:
      • Mental Health package for ICRC
      • OHRI hello world
    • Near-term targets
      • Skeleton of package
      • Manually walking through merging OpenMRS 3.x and a package both using same skeleton
        • What are the challenges?
        • What are the opportunities for tooling?
        • How could it apply to OpenMRS 2.x? Can this be retrofitted to OpenMRS 2.x?X}

2021-11-08

Attendees: Dimitri, Florian, Anjula, Daniel, Heshan, Jayasanka, Jen, JJ, Juliet, Daud, Kumuditha, Mark, Mike, Pasindu, Piumal, Suruchi

  • 3.x performance improvements
    • Review of proposal from Florian: Performance improvements to app shell and framework
      Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.
    • Priorities
      1. Offline on demand (O3-907)
      2. Dynamically shared dependencies (O3-909)
      3. React as primary framework (O3-911)
  • Packaging

2021-11-01

Recording: https://iu.mediaspace.kaltura.com/media/t/1_4fjqau13

  • Packaging
    • Last week's decisions
      • Combined at build time (not hot-loaded)
      • Leverage Maven's conventions for namespacing 
      • Repository naming convention: openmrs-package-<purpose>
    • Using POM or properties file vs including artifacts
      • Would like to avoid having to manage/edit POMs
      • Defer until we decide on structure
    • Distribution vs Package
      • Share similar structure
      • Distribution includes definitions for specific deployment decisions (e.g., version of OpenMRS platform to deploy)
    • Draft Schema
    • OHRI Packages Inventory

2021-10

2021-10-25

Attendees: Burke, Michael Seaton, Amos Laboso, Andy, Daniel, Dimitri, Ian, Jen, Juliet, Daud, Mark, Suruchi, Tendo

  • Special upcoming community session: OpenMRS Partnership model (Should we host this during a TAC call time?)
  • FYI: Community Architect Roles now posted; please add any comments: Architect Roles across OpenMRS
  • First pass at a Package: Working session!
    • Sample content: 

      • To help bring some real-world context, I’ve set up a list of example package content using the ongoing work from OHRI - see details here.

        We’ve now got real examples of real content that would be included in a package, such as:

        • Package name
        • Concept Metadata
        • General Metadata
        • Forms
        • Frontend Config
        • Frontend Modules
        • Other OMRS Modules

        Other things that I expect will come later are:

        • Reports
        • Specific Patient State calculations
        • Business Rules for Computed Obs
    • When will packages be loaded? Do we expect them to be "hot-loaded" into a running system?
      • There will be a build step, where package contents and system contents are merged into another.
      • Changing functionality at runtime could be re-introduced in the future by performing the build/deploy in the background (e.g., using containers).
    • Assuming a package is an archive, how do we namespace contents?
      • Packages will need to have a unique ID, so tooling can namespace content. We'll adopt Maven's approach to namespacing (i.e., packages like org.pih.htmlformentry).
      • Will need to work out business rules not only to handle dependencies, but also control sequence of files across multiple packages.
      • Repository naming convention: openmrs-package-<purpose>
    • Do packages need to contain actual artifacts (e.g., modules or other maven artifacts) or just references to them?
    • Creating practical examples
      • Candidates (we'd like to see 2-3+ early on to test approach)
        • Mental Health
        • NCD
        • OHRI
        • PIH has several potential cases
  • Conventions for handling issues (will discuss on this week's S&O call)

2021-10-11

  • Community Roles
  • Shared Assets and Fundamental components
    • Working on guidelines & processes for how to define and build these to demystify how shared assets are designed/built
    • Can share use cases, designs
    • Building for & using within multiple implementations helps ensure things are re-usable
    • Sometimes things are needed sooner and there isn't time to build them in a fully re-useable way
  • First pass at Packaging
    • Proposal: working through how OHRI content & functionality could be introduced into OpenMRS 3.0 using packaging approach
    • ICRC planning on a mental health package, which could serve as a second proof of concept
    • Proof of concept – OHRI programmatic package (COVID, HCT, etc.)
      • ESMs
      • Concepts
      • Forms
      • Reports
      • Configuration - home screen, dashboard
    • Samuel Male will discuss with UCSF team
    • We'll continue conversation over Talk/Slack and keep topic on TAC calls to move it forward

2021-10-04

Attendees: Burke, Jen, Amos, Andy, Daniel, Dimitri, Juliet, Mark, Mike, Samuel, Grace P, Suruchi

  • Concept Names breaking dbsync
    • Potential solution proposed by Mike Seaton would require changing Concept Name from voidable to retireable.
    • Dictionary Manager and CIEL do create UUIDs for concept names
  • Review & Approval by TAC 
  • Packages prototype plan - where are the soft edges we need to harden 
    • Get 3.x Foundation
      • Work to get SDK to support Iniz (Done)
      • Package loading to support to handle backend modules, esms, and other packages (could try with OHRI? Ampath? Demo/Out-of-the-Box Outpatient Package?)
      • Put packages inside a new "Packages" folder in folder hierarchy
      • How to handle combination of packages?
        • Are packages handled/processed independently in a predictable order? Or do we have a build step that tries to merge all settings/content into a single "build"?
          • Favoring the latter (merging all packages into a final "build") to be more deterministic/predictable
          • Would eliminate support of manually configured systems (e.g., a running system not created through packaging mechanism)
            • If it's hard for implementations to convert to packaging conventions for their existing builds, we could create a process to create a package from a running system
        • Recognize conflicts
        • Merge configurations
        • Handling ordering of content
      • Iniz may need to know about alternate 
    • Create Package
      • Consensus on Folder structure (and that we'll build our tools on that)
      • Consensus on how Folder gets zipped up → Decision to leverage commodity tools Maven and npm as much as possible? Why create our own bespoke way of packaging things if we already have these tools in use.
      • Then: Tool to take Maven XML file and turn into list of versions of properties we have  
        • e.g.: want certain pt lists. How do you create those lists? → cohorts. How do you represent that in a file? Just the way Iniz does it? (Just use Iniz to build your package)
        • Represent these things in the CSV format they're already using
        • Exception: Forms → 
    • Find a Package
    • Add a Package to your system
      • Where you'd add the config to have it added at build time
    • Update a Package
    • Can someone start an example template we can review somewhere?

2021-09

2021-09-27

Agenda:

  • Supporting organizations in OpenMRS
    • Primary goal is to label data being sent to an HIE as coming from a specific organization.
    • If we use location hierarchy, we might 
    • Need to understand use case: are we sending data from OpenMRS as a single organization? Or is there a use case where a single OpenMRS instance would be sending data to an HIE as if from 2+ organizations?
  • Supporting Referral Orders
    • We reviewed the proposal for modeling new order types within the OpenMRS Platform.
    • Mike Seaton pointed out examples like this, where TestOrders are being used (in this example, to add location) and there could be others like this that would need to be refactored.
    • We discussed the extremes of lumping & splitting – i.e., from a single Order with the superset of all needed properties for all order types with many properties left blank vs. creating separate classes for every possible order type with the specific properties needed. Both extremes have significant downsides (a single class defers all type-specific behavior to clients and too many order type classes isn't flexible enough when order types – especially the multiple types of lab tests – may be classified differently at different implementations).
    • Experience has shown that a handful of classes can cover the needs of order entry (e.g., drugs, tests, referrals, medical equipment, nursing, patient education, diet, activities, precautions, call orders, end of life care), which involves splitting one level deeper than FHIR, but can align with FHIR's approach.
    • There was agreement and no dissension on the proposal to add ServiceOrder as an abstract class (extending Order) and making TestOrder and ReferralOrder as extensions of ServiceOrder.
    • Burke Mamlin will report this on the Talk topic

2021-09-20

Agenda:

  • Supporting Org & multiple Orgs in the backend (like how FHIR doesn't mix location and organization).
    • I-TECH would like to have support for Organization in OpenMRS (Mozzy). 
    • Backend currently has no Org model - whereas FHIR doesn't mix location and organization. (Problem for both Bahmni and UW/ITECH, where this comes up in facility registry workflows.)
    • discussion around how we can support the FHIR concept of “organisation” and whether and how we can untangle this from “location”. 2 driving use cases: tagging data as coming from a specific organisation to support integration with a Facility Registry and for referral orders to be able to specify “I referred this patient to XXX clinic”.

2021-09-13

Agenda:

2021-09-06

Cancelled due to Labor Day Holiday

2021-08

2021-08-30

Agenda:

  • Cohort Module Next Steps
    • Persons or Patients for cohorts
      • Consider Cohort implementing a "Group" interface
      • 99% use case is for Patient, so will stick with Patient
      • If Cohorts is only for Patient, then households would require MRN for every household member
    • Supporting start & end dates
      • Cohort intersections are harder with start & end dates
    • Approach for cohort definitions
      • Would like to avoid over-designing definition support at this time, but would like to be able to serve up dynamic cohorts from the Cohort Service without hacking with AOP, etc.
      • Could use a "status" to determine whether cohort is updating (for long-running calculations)
    • Approach for membership roles
      • Worth considering for household support, but 99% of use case (head of household) could be done with a membership attribute
    • Approach for cohort obs/encounter/visits/programs
      • Don't bring this into the platform at this time
    • Next Steps: Ian to follow up with proposal
  • Sourceforge alternatives? https://talk.openmrs.org/t/sourceforge-alternatives/34500
  • OpenMRS 3.0 demo & dev environments: Updates? Remaining blockers?
    • TODO: Burke will get Ian access to terraform
  • Pharmacy-related questions (Mark & David) - conversation on OpenMRS Talk
    • Lots of people use Odoo
    • PIH using OpenBoxes, would like to build something for the Pharmacist management (would connect to OpenBoxes) unless someone knows of a good open source pharmacy system
    • AMPATH is using Maisha Meds
    • UCSF is very interested in Pharmacy functionality for OHRI
      • Next step: PIH & UCSF connect to review use cases
    • Decision: Fine to have Med Dispensing info in EMR, as it is suggested in FHIR. Agreement for new "Medication Dispense" table in OpenMRS backend. https://www.hl7.org/fhir/medicationdispense.html
      • Next step: Mark to review FHIR description and come back with core needs identified vs what we already have
  • Questions about our Help Desk (Juliet)
    • Receiving lots of issues about people creating OpenMRS ID account and not receiving emails
      • Next step: Juliet will create an Infra ticket for this                                                                                                                                                                                                                                                               This is the ticket for this issue  Unable to locate Jira server for this macro. It may be due to Application Link configuration.
    • People doing marketing or research (can be ignored)

2021-08-23

  • Working on job descriptions for data engineer and frontend architect
  • Deploying OpenMRS 3.0 demo
    • Ian will work with Burke to get this deployed
    • Currently Github Actions are updating import map in Digital Ocean
  • Packages next steps
    • Get discussion onto Talk
      • Build time vs run time? Likely focus on build-time processes for now and anticipate opportunities for run-time deployment in the future (e.g., leveraging Docker)
    • Create an inventory of what packages can contain (e.g., 3.x folder structure + manifest)
      • Would like to include ETL rules as part?
    • Including a "manifest" (try to do via Maven)
      • Owner, URL, version
      • Version of packaging used
  • Cohort module next steps beyond talking - whats the process to get this done? bring to platform team? who is the idea owner? (Ian or Dimitri?) Bett is ready to write the code; we need someone to ensure approach/lay out vision and do PR reviews
  • Confluence/Jira Cloud next steps: SSO is the blocker. Test out leveraging Keycloak; get it working with LDAP?
    • Will need to identify someone to spike on this. If not done in 2021, could. use GSoC 2022 project.
    • Will need to involve Cintia Del Rio in the migration

2021-08-16: Improving prescribing and dispensing

Attendees: Burke, Mark, David, Daniel, Dimitri, Grace, Isaac, Juliet, Suruchi

  • Improving prescribing and dispensing (PIH)
    • The ability to dispense meds through UI and for docs to know what meds are available
    • Is the underlying approach on how you store immunization data clear? Clearly supported in backend?
    • PIH needs a paperless prescribing and dispensing workflow
      • Clinicians prescribing meds
      • Pharmacy can see prescriptions online
      • Ability for pharmacy to make some modifications to an order
      • Ability for pharmacy to flag prescriptions as needing attention (e.g., ask provider for clarification)
      • Pharmacy to dispense meds
      • Clinicians having a sense of inventory at the time of prescription
      • Currently using a 2.x version at the facility with the requirement
    • Currently OpenMRS has drug table. If the pharmacy doesn't currently provide a med, should it be in the list?
      •  Burke: I wouldn't use existence of entries in the drug table to manage stock outs; rather, add an attribute to indicate formulary availability to the drug table with something like drug.out_of_stock. (not currently in FHIR)
    • Approach to Pharmacy and Inventory management (embedded vs integrated)
      • Ask the community what people are using for pharmacy systems
    • Mekom created an ERP system to check inventory/invoice status
  • Security
    • Isaac Sears has stepped down from overseeing security as he's a "little" distracted by medical school (smile) 
    • OMRS will still need to address 3rd party reports within 90 days (so someone needs to monitor Talk security forum)
    • No security mailing list vulnerability reports in multiple months now; seems a result of work addressing vulnerabilities with NC State
    • GSOC student experience great; Joshua Nsereko  strong & likely to be added to vulnerability response. Sharif Magembe  & Ian Bacher have been helping with PRs - good resources.  
  • Website, product names & logos https://talk.openmrs.org/t/new-website-feedback-on-new-terms-icons-needed/34381 

2021-08-09

  • Data model implications for Patient Lists / Cohorts and user access to cohorts
  • Darius Jazayeriis working on User Groups modeling
  • Deploying OpenMRS 3.0 into infrastructure
    • Getting very close
    • Burke Mamlin will investigate if we have docker images published to Docker Hub or that could be published. Once published 
  • Packages discussion
    • Run time vs Build time
      • Do we approach packages as build-time components?
        • For orgs/implementations with build pipelines (e.g., PIH, AMPATH, Mekom, etc.), introducing changes at build time is standard practice
        • Introducing changes at runtime on production systems can be very risky
        • Are there use cases where people depend on introducing new content or modules during runtime?
      • Alternatively, we could consider using the existing convention for laying out content & behavior in a folder hierarchy to create a zip file with a manifest that could be "uploaded" into iniz and processed during runtime.
        • How would we handle frontend components (esms)
  • Update: OpenMRS Radar has been updated to 2021 Q2
  • Next week:
    • Improving prescribing and dispensing (PIH)
      • The ability to dispense meds through UI and for docs to know what meds are available
      • David DeSimone (voluntold by Mark Goodrich) will introduce topic on Talk

2021-08-02

Call canceled due to lack of quorum

  • Data model implications of Patient Lists

2021-07

2021-07-26

Attendees: Juliet, Burke, Ian, Grace, Dmitri

  • CI for OpenMRS 3.0
  • Cohort Builder Strategy
    • Plans for Cohort module
    • Creating dynamic lists of patients
      • Could use reporting module to generate cohort
      • Cohort module could persist cohort definition & handler (e.g., a reporting definition and a class that can turn that definition into a cohort)
    • Working on REPORT-873 to allow SQL queries within the reporting engine to perform better
  • Packaging Strategy – deferred topic

2021-07-12

Attendees: Isaac, Burke, Ian, Grace, Steven, Mark, Daniel, Suruchi, Andy, Dmitri

2021-07-05

No meeting - vacations

2021-06

2021-06-28

Attendees: Dimitri, Grace, Ian, Mike, Burke, Andy, Cliff, Daniel, Joshua, Juliet, Kaweesi, Suruchi

  • Changes to distro POM to make SDK tooling easier (Dimitri, Brandon, Mike) - Conversation on Talk
    • Hoping to have a "single source of truth" to represent the needs of a distro (instead maintaining in distro file & POM)
    • Do we need to have modules listed in the POM if SDK's maven plugin can manage them?
      • Could lose features of maven
    • SDK create folder with WAR, omod, OWAs in different directories in target folder.
      • PIH has a process to throw those artifacts into a debian package
      • SDK could adopt folder structure of iniz
    • Packager maven plugin currently create a packaged OpenMRS configuration
    • General agreement to align toward using distro.properties as distribution definition with tooling (like SDK) leveraging the same approach, including distro definition and folder layout.
    • Currently, SDK does not help with configuration.
      • General agreement of separation (loose coupling) of distribution and configuration (i.e., distributions should not be required to have a configuration and a distribution may be deployed with a single configuration or with different configurations)

Summary: eventually, we will want the 3.x distro to be driven by an openmrs-distro.properties file, rather than by its pom.xml + spa-config.json files.
This would require to rely on the SDK, at least to a certain extent.

2021-06-21

Attendees: Dimitri, Juliet, Suruchi, Burke, Jen, Andy,  Kaweesi, Daniel, Isaac, Grace

  • Reminder
    • Lightning Talk on Forms Engines this Friday 25 June at 13:00 UTC
  • Changes to distro POM to make SDK tooling easier (Dimitri, Brandon, Mike)
    • Defer to call when Mike and/or Brandon can join or take to Talk
  • Update on how Workflow State is being handled/planned to be handled in 3.0: Cohort Module
    • Program/Workflow - Primarily used for Studies & Treatment Programs
    • Cohorts - Patient Lists (used for studies or finding patients with characteristics OR for queueing)
    • Derived Concepts (aka Logic, Calculations) - Calculating an "observation" based on existing data
    • TODO: Burke will pursue use cases and work on getting design discussion in community (e.g., Talk)

2021-06-13

Attendees: Burke, Grace, Dimitri, Andy, Daniel, Eudson, Ian, Jen, Joshua Nsereko, Juliet, Joseph, Suruchi, Tendo

  • Anyone recognize this bug?
  • Packages technical modeling ideas
    • Package vs Distribution
    • Thinking of Packaging similar to Maven's packaging (like a POM file)
    • "A package is a bundle of behavior (modules, apps, etc.) and content (concepts, forms, etc.) to solve a particular problem." -Burke
    • Distribution declares specific version of core/platform/frontend; whereas, packaging defines requirements but doesn't necessarily declare specific versions.
    • Could be done at build time 
      • Packages technical roadmap
        1. (DONE) Conceptual idea
        2. (IN PROGRESS) Specification: Definition of what would be in a package, how it is wrapped 
        3. Directory: Way of finding available packages
        4. Package Manager Tool: that would "unpack" the package (Unpacker/Explorer/Inspect: Tooling that asks "given this package, what kinds of concepts is it using?")
          1. Tool expansion: to show dependencies
          2. Tool expansion: Deal with depenciencies between packages
  • What still needs to be done to support Iniz Validator (if anything)? 

2021-06-07:

Attendees: Grace, Ian, Dimitri, Tendo, Juliet, Daniel, Jen, Settimba

Recording: https://iu.mediaspace.kaltura.com/media/t/1_hi8a7uja

2021-05

2021-05-28: 

  • TRUNK-6006 - burke to follow up
  • Time change: Moving to Mondays at 2pm UTC / 10am EDT / 7am PDT / 5pm EAT / 4pm CET / 7:30pm IST, starting June 7.
  • How are we using these calls; Goals for TAC for rest of 2021
    • Who do we want participating in TAC?
      • Representation from Squads and major strategic efforts
        • Micro Frontend work
        • OpenMRS 3.0 strategy
      • Senior design & technical decision makers
    • What has TAC accomplished by the end of 2021?
      • TBD
    • How do measure TAC's effectiveness?
      • Set goals (at least 2x/year) and reflect on progress (at least 2x/year)
    • What is the purpose of TAC?
      • Updates? Would prefer to communicate updates in community forum (e.g., Talk/Blog)
      • Helping unblock key technical issues (e.g., security issues)
      • Brain trust: Access to senior design & technical decision makers
      • Make or approve technical/architectural decisions for the community
      • Communicate decision/strategy/vision to the community (and stakeholders, like MoH, funders, etc.)
    • What we want (to keep)
      • The brain trust
      • Ability to do deep dives
      • Get more folks to join
    • What we don't want
      • A series of updates
      • Being too reactive (keep meetings productive & engaging)
  • Tech radar

2021-05-21:

Attendees: Isaac, Ian, Burke, Suruchi, Grace P, Mike, Tendo, Steven W, Juliet

  • Please vote on better time: https://talk.openmrs.org/t/lets-find-a-better-tac-call-time/33531
  • Notices of interesting work/discussions going on:
  • Progress with program workflow module: Meeting OHRI's needs? Other POC users' needs?
    • FHIR review by Burke: Haven't found specific FHIR resources that would be helpful. There are generic resources but nothing ++ specific. Episode of Care. There are "careplans" and "tasks" that track the transitions across states, & plan definition (defines the careplan).
    • Follow up with OHRI in subsequent call on progress using existing Program Workflow. 
  • Suruchi talk: Product Management vs Project Management & key takeaways from the INDUSTRY Virtual Conference for OpenMRS
  • Iniz and Liquibase changesets: Process ongoing via PIH of eliminating custom code & standardizing

2021-05-14:

Attendees: Isaac, Burke, Suruchi, Juliet, Grace P, Jen, Joseph Kaweesi, Jude, Daniel, Herbert, Tendo, nyyesigahen

2021-05-07: Backend Support for Point of Care Workflows

Recording: https://iu.mediaspace.kaltura.com/media/t/1_n634lqqg

  • Grace away Monday/Tuesday next week
  • Anyone using old PM Tool? Taking down. Agreed. 
  • Teaser: Suruchi Product Management talk next week
  • QA update next week
  • Review Backend Support for Point of Care Workflows / how can we leverage Program Workflow States (~30-40 mins)
    • Need someone to own going through requirements and trying out building this into program workflow, and then i.d. where we're finding a blocker
    • Fitti to start by asking his team to look at the program workflow module - 2 weeks
    • We will reconnect about progress at TAC in 2 weeks.

2021-04

2021-04-29: 

Attendees: Ian, Burke, Jen, Isaac, Mike Seaton, Juliet, Grace P, ...

Recording: https://iu.mediaspace.kaltura.com/media/t/1_og7d1xia

  • Bintray migration check-in: Largely done. Cut off date tomorrow. Need to update:
    • The add-ons server (Ian; in progress)
    • Bug in SDK - hyphen marks off name from version; won't support modules with hyphens in name (Ian; in progress)
    • Change so SDK doesn't go 1st to Bintray. Prevent confusing error messages in Log file. https://github.com/search?q=org%3Aopenmrs+bintray&type=code 


  • Travis → Actions: 
    • Changeover mostly done. Nothing building on TravisCI anymore. Though we got 25k Travis credits. Would run out b/c of the ++ builds we do. Used 300 credits in last mo w/ minimal builds. 
    • Sanity check of OWAs changed - Could do minor version release for all OWAs to see if everything works as expected. (Ian)
    • Will need to monitor Actions; if no PR touched before build it may not run (GH policy due to crypto mining in Actions)
  • Core building against 8 versions of JDK - checking that changes don't break in Java 8-15.


  • Next week teaser: Backend Changes to support Point of Care Workflows → how to leverage Program Workflow States & existing datamodel; and, make sure we can connect this datamodel to encounters. 
    • Requirements doc to be shared
    • Would be great to have embedded in OMRS 3 w/ flow to transition workflows etc.
    • History of modules created where an obs would unlock specific state transitions. But need to address encounter-based workflow needs. Either Patient Program or Patient State
    • Looks very similar to workflow PIH needed in Malawi



  • Platform Team idea
    • OHRI bringing 1+ FTE Devs - could get back to ~3 full-time folks helping move platform etc forward
    • Platform probably warrants additional care given it's our fundamental resource everywhere (smile) 
  • Platform 2.5 Goals & Resources
    • Created https://om.rs/platformboard - Talk & JQL details: https://talk.openmrs.org/t/platform-2-5-release-management-board/33230
    • Make Diagnosis immutable for 2.5? https://talk.openmrs.org/t/why-is-diagnosis-not-immutable/33255/5
      • Diagnosis and Conditions recorded as obs - when upgraded to 2.2 lost their immutability
      • Connects to question of audit log
      • Decision: Move forward with audit log. Could have Diagnoses immutable, so long as there's a history of changes. Sweeping change of how voiding works everywhere not in 2.5 scope.
      • In 3.0 will be using Form Engine more & more. Accessing data vs viewing data. System Admins will need to see if there's been illegitimate uses. 
      • Decision: Some audit log improvements could definitely be in 2.5 scope. Created Audit Log epic to track this work:  Unable to locate Jira server for this macro. It may be due to Application Link configuration.


2021-04-22: Platform 2.5 Planning

Recording: https://iu.mediaspace.kaltura.com/media/t/1_6t365ejn

Attendees: Burke, Tendo, Isaac, Grace, Mark, Mike, Daniel...

Misc Updates:

2.5 Platform Release

"Platform" = Core + REST webservices + FHIR. So Platform 2.5 = Core 2.5 + latest REST WS + latest FHIR. Decision: remove OWA + addonManager. Burke to post on Talk about this. 

How do we manage what fixes are included? 

  • Jira decision: Platform should be a high-level concept - having it as a version option is confusing. Remove "Platform 2.5" as a version option?
  • Board that shows everything included/desired in 2.5: Instead of having a Platform 2.5 version option, Platform 2.5 board that consolidates anything with the versions for Core 2.5 + latest REST WS + latest FHIR.
    • FixVersion 2.5 OR AffectsVersion 2.4

Discussion: Instead of continuing to give people OWA + addonManager included in Platform, should we remove them?

Do we want to continue recommending the addonManager in the Platform release mgmt? Or do we take it out?

  • Have been recommending that people use the RefApp instead - then they were happy with this.
  • Not aware of anyone using addonManager in production
  • Decision: Point them to the RefApp. but include the addonManager (so that non-RA users still have something they can use to manage modules). Not put effort into improving addonManager. 

Do we want everyone to continue getting the OWA module?

  • We had decided not to promote OWAs. Trying to deprecate them. So why are we giving people an OWA manager out of the box? 
  • People could still use it, just a bit more work to find and use it. 


2021-04-15: Bintray → Artifactory & Travis → GitHub Actions Migrations; How to prevent Platform bugs; RefApp 2.12 scope discussion

Attendees: Ian, Mark, Juliet, Isaac, Burke, Daniel, Grace P, Jen, Sharif, Steven W, Mike, Tendo
Recording: https://iu.mediaspace.kaltura.com/media/t/1_0sn4akep

Jira updates: Spring Graveyard completed; 250 tickets cleaned up. Pattern we're using in Squad calls of using Sprint board.

Bintray migration to Artifactory - Ian - Mostly done, except Add Ons. Now deployed to Artifactory instead; 6 OWAs in RefApp all migrated. Not all underlying jars for OMODs in Bintray exist in Artifactory instance. Might have bare OMODs in Art that could be downloaded and used. 

  • Still need to migrate Add Ons over to Artifactory - Ian own
  • Hard EOL date so bigger priority than Travis

Travis migration - Ian - repos built in last 6 mos covered.

  • Reviewing repos built in last 1 yr and migrating those. Ian continuing to do on ad-hoc now. When we need it, we need it, we know how to do it. Key contacts would be: Ian, Burke
  • Nice-to-Have Idea: Bot - travis.yaml → go to this wiki page if you want this built

Recent bugs discovered

e.g. links for legacy UI don't work anymore on Platform.

  • Run platform: legacy UI module links for .form, .list, no longer work at all. 

  • Run setup wizard: displays ugly; not showing images, some buttons not showing up; looks like plain blank page. 

  • Automated UI tests: would have caught both of these. Takes ++ time to find & fix esp. after the fact. 

Commit that broke Postgres; commit that broke MySQL. 

  • CI plan that runs both tests - Postgres & MySQL - could have caught this. 
  • Do we need to also support MariaDB? So far seems that as long as it works for MySQL, it's ok
  • Goal: Daily RefApp build would test against MySQL & Postgres. OMRS Core builds would test against supported DBs on any commit as well.
    • (all the tests that run against H2 would switch to run against MySQL/Postgres). No technical blockers. 

TODO: Sharif, Daniel, Joseph to follow up on next steps for automating these. 

A Key Takeaway: legacyui tests are still valuable because they also expose bugs in the platform


RefApp 2.12 scope proposal

  • existing bug fixes - esp. because of # of security issues patched. NC state team wants to publish their findings. Legacy UI module especially key to be updated before they can publish. (Hard publication deadline by end of summer)
  • qa tests
  • urgent new fixes
  • not looking for new feature requests - focus is on cadence, updating module versions. Get latest versions of modules bundled. 
  • Goal: release within next 1-2 months 
    • TODO: Post to community requesting release manager; updating on plan

Call for input - ideas to recruit mid-level devs

2021-04-09: XSS patch discussion, Bintray & Travis Migration plan, Showcase debrief

Attendees: Isaac, Ian, Grace P, Daniel...

Regrets: Burke

Recording: https://iu.mediaspace.kaltura.com/media/t/1_gjowtnzi

  • Specific XSS patch discussion (5-10mins) (Isaac): Proposal to disallow HTML characters
    • Would disallow formatting like <br>...</br>
    • Action: Isaac to check on Talk if anyone relying on these. → Decision: To html encode the note. HTML characters can still be entered but won't have a formatting impact - so no HTML injection. 
  • Logging not happening where it should be
    • E.g. deleting a patient
    • Plan: add log messages to DAOs  → Follow up: conversation ongoing on Talk about Audit module; this solves most of the logging problems NCSU report brought up. Work is going to begin again on that module in May. (Led by Mekom)
  • Debrief Community Showcase & 3.0 Feedback Session (All) - what resonated? Surprises? Concerns?
    • Recordings are all here: 2021-04 April Mini-Meeting & Spring ShowCase
    • Helped communicate where we're going, in a concrete way (e.g. what are MFEs and why are they helpful)
    • Updates from Implementers helped confirm we're thinking about right things
    • People very afraid of upgrading (to 3.0) - need at least a simple draft migration plan blueprint and a pilot example
    • Offline & Mobile CHW use cases quite prominent - we probably need a community design/lightning talk about this - Jen following up
  • Migrating off Bintray: Ian/Daniel/Mike working on this
  • Migrating off Travis:
    • Pretty sure we have everything that was actively running on Travis migrated over. QA issues no longer running on Travis. 
    • Remaining repos running on Travis are less frequently used - less easy to automate. 
    • Next Steps: Ian going to go through all these manually (sad)
  • Daniel's update: Highest priority for now is the automated tests for the platform.
    • having all our existing tests running on both MySQL and PostgreSQL
    • having tests for the platform setup wizard for both initial installations and upgrades

2021-03

2021-03-26: Iniz/OCL Update, Client vs Server Timezones, 3.0 Framework confirmation  

Attendees: Dimitri, Mark, Cliff, Daniel, Grace P, Grace N, Ian, Isaac, Jen, Juliet, Mike S, Moses, Suruchi

Recording: https://iu.mediaspace.kaltura.com/media/t/1_ik3roecf

  • Quick check-ins
    • Security: NCSU fixes ongoing; HTML fixes in Legacy UI Module - if running into issues w/ error messages let Isaac know.
    • Easter Plan? Call next friday or not? TODO: Poll Next Week
    • Using Design Sesh Monday to go through remaining Travis projects. 
    • Virtual Community Meeting happening April 7-8, check it out here
    • No more recurring failure issues with CI. (smile) 
  • Update on Iniz/OCL support work (Suruchi)
    • OpenConceptLab Loader in progress, some blockers. To post draft PR in Iniz for Iniz team to follow; to write test, starting with test from Metadata Use Case. 
  • UX implications of storing a preferred time zone as a user property (cfr HTML-755 and related tickets.)
    • Because our legacy systems stored time as the server time, just saying "we'll use the client time zone" in 3.0 isn't that simple.  
    • Need to bring this up with other stakeholders: OHRI, Burke. Do people need to be able to change their time zone? 
    • Using the client time zone in 3.0 is recommended. 
  • 3.0 Framework - Confirmed overview of vision & key technical pillars
    • No concerns voiced with sample presentation of 3.0 Framework

    • AES: Focus on FHIR-based reporting - will be good long-term, but may not fit short-term needs of implementations right now. Solution will be needed for those. They can’t wait for state of the art analytics-on-fhir to be ready. Possible ppl start doing other things in the meantime. Pressing reporting needs. Mekom had to use BahmniMart b/c works out of box to get results out of OMRS. 

      • Capacity building around query-writing w/ new tools
      • EIP is where transform would naturally work well b/c extract has already happened - but this workflow isn’t set up in AES; AES using Camel, maybe could/should have been using EIP

      Allan mentioned roadmap for non-fhir reporting: What’s the short term solution that could be ready sooner? 

      Dimitri to join next AES squad call - ideally (1) share market observations and (2) pick up non-fhir reporting

2021-03-19: Plan for Iniz support for OCL, Decision to move from Travis to GitHub Actions

Recording: https://iu.mediaspace.kaltura.com/media/t/1_peabyzal

Attendees: Isaac, Grace, Mike, Tendo, Ian, Burke, Daniel, Jen, Suruchi, Juliet, Mark, Settimba

  • Security Update: More PRs coming in from NC State team, Isaac continues to review these. Isaac needs to reduce OMRS duties in August. Jen & Isaac to follow up re. further growing NC State relationship.
  • (10 mins) Iniz support for OCL - Overview of technical plan to enable our users to use both Iniz and OCL for OpenMRS
    • Use cases:
      • Enable Concepts to be loaded into Iniz that are managed in OCLOMRS. Have Iniz use Subscription Module. Looking into loader Iniz using. Goal is to have Iniz understand the OCL .zip file (and the JSON file inside).
        • (confirm check-sum is ok) Iniz uses a check-sum to determine whether or not to re-load a file - so whatever we put into Iniz, if it's the same content, then ideally it would have the same check-sum
      • Support offline (and reasonable file size). Will support offline loading needs as well / "deploy with USB stick" scenario. (currently 18MB pretty & zipped)
        • Example using export of CIEL v2021-01-29 from OCL:
          • Raw (one-line) JSON: 270M (17M zipped)
          • Pretty format JSON: 325M (18M zipped)
      • Support diff check/review of JSON file (user friendly to look at). The OCL .zip may not have been originally designed with that use case in mind. JSON needs to be formatted nicely enough, with predictable order, so that diffs/review would be relatively easy. (e.g. if you produce it 3 times, you get the properties in the same order every time). → May need update to OCL Module to support unzipped or zipped file.
        • Pretty-Print Feature request for OCL: a parameter when requesting JSON export to pretty print the content.
    • Use #openmrs-initializer channel for updated; can tag Mark Goodrich for support as well (smile) 
  • (10 mins) CI Plans failing - Process to kill docker containers on build agents (Ian)
    • Having to build same build up to 10x/night!! With each push. Productivity killer.
    • OCL Builds are big part of the cause - TODO: Burke & Grace to f/u with OCL team; have them set up a separate agent. 
    • Some discussion re. moving to GitHub Actions. (So far these are free for OSS) Has benefit of not having to maintain infrastructure; and built-in to GitHub.
    • Is there a build dashboard product that allows you to point to multiple links (e.g. Bamboo + Travis + GitHub Actions) - reduce duplicated deployment 
      • Currently have Travis quota - if exceeded, the builds won't build and in PR it says "Pending"     (so we moved ++ MFE and modules off of travis)
      • Need to understand: What would be the side effects of moving to GitHub Actions? What about Bamboo would we miss?
      • Are any modules still using Travis to build? Should move these over to GitHub Actions. Travis.org shutting down in just a few weeks.  We already exceeded the restrictions within a week - used 10,030 of 10,000 credits. "Travis is useless to us." 

Decision: 

Phase 1: Move all our modules/projects (esp. essential ones) using Travis over to GitHub Actions

Possible Phase 2: Move Bamboo builds to GitHub Actions (requires more discussion → Talk)

2021-03-12: Using HTML characters in Test Fields, Technical Overview of New QA Framework

Attendees: Isaac, Cliff, Daniel, Dimitri, Grace P, Ian, Juliet, Kaweesi, Tendo, Mark, Mike, Sharif, Grace N, Jen

Recording: https://iu.mediaspace.kaltura.com/media/t/1_s237111x



2021-03-05: NigeriaMRS Telecommunications demo, IHE update, Metadata management update

Recording: https://iu.mediaspace.kaltura.com/media/t/1_tth784yw

Attendees: Isaac, Grace P, Settimba, Juliet, Grace N, Mark, Mike S, Jen, Steven Wanyee, Daniel

  • Reminder: Vote for a GSOD project. This year is different - we will get dedicated funding to support a Technical Writer on a specific project. Pick one here: https://talk.openmrs.org/t/brainstorming-vote-for-a-project-idea-for-gsod-2021/32289/10?u=grace
  • Security update from Isaac: 
    • We continue to work on the NC State-id'd vulnerabilities. They have provided some undergrad students this semester who will work on patching OMRS SW vulnerabilities as part of their assignments. Meeting with them 30 mins q. Friday. If you see any security-related PRs, let Ian know.
  • Nigeria MRS - Isaac
    • Workflow for getting a Phone Visit: patients go to a Wix site and submit a form with their information (or they call a clerk and clerk enters it) - that goes into OMRS - custom module shows a list of new patients on the front page, they see the new patients, they call the patient. Clinician has option to follow up w/ pt via text messages (through a new module) - that's Dr. Levine's work. Dev'd custom OMRS modules.
    • No video consult
    • https://github.com/fortitudoinc/fortitudoinc-infra
    • Reach out to Isaac for info of people managing this project today
  • IHE update - Ian - IHE Connectathon: Takeaways and roadmap implications (e.g. IPS)
    • EU connectathon coming up in May/June
  • Update on Metadata management & packaging recommendations: Uzing Iniz, CSVs, +/- OCL for OpenMRS 
  • CI Breaking frequently this week - raised w/ Cintia, Burke - seems due to Memory leaks. Will this be a consistent scaling problem? If so, we should consider GitHub actions (they use GitHub's infra; can do everything Bamboo is doing; except doesn't give us a unified place to see your build status; Bamboo especially good for managing pipelines - projects running off others)
    • Some builds take more memory that others
  • Announcements
    • OHRI Technical Foundations call on Tuesday next week
    • MFE Architecture update session on Monday next week

2021-02

2021-02-25: Platform Release Priorities, Metadata i18n update, & FHIR's International Patient Summary (IPS)

  • IHE Connectathon session: Tuesday, March 2 at 10am ET | 7am PT.
    • Go to IHE NA Connectathon and click on Register Here or Register Now! • When completing your registration, select the Gold Package • Apply the promo code GlobalGood on the payment page at the end. • Space limited to 150 participants
      150 spots available for free for OMRS community
  • The FHIR IPS (International Patient Summary): Overview, maturity level in the context of implementing the SHR specification of OpenHIE
    • Designed especially for "unplanned, cross border care". Very untested at this point - most production use we've heard of is it being used to exchange some information across medical practices in Argentina. Decent structure to start from for an SHR. 
    • IPS Implementation Guide: https://build.fhir.org/ig/HL7/fhir-ips/StructureDefinition-Composition-uv-ips.html
    • Very simple to support. Was very straightforward to set up basic level for IHE connectathon: Ensured there were intl SNOMED codes in the data and then these were readable. 
    • Doesn't get you what you might need in more regulated environment
    • US, Canada, AUS, UK all have own version of FHIR-based continuity of care documents. None based on IPS but IPS informed by some of them. 
    • IPS could be helping form a nucleus of, what information should be shared in an Intl context?
    • Comparison to US CDI (Core Data Initiative): Some useful patterns but would get very hard to use directly in an Intl context. e.g. way CDI profiles patient: needs to support races and ethnicities, but definition of what qualifies for these refers to specific US regulations of what the US gov defines as race, which may not be helpful internationally.
    • IPA Initiative: More a CDA, made more internationally available. 
    • If a specification is needed right away by an implementer, the CDA is the low-hanging fruit. But IPS is likely to replace as next version. 
    • Most people are using FHIR to support national systems, rather than for international data exchange. 
    • IPS may eventually be superior to the CDA because the underlying structure is just via resources - so if your system supports FHIR, you can import them as if they were native data.
    • Work ITECH has done in FHIR squad lately is already pulling down support for parts of IPS.
    • Concern: Cross-border care is a much rarer use case than 
  • Update on metadata i18n: we seem unblocked: https://talk.openmrs.org/t/i18n-support-for-all-classes-extending-baseopenmrsmetadata/26218/24
    • TODO: Just need to make sure in MFEs code is using the display property of the resource (not the Name property) to the user → TICKET TO CHECK
    • TODO: Confirm that FHIR API is returning the display property (not the Name)
    • Dimitri & Mike working on update to Iniz: https://github.com/mekomsolutions/openmrs-module-initializer/issues/95 This will create way to define metadata and the different locales you want to support. They experimented with this and changing the locale in Iniz just worked at changing the messages. 
    • Addresses Mekom's biggest concerns about OMRS i18n. 
    • UI Framework is driving 
    • Though - it would be nice to switch btwn locales without having to change the backend. Display string could show all the locales supported; so you could pick this and see everything that's supported - toggling btwn Eng/Fr/etc happens in a snap. Could be helpful for offline. 
    • RTL & date formats
  • Platform Roadmap priorities - MetroRetro board: https://metroretro.io/board/LBQDUT9RE2V1
    • OCL v Iniz: Iniz will support OCL config file

Platform Release Priorities: Ideas Deep dive.

2021-02-19: Implementing Patient Flags/Alerts, and key updates from the FHIR, Analytics, and MFE Squads

Recording: https://iu.mediaspace.kaltura.com/media/t/1_pihdlh25 

Attendees: Burke, Daniel, Dimitri, Grace, Ian, Isaac, Jen, Mark, Mike, Sharif, Tendo

Updates

  • Security: Weekly Sync with NC State students to support their issue work
  • Jira proposal: In 1 week, we’ll change all the Jira projects using the RefApp workflow to use the TRUNK workflow. https://talk.openmrs.org/t/jira-improvement-plan-part-2-trunk-workflow-replace-confusing-ra-workflow-to-use-the-trunk-workflow/32282 
  • (5 mins) (Grace, Dimitri, Mark, Mike) Update on OCL Subscription Module v Iniz conversations this week
      • Iniz would have 2 different formats; could have it refer to Subscription Module (by using OCL Subscription Module API; would be aware of module and depend on it) (low-hanging fruit for Iniz)
      • JSON Output needs to be readable & consistent (predictable sort order) - so it’s easy to diff 

      To Validate w/ Subscription Module: 

    • Not too slow for 10,000’s concepts (TODO: Grace check)
      1. Consistently exports it the same way every time so you can handle diff
      2. Ability to sync or export multiple collections - not handled well w/ Subscriptions atm (UI designed for 1 link) - add to roadmap

    • DONE: Mike to look at Subscription Module code. Looked good; trying to do all the right things. Using multi-threading to try and import the concepts and mappings as quickly as possible (even moreso than some of our other, single-thread tech.) Seems well thought through. Does rely on ordering of the JSON structure & how it’s formatted.

  • (5 mins) (Grace, JJ, Dimitri) MFE Squad Update - Carbon progress and April pilot plan
    • Decided to move ahead with Carbon 5 mo ago. Accelerated designs and generally positive team feedback. Tablet designs done; wrapping up desktop behavior now. 
      • Need component library for devs to grab from (copy and paste code).
    • Working towards April pilot of new UX in HIV Outpatient clinic at AMPATH in ~April 
    • Experimenting with AMRS Form Builder
      • Still plan to support HFE; may be through iframes; not a top priority at the moment. Angular App - showing Angular App running in a REACT App! (Win w/ MFE framework that that's possible.)
  • (10 mins) (Burke) Analytics Engine Squad Update - pilot launch plan & FHIR schema decision
    • AE Squad Prepping to launch ETL pipeline for performant analytics at AMPATH
    • ITECH already using Analytics Engine pipeline to generate the patient data to send via FHIR to SHR in Haiti; using batch pipeline
    • Based on decision to use FHIR schema (using as basic representation for clinical data from OMRS; stored as parquet files b/c they're a columnar format that can be efficiently queried; Google research has shown this approach can significantly improve the speed of queries. Can write queries in python or SQL.)
    • Looking for additional implementers and pilot sites - want input so we make a solution that works for multiple implementers
      • TODO: Grace f/u w/ Bashir and Allan re what someone can run on their machine to check it out
      • New Data Analytics person joining PIH
  • (5 mins) Ian & Grace: Overview of FHIR squad shared priorities. Confirm FHIR being used as main modality.
    • Main momentum around integrating OMRS into an HIE ecosystem - esp. for CR/MPI and SHR (implementers bringing requirements). MPI/SHR work spearheaded by ITECH; squad trying to extend it for others to use.
    • Patient flags has lot of overlap w/ Analytics Engine b/c "this VL is dangerously high, consider moving to new ART"
      • module: Patient Flags Module does this. But performance very poor: Every flag is a SQL query, so when viewing the pt chart, every SQL query has to be run to generate the flags. 
      • FHIR aspect similar to pt list discussion: Bett has added support for patient lists in FHIR. Next is to set up system-generate lists e.g. "patients who are due for an appointment today" "patients who may be LTFU" 

Big Topics

Posting coming from Burke about 2021 Technical Vision - decision to go towards MFE approach; reporting via Analytics Engine, etc

2021-02-12: 

Attendees: Isaac Sears, Grace P, Dimitri R, Juliet, Ian, Burke, Mike Seaton, Jen, Mark G, Daniel, Andy K, Settimba Lamech Nalumoso, Cliff

First half: Announcements & unblock specific questions. Second half: Key technical updates you should know happening around the squads.

  • Announcements:
    • (2 mins) Fellowships Spots open - spread the word & let us know if you want to help review applicants. https://talk.openmrs.org/t/openmrs-mentor-and-fellow-opportunities/31966 
    • (5 mins) (Burke) Brief introduction to OHRI project
      • "OpenMRS HIV Reference Implementation". UCSF leading dev. Timeline: Proof of concept by Sept. Overall a multi-year project.
    • (2 mins) OpenHIE Experiment: Update on IHE Connectathon HIE use case happening in 3 weeks (Ian & Piotr)
        • Cloud Hosted OMRS paired to HAPI FHIR server (using FHIR IPS content)
          • Sending messages via OpenHIM
          • OpenCR on proxy HAPI FHIR server
          • SHR stand-in on HAPI FHIR server as standalone
          • Using the iSantePlus distribution of OMRS
  • (10 mins) (Dimitri and Andy) Discussion: adding a ‘conceptnames’ domain to Iniz
    • Iniz 2.0 release coming very soon (so this will need to be part of a another future release)
    • Mekom plans to combine OCL with Iniz; meeting happening Monday w/ Ellen/Suruchi/Michael/Grace to review this 
    • Overlap with OCL Subscription Module? Whether it makes sense to have Iniz Module and Subscription Module. MDS has been hassle. 
  • (5 mins) (Dimitri) Backend Forms Validation 
    • not talking about frontend form logic here, but backend integrity validation.
  • (10 mins) (Grace) Overview of the OCL Client
    • What it is and how it's useful to rapidly manage concepts
    • Reviewing Subscription Module overlap w/ Initializer

2021-02-05: SSO with OpenMRS

https://iu.mediaspace.kaltura.com/media/t/1_hawh0zzk

Attendees: Burke, Dimitri, Ian, Daniel, Grace Nakiguli, Grace Potma, Jennifer, Juliet, Isaac Sears, Mike Seaton, Tendo Martyn, Moses Mutesa

Recording: ___

  • SSO with OpenMRS: Demo of SSO working with the RefApp and Google OAuth (Mekom)
  • Deep dive on issue with Iniz: Making ConceptName a first class domain object
    • Dimitri R described an issue they were having with concept names, since iniz expect each row to be an "object" that it can clear & reset according the CSV and concept names are referenced directly (from obs), preventing them from being arbitrarily deleted & recreated
  • Deferred topics
    • Quick review of OCL for OpenMRS: Different than OCL
    • Setting the stage for a deep dive: Proper support for i18n of metadata

2021-01

2021-01-29: Modeling Patient Lists with FHIR groups, Tech Radar changes, and final GSOC project list review

Recording: https://iu.mediaspace.kaltura.com/media/1_1uvnkxbx

Attendees: Ian, Dimitri, Isaac, Burke, Daniel, Jen, Bett Kipchumba, Steven, Grace Bish, Mike Seaton, Tendo Martyn

Update on Timezone convention:
Dimitri working on wiki page for timezone conventions; PR to fix a couple places where new conventions aren't followed yet (e.g. in HFE). Hoping we could have one piece of code, a utility class in core, that we can point to as the string convention to follow. Currently staged in an HFE pr.


20 mins - Decision Needed to Unblock Patient Lists: Using cohorts to model FHIR groups (Ampath is blocked on implementing; proposal and previous discussion here)

  • Proposal: Represent patient version of group using cohort for that - PR pending to do exactly that. But we don't currently have FHIR expression for characteristic (needed in order to express groups by characteristics of patients, e.g. male >50yrs). 
  • What we don't want: to end up with groups in FHIR, cohorts in core, and some definition of patient lists all living somewhere else.
  • Decision: Expanding cohorts in core to meet the needs of FHIR = better.
  • When: Platform 2.5 release too far away; and anyway, lift of doing a platform upgrade out of scope for immediacy of Ampath's needs. Can we support this update to core via backporting to 2.0 or 2.1? Start with support in 2.5, and plan a structure for 2.1 that will upgrade into 2.5
  • Next Steps: Ian and Bett to follow up on next steps; Bett to proceed with work as planned/described in order to support Ampath's urgent need of patient lists; Ian to provide model guidance as-needed. 

20 mins - Tech Radar Feedback from this survey: https://forms.gle/F5NHH8Q7F9TYEy2i9

  • Angular → Assess? → Burke to bring to community on Talk
  • TypeScript: What do people find difficult about it specifically?
  • Kotlin: Being used in Zambia ++ → Steve to f/u re. how much this is being used

Changes made today:

  • Carbon → Adopt
  • Bootstrap → Hold. since there are no plans to adopt it further, and we don't want to cause confusion while we are putting more emphasis on Carbon
  • Reference Application as Framework → as Foundation

Additions to consider:

  • Tomcat or other J2EE container(s).
  • Standard Deployment conventions: Artifact Packages (how to make this more clear - no clear convention right now; might use docker, ansible, etc; something we could point people to)


20 mins - Review GSOC Project list

  • General agreement voiced for GSOC '21 projects that have been proposed

2021-01-22

Attendees: Dimitri, Burke, Mark, Cliff, Daniel, Isaac Sears, Jennifer, Juliet, Mozzy, Sharif

Reminder: Next week = Radar update discussion. Complete prep work here (5 mins): https://forms.gle/F5NHH8Q7F9TYEy2i9

Big

Focused (will probably impact roadmap discussion somewhat)

  • Nailing down timezone conventions: Need unique way across OMRS; ongoing blocker for Mekom. Talk convo & Slack convo heading in the following direction; let's confirm:
    1. How does the server send dates to the client? Answer: Only UTC dates from backend (then frontend can handle changing to timezone of user). Define what's stored on the server so the REST layer can do a conversion as needed
      1. But: 1.x versions may not be able to handle this conversion. 
      2. Ideally should always return timestamps with a timezone (right now people have to assume in some places that it's UTC). ICRC having to set up servers in UTC in order to be sure. But can create situation where DB timezone is different than client server (because these will be locally hosted)! ("Local time" is generally equivalent to "where our server is")
      3. Challenge: Approach doesn't handle sites with DST 
      4. Challenge: Encounter dates are handled just as dates without a time stamp. Assumes T = 00:00:00 → Making this change could affect this and cause people problems
    2. How does the client send dates to the server? Answer: ISO 8601 dates.
    3. The client should display local dates and times to users. (so it should do this with the dates it receives from the server, UTC → client timezone).
    4. Agreement: Defining at a server level what data are stored, what's used for timezone data, leveraging that info at the REST layer to always send time in UTC from REST calls (but explicitly include timezone so it's UTC not assumed to be UTC). 
    5. Todo: Explicit Documentation of "This is How to Implement Timezones". Clear place in server to say "here's what the timestamp is in this server" so REST calls can use that to convert time stamps as needed to the location of the request.

2021-01-15

Recording: https://iu.mediaspace.kaltura.com/media/1_b08tbxxl

2021-01-08: Tech Radar intro review; Approaches to Managing Config; More detail on new Config Validator

Recording: https://iu.mediaspace.kaltura.com/media/1_v39b9j72

Attendees: Burke, Isaac Sears, Daniel, Dimitri, Ian, Ines Fernandes, Jennifer, JJ, Luis, Mike, Pedro, Reagan, Tomas Oliveira, Sharif, Stephen Musoke, Sharif, Tendo, Moses

Quick Updates

  • Security
    • Isaac working on Wiki clarity (Security pages) especially about process & how we handle vulnerabilities based on feedback from OMRS20. Big NC State report handed over has 100's of points Isaac is working through with them - several of the NC State team members have been actively making PRs to fix issues! High-severity issues have so far not been reproduceable. Platform-level and anonymous attacks are what we're looking out for especially. 
    • Q1 Goal: Focus on vulnerabilities outlined in NC State report. Isaac organizing into Jira issues, then will be looking for help w/ patches. XSS bugs may be GSOC appropriate. 
  • OpenMRS Radar change plan update
  • OCL for OpenMRS: details of Q1 goals (i.e. the plan to make this thing useful for more implementers!)
  • Analytics Engine Squad: details of Q1 goals – (1) getting engine running in parallel at AMPATH, (2) getting a 2nd implementation to try/test engine.
    • PIH & Mekom interested to look at it. 
    • Caution that "analytics" phrasing can cause confusion about whether it competes specifically with DHIS2. Be careful with messaging: "Nice bridge to DHIS2".
      • Perhaps adding "getting data to DHIS2" as a parallel goal with indicator production would help underscore how the analytics engine is meant to expose data to tools like DHIS2 and not to replace or compete with tools like DHIS2

 Meaty Topics

2020 Meeting Notes

 2020 Meeting Notes

2020-12-18: New Config Validator

Recording: https://iu.mediaspace.kaltura.com/media/1_wsoekny5

Attendees: Dimitri, Burke, Daniel, Ian, Juliet, Mike, Reuben, Sharif, Grace, Moses, Mark, Steven, Jennifer

Agenda

  • Next meeting: Jan 8 2021
  • (5 mins) Technical Radar: Update plan.
    • Tech-based rather than Survey-based then several subsequent TAC sessions - Burke & Grace to work on
    • Discussions during TAC in new year
  • (20 mins) Initializer Update: https://openmrs.slack.com/archives/CPC20CBFH/p1608214319036700
    • Initializer Validator: The standalone config validator is almost ready!
      • https://github.com/mks-d/openmrs-module-initializer/blob/validator/readme/validator.md
      • Needed the most: Discovering at run-time that something not running. Idea is to allow one command, wait a few minutes, and then see all errors properly reported. Unlocks CI against configs. Can run from command line without needing to install anything. Esp if you have a team of devs who haven't worked on much OMRS things yet; waste time trying to see what's wrong; don't know how to use SDK, just using distro. Massive time saver.
        • More interesting work could be done: e.g. roles that fail to load due to privilege errors
          • Serializer & Export tool could help unlock updates & make faster
          • PIH has config setups for EMR implementations that have dependency on the reference PIH EMR config; those can specify what they want to pull in
      • "The Initializer Validator is a standalone fatjar to make dry runs of your OpenMRS configs and to report on any errors. This enables developers and implementers to be warned well ahead of time that a config would fail when loaded on real OpenMRS instances."
      • Use Cases: 
        • On top of CIEL
        • Skipping some domains
        • Including only some domains
        • Excluding some files in a domain
      • Available date: _____
      • How it could help w/ RefApp or Platform releases: 
        • Would need to plan ahead to extract config and incorporate initializer before this could be used, but that's part of the goal
  • RefApp & Platform Release
    • Platform: release plan beginning of next week
    • If you find issues: Use "Affects Version"
  • OCL's MSP
  • Review the Product Dashboard: Vision, Direction, & Projects
    • What's on the horizon next year? Trying to capture this with a new short roadmap view.
  • GSOC Projects: Plan to i.d. projects

2020-12-11

Recording: https://iu.mediaspace.kaltura.com/media/1_w0e2phv5

Attendees: Isaac, Grace, Juliet, Romain, Ian, Burke, Jen, Mike, Sharif, Daniel, Moses, Dimitri, Tendo

  • (2 mins) Holiday meeting plan - last 2020 call next week, reconvene Jan 8th
  • (1 min) Reminder: The Product Dashboard: om.rs/productdashboard
  • Demo Server - failing 
  • (10 mins) Conference technical debrief: Given what we heard at the conference, is there any new technical direction we should consider, or existing directions we should further emphasize? MetroRetro link: https://metroretro.io/board/LB0VW05UTCS2
  • (10 mins) Security: Recent Advisory & Result of discussions w/ Isaac and Ian at conference
    • User permissions could be better organized: Permissions tend to be overly permissive. E.g. Implementer who wanted to enable clerical staff but couldn't give them more access because of how much that would unlock.
      • NEXT: _______
  • (20 mins) Update on Deployment Packaging prototype work by Romain
    • Looks good! Looks powerful.
    • https://github.com/openmrs/openmrs-distro-referenceapplication/tree/3.x
    • Can we convert the SDK to use this, instead of the tomcat it uses now? 
    • PIH: Teams not ready to use Docker on servers; using ansible process that sets up ubuntu with java, tomcat, etc; they follow an ansible playbook
    • Would need to build & maintain a maven plugin
    • NEXT STEPS: Romain & Mike to connect about project inheritance, & write some documentation about switching 
    • THEN: Update SDK  to take this approach. So next standalone/CI deploying uses that approach.
  • (5 mins) Platform release updates: Beta released; confirm timeline for full release 

2020-11-20

Attendees: Burke, Cliff, Daniel, Ian, Isaac, Jen, Grace, Mark, Mike, Romain, Sharif, Steven

Recording: https://iu.mediaspace.kaltura.com/media/Technical+Action+Committee+%28TAC%29/1_rospturg

Updates: 

  • Meeting time/structure: Agreement to revert back to weekly TAC meetings, not these q2weeks "Deep Dives". Not sure it's made a difference; probably added confusion. We seem to have a good cadence now of updates, 15 min topics, and 30 min deeper topics on most meetings. (Todo: Grace)
  • Updates from FHIR Squad, Analytics Engine Squad, and MFE Squad
    • FHIR: Bandwidth challenges. Working on design; need tickets. Goal to get FHIR module supporting orders and a few other resources we need to meet the International Patient Summary (nice reqmts set and forms basis of supporting exporting data to a SHR)
    • Analytics Engine Squad: Progress w/ getting data exported and into FHIR SQL view - getting data out to a generic FHIR store. UUIDs and how to properly handle that in pipelines connected to hibernate tables. Also working on e2e tests right now to have confidence they're not breaking things with changes.
    • MFE Squad: Now moving from architecture to lightweight e2e prototype. Goal to help people create their own MFE during Hackathon
    • Security: Isaac coordinating with NC State team working through list of 300 findings; currently focused on replicating SQL injection concerns; so far either no . Next is access vulnerabilities; one of their team members already submitted a PR to help fix (smile)   Unable to locate Jira server for this macro. It may be due to Application Link configuration.  Mostly not high severity nor immediately exploitable
      • Increase Isaac's Jira permissions
      • How to make an issue a "Secure Issue" (Jira feature) vs secure project for high severity issues - within the project could use security aspect to control ticket visibility
      • TODO - Grace f/u
    • Deployment Packaging: Romain: Updates on branch that includes deployment packaging approach https://talk.openmrs.org/t/updates-on-branch-that-includes-deployment-packaging-approach/3089 Easy to update SDK and use SPA module as a way to distribute MFE. What we just want is a docker project that has MFEs in the right place. There would be 2 ways to run the MFs:
      • One is using the openmrs-module-spa (so, through Tomcat). And this is already implemented now in Romain's fork
      • The other is via a Nginx server (difficult)
      • update the Dockerfile/docker-compose.yml files provided by the OpenMRS SDK
      • Suggested Direction? Separate packaging from running - start by agreeing on how to represent the distribution. Right now since RefApp is generating docker files it's gotten a bit mixed. 
        • Feel free to change RefApp process
        • Focus is providing an example that makes MFE work with only the minimum set of modules
        • Romain to keep Talk up to date
  • Issue Management process improvements: Jira Graveyard, projects clean-up plan
  • DHIS2 Connector Module is updated and upgraded - spread the word https://addons.openmrs.org/show/org.openmrs.module.dhismodule
  • RefApp Release
    • Currently we want to get Reference Demo data updated (not a blocker but something we'll fix)
    • Release alpha for community testing by Monday
    • Draft Wiki page coming Monday to communicate what exactly has changed for the RefApp release

Bigger Topics:

  • How do we get the RefApp release out the door ASAP? Discuss testing & shipping plan. In the future, how do we capture the knowledge of what needs to be updated?

    • what precisely has changed for these important ones that we found had significant commits and didn't have recent PIH testing coverage:

      • Data Exchange - commits are all related to getting things running on platform 2.4 and one security fix.
      • Reference Metadata - does have some changes beyond just removing the COVID-19 concepts.
      • Reporting Compatibility - 2.0.7 released Oct 12 - Mike reviewing commit history - some recent fixes from Daniel - some issues fixed for Rwanda upgrade team. Used in Rwanda distro which is actively being used now.
      • Heads up: we'll want to upgrade the modules further based on additional fixes done through Rwanda upgrade

Team agreed that these are not a blocker - continue with RefApp alpha release; in the meantime we'll confirm the testing plan w/ community members on Talk.



  • Updating the Docker images generated as part of the RefApp and Platform builds so we can actually start recommending using those to replace the standalone 

2020-11-13

Cancelled

2020-11-06

Recording: https://iu.mediaspace.kaltura.com/media/1_8mpqolgm

Atttendees: Burke, Ian, Daniel, Jen, Juliet, Lucy Kimotho, Mark, Mike, Sharif, Steven

RefApp Updates: Board

Platform

  • Ian & Mark continue to test alpha

How to handle OpenMRS Attributes -> FHIR Extensions.

  1. Our Goal: Get as much data out of a distro, in FHIR, as possible
  2. Why Extensions: Way to tack on information you need to communicate, but it doesn't have a place in FHIR (OMRS handles this as "Attributes") 
    1. Extension Use Case #1: Helps capture data that people are storing in their distro, which we don't have modelled in the Data Model, but you still want to put it in the right place via FHIR (e.g. created their own attributes e.g. Ten Cell - which group of ten houses someone lives in in Tanzania)
    2. Extension Use Case #2: Where OpenMRS backend itself has data that doesn't fit in FHIR model - instead of custom adjustments to a fhir-specific datatype for each issue, use extensions - reduce modelling overhead; focus on more precise mechanisms for high-value content / content majority.
  3. Background: Active views throughout OpenMRS where data might need to be mapped into FHIR extensions. Difficult in some places. FHIR extensions are supposed to be identified by a URL → go to URL → get FHIR structured definition. Allow FHIR client to determine something about FHIR extension structure without needing that pre-programmed. Can we do this the way OMRS is set up right now?
    1. OMRS capturing data as various attributes
    2. Easiest thing for a number of these data is to represent them as FHIR extensions
    3. Ideally extension name convention is predictable
    4. Any of these can be mapped to extension: 
    5. "Each extension contains a URI that references the source of the definitions as a StructureDefinition. The source SHOULD be a literal reference, such as an http: URL that refers to an end-point that responds with the contents of the definitions - preferably a FHIR RESTful server supporting the StructureDefinition, or a logical reference (e.g. using a urn:) - for instance, to a national published standard. Extensions may be defined by any project or jurisdiction, up to and including international standards organizations such as HL7 itself."
      1. Challenge is that different distros likely have different URIs. 
  4. Proposed solution: (1) Reference to the attribute, (2) optional FHIR model reference, and (3) optional URI override (table UI to help implementer identify what's using extensions already, and add their own site's correct URI to the FHIR extension)

2020-10-30

Agenda

2020-10-23

Recording: https://iu.mediaspace.kaltura.com/media/1_4zsatgbw

Attendees: Romain, Grace Potma, Antony, Burke, Daniel, Grace Nakiguli, Ian, Jen, JJ, Juliet, Mark, Mozzy, Mike S, Sharif, Stephen Musoke, Bashir, Jan, Tendo

Agenda

  • Led by @mksrom & @mksd: (30 mins) Deep dive into what’s needed for Easier Deployment & Distribution Packaging
  • Dimitri & Romain will demo their current work to improve distribution packaging - and they’re close to doing this with all metadata configurable. Romain has got a WIP prototype that puts together the distribution ahead of its Dockerization, and Mekom has standards in place we’d like to apply to the new OpenMRS 3.0. The backend as well Romain has gotten down to 10 modules - Core + REST + FHIR + EMR API + …, total: 10.
  • They’ll also share some of their experience/thoughts on where we should go together for packaging and delivery, e.g. delivery pipelines and mechanisms that will avoid infrequent upgrades (Mekom has extensive experience setting up Bahmni instances fully microserviced with Docker that we can draw from in this conversation).
  • Background: We have identified that painful deployments/upgrades need to be a priority that we address for our implementers, and at the same time, we are working hard to make OpenMRS 3.0 a more compact distribution, made of a much smaller bunch of backend modules. So in short it will be a much more lightweight piece of software altogether easing both the release process and the challenge to upgrade. (OpenMRS Core and backend modules are harder to upgrade than microfrontends, so we would be shifting the balance with the new OpenMRS 3.0 architecture.) But let’s get on the same page together about what work is already happening now by members like Mekom.
    • Next is to design backend config.
    • Starts OMRS docker container using docker image made by OMRS SDK. Even brings in some concepts.
    • Is it possible to run in a non-docker environment? Possible to package as a WAR file in tomcat? (B/c w/ lots of implementations, would be great to package this and dump in as a WAR file). Maybe POM could be integrated into SDK.
    • This is a pattern for how to do a distribution - but not just a pattern, can also be the distribution!
    • What could people take from this? Create a maven project, create a pom file in which to say the parent is the openmrs artifactId>openmrs-distro-mf</>, then all the pom is narrated, add your modules and override the config/concepts/visit types you want. Mekom already doing this for their bahmni Haiti distro.
      • Could advertise this as the way forward.
        • Mike S: Tried doing a number of parent poms; found war files easy.
      • Step 1: Need standard patterns with what the expected artifact looks like: e.g. directory call omrs_war, omrs_frontends etc; that becomes the convention, and these are the artifacts included in those things. "This is what a standard OMRS distro looks like self-contained." Need agreement on what are the artifacts & intuitive naming convention.
      • Step 2: Docker deployment structure that knows how to put things in the right package, right images. 
        • Stephen M: Capacity issue, not technical, with docker/containerization vs existing tomcat setup across >1000 sites. Could we put these commands into the SDK so you could just configure them? So you don't have to write a lot of scripts, where you get into one script and have to do another one? Your docker image would know you check these configs and the iniz module. If build server is a tomcat server, easier. Tomcat is already at his 1200 sites, docker is not. Bigger issue is that the people upgrading the sites know tomcat and mySQL, machines w/ 4gb ram, windows 7. Don't know docker.
        • If we can take all this stuff and bundle into a war file to add to tomcat and explode = nirvana. For sites across Nigeria too.
        • Could have single bundled resource into a war file. Bundle everything into the war (sure most people don't do this but it worked for this team!). That would totally solve the problem. 
      • This is already happening, e.g. at PIH, Mekom, others. What is needed is for OMRS standards, documentation, and builds expect this kind of configuration.
      • Next Steps
        • Mark, Mike to compare RW work to Romain's prototype
        • Mike move wiki pages to RFC & issue PR around convention & structure. Get rid of ref metadata package and use iniz; that way testing both mfe and iniz w/ sufficient data
        • Agreement: The RefApp should be this thing. 3.x branch (apply this convention in next RefApp release ~Q1 next year).
          • Romain: Make 3.x branch for RefApp distro, that includes Mekom's approach to deployment? Login page & dashboard. 
          • Grace: JIRA - Open issue to track; share in Talk: _________.
            • Update SDK. Automate Docker deployment whenever we release a new version, automatically tags the new version in the Docker hub. RefApp 3.x Version. 
        • Wiki page to describe the standard we're aspiring to, and point to those repos. 
        • Our next refapp 3.0 must run on this infrastructure. With some spa, even if just a single page, we will have nailed it. (Plus a war that installs docker?) Dogfooding - make for refapp first. Standalone failing - could use that.
  • Screenshots:
  • Jira cleanup Proposal
    • Favor expressed
    • Add label: Graveyard 2020 + Graveyard dashboard to show which ones were cleaned up (by project or by age) (& no notifications)

2020-10-16

Attendees: Burke, Cliff, Daniel, Grace P, Ian, Mark, Mike, Sharif, Tendo, Jen, Juliet, Grace N

Recording: https://iu.mediaspace.kaltura.com/media/1_6d8pta0c

Agenda

  • Plan for testing 2.4 Platform release - Cliff
    • Release goal: October.
    • Current Testing:
      • Manual API queries: For REST-WS module we are using this google sheet(https://docs.google.com/spreadsheets/d/1vrVYIjVZqxzS2FHmD63KGV2wqvpJN-x-k77atS6TtIM/edit#gid=0 ) to log testing activities. Later, data from the sheet will be used to develop an automated rest endpoint testing system and we will deprecate the manual testing of rest endpoints for future releases. We are only proceeding with the manual testing due to time constraints and absence of an established end to end rest-endpoint testing system for platform releases.
    • Additional guidance
      • Make sure RefApp 2.11 starts & runs on platform 2.4  
      • QA environment running platform 2.4 that people can try the RefApp against
      • Testing that different setup workflows work, including standalone
        • But, standalone not working is not a blocker, would just need work to update standalone approach after getting the platform out
        • MariaDB and mySQL tests have errors - suggests possible issue with platform standing up against plain mySQL server; could block docker
      • Check that Implementers' Distributions run with platform 2.4:
        • PIH to try to update their snapshot to run on platform 2.4 - matter of finding time if it doesn't start
      • Follow up on Talk
  • Overview of what we accomplished in Q3 (July - September)
    • FHIR2 module release
    • OCL for OpenMRS webapp MVP release
    • Microfrontend architecture - being used in production by 2 implementers
    • New Platform 2.3.2 release - bug fixes
    • Nearing Platform 2.4 release
    • Nearing RefApp 2.11 release
  • What we're focusing on: Strategic Priorities draft - coming
      • Context: Are these the top 2 issues our technology users face right now?

        • Improving Deployments: “Even with the SDK, OpenMRS software is hard to set up. Requires developers who are expensive and sometimes very hard to find in our environments. Our organization doesn’t have enough funding as it is - implementing and updating the system needs to be easier and faster.”

        • Rapidly Getting the functionality you need from the Open Source community: “I can’t easily reuse the form templates, donor report templates, or frontend features developed by other organizations, because they use different metadata, a different frontend framework, might break other things in my system’s configuration, or have a totally different UI, or totally different workflow - even if it was for the exact same program (e.g. Cervical Cancer). We have to re-invent the same wheel too often, but with a short timeline and small budget, it’s often easier to build things ourselves”. (Need robust framework for collaborating together - recognition this is not solely a technical problem)

      • Strategic Themes:

    1) Easier Deployment. 

    (Ongoing) Modernized frontend architecture. No terrifying updates. Get it live/updated fast.

    Modernized containerization for faster plug & play. Deployment best practices.

      • What is happening on this topic right now? 

        • Having a standard way to define/config a deployment has been a TAC conversation but no activity going on. 

        • PIH worked on some config elements like in Reporting Module that could be documented/harvested - using Iniz + customize reports where Iniz lives; just lives in PIH modules right now. 

        • Could be something said for using Initializer. End up needing support from Mekom for one's own use case.
        • Packaging Plug-in: not PIH-specific 
        • Existing ways to deploy package you need; mount with one command. SDK could take one of these things and fire it up.
        • Compare to Mekom - e.g. dockerized versions of Bahmni.


      • 2) Reduce duplicated effort - walking together. Easier to reuse others' work. 

        • (Ongoing) Shared approach to frontend development (using MFE framework).

        • (Ongoing) Easy to share concepts via OCL for OpenMRS. 

        • (Ongoing) HL7 FHIR to be based on international standards and ready for integration.


      • 3) A modern, responsive RefApp 3.0. Modernizing the RefApp frontend starting with HIV outpatient use cases.


        • (Ongoing) Using Carbon Design System for UI consistency and faster dev value. Needs to become a Point of Care application, that’s modern, friendly, and works well on tablets.

  • Forms vs Notes and structure; Programs vs Pathways
  • Deep dive topic intro: how to handle OpenMRS Attributes -> FHIR Extensions
    • Active views throughout OpenMRS where data might need to be mapped into FHIR extensions. Difficult in some places. FHIR extensions are supposed to be identified by a URL → go to URL → get FHIR structured definition. Allow FHIR client to determine something about FHIR extension structure without needing that pre-programmed. Can we do this the way OMRS is set up right now?
      • Will discuss next week.



2020-10-09: Quality Assurance & Testing Landscape at OpenMRS

Attendees: Grace, Christine, Daniel, Ian, Jen, Ivan, Sharif, Tendo, Burke, Jan, Kaweesi, Cliff, Bashir, Steven

Recording: https://iu.mediaspace.kaltura.com/media/1_9vc30kji

Agenda/Notes:

  • Deep dive into Quality Assurance
  • Questions
    • Guidelines on Unit Tests?
    • Guidelines on Automated Tests we've followed in the past, principles on automated testing in general?
      • Coverage rules: Using coveralls on certain projects 
    • What not to test? In 2013, Thoughtworks Radar recommended holding on exhaustive browser based testing.
    • Can postman tests be imported into Cucumber?
    • TAC guidance: 
      • Focus on API automated tests, and only high-priority frontend tests
      • If there's any place that we need testing more than usual, it's for the upcoming Platform release - because so many changes to backend tools, so there's subtle changes we could miss. 

2020-10-02

Recording: https://iu.mediaspace.kaltura.com/media/1_q6b8hczh

Attendees: Grace, Ian, Burke, Daniel, Isaac, Jen, Mark, Mike, Moses, Steven

Agenda:

  • Updates:
    • Testing: Next week's technical dive on Friday will be an exploration of our automated testing and overall test framework - where we are vs where we need to go. 

    • Frontends: Share the summary and the implications of the prototype work Florian shared on the MFE squad call (JJ & Burke) 

      • How frotends will be deployed and related to each other. Ties core parts of the framework together; can download whole MFE in more logical way
      • i.e. defining best practice for working w/ frontends and being able to start using them, defining those things, instead of via modules that plug in
      • loading in OMRS frontends w/ npx; having frontend running and being able to pop in your own modules easily.
      • Idea is lower-barrier way for people to load and start experimenting with Frontends
      • Agreement: Doesn't make sense right now to bundle SPA module in RefApp release. No expectation it will be included.
      • Productive call w/ Bahmni tech leadership
        • Plan to collaborate on Forms 2 and Appointments as first ux5se case / example of working together with microfrontend approach, so that work can be shared and work outputs can be used by both communities
  • AWS Proposal
    • Amazon Imagine program grant submitted this week. Improve docker image for OpenMRS - e.g. create Docker compose; easily get OMRS up and running. Way of distributing the RefApp using that docker image.  
    • Net result: Amazon machine images to allow you to duplicate the test environmexnt so that if you want to use AWS, click on OMRS image and get an OMRS instance complete with DB up and running.
    • Adapt SDK to generate appropriate docker-compose construct
    • Proposed small scale pilots, demonstration of NCD project for Kenya/Uganda
  • Future of the standalone distribution (using deprecated embedded MySQL engine)
    • Something like (1) Install Docker, (2) docker run -p 80 openmrs/reference-application:demo ... though, might want to use docker-compose (from AWS project (smile))
    • To get the DB, using mxj to execute - which hasn't been supported by MySQL since 2013. Doesn't work at all on latest version of macOS.
    • Proposal from Ian: Would be asking people to write Docker-compose up command (rather than installing new thing)
      • Agreement voiced by Mike
      • Over 200 sites just in Nigeria using standalone for several years - Asked why, esp. b/c not designed for production use? They like that it simplifies the work of managing different sites
        • ie.: There's clearly great value in providing something that can be up and running fast! One click to get up and running.
      • Next steps: 
        • Vision draft to present to TAC - Ian & Burke - Next TAC
          • Current state of docker-based demo here
          • Produced from SDK here
        • Working meeting 
        • Use existing process for RefApp 2.11.0
  • PEPFAR Patient Level Indicators work
    •  Idea is: If we feed FHIR resources into their calculation mechanism, may offload a lot of work for implementers. End up with FHIR shared health record that has all the patient data that the indicators are calculated against, and some validated CQL to calculate those indicators. 
      • Key takeaways: Don't want to turn into data warehouse for an HIE? Keep in mind this won't solve the Analytics Engine problem. Serious concenrs with how the work will help address our needs for a highly performant solution. 
    • OCL involvement & future for OCL
    • OpenHIM & what are the implications of this for OpenMRS?
  • Announcements & Calendar preferences
    • Add OMRS.cal into talk header - Burke

2020-09-25 - Deep Dive re. RefApp & MFE Bundling Plan

Recording: https://iu.mediaspace.kaltura.com/media/1_vhjx70z2

Attendees: Ian, Daniel, Burke, Mark, Grace 

  1. RefApp & MFE Bundling plan 

    1. https://talk.openmrs.org/t/removing-single-page-application-spa-in-ref-app-2-11-0/30315

    2. Remove Spa Module from RefApp release, because won't be used anyway. 
    3. Concern from Burke: We want the lowest possible barrier to entry. If someone wants to see what MFE is, and see against their own data, isn't using a module the easiest way to test that out? 
    4. Florian & Brandon unable to make it - Burke and Mark to f/u on talk to understand background of decision to move away from SPA Module approach 
  2. No Other Deep-Dive topics today.

2020-09-18

Recording: https://iu.mediaspace.kaltura.com/media/1_5hjewjtz

2020-09-04

Recording: https://iu.mediaspace.kaltura.com/media/1_qx4qfep4

  1. Security Best Practices Guidance
    1. Any feedback on Ian/Isaac's security best practices work for module updates? https://docs.google.com/document/d/1CS61Q51zhCazSPN_046il7QaPUnG3zhB9Kegxxu06iE/edit
    2. TODO: Isaac Sears  - Add to Wiki, in Documentation space, under Developer Guide → Conventions OpenMRS Module Release Best Practices
    3. TODO: Isaac Sears  - Talk Post to alert community
  2. Release updates
    1. Platform - Oct
      1. Alpha release planned for this week; one remaining blocker then we'll release
      2. When we have alpha, should have something like recognition in the SDK that will create an alpha version of the platform and then in the announcement of the alpha release we need to get messaging out to community about the big updates coming with 2.4 - "If I'm a module dev, what do I need to do to start testing against this?"
        1. Here's how to set up the alpha and do testing
    2. RefApp 2.11 - will be on Core 2.3 - Oct
      1. Why 2.3 not 2.4? 2.3 because 2.4 has major under-the-hood changes (upgrades Java support, several key libraries - upgrade to spring & hibernate) . Would mean much bigger delay to getting 2.11 out. 
      2. Why not a 2.10 Maintenance release? 
      3. Instability of SPA module
        1. Maintaining SPA application to be more stable - to avoid so many errors if trying to include in next RefApp
        2. Will continue to be unstable for a while. Shouldn't cause OMRS to crash. There will be >=1 more major release of this module soon. 
        3. Plan: Issue heads up that SPA is experimental fx, in future releases there will be major updates (so if you're using it you know what you're getting into). "As part of this RefApp we are including a beta version of the SPA module so that it's easier to experiment with it as the application of Micro Frontend technologies is being experimented with"
          1. TODO: Brandon/MFE Squad - Update Sharif and Moses when next SPA release out
          2. Brandon can be poi
      4. Ian: Roll back COVID concepts that were tied-in with 2.10?
  3. Updates from MFE Squad by Brandon on Extensions design and technical approach being implemented

    1. Here's the fun presentation the MFE Squad put together that walks you through the benefits of the extension system: https://docs.google.com/presentation/d/1ParNFdehbBexycC_XzdvpPNXBCea-4GYwAuoPFtvYIY/edit#slide=id.g921ee92cfb_0_2

    2. Invitation to provide commentary in RFC: 

      https://github.com/openmrs/openmrs-rfc-frontend/pull/27

    3. Mekom (for ICRC - Immunization) and PIH (for Medication Order Entry) using MFE and Extension approach for this work
  4. Analytics Engine Squad - Updates
    1. Generating prototypes of approaches - expect to see prototypes in the coming weeks 
    2. Analytics Engine space in infrastructure (might commandeer servers being used for Sync)
  5. Upcoming feedback from security review (after this call) - people interested in helping address - may be call for help resolving some tickets soon w/ patching/remediating issues they bring up → or reach out to Isaac Sears (smile) 
    1. PhD research group at NC State uni have been analyzing OMRS security over the summer
  6. Discussion topic: What if we were promoting Forms 2 and Apt Scheduling as examples of shared efforts across communities to have the first MF-ready modules compatible with both OpenMRS or Bahmni?
    1. Forms: Going to need to have compatibility layer w/ HTML Form Entry. Already have integration w/ AMPATH forms. 
    2. Brandon: Yes, these things may make sense to use with earlier integration w/ RefApp. Design issues to address: Form display; how forms are embedded in visit view (with visit lists of diagnoses) would need another kind of container page the RefApp chart could link to, that functionas like the RefApp visit page. 
    3. Mozzy: Consider design of Bahmni Reports in RefApp? From implementers' point of view, makes things much easier so would be another nice one to consider
    4. More discussion needed - TODO: 

2020-08-28

Recording: https://iu.mediaspace.kaltura.com/media/1_4odg2nim

**Brief Updates**

  • (2 mins) Update: Release/Launch Calendar (@grace) https://openmrs.atlassian.net/wiki/display/docs/Technical+Roadmap
  • Reminder: Squads Showcase last thursday of every month (next Oct 1)
  • (2 mins) **Migration Path to 3.0**: Next steps with vision and community discussion?
    • TODO: Grace Follow up with Pradipta to schedule time to meet with Bahmni, Angshu (PAT or coalition) (JJ, Brandon, Burke, ...)
    • TODO: Brandon to post Extensions technical vision
  • (2 mins) Decision re. whether RefApp 2.11 will be on Core 2.3 vs 2.4? Likely 2.3. Need to confirm with Release Manager. 
  • (5 mins) Module Maintenance plan updates? Requests for help?
    • TODO: Identify 1-2 teams that make sense, that ought to exist (and might not yet); clear people already maintaining repos
      • Burke - Review repos getting most activity, try assigning those and share 
      • Grace - Work w/ PM Team - clarity of idea of Maintainer lead accountability; help communicating or i.d.ing teams and people
    • Consider making Teams where an OMRS Fellow is starting; ideally mentorship can happen in this structure in a sustained way (e.g. DHIS2)
  • Ian & Isaac - skeleton Best Practices for Module Creation  for next TAC 

**Bigger Topics**

  1. Design System Recommendation from MFE Squad
    1. Documentation available: Why did we choose Carbon Design System over our previous Style Guides?
    2. MFE Squad would like to move forward with trying out Carbon design system
      1. High level goal: Make it easier to develop frontend, quickly. 
      2. Why Carbon?
        1. Well documented.
        2. Less opinionated than Lightning. Ability to personalize to an extent.
      3. Next steps
        1. UX Designer putting together additional high-fidelity mockups of patient chart. Finding Carbon easier to theme than expected.
        2. Order entry will be one of the pieces worked on.
        3. Not yet telling community "Just use Carbon" because we still need to experiment with it more in the MFE work. But people are welcome to experiment with it.
    3. Questions for team discussion:
      1. How will community learn about progress, how it goes?
        1. Squad showcases
        2. Community meeting to report findings from initial trial period trying out Carbon
        3. Posts and wide dissemination online - findings on Talk Threads, tweet
        4. Following up with Jen
      2. Implementer experience with new Design System: How will we validate that it's fast or even faster than Bootstrap for new devs to use (validate fit with field-reality of quick work that is often needed in implementations)? How will we help make this easy to learn/use for community members moving forward?
        1. Design Systems intended to solve problem of making dev efforts easier. Doesn't mean it's all ready out of the box and we'll still need to commit to learning it and adopting it for OMRS.
      3. The Frankenstein Problem: What issues related to the Design System we can expect to run into (if any?) as implementations start using bits of microfrontend apps in their distribution, before using the whole new frontend?
        1. Same situation as prior to moving to Carbon. Will be a common problem. For visual coherence, should use a Style Guide over-ride that tweaks the CSS of MFEs to imitate RefApp a bit more. Should be small piece of code to build/maintain. Would be less jarring visual experience, though doesn't address interim awkward workflows - not seamless (that would be much, much heavier lift). 
          1. MFE Squad to provide themeing and skinning guidance (e.g. color schemes and logos - goal is avoid jarring color differentials). Make those knobs easier to turn.
          2. Majority of effort should go into getting baseline provided UI "right". Then main flexibility is color and logo. 
          3. Recognition that distributions have invested in custom adjustments to frontend. The reason they'll switch is believing in vision of where system needs to go.
      4. Future Upgrades: Who is responsible for reviewing the 3rd party updates and deciding when it's time to do a corresponding upgrade?
      5. Implementer experience with updates: What will handling updates look like for implementers? 

2020-08-21

Recording: https://iu.mediaspace.kaltura.com/media/1_dun7fz37

Attendees: Burke, Jen, Bashir, Brandon, Daniel, Ian, Isaac Sears, JJ, Juliet, Mike, Steven, Tendo

  1.  Announcements
    1. Fellowship application review started. Contact Jennifer Antillato become a part of the review/selection process.
    2. If you encounter a Zoom Passcode for an OpenMRS meeting in the future, get into meetings with passcode "1"
  2. (1 min) Update: QA Support Team & QA Advisors
  3. (5 mins) Update: Style Guide review & decision process: Looking at Carbon and Lightning examples on Tuesday next week
    1. Wednesday deep dive: Bootstrap was more of a library than the approach to UI we were looking for. Lightning and Carbon came out on top.
      1. Style Guide & Design Systems Analysis - July/Aug 2020 
    2. Visual comparison of data-heavy EMR screen (Patient Chart View) example from both Carbon and Lightning - Ciaran
    3. Compare key points of using Carbon vs Lightning with style guide vs design system approach - Brandon, Romain, Ciaran
      • What people can do right away:
        • See and share the video tutorial Using CSS from Third Party Style Guides. This is an example of how we might easily pull from style guide into our own system via dev tools & copying CSS.
           
        • Look at Lightning component blueprints - Lightning component blueprints are a way of making it easy to build styled components without introducing hard-to-manage dependencies into the application. https://www.lightningdesignsystem.com/components/overview/
    4. Communication plan
      1. TODO: Grace: Clearer documentation
        1. Talk: Too much to weed through right now. Clarity that "we're making this decision, and we're making it now." Clear "these are the decisions that need to be made". 
        2. Teaser of rationale, work thus far, direction.
        3. Tuesday visual session "this is what UI could look like, this is what implementation could look like"
        4. Not about switching out in RefApp
        5. Clear guidance on how to make a decision for things like this - clear structure that decisions like this go through
      2. Implementers: ___
      3. End users: Bring designs to some frontline staff
      4. Conference - would review work, background, rationale, findings, way forward
      5. How to involve Bahmni?
        1. Involve in Tuesday call, reach out as much as possible
  4. (10 mins) RefApp 2.11 Release Timeline & Updates to Release Checklist: /wiki/spaces/RES/pages/26266013
    1. Roll back COVID concepts that were tied-in with 2.10?
    2. What is the TAC's responsibility for Roadmap clarity? What else is needed?
    3. Trunk release Oct, Ref App Release Timeline Feb - sounds reasonable
      1. No concerns from PIH. If using new platform, probably about the right timeframe. 
      2. Ideally default is Beta before conference in early Dec. RefApp out twice a year.
      3. Feature list: In this case, just refresh modules to latest version. So planning priority is that module list matches
      4. TODO: Burke to i.d. 2.3 vs 2.4  
  5. (10 mins) DHIS2 integration plan: merging adx branch and GSOC branch
    1. Rationale
    2. Comparison between OpenMRS DHIS2 integrations
      1. Summary https://docs.google.com/presentation/d/16-20-UgZLnU2KuMps2HXMzu9ZEmdIRVWmY1qXz-pOG4/edit#slide=id.g35f391192_0
      2. Full detail: https://docs.google.com/document/d/1vtDfnlA84Go7_lZXggDmuj3k4oSib5Nl3GHc4S3XhEo/edit#
  6. (25 mins) Extensions
    1. https://docs.google.com/presentation/d/1ParNFdehbBexycC_XzdvpPNXBCea-4GYwAuoPFtvYIY/edit#slide=id.p
  7. Topics for Technical Deep Dive next Friday
    1. Final Style Guide / Design System recommendation to TAC next Friday


Aug 2020 to present day

Archive: TAC Notes 2019-2022

July 2020

July 17 - Aug 6: https://notes.openmrs.org/tac2020

17: Notes  |  Recording

10: Updates & Patient List Pain-Points    Recording

June 2020

May 2020

29: Platform Release Manager | Module Maintenance Convention

22: Roadmap Status | Module Maintenance Convention

15: Technical Vision Statements | How is TAC influencing development?

08: ETL/ELT Stand Up Timing | Technical Vision Statements | Module Maintenance Convention

01: Technical Roadmap | Technical Vision Statements | Conventions

April 2020

24: Technical Roadmap | Improving dependency changes detection and tracking

17: ETL Technical Vision Statement | Deep Dive: Custom Modules | Technical Roadmap

10: Tech Radar | ETL Vision Statement | FHIR Vision Statement | GSOD Projects

03: Tech Radar | PLIR Scope Review 

March 2020

27: Tech Radar | PLIR Scope

20: Tech Radar

13: Tech Radar | Technical Vision Briefs | Technical Roadmap  Recording

06: Technical Roadmap | Tech Radar   Recording

February 2020

28: Bahmni Technical Q&A  Recording

21: High Priority Items | Technical Vision | Tech Radar Recording

14: Patient Level Indicator Reporting SOW | DIAL Catalytic Grant Round 4  Recording

07: High Priority Items Survey | DIAL Catalytic Grant Round 4 | FHIR Design Forum | GSoC projects   Recording

January 2020

31: Areas of Focus | Roadmap + Release  Recording

24: 2020 Priorities  Recording

17: Technical Vision | 2020 Priorities  Recording

2019 Meeting Notes