Wiki Spaces


Get Help from Others

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


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

Ongoing Design discussions

Patient list supportAMPATH-specific needs pulled out of cohort module.
Deployment and Configuration
Support for User groups

Darius Jazayeri working on a design

MultitenancyDiscussed on 2021-11-17

Outstanding TO-DOs

  • Be open to revisiting our meeting time – our 17:00 UTC timing may prevent some from joining, we could consider having a Doodle poll (or multi-select Talk poll if with just a few choices) to pick a more convenient time for the community if/when we hear of folks unable to join at the current time.

Review Platform Kanban Board


  • Platform 2.5.0 updates
    • Last week's Blocker cleared(Caused by previously released  2.5.0 artifacts  at Jfrog on Nov 18)
    • Core 2.5.0 Successfully Released to maven , Platform 2.5.0 Release completed . Can be downloaded here


  • Platform 2.5.0 updates
  • Backend Support for Service Delivery Queues / Workflows
    • Do we support multiple states per Visit? Per Encounter?
    • Can we support queueing outside of Visits/Encounters?
  • Building a frontend Maven package
  • Platform in 2022
    • GSoC projects (e.g., 2FA support)
    • OpenMRS 3.0 vision
      • Packaging
      • Better dev experience by removing hot loading of modules
      • Improving the event module (at least upgrading version of activemq)
          • For example, would like to be able to support a rules engine (notification of changes)
          • Support for FHIR subscriptions
      • Rules engine
        • Workflows (clinical workflows as patients move physically through a clinic)
        • CDS
      • Support for draft encounters and encounters to be created before all data are collected (better support for prospective workflows) (right now a form and an encounter are almost identical in the backend - can't submit a form unless you create the encounter along with it - requires major refactoring)
    • Servelets & filters in modules ordering needs to be improved
    • Should rethink password hashing (mechanism for updating to secure password schemes)
    • Password resetting workflow
    • CSRF protection by default
    • Enhancing concept dictionary to better support FHIR value sets (allowing multiple authoritative sources)
    • First class support for clinical notes with rich text
    • Reporting as a micro service


  • Platform 2.5.0 updates
    • Final release delayed due to changes committed after beta release
    • Trying to release and test 2.5.0-beta2 before final release
    • Blocker at CI See talk thread
  • OMRS21 Squad Showcase updates by Christine Gichuki 
    • Squad showcase on Wednesday or Thursday during OMRS21 (Talk thread)
    • Need to fill in slides for Platform Team here.
  • GSoC 2022 – start thinking of Platform-related projects that could be done in ~2 months by a skilled dev


  • Platform 2.5.0 updates
    • Had some discussions on this week's PM call about using Tomcat 8. Daniel Kayiwa had been using it without issues.
    • Began work on final release process
    • Discussions about the fate of OpenMRS-Standalone  (to include /  exclude in 2.5.0 Daniel Kayiwa  Burke Mamlin )
      • Embedded MySQL engine is no longer supported
      • Could we migrate toward leveraging Docker for standalone?
        • Has the advantage that we are headed toward Docker-based deployment
        • The approach used by the SDK
        • Would swap requirement of having Java installed to having Docker installed
      • Another option could be to use another embedded database (like postgres), but that could take more effort without enough benefit to justify it.
      • For now, we can continue to include the standalone noting the limitation that it is deprecated, is known not to work on recent Macs, and we are working on a new (likely Docker-based) replacement for the standalone in future releases.
    • Status / fate of TRUNK-6026 (storing patient-specific user properties)
      • Marked as "won't fix". We can revisit when we have real world examples.
  • Supporting multi-tenancy
    • Good thoughts from Angshu in this Talk thread
    • One approach was Location Based Access Control Module, which led to a more recent approach of lower-level approach Hibernate-level filtering as Data Filtering
    • What if each resource (each piece of data) included provenance (which organization to which it belonged)? This could allow not only for more explicit (and better performing) filtering as well as introducing external data into a system (e.g., when a patient normally seen at Hospital A has a visit at Hospital B) without losing its provenance of the data.
      • We could look to FHIR for modeling these details and introduce them to the data model over time.
  • Platform 3 ideas (deferred due to time)


  • Facility Registry (FR) work - Talk Post
    • Want to review work done on integrating locations with a facility registry, linking OpenMRS with GoFR
    • Where should FR be demonstrated to OpenMRS community?
    • Added location.type to data model as Concept to link locations (and align w/ FHIR model)
    • Would bring locations into OpenMRS with an attribute that tags them as externally managed locations
  • Platform 2.5.0 updates
  • Nathan introduced this new ticket:
    • RESTWS-866 - Getting issue details... STATUS
    • In cases (generally discouraged, but sometimes unavoidable), where the database is changed under the hood (directly in SQL), Hibernate needs to be notified to clear any cached resources that may be affected.


  • Platform 2.5.0 updates
    • 2.5.0-alpha.3 powering  Refapp 2.12.0 at   Refapp uat-server
    • Testing began yesterday (2nd Nov 2021 ) with many volunteers from QA support squad promising to give a hand
    • Testing to last a week
    • Would like to have OpenMRS 3.1 to run against Platform 2.5
    • Planning to move to beta within the next week
  • Frontend Requirements for the Platform - wishlist
    • Care Delivery Queue design
      • Patients going through care workflow during a visit (e.g., registration > triage > waiting to be seen > etc.) need to be viewed in queues, we want to be assign a priority (urgent, emergency, ...) to patients, 
    • Event handling (what is our generic approach to handling events within the platform)
      • Needed by FHIR module and for frontend to update
      • Would be useful for CDS
      • Discussed spectrum of approaches
        • Quick and dirty – one-off hacks for specific events
        • Event-specific solutions (e.g., Brian McKown's module that hooked form save in API and could update patient state in program workflow(s) based on specified observation values, like "Change HIV Program state to Lost to follow up if Disposition question answered with Lost to follow up.")
        • Creating specific observer API methods as needed.
        • Creating an observer interface to be implemented as needed within the API
        • Creating an event bus (can get complex & introduce performance issues if, for example, listeners can influence/cancel events)
    • For user-specific settings, can use user properties (modules should namespace their keys).
    • Need ACL (e.g., leveraging user groups).
      • Would like to be able to control access to data (not just API methods)


  • Platform 2.5.0 updates 
    • Alpha out on platform UAT-SERVER f (platform-2.5.0-alpha.3) , still missing some bundled modules (awaiting more  discussions from Daniel Kayiwa  and Platform Team) See Thread
      • Problem is with addon manager (index is messed up)
    • Next step: configuring uat-refapp to deploy RefApp 2.12 atop platform-2.5.0-alpha
  • Look at dashboard -
  • Updates on Cohort Module
    • Bett focused on cleaning up issues caused by separating cohort module into two separate modules
    • Ian working on default definition handlers
    • OpenMRS 3 is categorizing patient lists using cohort attributes. Would like to know difference between "user" vs "system" patient lists. Are these simply distinguishing manual vs automatic definitions? Or something else?
  • Updates on OpenMRS Packaging


  • Platform 2.5.0 updates
    • Expecting alpha to be out within 24 hours and provide at least a week or two for testing on
  • Look at dashboard -
  • Updates on Cohort Module
    • Working on getting active members of cohort in few steps
  • Using Facility Registries in OpenMRS
    • We agreed that adding location.type  as a Concept  could provide the linkage between abstract location concepts and specific locations.





  • Platform 2.5.0 update
    • Alpha delayed to include order attributes and referral orders in 2.5.0
    • TODO: Need implementer input on how to handle location modeling for Referral Orders (Talk)
  • Cohort Module update
    • Is giving users admin/edit/view access to cohorts sufficient? Do we need to make a distinction between owner and admin? Can we get away with admin & view to start?
      • TODO: Burke will really this time create a Talk post to get input from JJ, Grace, and others
  • Kanban board



  • Platform 2.5.0 update
    • Platform 2.5.0-alpha Release Notes in progress
    • TRUNK-6027 - Getting issue details... STATUS will check with Christopher to see if he can finish up within the next week; if not, Daniel offered to take it on so we can get Order Attributes into 2.5
    • TRUNK-6029 - Getting issue details... STATUS will strive to get Referral orders into 2.5
  • Cohort Module
    • Bett has separated cohort & cohort add-on modules into two modules
    • Ian is working on ticket creation
    • Handler interface is reasonably clear. Will create some default handlers.
    • Would like to have additional use cases for permission handling
      • Is giving users admin/edit/view access to cohorts sufficient? Do we need to make a distinction between owner and admin? Can we get away with admin & view to start?
      • TODO: Burke will create a Talk post to get input from JJ, Grace, and others
  • QA Questions
    • Comparing REST-Assured and Karate as options for testing
    • What's the reason existing tests weren't used in previous releases?
      • There were only 14 tests to be added to REST module tests. Why weren't the existing ones being used instead of doing manual testing?
      • ANSWER: people just weren't aware of them
    • What additional tests are needed in the Platform?
      • ANSWER: Nothing comes to mind (smile) 
    • What's the timing of 2.5 beta release?
      • ANSWER: Mid-October... maybe late October. But this shouldn't affect timing of introducing REST-Assured or Karate
  • Address Hierarchy has a hacky AJAX-like API. Would be great to get these into REST API
  • REST Web Services authentication issue with Bahmni
    • A 403 Forbidden is returned if credentials have expired (see here). Should this be a 401 Unauthorized?


Platform 2.5.0-alpha Release : Notes

Mother Roadmap

Patient Lists (Cohort Module changes) status





  • Other: Datamodel gaps identified by Bahmni on FHIR call
    • OMRS Data Model missing the following - means Obs field getting heavily used/abused!
      • *Organizations* (we have locations but no support for "Organization") FHIR doesn't mix location and organization. Coming up in facility registry workflows. (Problem for both Bahmni and UW/ITECH)
        • how can we 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”.
      • Imaging (hacked up through Obs structure)
      • Microbiology (no clear model; things hacked around Obs model. e.g. the culture. Bahmni Microbiology/bacteriology so flexible that from one implementation to another, approaches not useable between implementations)
      • Referral modeling: Procedure request, Counseling request - can fit into order model - info like location being referred to. So most OMRS implementations define a form, stored as obs, converted into service request. 
        • Event simple location & referral (reference to provider or location) - can potentially model an org by location.  



  • Platform 2.5 Release planning (OpenMRS Talk topic)
    • Could use more eyes/reviews on PR #3852
    • Asked Grace to query OpenMRS 3.0 squad on whether patient-specific user properties are needed now/soon (if not, we can de-prioritize TRUNK-6026)
  • TODO: Burke Mamlin to try to move the design for OpenMRS Referrals forward
  • Getting actionable Platform tickets!


Apologies: Antony (he would like to get himself & his team more involved in Platform)


  • Kanban Review
  • Tomcat 8/9 support
    • Agreed to support both Tomcat 8 and 9, the default (e.g., using SDK) would be Tomcat 9
    • Added cargo to openmrs-core to allow devs to easily choose a tomcat version
    • There may be a few issues with legacy UI, but have not been able to reliably reproduce to investigate. Will plan to continue with Tomcat 8/9 support and address any issues as they arise.
  • TRUNK-6020: User Settings (discussion in Talk)
    • Require MySQL 5.7+ or Postgres 9.2+ for Platform 2.5 to allow JSON values?
    • VARCHAR to LONGTEXT for user_property.value  would avoid major changes. Would defer switching JSON data type (maybe for Platform 2.6)
    • Could use the opportunity to bump to from VARCHAR 100 to 255
    • TODO: Burke Mamlin Document this in Talk topic
  • Platform 2.5 Release Manager – tendo kiiza Martyn  
  • Cohort Module Next Steps
  • REST of Administration
  • Platform Work available for week to come. Where are the Platform tickets?
    • TODO: tendo kiiza Martyn move user_patient_property work into a new ticket and link as related to TRUNK-6020



  • Tomcat 8 and 9
    • Per Daniel, everything works on Tomcat 8 and 9. Also Anthony reports that Tomcat 9 works in KenyaEMR. Some used Tomcat 8.
    • Waiting to hear from Todd at PIH about Rwanda implementations
    • Ian's suggestion:
      • Consider upgrading Tomcat version on the infrastructure and docker images
        • OpenMRS core webapp
        • SDK uses a Version of Tomcat 7 embeded that will need to be updated
        • All docker images currently use Tomcat7 and should be updated
          • 3.x webapp also uses Tomcat 7
    • Daniel added a plugin to OpenMRS core (commit) that  allows one to choose the version of tomcat to run
      • Navigate to the openmrs-core root dir and run mvn cargo:run -Dcargo.maven.containerId=tomcat9x. Possible options for the -Dcargo.maven.containerId parameter include:  
        • tomcat9x
        • tomcat10x
        • jetty10x
    • Has the TagLibs issue been addressed? OpenMRS Talk: Tomcat version with deprecation tomcat7
      • Daniel encountered the issue on Tomcat7, rarely on Tomcat 8 and 9. It is random and not easily reproducible
      • Bett reported encountering the issue consistently on Tomcat7. It's nomally resolved by restarting the service
      • Bett to document the steps to reproduce the error, by next week
  • Daniel pointed out a need to have a set of platform tickets that can easily be handed to volunteers who want to contribute
    • Tendo will help by extracting the tickets from the previous minutes
  • Review of the Platform roadmap
    • Issues are still underspecified
    • We should start looking for a release manager for Platform 2.5?
      • Tendo to do a talk post for the call of a platform release manager 
      • Suggestion to have the selected Platform release manager to join the platform team
    • What should we add to the platform roadmap
      • Calls to get feedback from implementers has not yielded much. The platform team will therefore need to look within for suggestions. 
      • Ian from the squads 
        • OCL module?
      • Bett from Ampath: 
        • Patient Lists
        • To provide more suggestions next week
      • Anthony from Palladium: 
        • Legacy UI: Reported some bugs and will share more details including reproduction steps
        • To provide more suggestions next week
    • Ticket review: TRUNK-6018
      • Can we have a patient program with different states where each state belongs to different encounters?
        • What's the relationship between PatientState and Program Workflow state? Ideally the Patient State should be derivable from the program workflow states?
        • Examples of program workflow states:
          • Active
          • Lost to follow up
          • Dead
          • On Transit
      • Program workflow states discussion: Patient program workflow state design







  • Reviewing PRs
    • Discuss key PRs (from Outstanding PRs
    • Examples of PRs with issues: Ken's spreadsheet
    • Next steps for surfacing a metric (e.g., list of open PRs across key projects)?
    • What can we do better with PRs over next week
  • Prioritizing Backlog
    • Currently we have Platform Kanban Board with this filter
      • affectedVersion in ("Core 2.4.0", "Core 2.5.0", "Platform 2.4.0", "Platform 2.5.0", "RESTWS 2.30.0", "RESTWS 2.31.0", "FM2 1.1.0", "FM2 1.2.0") OR fixVersion in ("Core 2.5.0", "Platform 2.5.0", "RESTWS 2.31.0", "FM2 1.2.0") AND fixVersion not in ("Core 2.4.0", "Platform 2.4.0", "RESTWS 2.30.0", "FM2 1.1.0") OR project = Platform AND resolution = Unresolved ORDER BY Rank ASC
    • Would like to include
      • Projects: Core, RESTWS, FM2, PLAT (smaller set of tickets focused on Platform release process and coordination of Platform modules with core API)
      • Label: Community Priority
      • Last updated within 6 months
    • Updated Kanban board to use this filter
      • project in ("OpenMRS Core", "Webservices REST Module", "FHIR Module v2", Platform) AND labels = community-priority AND resolution = Unresolved AND updatedDate > startofday(-183d) ORDER BY Rank ASC
    • Mechanism to prioritize issues
      • Community priority label
  • Platform 2.5 Release
  • Near-term Wins
  • Facilitate design discussion on high priority platform changes


Attendees: Bett, Daniel, Ken, Tendo, Burke


  • Reviewing PRs
    • PRs to discuss from Outstanding PRs link 
    • Next step(s) to surface a metric (e.g., list of open PRs across key projects)?
    • What can we do better over the next week regarding PRs
  • Prioritizing Backlog
    • Currently we have Platform Kanban Board with this filter
      • affectedVersion in ("Core 2.4.0", "Core 2.5.0", "Platform 2.4.0", "Platform 2.5.0", "RESTWS 2.30.0", "RESTWS 2.31.0", "FM2 1.1.0", "FM2 1.2.0") OR fixVersion in ("Core 2.5.0", "Platform 2.5.0", "RESTWS 2.31.0", "FM2 1.2.0") AND fixVersion not in ("Core 2.4.0", "Platform 2.4.0", "RESTWS 2.30.0", "FM2 1.1.0") OR project = Platform AND resolution = Unresolved ORDER BY Rank ASC
      • Core
      • RESTWS
      • FM2
      • PLAT - smaller set of tickets focused on Platform release process and coordination of Platform modules with core API
    • Mechanism to prioritize issues?
      • Community priority label?
  • Platform 2.5 Release
  • Near-term Wins
  • Facilitate design discussion on high priority platform changes




  • Reviewing PRs
    • TODO: Daniel & Ken to start looking at PRs
    • Having some amount of dedicated time to look at PRs (or get others looking at PRs) each week
    • PR metrics
      • How many people are doing PRs? Can we grow the number of people doing PRs?
        • Would be helpful to know how many people are doing PRs in the community. Is it shrinking or growing?
      • Time to response
      • How many without response to dev?
      • How long since PRs opened?
    • Conventions for PRs?
    • Using PR review to grow developer community (encourage contributions, empower new devs)
    • Expectations for PRs?
      • How long until someone has responded?
      • How long until a decision is made?
      • How many lines changed?
      • Defining types of reviews ("basic PR review" vs. merging)
    • Would like to see PR reviewing as an expectation of fellows, part of Dev Stages, etc.
    • Action items
      • Open PRs amongst key OpenMRS repos
      • How long since last activity (comment) on PR
      • Daniel & Ken to dedicate at least 1/2 day per week (between them) to reviewing (or getting others reviewing)
  • Prioritizing Backlog
    • TODO:  Burke to help set up a Kanban board
  • Platform 2.5 Release
    • Soliciting requests from community
      • Feedback from squads and implementations on platform-specific features.
        • Pain points
        • Priority areas
      • TODO: Tendo to do 2nd pass of reaching out to individuals
  • Near-term Wins
  • Facilitate design discussion on high priority platform changes

  • Daniel Kayiwa and Ken Omondi to coordinate to dedicate at least 1/2 day weekly on PRs (reviewing or getting others to review)
  • Burke Mamlin to create Kanban board for Platform issues
  • tendo kiiza Martyn to make 2nd pass of reaching out individuals to solicit what they feel could be improved with OpenMRS Platform
  • Burke Mamlin to bring idea for near-term wins to Talk – done here
  • Burke Mamlin to identify Talk threads for key design discussions


Attendees: Grace, Ken, Daniel, Tendo, Bett, Nathan, Steven, Irene


  • Timing of call
    • In order to attract more contributors to the meeting, should we change the timing of the call? 
  • Reactions to suggestions made on talk post
    • Incorporation of Lombok 
      • Reservations:
        • The effort spent on doing getters and setters is not significant enough to introduce Lombok as a dependency to the core platform
        • Code written using getters and setters is more readable than those written using Lombok
  • How can the larger community members help in the platform work? What are the priority areas ? 
  • Roadmap for platform 2.5
    • There's an urgent need to update the roadmap document.
    • The roadmap should be pegged on the Squad and Implementations priorities
    • Given that we are already mid-year, the roadmap should cover the next 3-4 month timeline.
    • What is the intersection between implementation-specific and community priorities?
      • The decision on the priority levels will be subjected to discussions by the platform team 
    • How do we get feedback from known implementations and squads? 
      • Would the upcoming showcase provide an opportunity of getting everyone around a table to discuss?
      • Asynchronous contribution from squads and implementations via OpenMRS talk is the other approach
    • Feedback from Ampath & PIH
      • Provide support for higher versions of Tomcat (Tomcat 10) 
      • Provision to selectively rebuild lucene indexes
    • Upcoming work: Martin Tendo to take lead in getting feedback from implementations and squads. Focus on: 
      • Pain points
      • Priority areas
  • PRs
    • So far, there are no high priority tickets from the available TRUNK tickets. 2 PRs merged during the past week.
  • Kanban: 


Attendees:  Daniel, Ken, Tendo, Burke, Bett, Ian, Nathan, Sharif


  • Kickoff – deciding on meeting structure
    • PRs (prioritizing, assigning, reviewing, decisions)
      • Distinguishing between PRs that are part of Platform priorities vs. community PRs that touch the Platform
      • Factor in both technical & product priorities, where product includes user needs & product priorities
      • Use "community-priority" label
        • Wouldn't expect community-priority to haver Priority other than Blocker, Must, or Should
      • Use ticket priority
        • Focus on Blocker, Must, and Should
        • Reserved bandwidth for Could and Non-Essential
    • Prioritized Backlog (prioritizing, assigning, working on tickets)
    • Prioritizing/assigning upcoming work
    • Showcase/demo
    • Design (Talk → Tickets)
    • Strategy (overseeing data model changes, keeping libraries updated, adopting/aligning standards)
  • With a relatively small team, let's start with Kanban (maybe transition to sprint approach if number of active devs grows)
  • Review outstanding PRs
  • Review Platform board
    • Switching from Hibernate mappings to annotations
  • Review Backend-related Feedback
    • Improving Global Properties
    • User Settings (including User+Patient settings)
    • Auditing
    • Clinical notes / documents
    • Draft Encounters
    • Event Bus (to support FHIR subscriptions)
    • Better use of Spring
    • Migrating from Hibernate to JPA (TRUNK-5762)
    • Reducing startup time
  • No labels