Stream: Medication
Topic: Tracking a MedicationDispense
John Moehrke (Aug 03 2018 at 15:43):
I have a use-case where the MedicationDispense is done by a remote dispensing department. The delivery is done via a courier such as UPS/FedEx/DHL/ etc... I don't see a logical place to put a tracking number in MedicationDispense, and don't see an extension. Is this a common enough need to call for an extension? (I am not looking to urgently get it in before ballot, just asking).
Melva Peters (Aug 03 2018 at 16:31):
We have destination and receiver, but neither of these would typically include this level of detail. I don't believe we've had this use case before so if you can add a tracker, Pharmacy will consider
John Moehrke (Aug 03 2018 at 17:01):
done GF#17619
Brian Rickabaugh (Mar 10 2020 at 18:16):
Was this ticket completed and the concept incorporated into the spec.?
We have a use-case to add logistics tracking information to a MedicationDispense resource. I'd like to be able to add things like: Tracking ID, Carrier and URL to tracking information.
Melva Peters (Mar 10 2020 at 18:32):
No change was made to the specification based on this tracker. The suggestion was that you use an extension to MedicationDispense to meet your requirements. You can check the status in JIRA: https://jira.hl7.org/browse/FHIR-17619
Jose Costa Teixeira (Mar 10 2020 at 21:45):
@Brian Rickabaugh You can use a (contained) SupplyDelivery - the tracking number is the SupplyDelivery.identifier
Brian Rickabaugh (Mar 10 2020 at 22:32):
I don't personally view a medication that has been dispensed through mail order delivery to have a different color or shape than a standard MedicationDispense resource. In my opinion, handing the prescription across a POS counter vs. someone's doorstep does not fundamentally alter its character enough to warrant narrowing its existance into a sub-class.
Given the present and growing footprint for delivery of prescriptions through various carriers, I would offer for consideration adding these fields to the base MedicationDispense resource:
A.) Add "delivered" to status.
B.) Add "trackingInformation", which includes a tracking id, carrier code/name and deep tracking URL.
C.) Add "whenDelivered".
You could wrap all of this in a shippingInformation container similar to supportingInformation.
Would referencing a SupplyDelivery resource on the supportingInformation field make sense?
Jose Costa Teixeira (Mar 10 2020 at 22:43):
Dispense= the act/moment when a product is assigned to a patient. everything after or before that can still be part of the dispensation process but is just transport.
If that definition makes sense to you, then MedicationDispense has the core attributes, and other things would be extensions or other resources.
Jose Costa Teixeira (Mar 10 2020 at 22:44):
adding something like "whenDelivered" - what do you mean if it has been handed over by the central pharmacy to the transport to the satellite pharmacy to the nurse to the patient? Which delivered?
Lloyd McKenzie (Mar 10 2020 at 22:44):
Right. SupplyDelivery is non-patient-specific.
Brian Rickabaugh (Mar 11 2020 at 16:36):
Jose Costa Teixeira said:
Dispense= the act/moment when a product is assigned to a patient.
@Jose Costa Teixeira - I am interested in understanding your definition of what assigned means in this context?
Jose Costa Teixeira (Mar 11 2020 at 16:43):
something was inventory and is now assigned to a patient.
a few cases of dispense:
- when a nurse puts ward stock items in a patient's bedside table or in a patient's tray
- when the pharmacy prepares the patients' medication
Jose Costa Teixeira (Mar 11 2020 at 16:44):
some cases of not dispense:
- when central pharmacy distributes stock to wards
- when a nurse puts the medication that has a patient's label to the patient's tray
Jose Costa Teixeira (Mar 11 2020 at 16:45):
this definition came after several discussions and it was a wise colleague from the UK - it was beautful how this notion simplified so many workflows and so many concerns
Jose Costa Teixeira (Mar 11 2020 at 16:45):
BTW, this is the definition in ISO 19293
Brian Rickabaugh (Mar 11 2020 at 17:03):
Jose Costa Teixeira said:
- when a nurse puts ward stock items in a patient's bedside table or in a patient's tray
- when the pharmacy prepares the patients' medication
I agree with your first bullet. That is a complete (full life-cycle) dispense event. The medication was prepared and distribution of that medication was completed. I do not agree that the second bullet represents a completed dispense event.
Here is Webster's definition of dispense. The third definition being apropos.
https://www.merriam-webster.com/dictionary/dispense
The definition is prepare and distribute. Preparation alone does not satisfy the definition.
A MedicationDispense resource that is "ready for pickup" is in an in-progress state. Once the medication is picked up it moves to completed.
For my use case (mail order delivery of medications) what state is a MedicationDispense resource in when it has left the dispensing facility and is in transit to the destination?
Should I use "completed" when I have a delivery receipt from the carrier?
Melva Peters (Mar 11 2020 at 17:22):
@Brian Rickabaugh I would agree that the status when you have that delivery receipt is "completed" the same as if it was handed to the patient or care giver.
Jose Costa Teixeira (Mar 11 2020 at 17:23):
As I mentioned, we needed to isolate the event of assigning a medication to a patient. Our colleague said this was it.
Jose Costa Teixeira (Mar 11 2020 at 17:26):
There are many variable, inconsistent definitions of dispense.
If you take transport into consideration, you will end up with operational challenges, because what is "complete" in one person's view is not "complete" in another , or depending on whether there is a transport in between.
For example in France there was a standard that actually had 2 types of messages for each mode of distribution.
And the words there got fancy. Dispense, dispensing, dispensation, distribution...
Jose Costa Teixeira (Mar 11 2020 at 17:26):
This is why I mentioned "if this definition makes sense to you" - to me, it reduced the number of different interfaces from 14 to 6 or so.
Jose Costa Teixeira (Mar 11 2020 at 17:27):
you can make simplifications, but simplifications of workflow always bite us back.
Jose Costa Teixeira (Mar 11 2020 at 17:32):
Brian Rickabaugh said:
Should I use "completed" when I have a delivery receipt from the carrier?
Completed as in Dispense.status? My perspective: you should not.
"should not" as RFC 2119 : you may still do it if you understand what the impact is and are OK with the consequences of that simplification. Do you consider things may get damaged in transport? Do you consider only one transport action? ...
Jose Costa Teixeira (Mar 11 2020 at 17:34):
I don't expect Merriam Webster is an authoritative source in detailed technical matters.
Jose Costa Teixeira (Mar 11 2020 at 17:36):
there are several definitions, some of them with different legal status.
I don't think MW goes through that rabbit hole.
Jose Costa Teixeira (Mar 11 2020 at 17:36):
but if you need a definition:
http://www.skmtglossary.org/GenericSearch.aspx
Jose Costa Teixeira (Mar 11 2020 at 17:36):
I like that one :)
Brian Rickabaugh (Mar 11 2020 at 18:02):
Jose Costa Teixeira said:
Do you consider things may get damaged in transport? Do you consider only one transport action? ...
I share your sentiment and concerns around how to express and accurately assign the state of a medication that is being dispensed through the mail, without diluting it to the least common denominator (simplification) so as to make it less meaningful or open to misuse/abuse.
I definitely don't want to use "unknown".
Lloyd McKenzie (Mar 11 2020 at 18:16):
A dispense is not complete until the medication is (or is assumed to be based on the level of knowledge the workflow permits) to be in the patient's hands (or in the hands of whomever is responsible for administration). If medication is issued/allocated but is returned to stock/destroyed before it gets to the patient/nurse/whomever, then it shouldn't be marked as 'complete'. Now, of course in the real world, all sorts of things can happen, but the intention of the MedicationDispense resource is that it represents the full action from a request to issue medication to that medication being received (including evaluating/clarifying the order, checking the order appropriateness including drug interaction checking, prepping the label, counting the med, packaging the med, doing insurance claims processing, holding the med for pick-up, counselling the patient/care-giver on use, and actually transferring custody of the medication.
Jose Costa Teixeira (Mar 11 2020 at 18:33):
Lloyd McKenzie said:
A dispense is not complete until the medication is (or is assumed to be based on the level of knowledge the workflow permits) to be in the patient's hands (or in the hands of whomever is responsible for administration).
In some jurisdictions, perhaps. Not in all. In some places that sentence is true but changing dispensing by "delivery" (or something similar)
Jose Costa Teixeira (Mar 11 2020 at 18:34):
In some cases, a central pharmacy has the job to pack medication for patients, and they've done their job regardless of what happens next.
Jose Costa Teixeira (Mar 11 2020 at 18:35):
The same for "evaluating, clarifying the order" - that is not a linear process. We tried assuming it is, but at some point it got too funny.
Brian Rickabaugh (Mar 11 2020 at 18:36):
Lloyd McKenzie said:
Then, I think a delivery receipt from the carrier is the best available evidence for "complete" in a mail-order context...
...medication is (or is assumed to be based on the level of knowledge the workflow permits) to be in the patient's hands (or in the hands of whomever is responsible for administration).
Of course, if the prescription was dropped on the wrong front porch (or stolen by the neighbor), all bets are off; but, I currently have no way to prove that. In an ideal world, I will implement capabilities to allow the patient to acknowledge receipt.
I really wonder how other mail-order pharmacies are constructing these resources.
Jose Costa Teixeira (Mar 11 2020 at 18:39):
I'm not saying the process is always complicated. I'm saying that if you can guarantee that in real life it is simple, please simplify. But really make sure that the 20% do not force you to rework the 80% or add 4 times more interfaces.
Brian Rickabaugh (Mar 11 2020 at 19:06):
Thanks, Jose and Lloyd. I think that makes sense and really appreciate your input.
Brian Rickabaugh (Mar 11 2020 at 20:12):
I haven't quite resolved or have clarity on the suggestions RE tracking information. I think SupplyDelivery has some potential.
Brian Rickabaugh said:
Would referencing a SupplyDelivery resource on the supportingInformation field make sense?
Any thoughts on this question?
Michelle (Moseman) Miller (Apr 05 2021 at 21:32):
@John Moehrke @Brian Rickabaugh Did you end up with an extension? If so, would you mind sharing? Speaking as a vendor, we have some similar use cases needing carrier and tracking number. I question whether we need that extension elevated to be a common HL7 extension....
CC: @Melva Peters
John Moehrke (Apr 05 2021 at 21:36):
wow, that was so long ago that my CR went into gforge... I have no idea where that went in jira... I never further developed the project I had started. So I have no idea what happed
Jose Costa Teixeira (Apr 06 2021 at 05:42):
There is an initiative to add a Transport resource. That might help.
Michelle (Moseman) Miller (Apr 06 2021 at 15:33):
@Jose Costa Teixeira I found https://confluence.hl7.org/display/FHIR/Transport+Resource+Proposal -- do you happen to know the current status? Has this been approved yet? Is the google doc the best place to view the drafted resource?
Jose Costa Teixeira (Apr 06 2021 at 15:34):
that would be @Brian Postlethwaite I guess?
Brian Postlethwaite (Apr 06 2021 at 22:21):
I think that current work is being profiled on Task from memory, I'll have to go look which group was going the work on it. It will be in the PA Jan WGM meeting minutes.
Lloyd McKenzie (Apr 06 2021 at 22:26):
I would expect you'd need an explicit resource to represent the authorization for transfer - Task won't cover that. My leaning would be to have an explicit resource for the event too - using Task and capturing source and destination as Task.inputs seems kind of clunky...
Jose Costa Teixeira (Apr 06 2021 at 22:43):
IIRC, the discussion ended up in the event resource (i.e. the Transport) having a higher priority over the request (TransportRequest)
Jose Costa Teixeira (Apr 06 2021 at 22:43):
@Hans Buitendijk ?
Mona O (Jul 10 2021 at 13:43):
@Brian Rickabaugh, @Michelle (Moseman) Miller , Did you ever resolve and implement tracking information? If so, would you mind sharing your approach?
Brian Rickabaugh said:
I haven't quite resolved or have clarity on the suggestions RE tracking information. I think SupplyDelivery has some potential.
Brian Rickabaugh said:Would referencing a SupplyDelivery resource on the supportingInformation field make sense?
Any thoughts on this question?
Kevin Mayfield (Jul 12 2021 at 04:12):
Just doing early analysis on this. Our use case is similar, just looking at the patient notifications though - text and references.
I favour referencing the fulfilment ie medicationDispense at present.
Kevin Mayfield (Jul 12 2021 at 04:15):
Probably using CommunicationRequest.
Kevin Mayfield (Jul 12 2021 at 04:17):
Seems logical to add tracking Identifier to MedicationDispense
Lloyd McKenzie (Jul 12 2021 at 04:22):
Why CommunicationRequest?
Kevin Mayfield (Jul 12 2021 at 04:29):
Use case I've been reviewing is purely notifications plus we should have registry and repo with more detailed information.
Kevin Mayfield (Jul 12 2021 at 04:37):
Think that gives us the option of drilling down into delivery details but the tracking events to patient and prescriber will be lightweight plus some 'full fat' events to prescriber.
Kevin Mayfield (Jul 12 2021 at 04:38):
Focused on MedicationDispense
Lloyd McKenzie (Jul 12 2021 at 04:39):
Wouldn't a pure notification just mean sending the MedicationDispense resource or perhaps wrapping it in Communication. Why CommunicationRequest?
Kevin Mayfield (Jul 12 2021 at 04:45):
Don't believe the main actors need that much detail. The notification has enough information to allow retrieval of the current MedicationDispense if required.
Example messages: your medication X has been dispatched,
Your medication is 8 stops away
Patient A medication Y has been cancelled
Kevin Mayfield (Jul 12 2021 at 04:48):
Centrally we don't need detailed information either, just to be updated on when Prepared, when delivered, when handed over, etc triggers (on MedicationDispense)
Lloyd McKenzie (Jul 12 2021 at 05:22):
Ok, but those would still be Communication, not CommunicationRequest. CommunicationRequest would be "Please share information that you have with someone else"
Kevin Mayfield (Jul 12 2021 at 05:32):
I'm finding the distinction between those a bit confusing.
From intoper point of view we are requesting a communication is sent. The result of that is a Communication?
Kevin Mayfield (Jul 12 2021 at 05:41):
Is the distinction one is a consequence and the other is a notification?
Lloyd McKenzie (Jul 12 2021 at 15:17):
Request resources are always "authorizations" for something to happen. To drive workflow, you need Task or operation or tag or something else to drive behavior. CommunicationRequest is for things like "Please share DiagnosticReport 123 with Practitioner ABC".
Michelle (Moseman) Miller (Jul 14 2021 at 02:30):
@Mona O We haven't implemented MedDispense via FHIR yet, but within internal informational models, we treated the carrier and tracking number as MedDispense attributes.
Last updated: Apr 12 2022 at 19:14 UTC
