Stream: implementers
Topic: Howto link MedicationAdministration to MedicationDispense?
Oliver Egger (Jul 04 2018 at 12:05):
The medication sequence is defined as prescribe->dispense->administer, however I see no possible reference between MedicationAdministration and MedicationDispense in the resource (only indirect with Reference(MedicationRequest). I would like to directly associate the Administration with a Dispense. The Mobile Medication Administration (MMA) #IHE FHIR profiles describes
If the administration has a documented reason or related information besides an explicit prescription or request, for example is consequence of an implicit order that comes a dispense or is related to a condition that justifies the use of a medication, then MedicationRequest.supportingInformation shall be filled in with that information.
is this the recommended solution or is there an easier solution?
Lloyd McKenzie (Jul 04 2018 at 13:25):
That's not really what supportingInformation was intended for. (That's more for things like the height and weight used to calculate dose or the current blood pressure value if dosage was conditional on that, etc.) Given that in pharmacy, a dispense includes a more refined order, I can see that being tracked in some cases. As I look at the model, there's also no mechanism to point to a service request or care plan as the driver for the administration either. Sounds like something to submit a change request for. At minimum, it would make sense for there to be a standard extension for this.
Jose Costa Teixeira (Jul 04 2018 at 15:41):
In IHE we wanted to avoid linking administrations to dispenses unless there was no explicit order to trace it from. But we did not find anything better.
@Lloyd McKenzie what kind of extension? something like "priorActivity"? or something else (just asking for a kind of a name to point the request in the right direction)
Jose Costa Teixeira (Jul 04 2018 at 15:42):
BTW, ReasonReference could be stretched for this but it is a long stretch.
Lloyd McKenzie (Jul 04 2018 at 15:47):
I think of it as additional "basedOn" repetitions. The extension would let you convey additional repetitions (e.g. if you want to point to a cascade of orders, point to the care plan, point to the dispense, etc.)
Jose Costa Teixeira (Jul 04 2018 at 16:04):
slicing? you don't know how many slices you will end up with - wouldn't this make slicing complicated?
Lloyd McKenzie (Jul 04 2018 at 16:16):
Not following the slicing question
Jose Costa Teixeira (Jul 04 2018 at 16:21):
i amassuming that you mean having basedOn on medicationAdministration.
Jose Costa Teixeira (Jul 04 2018 at 16:23):
for this, i understand that we would say "first occurrence of basedOn is for the Dispense, second occurrence is for the CarePlan"... is that what you imply with basedOn?
Lloyd McKenzie (Jul 04 2018 at 16:23):
Changing "request" 0..1 to "basedOn" 0..* and opening up the list of target resources would be my preference, but I can see that might not fall in the 80%. Don't see why slicing would be needed
Lloyd McKenzie (Jul 04 2018 at 16:24):
You'd just send whatever orders, dispenses, care plan, referrals, etc. were relevant
Lloyd McKenzie (Jul 04 2018 at 16:24):
If you wanted to constrain and say "there must be a MedicationRequest and it must be an order", then yes you'd need to slice.
Jose Costa Teixeira (Jul 04 2018 at 16:25):
ah ok i thought you were pointing at slicing. Adding "basedOn" would work. How does a standard extension work if it comes directly from the Event pattern? just like any other extension?
Lloyd McKenzie (Jul 04 2018 at 16:29):
Just like any other extension. In this case, the extension would be for "extra" repetitions and non MedicationRequest repetitions
Jose Costa Teixeira (Jul 04 2018 at 16:44):
ok will request that.
Jose Costa Teixeira (Jul 04 2018 at 16:44):
thanks
Oliver Egger (Jul 04 2018 at 18:29):
thanks for this discussion! to summarize: 1. an extension basedOn could be created, and request will stay as is., 2. submit a change request to change requests to basedOn as suggested by @Lloyd McKenzie . Which option @Jose Costa Teixeira will you request? I'm in favor of no 2, this would also be congruent to ihe pharmacy cda content profiles where administrations can reference requests, treatment plan items and dispense.
Lloyd McKenzie (Jul 04 2018 at 18:31):
I think we request #2 and note #1 as a fall-back if the WG decides #2 isn't in the 80%
Jose Costa Teixeira (Jul 04 2018 at 19:03):
CR for IHE is #1 . for HL7 it's request #2. IHE can do the extension whenever needed, while #2 is getting reviewed and approved.
Jose Costa Teixeira (Jul 04 2018 at 19:04):
keep in mind that in IHE on FHIR we will avoid the linking that is done in CDA profiles. We will more likely adopt Task or some sort of plan to trace things back.
Jose Costa Teixeira (Jul 04 2018 at 19:05):
i.e. we will probably not say "link this to whatever is the previous step" but rather "link this to a plan. If you want to do pharmacy workflows, have a plan. If you have a really short use case, feel free to use no plan, but the moment you expect a workflow to be managed go for a plan".
Jose Costa Teixeira (Jul 04 2018 at 19:07):
in the above, "plan" is medicationRequest, or Task... i am not sure yet, hasn't been discussed.
but I thnk we really want to reduce that part of the complexity.
Last updated: Apr 12 2022 at 19:14 UTC
