Platform Team Meeting Notes 2022

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


  • O3 Docker backend slow to start up
    • Demo data module is generating a lot more encounters. Would be nice if we ran this to create a snapshot (would need both database and iniz checksums)
    • Would moving iniz checksums into the database help?
  • Ian's question for everyone
    • Trying to parallelize data generate to make data generation (e.g., for demo module) perform faster, but running into issues with tests failing. When tests are running in independent daemon threads, the data cache is blank.
    • Daniel: could the problem be related to the hibernate session object not being thread safe? And probably our default for hibernate.current session context class could be thread
  • Update on auth module (Mike Seaton )
    • Mike Seaton will move openmrs-module-authentication into OpenMRS github org
    • How to manage FHIR & REST authentication?
      • Would prefer to have web services (FHIR & REST) to defer authentication to core
      • It might work to have FHIR & REST to have a soft dependency on the new auth module, allowing the central auth module to load authentication into the session before calls get to FHIR/REST (so they would just work)
  • Community is moving toward using Platform 2.5.4+ as the "standard" (supported) backend.
  • Would like to add CSRF guard into FHIR & REST calls


  • Discussed CI pipeline issues. Agents have been fixed.
  • Unable to reference an external log4j file
    • Currently logging can be very confusing (multiple versions of log4j over time – e.g., log4j2 on 2.4+ and log4j in pre-2.4 versions)
    • Can help by documenting current log4j2 support
      • Having a log4j2.xml, log4j2.json, or log4j2.yml file next to runtime properties should work for platform 2.4+ and changes to the file pulled in automatically
      • See Log File Settings
    • It would help if logging pattern was documented, relatively easy to understand, and could be tweaked (at least at high level) through settings in the runtime properties file.
      • Unfortunately, support for log4j2 properties file format isn't as straightforward as being able to support JSON/XML/YAML



  • Changing time of call?
    • Seeing if there are people who are unable to join at current time
  • Investigating FormDataService module to provide support for draft forms
  • Multiple Concept search feature
    • When searching for multiple concepts, there isn't a way to link which results belong to which requested reference
  • Investigating regression to 404 when requesting "/openmrs"
  • Grace's questions
    • Docker images updated by Rafał. How do we maintain references (e.g., for documentation)?
      • Adopt short links
    • Reviewed WHO DAK requirements


  • Currently using community priority label to indicate platform tickets that are priority.
    • TODO: Burke Mamlin to try changing Kanban board to use simplified view
  • Inputs
    • Slack discussion (in #platform)
    • Talk discussion (calling out @Platform_Team on Talk, following up to see that it gets attention)
    • Creating a ticket and marking at community priority (if it's a well-formed idea or ticket already exists)
  • Prioritization
    • To do on Platform Team calls
  • Getting ideas into actionable tickets
    • Prefer Talk discussions
    • Ad hoc calls when needed


How do we communicate & prioritize backend/platform issues within the community?

  • Current people
    • People looking to help with community needs: Daniel, Rafał, Daud (fellow), Bett (20% fellow), and some Joshua (from QA)
    • People working on implementation/organization-specific needs: UCSF, Mekom, AMPATH, PIH, ...
  • Operational needs
    • Which issues are considered?
    • Prioritization
    • When? Maybe move Platform Team call to better time for EAT
  • Design needs
    • Discussing backend design issues
      • Talk threads
      • Ad hoc calls?


  • Discussion about searching patient identifiers (from Slack)
    • The underlying issue here is that we need data from both core and a module (idgen). idgen does a decent job of providing a searchable set of results so it’s possible to list all identifiersources and their corresponding identifiertypes. However, its not possible to go from identifiertypes -> identifiersources, and this means (since there’s no guarantee that all identifiertypes have an identifiersource) that we don’t have a single REST endpoint that can be used to query all identifier types and their configuration. (There’s also an additional GP that needs to be read that was part of EMRAPI to indicate the primary identifier).
    • We should definitely build a single API endpoint for this; web-requests are not cheap and right now we’re basically requiring 4 requests just to figure out what identifiers should be displayed. However, it’s not clear to me where this should live. We can’t really put it in Webservice.REST, since Webservices.REST doesn’t (and shouldn’t) depend on idgen. We could put it in idgen I suppose, but that might be overloading it’s purpose.
    • The primary use case: give me all available patient identifier types and everything I need to know about them (including which is primary, which are required vs optional, which are preferred, which are auto-assigned vs need to be entered manually, and any restrictions like ID format)
  • Support for draft forms
    • API endpoints added to FormService
      • Save a draft form (given user & patient)
      • Update an existing draft form
      • What draft forms are available for this patient? (limited to those user can see)
      • What draft forms are available for this user? (do we need us?)
      • Get a specific draft form
      • Delete draft form
    • How long a drafts kept? (default to forever?)
    • Draft Form information
      • User
      • Patient
      • Which Form is associated with Draft Form
      • Form contents (JSON payload)
    • Implement core API endpoints via a Draft Form module (would depend on RESTWS and implement endpoints by extending RESTWS module, not inventing new module-specific REST API)


  • Reviewed Kanban and discussed some devops issues


  • For results viewer, there's a panel viewer
    • Fetching a list of concepts
    • How would we we fetch all observations for a patient?
      • Would like to avoid a "get all observations for the patient" API call (unless results are paged), since this could be a large amount of data
  • Type field on forms
    • Could be like a mime type to identify the form schema ± flavor/version – i.e., which forms engine(s) can work with the form.
  • Switching to concept mappings as the preferred way to reference concepts (rather than always by UUID)


  • Backend feature requests for OpenMRS 3 (TRUNK-6065)
    • Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.
    • Unable to locate Jira server for this macro. It may be due to Application Link configuration.  
    • Do we want to use a label instead of an epic?
  • Looking up concepts via concept mappings
    • Need a way to get a concept by SAME-AS mapping and get a single result (i.e., not using search)
    • Would need to verify that there aren't "valid" real world cases where multiple concepts are mapped via SAME-AS to the same target
      • Craft a quick query for AMPATH, Mekom, PIH, KenyaEMR, etc.
  • Modeling dose units & frequencies


  • Burke will check in with Bett on cohort module work for patient queues
  • Burke, Ian, and Daniel to check in with Herbert on "SDK for RefApp3" GSoC project



  • Med ordering on the frontend is currently using JSON configuration for what drugs are orderable and their common selections (route, frequency).
    • Frontend needs options for routes, frequencies, and dosages for med orders.
    • Bahmni currently has a single endpoint that returns possible values as a "configuration"
    • We could represent these in concept sets (aligning with FHIR's use of valuesets); however, it would be preferable for the frontend to obtain them through a call to the API (i.e., an order service endpoint) rather than going directly to the concept dictionary, since it would allow the order service to add additional business logic in the future (e.g., smart search features to convert commonly used but error-prone latin abbreviations for routes and frequencies into standardized naming conventions, the ability to support drug-specific queries to constrain values to those appropriate for a specific drug, etc.).
    • Sometimes routes, frequencies, and dosages have interdependencies (e.g., preferred frequency might vary by route or dosage), so it would be good to have a response format that can communicate these relationships.
  • Adding data to new instances




  • Modularizing the backend
    • Breaking core into modules – picking our battles
    • Defining clear & explicit interfaces (contracts) with services
      • Defining data model classes as interfaces
    • Being able to focus refactoring or changes to a specific area of the codebase
    • Implementers are two years behind with the platform
    • Next steps:
      • Continue to think/discuss about this issue
      • Instead of moving new functionality into core, we consider modules as bundled modules in the platform
  • Queueing Update
  • Do we want to set up code scanning on openmrs-core? if we can use this to replace Sonar, that would be cool (the issue with Sonar is that it requires Java 11 and most of our projects can’t be built with Java 11 because they depend on older libraries)


  • Discuss any builds needed to address recent patch in omrs-core
    • All patched WARs are available (except 2.0 is having build errors on CI)
    • Daniel will try to run deploy builds on CI to get WARs on Sourceforge. If it works, Grace can send out announcement. If it fails, we can work through issues and, if needed, send announcement with links to 
  • Need to create liquibase Snapshot for 2.5.0 
    • Ian will create a ticket for creating a 2.5.0 liquibase. Daniel can use this to create a CI step to run this process that can be triggered manually for now and eventually adapted to automatically run only on x.x.0 releases.
    • Unable to locate Jira server for this macro. It may be due to Application Link configuration.
  • Queue/workflows
    • Discussed plan. Bett will work on first pass changes based on conversations with Ian and will update us on his progress via #platform on Slack. The goal is to provide Bett with some near-term feedback so he can proceed with coding but doesn't invest too much time & effort on an approach that we decide has issues and needs to change.
  • Update/Simplify: OpenMRS Platform Release Process


Appointments: Discussed how to unblock for 3.x


  • Bahmni working on PR for Platform to address log4jshell-related fixes
  • Unable to locate Jira server for this macro. It may be due to Application Link configuration.