2015-07-22 Design Forum

Owned by Jamie Thomas
Dec 11, 2015
2 min read
Attendees
  • Darius
  • Jonathan
  • Burke
  • Daniel
Agenda/Notes
  • Encounter Transactions and visit Templates
Monday's notes:
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