Page Comparison

Ongoing Design discussions

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

...