Stream: Medication
Topic: Substitution
Richard Townley-O'Neill (Aug 30 2018 at 05:02):
MedicationRequest.substitution covers substitution of one medication for another.
In Australia, in community prescribing and dispensing, substitution of one brand for another is common, but substitution of one active ingredient for another is forbidden. In hospital prescribing, substitution of one active ingredient for another is permitted.
The element MedicationRequest.substitution seems to be designed for active ingredient substitution, rather than brand substitution. It looks as if it cannot do both, e.g. cannot say "can substitute brand, but not active ingredient".
Jean Duteau (Aug 30 2018 at 05:06):
No, you could totally do that with the proper terminology. The existing value set is just an example and I've used different value sets to convey similar semantics to what you are asking for. I can't find the specific value set that I used (I've archived that material) but it was something like "All substitution allowed", "Stay in drug class", "Same Active Ingredient", "No Substitution".
Richard Townley-O'Neill (Aug 30 2018 at 05:13):
I thought about that, but the element MedicationRequest.substitution.reason seems to be about why substitution is allowed/prohibited or why it was done.
Using it to say "this is the type of substitution I'm talking about" seems like a misuse of the design.
Jean Duteau (Aug 30 2018 at 05:15):
Yeah, we should probably tighten up our language here. Because saying substitution.allowed = true with a reason of "keep within the same drug class" seems to be a common enough use case and I'm not sure we (the committee) meant to restrict that.
Jean Duteau (Aug 30 2018 at 05:18):
Tracker item raised about this.
Richard Townley-O'Neill (Aug 30 2018 at 05:32):
The general case could be complex, if there is a need to record two types of substitution, both with reasons. e.g. type_of_substitution="brand but not drug" with reasons "to allow cheaper brands" and "prohibited by regulation".
I think that I don't need two reason codes, so I'd be fine with the addition of a substitution type code element.
Richard Townley-O'Neill (Aug 30 2018 at 05:39):
Tracker #17769
Jay Lyle (Apr 29 2019 at 13:24):
In DSTU2, the MedicationDispense.substitution boolean is presumably set to True if the dispensed medication differs from the ordered medication. However, the MedicationOrder also supports substitution, allowing the pharmacist to specify a MedicationOrder.dispenseRequest.medication different from that ordered by the clinician.
1. Does DSTU2 MedicationDispense.substitution indicate a difference from MedicationOrder.medication, MedicationOrder.dispenseRequest.medication, or either?
2. Should DSTU2 MedicationOrder.substitution reflect a difference within the MedicationOrder (.medication vs .dispenseRequest)?
3. In R4, there is no MedicationRequest.dispenseRequest.medication. If the pharmacist makes a substitution prior to Dispensing, do we expect the processing entity to revise the MedicationRequest? How would such a modification be flagged?
This difficulty may result from different perspectives on the pharmacy process. We are supporting a pharmacy process where the MedicationOrder may pass through several states before resulting in a Dispense.
Jose Costa Teixeira (Apr 29 2019 at 14:39):
Dispense (and the attributes incl substitution) is about what happened i.e. if there was a substitution.
MedRequest is about what is allowed to happen. so, starting with question 3. this is not flagged. it is a new medrequest - something the pharmacist says is planned to happen
Jose Costa Teixeira (Apr 29 2019 at 14:40):
similar to v2 OMP/RXE
Jose Costa Teixeira (Apr 29 2019 at 14:41):
1 and 2. i dont understand. substitution in a request is whether product ban be substituted
Lloyd McKenzie (Apr 29 2019 at 14:55):
MedicationOrder.substitution is about whether substitution is permitted, not about whether it's happened.
Lloyd McKenzie (Apr 29 2019 at 14:55):
Reasons for changes between what's in the placer order and filler order are not reflected anywhere to my knowledge
Jay Lyle (Apr 29 2019 at 14:57):
Thanks, Jose. Check my understanding:
For R4, if the pharmacist tweaks the request, it's a new request. It may have the same native identifier, but the FHIR resource identifier is different; it's not just a version.
That seems self-consistent, though it will make our design more complicated.
Re questions 1 & 2: DSTU2 MedicationOrder supports two medications: the root medication (which we are thinking is what the clincian said) and the dispenseRequest.medication, which is what we are thinking is how the Pharmacist interprets it. But before dispense.
Lloyd McKenzie (Apr 29 2019 at 15:07):
The dispenseRequest.medication has nothing to do with how the pharmacist interprets it. It reflects the fact that you might order a product that comes packaged a particular way - e.g. with a device - and want to specify the code for that - but when you talk about administering you point to the specific drug, not the "package" to be dispensed.
Jay Lyle (Apr 29 2019 at 15:46):
That's very interesting. so, which is which? and why was it removed in R4?
Lloyd McKenzie (Apr 29 2019 at 15:50):
@Melva Peters might be able to comment on reason for removal - my guess is that it was an 80% call. The one on dispense was what was being authorized to be supplied, the higher level one was what was to be administered.
Jean Duteau (Apr 29 2019 at 15:50):
It was removed much earlier in STU3 v1.6. The Pharmacy WG would have to search hard to find out why, but I suspect we had feedback from implementers that they didn't handle this.
Melva Peters (Apr 29 2019 at 23:55):
The MedicationRequest.dispenseRequest.medication was removed as part of tracker 8476. It didn't make sense to have two medication attributes so Pharmacy decided to remove the medication in the DispenseRequest attribute. There is another tracker item 10406 from Lloyd that also points this out.
Jay Lyle (May 02 2019 at 17:33):
Thanks. So the request identifies the clinically indicated substance (possibly a product but not preferably, contrary to DSTU2); and the product selection shows up in Dispense, right? In DSTU2 way may opt to ignore the dispenseRequest.medication to better align for migration to R4.
Jose Costa Teixeira (May 04 2019 at 08:03):
more like (IMO)
clinically indicated substance goes into a request.
if there is a step to define what medication is to be dispensed, it goes into another medRequest (in v2 this is the RXE)
then the medication actually dispensed is in the medDispense
This is similar but better than V2 approach where you would have OMP and RXE, but the boundary between OMP and RXE was not clear in implementations. Now it is easy: as long as you are stating an intent, you use a request.
Jose Costa Teixeira (May 04 2019 at 08:03):
I would indeed ignore MedicationRequest.DispenseRequest
Jay Lyle (May 04 2019 at 12:46):
Many thanks Jose; I think that's where we're headed but good to hear stated clearly.
Last updated: Apr 12 2022 at 19:14 UTC
