/
2015-07-22 Design Forum

2015-07-22 Design Forum

Dec 11, 2015

Attendees

  • Darius

  • Jonathan

  • Burke

  • Daniel

Agenda/Notes

  • Encounter Transactions and visit Templates

Monday's notes:

https://notes.openmrs.org/Design-Forum-2015-07-20

When are orders activated/finalized?

  • Doctor writes and signs an order: it is Signed and it is Activated

  • Nurse writes and signs an order: it is Signed and it is Activated (and also posted to a Cosign queue)

  • Student writes and signs an order: it is Signed, NOT Activated until Cosigned. (via a business rule) (also posted to the Cosign queue)

Burke: once an order is *activated* you would have to countermand it, and can't otherwise edit it

JT: thinks of that as being true for a *signed* order

Aside: FHIR doesn't define any of this. It starts from Active: https://www.hl7.org/fhir/medication-prescription-status.html

  • JT: I think this spec applies to the processing of an order (what the nurse does), not writing the order

Order status:

  • Draft = may limit who can see it, can be deleted without audit trail

  • Preliminary = "anyone" (more people) can see it, but not activated (subject to change, people may act on it with caution/understanding)

  • Student Signed = signed by someone without authority to finalize/activate

  • Signed = order "frozen" (written in ink), if signed by student, then order not activated until cosigned

  • Activated = person with authority has signed or cosigned -- can be prepared, acted upon by other processing units, etc.

  • Usually happens at same time as Signed, unless the signer is a student

  • Start time/condition (Started/Live) = refers to when the task should be carried out

  • Cosigned = person of authority acknowledges an order written by someone else

Order status flag structure suggestion: 

  • Draft / Preliminary / Signed are mutually exclusive, could be in one field

  • Activated would be separate boolean -- unless we make the former "draft / preliminary / signed but not activated / activated"

  • Live is a different field (may be a business rule based on start time and end time)

  • Cosigned would be a separate property of the structure

We wrote (mainly about Notes) on 07-20:

  • 1. Draft - only I (the author) can see it

  • 2. Preliminary ["shared" in Epic] - others can see it but it is marked preliminary.  It could be changed, in which case they would see the latest version with a flag to see the earlier ones.

  • 3. Final - it's no longer changeable

  • 4. (new) (maybe) "invalid" or some flag indicating that this data is not usable [processing error, wrong patient, whatever]

Kinda hoping that these definitions apply to many data types

List of statuses:

  • For Visit

  • JT suggests, as a starting point:

  • Created -- could apply to visits scheduled but not yet happening? (optional)

  • Open - [various elements can be finalized and active even while the encounter transaction is open]

  • or Created and Open could be combined, if the distinction is not necessary

  • Closed - after certain key elements (perhaps all required elements) have been finalized

  • For Encounter

  • For Observations

  • draft, preliminary, final still are applicable for status (also: pending, not valid ("X"))

  • an observation (e.g., lab result) can have a "modifier" -- exception, comment (e.g., hemolyzed) -- which orders and notes would not need because the nuance is already included

  • For Orders

  • Draft, Preliminary, Signed/Final, Activated

  • For Notes

Most calls to the API will return only activated orders