Ongoing Design discussions
Topic | Link(s) | Notes |
---|---|---|
Patient list support | AMPATH-specific needs pulled out of cohort module. | |
Deployment and Configuration | ||
Support for User groups | Darius Jazayeri working on a design | |
Multitenancy | Discussed 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-08-17
- Discussed Issues with Liquibase changes over Platform releases affecting use of Iniz
- Discussed which modules should be included as part of the Platform
- Current: REST Web Services, FHIR2, OWA
- Proposed: Iniz (initializer), idgen
- Discussed testing coverage for modules
2022-07-27
- 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
- Docker images updated by Rafał. How do we maintain references (e.g., for documentation)?
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?
- Platform Kanban Board (includes multiple projects
- Technical Road Map
- How do we discover shared issues?
- Prioritization
- When? Maybe move Platform Team call to better time for EAT
- Which issues are considered?
- Design needs
- Discussing backend design issues
- Talk threads
- Ad hoc calls?
- Discussing backend design issues
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)
- The underlying issue here is that we need data from both core and a module (
- 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)
- API endpoints added to FormService
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)
- Need to ensure we have a clear REST endpoint for concept service's getConceptByMapping
- We support /concept/CIEL:1065 (via this code), just need to document it (within the "List concept by UUID" section of REST docs)
- Need to ensure we have a clear REST endpoint for concept service's getConceptByMapping
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.
- 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
- Needs some design
- Mapping Order Frequencies to FHIR
- Mapping Dose Units to FHIR
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
- Should FHIR and FHIR2 modules clash on older platform versions 2.0-2.3.x
- FHIR2 was intended to replace FHIR. Anyone running an older version of the platform that has the FHIR module who wants to run OpenMRS 3.x or anything else that depends on FHIR2 should remove the legacy FHIR module and install the FHIR2 module.
- OpenMRS Packaging
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
- New Habit Proposal for these calls:
- Review Platform Kanban Board
- quick review of PRs from the last week in a selection of key repos (similar to what we recently started doing in the 3.x Squad) → prevent helpful PRs from getting missed for months; celebrate folks' very recent contributions. Proposed repos:
- Core: https://github.com/openmrs/openmrs-core/pulls
- REST: https://github.com/openmrs/openmrs-module-webservices.rest/pulls
- REST Docs: https://github.com/openmrs/openmrs-contrib-rest-api-docs/pulls
- https://github.com/openmrs/openmrs-module-coreapps/pulls
- IDgen: https://github.com/openmrs/openmrs-module-idgen/pulls
- FHIR: https://github.com/openmrs/openmrs-module-fhir2/pulls
- Which modules should be part of the platform in 2022-2023?
- Yes
- Address Hierarchy module
- OCL subscription module
- Initializer module
- Module Spa
- Maybe
- Packaging module
- OWA
- No
- Consider leveraging SDK for Platform management (e.g., modules) without introducing a UI into Platform
- Yes
2022-02-16
- Queueing update
- Need to define concept set for defining queue priorities, states, and services
- API call for test results for concept set(s)
- 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-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.
- 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
- Daniel Kayiwa has already pushed the fix for the atomfeed issue: https://bahmni.atlassian.net/browse/AP-12
- Ian Bacher to install Bahmni Appointments on local version of dev3 with the new version of atomfeed
- If this works (aka doesn’t crash the system), then we’ll install Bahmni Appointments onto O3/SPA again.
2022-01-19
- Bahmni working on PR for Platform to address log4jshell-related fixes
2022-01-12
- Review 9 graveyard candidate tickets
- Service Delivery queues
- Burke about to post an iteration to Talk thread