- Encounter Transactions and visit Templates
- 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)
- JT: I think this spec applies to the processing of an order (what the nurse does), not writing the order
- 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
- 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
- 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]
- 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
- http://www.hl7.org/FHIR/diagnosticreport.html has registered, partial, final, corrected as status values
- https://www.hl7.org/fhir/observation.html has registered, preliminary, final, amended
- For Orders
- Draft, Preliminary, Signed/Final, Activated
- For Notes
- No labels
Text is available under the Creative Commons 4.0 International Attribution License (CC BY 4.0).
Software is available under the Mozilla Public License 2.0 with Healthcare Disclaimer (MPL 2.0 HD).
"OpenMRS" is a registered trademark and the OpenMRS graphic logo is a trademark of OpenMRS Inc.