Ongoing Design discussions
...
Review Platform Kanban Board
2022-09-14
- Discussed CI pipeline issues. Agents have been fixed.
- Still having errors publishing to Sourceforge
- 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
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
...
- 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
...