/
2014-03-12 Design Forum

2014-03-12 Design Forum

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

  • https://tickets.openmrs.org/browse/ea-1

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