Attendees
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
- 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:
- 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
- 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
- Draft, Preliminary, Signed/Final, Activated
Most calls to the API will return only activated orders