2014-03-12 Design Forum

Owned by Burke Mamlin
Mar 12, 2014
OpenMRS Design Forum 2014-03-12
Topics
  • Should we add OrderSaveHandler to use OrderContext data to set order type and caresetting if null?
  • Strategy for running OpenMRS 2.1 on Platform 1.10
  • EA-1 Order structure
Notes
Agreed that OrderSaveHandler should use OrderContext data to set order type and caresetting if null for the order getting saved
Strategy for running OpenMRS 2.1 on Platform 1.10
    - Setup a VM running an instance of the latest builds of 1.10.x
    - Switch back devtest02 to run the latest version of the reference application for manual testing
    - Update the Reference application to build and run against 1.10.x
    - Update any broken modules in the ref app to work with 1.10.x and fix any issues in the reference application
Planning further out:
Reference Application Road Map: https://openmrs.atlassian.net/wiki/x/u7VTAQ
===== RA-68 - Retrospective Data Entry =====
We have implemented the ability to do real-time entry, which assumes (1) current user is the provider, (2) happening now, (3) at the current session location. We want to allow retrospective entry of forms, in a common and consistent way.
Jonathan: typically people will put who-when-where questions a the top or bottom of the process. But preserve the actual data entry piece to be the same as now. "It's not a complicated UI thing, but it's important to have a convention for it."
Burke: common case for OpenMRS is delayed transcription of encounter forms filled out in the field. (As opposed to "patient brought immunization/lab data from an old visit at another clinic", so I'm entering it today, but for a previous date.)
Two cases:
* Enter a previous visit
* Patient has an active visit, but enter data from a previous date
Next steps:
  • Explicitly write out end-user scenarios (e.g. "doctor is writing all their visit notes from yesterday's encounters")
  • List some specific stories
===== RA-304 - Implementation-specific Forms =====
In the new UI, a form requires some extra options/metadata around it that is currently stored in code/configuration, and not directly on the form.
Examples:
  • icon (maybe done by encounter type)
  • summary view of the form, for in-line display in the DEPD
Next Steps:
  • Enumerate the technical steps involved in exposing a form in the new UI; we'll need to figure out how implementation-defined forms can specify these things (e.g. Form Attributes)
  • Define a "form entry" app, or page for the patient which exposes all forms
  • Decide how we want to allow forms to be exposing as shortcuts on the CFPD and/or DEPD
TODO
  • clean up and transcribe notes from here into RA-68