Wiki Spaces

Documentation
Projects
Resources

Get Help from Others

Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack

Resources

Page tree
Skip to end of metadata
Go to start of metadata

Directory


Helpful Links

Find this page at om.rs/tacnotes

TAC calls at om.rs/zoomtac

Parking Lot: Topics for Subsequent Meetings

  1. (WEEKLY UPDATE FROM AT LEAST ONE SQUAD/TEAM)
  2. Team To-Dos:
    1. Finish updating Tech Radar Survey results: https://forms.gle/F5NHH8Q7F9TYEy2i9
  3. Tech Improvement Ideas:
    1. Initializer - why not adopt as part of recommended implementer technologies? What do we need to do next? (Esp. to unlock Iniz Validator)
    2. Audit trails and a UI for it. Maturity of the auditlog module?
    3. (Dimitri) Backend(?) forms validation, some embryo of an idea here for HFE, but could we get to a general approach across form techs?
  4. Process Improvement:
    1. PR Process (Ian): Making code reviews less intimidating: more lower-level devs involved in the code review process and make the whole process seem less intimidating. 
    2. Module Maintainers - update

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

2021-05

2021-05-21:

  • Progress with program workflow module: Meeting OHRI's needs? Other POC users' needs?
  • Suruchi Product Management talk

2021-05-14:

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


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: OpenMRS 2021 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 ValidatorThe 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)   RA-1865 - Getting issue details... STATUS  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://wiki.openmrs.org/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: Reference Application 2.11.0 Release Issue Tracking
    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

Technical Action Committee (TAC) Meeting Notes

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

  • No labels