Ongoing Design discussions
...
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)?
...
- Discussion about searching patient identifiers (from Slack)
- The underlying issue here is that we need data from both core and a module (
idgen).idgendoes 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
idgenI 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
...