Stream: implementers
Topic: Orders NOT to do something
Michelle (Moseman) Miller (Sep 01 2016 at 20:14):
Patient Care work group has been discussing GF#9335, which questions whether changes are needed to ProcedureRequest to support orders NOT to do something. We would like feedback from implementers on how "do not perform" is captured in your system.
For example, are some of the following notes or alerts on the chart while others are more formal orders?
- DNR
- do not turn patient due to spine fracture
- do not give blood or blood products
- do not flush central line
- do not take blood pressure on a certain arm
- NPO
Grahame Grieve (Sep 01 2016 at 21:20):
This factors into the Consent resource too - where the source of the 'do not' comes from the patient, these are notionally in scope for the Consent resource, though this is not universally agreed to. DNR is usually considered a consent based issue
Michelle (Moseman) Miller (Sep 01 2016 at 22:47):
@Bryn Rhodes , during Patient Care's discussion about how to handle "do not perform" orders, we were leaning towards using precoordinated codes to represent these things (e.g. DNR, NPO), but wanted to check to see how PlanDefinition handles it (e.g. in context of a protocol or order set).
Bryn Rhodes (Sep 02 2016 at 00:24):
@Michelle (Moseman) Miller We don't specify at the PlanDefinition level, we would leave that semantic as an aspect of the activity itself.
Michelle (Moseman) Miller (Sep 05 2016 at 23:51):
@Bryn Rhodes , since PlanDefinition references the ActivityDefinition, if we used a precoordinated code (e.g. for NPO), is that an acceptable value for ActivityDefinition.code? At first glance, I didn't see any elements for representing "do not do" (negating) ActivityDefinition.code, so is it safe to assume that ActivityDefinition requires precoordinated codes or am I missing where the negation is communicated elsewhere in the resource?
Bryn Rhodes (Sep 06 2016 at 21:23):
@Michelle (Moseman) Miller The base ActivityDefinition resource doesn't define any constraints on the contents of the code element, so you can use whatever code makes the most sense. It also doesn't define any structural elements to indicate negation at the ActivityDefinition level, so you can use an ActivityDefinition to describe the intent not to do something using a precoordinated code to indicate that, yes.
Eric Haas (Feb 01 2017 at 18:24):
I am trying to create an example for the specification using the ProcedureRequest doNotPerform element
Looking at these use cases:
-
DNR -would this be consent and a flag? seems bigger than an order.
-
do not turn patient due to spine fracture - OK
-
do not give blood or blood products - OK
-
do not flush central line -OK
-
do not take blood pressure on a certain arm - OK
-
NPO using NutritiionOrder for this? @Margaret Dittloff can you chime in
John Moehrke (Feb 01 2017 at 18:52):
The distinction between Consent and ProcedureRequest is dependent on WHO is asking something NOT to be done... right? This distinction seems historic, not clear it needs to be future. But this is the perspective I have.
Margaret Dittloff (Feb 01 2017 at 19:51):
Yes, @Eric Haas that makes sense tp me. The oralDiet.type SNOMED concept for NPO is 182923009 |Nil by mouth (regime/therapy).
Michelle (Moseman) Miller (Feb 02 2017 at 14:53):
FYI, back when Patient Care owned this resource, as part of GF#9335, we agreed that NPO could also be communicated via a precoordinated code. As such, we added a usage note about how to interpret the doNotPerform element in context of a precoordinated Procedure.code (like NPO):
" If the ProcedureRequest.code and ProcedureRequest.doNotPerform both contain negation, that will reinforce prohibition and should not have a double negative interpretation"
Eric Haas (Feb 02 2017 at 22:05):
Yes that guidance is still there.
Last updated: Apr 12 2022 at 19:14 UTC
