Stream: implementers
Topic: Table 0119 Order Ctrl Code to FHIR MedicationStatusRequest?
John Silva (Oct 16 2018 at 18:08):
I posted a topic in the V2 to FHIR thread but I'm not sure it will get much visibility there. I'm 'cross-posting' it here in the hope that more people would see it?
John Silva (Oct 17 2018 at 21:40):
Bump! (are there NO HL7 V2ers here :-) )
Grahame Grieve (Oct 17 2018 at 21:41):
there are, but our experience is that the v2 community is not interested in helping others out
John Silva (Oct 18 2018 at 01:16):
@Grahame Grieve - I wonder it it's because folks in the V2 community are busy implementing existing V2 systems (which are still more numerous than FHIR-enabled systems). I get the feeling that FHIR is about 'green field' implementations; there doesn't seem to be interest in trying to get V2 systems to interoperate with FHIR-based systems. The v2 to FHIR thread has been very quiet since it was setup after FHIR DevDays in June.
Grahame Grieve (Oct 18 2018 at 01:17):
well, we also have chat.hl7.org which has showed the same behavior for outright v2 questions. I think that there's quite some interest in v2 -> FHIR and I'm going to push it along shortly
John Silva (Oct 18 2018 at 01:20):
Should I be asking this question in the Orders and Observations listserv instead? (is that the name for the group?) It seems like this is a basic order workflow question, it's not just about ordel control codes but how are they represented in the Order workflow paradigm in FHIR? (For that matter, how does the V2 0119 table map to the V3 equivalents; maybe that would lead to an answer for this)
Grahame Grieve (Oct 18 2018 at 01:21):
given you got nothing here, definitely worth it
John Silva (Oct 18 2018 at 01:23):
Thanks! I was told that 'most' of the FHIR community 'lives here' and doesn't use the listserv -- but maybe the converse is true -- the V2 folks still use the listserv instead of the chat (Zulip) mechanism?
Grahame Grieve (Oct 18 2018 at 01:31):
I don't think the behavior is much different on the list serv.... but it doesn't hurt to try
Jose Costa Teixeira (Oct 18 2018 at 02:45):
This would be a thing for workflow, not v2
Jose Costa Teixeira (Oct 18 2018 at 02:46):
i am not sure what would be the best delivery here... some of these codes will map to request, others to event, others to task...
Jose Costa Teixeira (Oct 18 2018 at 02:49):
there doesn't seem to be interest in trying to get V2 systems to interoperate with FHIR-based systems.
there is some interest. not only to interoperate, but to provide gap overview or a migration path.
John Silva (Oct 18 2018 at 04:17):
@Jose Costa Teixeira - I just realized that the FHIR Workflow pattern https://www.hl7.org/fhir/workflow.html seems to address the generalized pattern that is used for many orders but didn't see any 'control codes' that define the workflow state transitions. For reference (which you probably already know) the MedicationRequest and ProcedureRequest follow the Request pattern with state transitions but there doesn't seem to be codes (e.g. the status field in these request resources) that are 'standardized' to define the state transitions between the states (unless I'm missing something). In HL7 V2 the ORC-1 or Table 0119 is about defining these 'state transitions'. It's also interesting that the MedicationRequestStatus and the RequestStatus (used by ProcedureRequest - which seems similar to the V2 ORM General Order message) have a similar set of status codes.
Lloyd McKenzie (Oct 18 2018 at 04:29):
The notion of "please hold" "hold refused", "hold accepted" would be the interminglying of a Task code saying "hold" (haven't standardized a value set there, but we're exploring at least an example value set) together with the Task status of "requested" vs. "completed" or "rejected"
Lloyd McKenzie (Oct 18 2018 at 04:30):
The status of the request itself would simply be "active" or "held". There's no notion of reflecting a request for transition in the Request resource itself.
Jose Costa Teixeira (Oct 18 2018 at 04:30):
NW says "this is a new request". in FHIR, this would mean for example a few Request-type resource.
CA says "please cancel", which would correspond to a request with status = Cancelled.
the actual progress status would be held e.g. on task resources.
John Silva (Oct 18 2018 at 17:51):
I suppose this is the difference between naming the states (nouns?) and the state transitions (verbs). The states would be things like 'active', 'on-hold', 'completed', etc., which seem to be what the MedicationRequestStatus (and RequestStatus) value sets represent. I guess there aren't the 'action verbs' that define the state transitions. As Jose points out, in V2 0119 it contains codes for both states and state transitions. [I guess this has been modeled in V3, but I'm not familiar with how it models this; is this that 'mood code' concept?] So I guess an approach for attacking the specific problem of my original question would be to determine which of the V2 0119 codes are states and which are state transitions and then only map the ones that are true 'states' to the MedicatioRequestStatus field. In V2 there are separate fields, ORC-1 (Order Control - Tbl 0119) which represent the state transitions, and ORC-5 (Order Status -0038) which represent the states. So, maybe the question I really should be asking is how to map the HL7 V2 Table 0038 into MedicaitonRequestStatus. ;-)
Jose Costa Teixeira (Oct 19 2018 at 05:04):
with the request pattern (in other words, in all request resources), we are not using the Request to track the evolution of the workflow.
There is now a difference between "status of the request" and "status of the workflow that is triggered by the request".
For example: status of request "cancelled" means that the requester says "please cancel". It does not say anything about whether the other parties have indeed suspended, or if they have just proceeded and the workflow is active or even completed.
John Silva (Oct 19 2018 at 12:07):
@Jose Costa Teixeira - OK, this makes sense from a 'theoretical' point of view but what happens in 'real life' workflows and how do we know and represent to the end user that a MedRequest (for example) is 'discontinued' or 'stopped rather than just that someone requested that the order be 'discontinued'? It seems in the V2 codes there is explicit support for driving the workflow state transitions (ORC-1 - Tbl 0119) and describing the state the workflow is in (ORC-5 - Tbl 0038). In the clinical workflow, and any application that needs to communicate this to the clinician, the state of the order needs to be explicitly shown to the user (clinician); it can't just be 'the intent to discontinue an order' but the fact that the order has really been discontinued.
Lloyd McKenzie (Oct 19 2018 at 14:56):
When you look at a Request, there'll be no indication that someone has asked for it to be stopped. The MedicationRequest will reflect its current state until that changes. It's either active or it's stopped. The MedicationRequest reflects the status of the authorization. It has no notion of requested transitions or requested fulfillments. All of those things are modeled only through Task.
Jose Costa Teixeira (Oct 19 2018 at 18:05):
It seems in the V2 codes there is explicit support for driving the workflow state transitions (ORC-1 - Tbl 0119) and describing the state the workflow is in (ORC-5 - Tbl 0038).
one thing is driving the workflow state transitions, another is reporting the result of that drive.
Jose Costa Teixeira (Oct 19 2018 at 18:08):
A real life workflow may not know whether, after a request has been stopped, things are effectively cancelled. Or if they can be.
example for medication request: upon canceling an order, how does the requester know that the subsequent steps (dispensing, inventory forecast updates, resupply, preparation, administration) have or not beeen cancelled? Other information must be there beyond "what has been requested"
Jose Costa Teixeira (Oct 19 2018 at 18:15):
so the answer to "how do we represent to the end user" is "by realizing what has happened from the possible sources of information",
and not "by using an order message as a workflow document that is updated by both parties".
Jose Costa Teixeira (Oct 19 2018 at 18:18):
I think the original question is pertinent, and we should provide some guidance on how people used to use ORC segment may solve their problems with FHIR.
John Silva (Oct 19 2018 at 20:53):
I'm not sure I understand all the subtleties of your reply. My 'simple use case' is that a user (clinician, e.g. a nurse) needs to know the current intention (status of a MedOrder) so that they do not continue giving meds if the request has been marked as 'canceled' or 'discontinued'. As the nurse, I do not (necessarily) need to know if the dispensing (or other supply operations) have been done already or not, I just need to know the physician's intent, i.e. this order was 'canceled' or 'discontinued' (as of XYZ date/time) so that I don't continue giving the patient meds.
John Silva (Oct 19 2018 at 20:56):
So, a more general FHIR question, are Request resources meant to reflect the state of an object in a workflow, whereas the Task resource is meant to reflect the state transitions? Doe this imply that Request type objects can't really 'exist alone' in a true workflow environment?
Lloyd McKenzie (Oct 19 2018 at 21:10):
Request resources represent authorizations. The authorization can be draft, active, suspended, completed or stopped. The authorization enables the workflow, but is distinct from it. Just because something has been authorized, that doesn't mean it's actually happening (or event that it weill happen.) Occasionally there may be situations where an authorization has ended but the originally authorized event might still be ongoing - either because the termination of the authorization hasn't been communicated yet or because the initiated action has passed the point of no return.
Lloyd McKenzie (Oct 19 2018 at 21:12):
Task is what lets you say "please fill", "yes I will", "no I won't", "done". It's also what lets you say "please suspend" or "please stop". If you want to communicate about the details of such actities in FHIR, you'll need Task.
John Silva (Oct 19 2018 at 21:24):
"Just because something has been authorized that doesn't mean it's actually happening" -- wow, that's confusing!! So Requests do not represent the current state, only some "notion of what I'd like the state to be" (with no responsibility that anyone will actually act on this request?) I guess coming from the V2 world the concepts of state (current) and state transitions are conflated into ORC-1 control codes. (I have to look, I seem to remember that someone in the 'V2 days' had done a nice state diagram which shows the relationship between the 'state transition' codes and the state codes.
The IHE Hospital Workflow ( http://www.interopsante.org/offres/file_inline_src/412/412_P_12922_20.pdf ) shows some of this but doesn't have the specific ORC-1 control codes used to drive the workflow state transitions. Maybe the IHE folks are working on a similar profile (Vol II) mapping to FHIR Requests and Tasks that would help clarify this.
BTW. Figure 3.1-1: Pharmacy Interoperability Model in the above IHE document is one of the nicest diagrams that shows the (in hospital) pharmacy order workflow!!
Lloyd McKenzie (Oct 19 2018 at 21:48):
When a clinician writes a prescription, you've got an authorization. The authorization might stay in your pocket or on the fridge. You might fill the prescription but never bother taking the med, etc. You might go to one pharmacy and they don't have any, so you go to another pharmacy. The state of the order doesn't change at all through out any of that process.
Jose Costa Teixeira (Oct 20 2018 at 02:03):
"So Requests do not represent the current state, only some "notion of what I'd like the state to be"
yes. A request represents what has been requested. The place where the current state of the workflow is represented is the task.
Jose Costa Teixeira (Oct 20 2018 at 02:13):
"
The IHE Hospital Workflow ( http://www.interopsante.org/offres/file_inline_src/412/412_P_12922_20.pdf ) shows some of this but doesn't have the specific ORC-1 control codes used to drive the workflow state transitions. Maybe the IHE folks are working on a similar profile (Vol II) mapping to FHIR Requests and Tasks that would help clarify this.
Perhaps you mean this document instead http://www.ihe.net/uploadedFiles/Documents/Pharmacy/IHE_Pharmacy_Suppl_HMW.pdf.
In section 4.6 Order Status Management we see an attemp to capture workflow state in ORC-5 and ORC-25, and why the state of the order is not the same as the state of the workflow.
Jose Costa Teixeira (Oct 20 2018 at 02:24):
The workflow expectations from IHE Pharmacy are well covered with the FHIR workflow resources.
IHE will surely provide guidance on Pharmacy (as HL7 publishes generic guidance on workflow).
Lloyd McKenzie (Oct 20 2018 at 02:41):
I disagree that "the place where the current state is represented is the task". The MedicationRequest will always reflect the current state of the authorization. It won't reflect what's actually been done about the authorization. Nor will it reflect requests to change the state of the authorization.
Jose Costa Teixeira (Oct 20 2018 at 02:57):
Correct. I meant the state of the workflow (and updated that statement). Hope it's clearer now.
John Silva (Oct 20 2018 at 08:40):
OK, but what does "authorization" really mean? I'm still trying to correlate this to V2, e.g. the OMP is the initial "Pharm Order Placement", I suppose it's a request of intent with an implicit authorization. The RDE reflects when the Pharmacy encodes the order knowing about what specific drugs are available in their pharmacy (and also maybe knowing about patient condition and allergies). If I were implementing a V2-based MAR these are the messages that I would use and I wouldn't care about 'authorization'; it's implicit in the fact that these messages are sent to me (my system) and I would present these orders to the user as "the current truth" -- if the order is active (ORC-1 is something other than DC or CA) the expectation is that the medication should be administered according to the instructions of the order. From my perspective the MedicationRequst is similar to the OMP/RDE and its state (or status) is what I need to present to the clinician as the "current truth" not some notion of 'authorized or not'. (I guess the way I'm looking at it is that the systems involved before I see the messages are already handling the Task workflow state transitions and to me, the MedicationRequst represents the "current state")
Jose Costa Teixeira (Oct 20 2018 at 11:28):
OK, but what does "authorization" really mean? I'm still trying to correlate this to V2, e.g. the OMP is the initial "Pharm Order Placement", I suppose it's a request of intent with an implicit authorization. The RDE reflects when the Pharmacy encodes the order knowing about what specific drugs are available in their pharmacy (and also maybe knowing about patient condition and allergies). If I were implementing a V2-based MAR these are the messages that I would use and I wouldn't care about 'authorization';
OMP and RDE act as requests. They express a request or demand or suggestion or whatever (in other words, authorization).
Jose Costa Teixeira (Oct 20 2018 at 11:36):
it's implicit in the fact that these messages are sent to me (my system) and I would present these orders to the user as "the current truth" -- if the order is active (ORC-1 is something other than DC or CA) the expectation is that the medication should be administered according to the instructions of the order. ```
who is "my system"? If the messages above are orders, the only thing you know is that they are ordered. If they are "cancelled", you know that the requester has abandoned the request. But you don't know if this has been acted upon. In IHE HMW you see that there is an order response (e.g. ORP) that confirms whether the order has been accepted or not.
In other words, the order alone does dictate the state of the workflow. The order plus the responses do that. and since we don't have a "requestResponse" resource, task contains that information.
Jose Costa Teixeira (Oct 20 2018 at 11:43):
From my perspective the MedicationRequst is similar to the OMP/RDE and its state (or status) is what I need to present to the clinician as the "current truth" not some notion of 'authorized or not'. (I guess the way I'm looking at it is that the systems involved before I see the messages are already handling the Task workflow state transitions and to me, the MedicationRequst represents the "current state")
Possible and common cause of the issue: "State of the prescription" is a language shortcut but does not really exist.
What exists is "state of the workflow that is started with the prescription". which is handled in Task. The state of the request only has what the requester controls.
MedicationRequest represents the current state of the request, not the current state of whatever was done from that request.
Think of "I just pressed the button to cancel the order of this expensive customized device (meanwhile the purchase order has been sent to the manufacturer and the invoice is already sent and paid, but the patient does not have it yet" - what is the status? for the patient it is as good as cancelled, but for the billing dept it is not really cancelled.
Lloyd McKenzie (Oct 20 2018 at 12:48):
MeditationRequest corresponds to the original order, the encoded order and the MAR entry. Each would be a separate instance, differentiated by the 'intent' element and linked together with basedOn.
If you ask a lab to execute an order and they say "no", that doesn't change the state of the order. Nor does someone saying yes and then changing their mind. You keep shopping around the order until you find someone who executes it.
Every time you say "Can you please fill order x?", that's a new task - but it's still the same order.
When you say "state of the order" that might encompass the state of the authorization as well as every fulfillment request, every dispense, etc.
John Silva (Oct 22 2018 at 09:55):
@Jose Costa Teixeira - but I believe there ARE codes in OMP/RDE messages that directly from the Filler back to the Placer that it has accepted responsibility for the order. Of course an order can be canceled or discontinued at anytime after the Placer and FIller have made this agreement, but that doesn't mean that, once accepted by the filler the order is just a 'friendly agreement". (and, of course, that doesn't mean the meds have been given yet, that's what the RAS/MedAdmin is for.) [I've got to find that state diagram that someone did years ago that describes the V2 Medication workflow -- maybe that will help me understand the subtleties.] Again, my goal is to present the order "state" to the clinician (doctor/pharmacist/nurse) of an order. The fact that it goes from "I'd like you to do this to yes, that's an imperative order" is a distinction I don't need to make since I'm not intending this for the CPOE but rather as an end-user's view of what are the active (or canceled/DC'd) orders for the patient. (For example, the 'NW' and it's companion 'OK' are sort-of the "please accept this order" and "OK, I take responsibility for this order" or 'DC' and "DR" (D/C as requested) is the ACK from the FIller that I understand and will take responsibility for D/C'ing the order (not give any more drugs for this order but of course I can't undo drugs already given!)
Jose Costa Teixeira (Oct 22 2018 at 13:27):
Yes, there are those codes. Which pretty much make OMP and derivatives almost a "document-based" workflow management where both parties update the progress of the workflow by updating the token they have available.
This leading to things like "status of prescription" and "pharmacy updating the order" which create a few headaches.
Lloyd McKenzie (Oct 22 2018 at 15:28):
If you're communicating a request to fulfill and an agreement to fulfill in FHIR, that maps to Task, never the Request resource. A Request isn't impacted by someone refusing or agreeing to fullfill the order.
Last updated: Apr 12 2022 at 19:14 UTC
