Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Ongoing Design discussions

TopicLink(s)Notes
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

2022-07-20

  • 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

2022-07-13

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?

2022-06-15

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

2022-05-04

  • Reviewed Kanban and discussed some devops issues

2022-04-20

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

2022-04-13

  • 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

2022-04-06

  • 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

2022-03-30

2022-03-16

  • 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

2022-03-09

2022-02-16

2022-02-09

  • 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? https://github.com/openmrs/openmrs-core/security/code-scanning 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)

2022-02-02

  • 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 https://github.com/openmrs/openmrs-core/tree/master/liquibase 
    • 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

2022-01-26

Appointments: Discussed how to unblock for 3.x


2022-01-19

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

2022-01-12

  • No labels