Page Comparison

Ongoing Design discussions

...

Review Platform Kanban Board

2022-09-21

• 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

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

...