Stream: implementers
Topic: Medication related devices
Björn Genfors (Jun 05 2019 at 14:17):
If you are to use the MedicationRequest resource to communicate about a request for a medication related device (let’s say an inhalation spacer for young kids), how would you identify which device that is? It seems to me there is no obvious place for it in the MedicationRequest resource. I have searched the chat and in part the Gforge tracker, but found no answer.
Also, I’m aware that the gray area between using DeviceRequest and MedicationRequest for medication related devices is intentional (https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=8944), but are there any guidelines regarding when to use which resource (apart from implanted devices), or is that simply up to each and every implementation?
Lloyd McKenzie (Jun 05 2019 at 15:05):
@Melva Peters @Jean Duteau
Jose Costa Teixeira (Jun 05 2019 at 15:29):
With IDMP in place, for some meds, the medication code could be specific enough to indicate that there is a device attached to it and which device that is. I am betting the same will happen from the device side - some devices will have a drug identified as part of its definition. As such, it would be part of the definitional resources - medicationKnowledge or DeviceDefinition.
That gray area is fluid, we cannot assert what is a med or device. So it is up to implementers.
Jose Costa Teixeira (Jun 05 2019 at 15:31):
We are working on making the meds and devices functionally compatible so that at least the implementers don't have different architectures for devices and meds. @Hans Buitendijk an interesting case for HealthcareProduct discussions: ordering a mix (med+Device) can be done either as a Device that includes a med, or a med that is in a device.
Richard Townley-O'Neill (Jun 05 2019 at 23:45):
How are medicated bandages and stents modelled?
Jose Costa Teixeira (Jun 06 2019 at 07:44):
Gray area. some of these may be considered medications or devices, and that is an administrative decision, not a clinical decision
Björn Genfors (Jun 06 2019 at 21:03):
Thanks for all the input. Maybe I made my quite specific question a little too unclear mentioning the gray area. Let's think of the following scenario. A child with infection induced asthma has all the meds needed, but it needs an extra inhalation spacer to be stored at it's daycare facility - just in case. This is prescribed by the pediatrician, to be picked up at a pharmacy (this is pretty much how things work in Sweden). This prescription contains an inhalation spacer, and an inhalation spacer alone. No meds. Where in the MedicationRequest resource do I put the code (or reference to) identifying the type of spacer that is prescribed?
Björn Genfors (Jun 19 2019 at 12:50):
@Jose Costa Teixeira you seem to have thought a great deal about these types of issues. Do you possibly have any ideas regarding identification of pure medication devices in MedicationRequest? Or do you know anyone else that might know even more than you do?
Jose Costa Teixeira (Jun 19 2019 at 13:00):
Hi @Björn Genfors I know a lot of people know more than I do from different sides :) I am pushing for making devices/meds/... work better together. And I think your use case is a very good one for that purpose - If I understand correctly, you want to order just the device-part of the product, as part of enabling a treatment
Jose Costa Teixeira (Jun 19 2019 at 13:00):
Kudos for the bonus part: it is not to be replacing the one that the patient has, it is only to be supplied, just in case.
Jose Costa Teixeira (Jun 19 2019 at 13:02):
My first reaction to this would be to use a deviceRequest, not a medRequest. Would that fit your tech/legal framework?
Björn Genfors (Jun 19 2019 at 13:23):
@Jose Costa Teixeira Thanks for sharing your thoughts. Yes, in this scenario I'm talking about a device only. As I see it, we're addressing two different problems
1. The general semantic problem: the MedicationRequest is described as being able to carry information about "medication related devices". What exactly these are (devices attached to medications (a syringe)? Devices needed for administration (an inhalation spacer)? Devices used in temporal proximity to administering a drug (a glucose meter)?) is up to some interpretation. If interpreted differently in different contexts, overall semantic interoperability is limited.
2. This particular problem: Either we use MedicationRequest for transfer of the device prescription, and in that case it's unclear how to identify what device is prescribed. Or we use DeviceRequest (for which there's no legal or technical hindrance). What resource should we then use to communicate information about the dispensing of that device (for which there is a need)? There's no DeviceDispense as far as I can see.
Jose Costa Teixeira (Jun 19 2019 at 13:26):
Excellent points.
1. MedicationRequest says indeed "It may be used to support the order of medication-related devices". My opinion is that this needs clarification. It only supports devices that are implicit in the medication (i.e. you order some drug code for insulin, and that code includes the syringe)
Jose Costa Teixeira (Jun 19 2019 at 13:27):
Agree this should not be up for interpretation, which will hinder interoperability.
Jose Costa Teixeira (Jun 19 2019 at 13:33):
2. At this moment, there is a DeviceUseStatement, SupplyDelivery is rather close but is not intended for that. We just barely started discussing this in the Product discussions @Lloyd McKenzie - implementers may expect a DeviceDispense just as we have a MedDispense. Depending on the patterns discussion, we may end up with a DeviceDispense or DeviceDelivery resource... but that is just my leaning, not necessarily the best option.
Jose Costa Teixeira (Jun 19 2019 at 13:34):
One part of the future that I can guess confidently: as this becomes clearer, IHE will work on this matter and should provide some guidance on these matters.
Lloyd McKenzie (Jun 19 2019 at 14:12):
We have SupplyDelivery to capture delivery of non-medications. In some systems, certain devices will be captured using MedicationDispense because that's convention (and because the systems involved can't necessarily differentiate between medication & device or because the device includes an integrated medication which is subject to medication dispense management rules). There are no plans to introduce a DeviceDispense resource to my knowledge. DeviceUsage is a proposed resource designed to track whether a patient uses a given device. It was introduced to support quality reporting that needed to know whether devices were being used as recommended, however it's not clear whether systems do (or will) actually capture such information discretely this way - which is why the resource remains 'draft'.
Jose Costa Teixeira (Jun 19 2019 at 14:16):
SupplyDelivery was initially for not-patient-specific things - I have been in favour of optionally supporting patient and IIRC that was one conclusion in the Product discusions. so we will be good.
Jose Costa Teixeira (Jun 19 2019 at 14:38):
Problem with medDispense is that this is not a medication and may not have a medication code.
I guess this means +1 for "boundaries between meds and devices are artificial /arbitrary, so not to be taken too seriously."
Lloyd McKenzie (Jun 19 2019 at 14:53):
If it's being captured as a MedicationDispense, then it has a code that will fall within the value set the jurisdiction allows. (I know a lot of Canadian systems dispense certain devices as if they were meds.) We can't enforce boundaries in the standards that aren't actually enforced in business practice.
Jose Costa Teixeira (Jun 19 2019 at 15:26):
If that means that medicationrequest can be used to dispense anything for which the pharmacy has a code, then I think we really should get our scope in order. I have often failed to promote the message "we can't enforce these boundaries in the standards".
Björn Genfors (Jun 27 2019 at 15:01):
@Jose Costa Teixeira @Lloyd McKenzie I'm sorry for the delay - thank you both for your input. I hadn't checked out SupplyDelivery before, this was a good tip (although I still haven't quite managed to wrap my head around if this is the perfect fit for my use case or not). I think we have just about reached the end of the road of this discussion. The little feedback I can give is that the list of possible SupplyDelivery receivers seems to be slightly too short - in the scenario I painted above the receiver would be either the patient, or a proxy (is that the correct English term?)
Lloyd McKenzie (Jun 27 2019 at 20:20):
Yes. This is not tuned for capturing dispenses to a patient. @Eric Haas ?
Eric Haas (Jun 27 2019 at 21:46):
@Jose Costa Teixeira ?
Jose Costa Teixeira (Jun 27 2019 at 22:50):
To me: we had (for a long time) some discussions on FHIR on this, now we are at a crossroads.
this is a logistics dispense, not a clinical one, and has little to do with a med (posology etc do not apply).
Jose Costa Teixeira (Jun 27 2019 at 23:01):
1. ongoing discussions are still that Supply is not patient-specific. I am not yet too confortable with this gap this brings, but we can't use that one for now.
2. DeviceRequest could be used, I think.
3. MedicationRequest should review the statement that it can be used for medication-related devices.
4. I understand that "if it is dispensed by the pharmacy, we can give it a medication number and we can treat it as a medRequest". so you can also use a MedicationRequest for this, and use medrequest as a generic product request that can be used with ordering anything. Which brings the overlap you mentioned and i agree this would best be clarified - sorry that it is not, at the moment.
For the future, I am personally still not against a "productRequest" - but that is just my experience after having a Device module, a medication module and having to go through the effort of making a "health product" module - all these things just got easier when we did. I guess this is not too different from 4 above, but then our scope should be reviewed, and if we have a generic resource, then we prepare adequately (hence my personal preference).
Thanks for putting your finger on this
Last updated: Apr 12 2022 at 19:14 UTC
