Stream: implementers
Topic: MedicationRequest.intent when processing HL7 v2.x RAS
Diederik Muylwyk (Mar 25 2019 at 14:59):
Hello.
I'm working on an HL7 v2.x translation to FHIR STU3/R4.
Question 1:
Can someone elaborate on the difference between http://hl7.org/fhir/medication-request-intent|order and http://hl7.org/fhir/medication-request-intent|instance-order? An example or use-case would be appreciated.
Question 2:
When processing RDE (Pharmacy/treatment encoded order message), I populate the resulting MedicationRequest.intent with http://hl7.org/fhir/medication-request-intent|order.
When processing RAS (Pharmacy/treatment administration message), the message includes an RXE segment that refers to the order. Presently, I use a conditional create for MedicationRequest resources resulting from such RAS processing. In the case where an RAS message results in a new MedicationRequest, should I populate MedicationRequest.intent with http://hl7.org/fhir/medication-request-intent|instance-order?
When an RDE message for such an order is processed later, the MedicationRequest would be updated with http://hl7.org/fhir/medication-request-intent|order. (Due to the source systems, mutli-threading, etc., RDE messages may be processed before associated RAS messages.
Thanks!
References:
- https://www.hl7.org/fhir/STU3/medicationrequest-definitions.html#MedicationRequest.intent
- https://www.hl7.org/fhir/STU3/valueset-medication-request-intent.html
- https://www.hl7.org/fhir/medicationrequest-definitions.html#MedicationRequest.intent
- https://www.hl7.org/fhir/valueset-medicationrequest-intent.html
Edit: Accidentally identified the value sets instead of the code systems (fixed). Note that these are the STU3 code systems, not R4.
Lloyd McKenzie (Mar 25 2019 at 15:04):
1. instance-order is similar to a MAR entry - a separate order for every single planned administration.
2. RXE would ideally use filler-order, as it represents the pharmacy's encoding of the order.
Diederik Muylwyk (Mar 25 2019 at 15:12):
Hi, @Lloyd McKenzie. Thanks for the quick reply.
1. Understood. Seems like I don't need to use instance-order at all.
2. For STU3, I'll have to use http://hl7.org/fhir/medication-request-intent|order. For R4+, I should use http://hl7.org/fhir/CodeSystem/medicationrequest-intent|filler-order. Is that correct?
(I accidentally identified the value sets instead of the code systems in my original question.)
Diederik Muylwyk (Mar 25 2019 at 15:22):
Whoops, that took a moment to sink in so actually...
I think http://hl7.org/fhir/medication-request-intent|instance-order would be appropriate for a MedicationRequest conditionally created from an RAS message. If/when an RDE associated with that RAS is processed, the intent would be updated to http://hl7.org/fhir/medication-request-intent|order (or http://hl7.org/fhir/CodeSystem/medicationrequest-intent|filler-order in R4).
If an associated RDE is never received, an intent of http://hl7.org/fhir/medication-request-intent|instance-order is correct and appropriate.
Thanks again, @Lloyd McKenzie.
Lloyd McKenzie (Mar 25 2019 at 15:56):
Agree that instance-order is appropriate for RAS.
Diederik Muylwyk (Mar 25 2019 at 17:35):
Am I expected to close a topic somehow once it has been answered/resolved?
Lloyd McKenzie (Mar 25 2019 at 17:39):
nope
Diederik Muylwyk (Mar 25 2019 at 17:44):
Okidoke. Thanks!
John Silva (Mar 25 2019 at 18:26):
In HL7 V2 RDE (Pharm Encoded Order) I don't see each planned admin as a 'separate order' but rather fulfillments of the order. For example, if the order is Acetaminophen TID for 2 days, that's the 1 order with 6 planned Med admins. Of course each of the admins would be a separate RAS (Pharm Admin) but admins are not orders. Then there's also the V2 RGV^O15 where you could give 'give-id/sub-id identifiers' to each of the planned admins from the order, but again, those are not 'new orders' or 'instance orders' they are just unique pre-assigned identifiers for the planned admins that can then later be associated back when the RAS (actual admins) are performed. I think the use case for this workflow is when the MAR needs to track each planned med and associate it with a specific med identifer, e.g. a barcode label.
That said, I'm not sure how you would map all of this workflow into FHIR MedicationRequest and MedicaitonAdmins.
Lloyd McKenzie (Mar 25 2019 at 20:35):
RXO = original order; RXE = filler order; RXG = instance order
John Silva (Mar 25 2019 at 21:46):
@Lloyd McKenzie that's not what I've seen them called. RXO/RXE/RXG are the segment names that are part of specific messages. RXO is part of an OMP^R09 Pharmacy Order message (usually 'unencoded' like what comes from the ordering dr.), the RXE is part of the RDE^O11 Pharmacy Encoded Order message (but this could go to Pharmacy or to CPOE or to other 'listeners' not necessarily 'fillers' of the order) and the RXG is part of RGV^O15 Pharmacy Give message; this is NOT an order but a way to communicate planned adminstration 'give-ids' and 'sub-ids' so they can be linked back together with the actual RAS messages (admins) that get sent later after clinician actually administers the drug (or not -- there is a not given field). I've never heard of RXG as an 'instance order'
Lloyd McKenzie (Mar 25 2019 at 22:08):
It doesn't matter what they're typically called, that's what they map to in terms of FHIR intents. RXO is the original order from the prescriber. RXE is the pharmacy-encoded order and covers the same timing period as the RXO (and thus corresponds to filler-order). RXG represents the instruction to administer a single dose - and thus corresponds to 'instance-order'.
John Silva (Mar 26 2019 at 10:19):
OK, that makes sense but the names DO matter -- since folks coming from the V2 world will know the V2 names and that is our reference point. It would be nice to see some mapping of the V2 'medication workflow model' into FHIR resources; is work being done along these lines? I know I had asked before and at the time you had told me that FHIR Med-resources are not really 'equipped' to effectively handle the Med workflow model. I think you mentioned that the Task resource should be used. It would be great if there was a 'reference model' for how Med workflow can be described in FHIR for those coming from the V2 event-driven (workflow) Med paradigm. (In the 'mean time' I've been using properties of the Med resources to 'hack' this. Similarly for the ADT workflow. It's good to know the IHE folks are working on mapping the ADT workflow to FHIR, that will be very helpful.)
Lloyd McKenzie (Mar 26 2019 at 14:49):
The #v2 to FHIR track is working on mappings, though I think it'll take them a bit before they get to meds.
The names are intended to maximize recognition/understanding with both new to HL7 implementers as well as existing HL7 implementers (whether v2, v3, CDA or something else). They also need to be independent of domain, so the terms can't generally be pharmacy-specific or lab-specific, etc.
Craig Newman (Mar 26 2019 at 15:21):
The v2-to-FHIR project hasn't started medication mappings, but if someone wants to send me the mappings they've developed, I'm happy to document them for future discussion. This will advance things more quickly.
John Silva (Mar 26 2019 at 17:35):
@Craig Newman -- I can probably send you some of the V2 mappings I have. Also, I have created GForge tracker items for Pharmacy about adding the V2 'suggested mappings' for the Dosage datatype, which they've done (though there are typos and inconsistencies in it) GF#17354, another about how to represent Therapeutic categories (GF# 17411) and that was closed since it's done in MedicationKnowledge (which is only maturity level 0, I had asked for this in MedicationRequests since we need to know about Therapeutic category at ordering time since a particular order might have an order-specific therapeutic use that isn't the same as the generalized category for the drug) and today one about adding the V2 0335 'C' value to the Timing Abbreviations ValueSet GF# 20609.
John Silva (Mar 26 2019 at 17:36):
@Craig Newman -- btw, I think the Rhapsody interface engine (not to advertise specific products but just as an example) comes with a set of 'pre-wired' V2 to FHIR mappings for med resources but I'm not positive about that.
Lloyd McKenzie (Mar 26 2019 at 17:59):
MedicationRequest has 'category' which can differentiate therapeutic category at the time of ordering (you can have multiple categories, so you can differentiate along whatever axis you like)
Melva Peters (Mar 26 2019 at 18:08):
There are some V2 mappings in the pharmacy resources already. We'd be happy to add additional ones.
John Silva (Mar 26 2019 at 18:20):
Yes, category cardinality was changed to 0..* in R4, when I posted the GF item this wasn't the case. (I think it was a result of me asking the question that it was changed --- or at least I'd like to think so :-) )
@Melva Peters I had posted a follow-up comment on GF 17354 about some typos and additional clarifications. For other V2 mappings, I'd have to get back to you; that GF item was only for Dosage datatype.
Jose Costa Teixeira (Mar 26 2019 at 20:41):
It would be nice to see some mapping of the V2 'medication workflow model' into FHIR resources; is work being done along these lines? I know I had asked before and at the time you had told me that FHIR Med-resources are not really 'equipped' to effectively handle the Med workflow model. I think you mentioned that the Task resource should be used. It would be great if there was a 'reference model' for how Med workflow can be described in FHIR for those coming from the V2 event-driven (workflow) Med paradigm.
@John Silva Yes, work is being done
Jose Costa Teixeira (Mar 26 2019 at 20:43):
the same model used in IHE HMW will be mapped (with a few extras) to FHIR.
John Silva (Mar 26 2019 at 20:48):
@Jose Costa Teixeira -- I think you pointed me to this IHE HMW before; I wasn't sure that the work has started on this; that's great!
Jose Costa Teixeira (Mar 26 2019 at 21:34):
the IHE HMW model is this
Jose Costa Teixeira (Mar 26 2019 at 21:34):
Jose Costa Teixeira (Mar 26 2019 at 21:34):
[FHIR resources in brackets]
Jose Costa Teixeira (Mar 26 2019 at 21:36):
the diagram is based on the messaging paradigm that was "requested" at the time, but we observed a long time ago that we needed not point-to-point, but a broadcast approach
Jose Costa Teixeira (Mar 26 2019 at 21:36):
enter FHIR
John Silva (Mar 26 2019 at 21:55):
Yes, there are many 'participants' (systems) in the Med Workflow; a pub/sub mechanism seems more appropriate than a event/point-to-point approach
Diederik Muylwyk (Apr 03 2019 at 18:53):
Hiya. My initial questions here were answered (thanks). I have new questions about mapping RDE_O11 to MedicationRequest and Medication resource over in #v2 to FHIR right here. Any input there would be greatly appreciated.
sean zitello (Jul 12 2019 at 18:52):
-- moved to Reply to prior comment
sean zitello (Jul 12 2019 at 18:55):
Craig Newman -- btw, I think the Rhapsody interface engine (not to advertise specific products but just as an example) comes with a set of 'pre-wired' V2 to FHIR mappings for med resources but I'm not positive about that.
I am sorry to say (I work for Rhapsody) that it does not currently come with any pre-wired V2 to FHIR mappings. However, it's not a very big lift to get there with say JavaScript or FreeMarker or Mapper (XML only) "filters" that are part of the application. I personally prefer the JavaScript JSON approach but I've seen all three used effectively.
David Hay (Jul 12 2019 at 19:41):
And it'll be interesting to see if there is a demand for transformations using the mapping language...
Last updated: Apr 12 2022 at 19:14 UTC
