Stream: implementers
Topic: Medication.amount usage
Simone Heckmann (Sep 19 2019 at 15:03):
I have added a Tracker Item (GF#24690) asking for clarification around Medication.amount, but maybe someone around here can comment:
Since Medication.package has been removed from Medication in R4, I assume the intent is to roll up different package sizes of the same Medication into one Medication resource instance and move the information about the package size to MedicationRequest.dispenseRequest.amount and MedicationDispense.amount.
However, it in not clear how to use Medication.amount in this scenario, since it still refers to the "amount in package" even though the Medication resource seems no longer tied to one specific package size.
To clarify:
Assuming there are 3 package sizes of "Bayer Aspirin 500", with 10, 25 and 50 tablets, I would assume they are all represented by the same Medication "Bayer Aspirin 500".
In this scenario, what would the Medication.amount be?
Melva Peters (Sep 19 2019 at 15:44):
Medication can be at multiple levels - so you would have one identifier for the different package sizes. You would have an identifier for the Bayer Aspirin 500 in a package of 10 vs a package for 25 or 25. If you have the generic Aspirin 500mg - there would be no packaging information.
Simone Heckmann (Sep 19 2019 at 15:47):
ok, after some reading up on the scope, I think I was under the misconception that package had been removed from Medication when it has rather been rolled into amount with package.content.amount -> amount.numerator and package.container -> amount.denominator, is that correct?
Maximilian Reith (Jul 21 2021 at 09:03):
I would like to reopen this topic, but in a sligthly different context.
How can i represent complex packages? For Example: Dolomo Tn Tablets 27 pieces. 9 tablets are coffein-based (ingredient: Coffein) and 18 codein-based (ingredient: Codein) tablets .
Could i use ingredient.itemreference to depict this information? since medication is allowed in itemreference (not substance only) and every referenced profile has an ingredient, too. So ingredient.itemreference will link an ingredient. This should work, even if all the referenced medicationprofiles have the same ingredient or the .ingredient is not populated explicit, since it is hidden/coded in medication.code (manufactured product).
Thanks
@Simone Heckmann @Alexander Zautke
Simone Heckmann (Jul 21 2021 at 11:40):
Sounds a bit like these are two completely different medications that happened to end up in one box. I'd say we either look at this as two different medications and figure out a way to link them together or we try to figure out under which circumstances systems need to be aware of this detail and whether it would be ok to just say amount = 27{tablets}, ingredient = x mg caffeine + y mg codeine and only specify the dirtribution into different pills in an extension...?
(probably depends whether Medication is used in the context of MedicationRequest or MedicationAdministration)
Rik Smithies (Jul 21 2021 at 11:53):
The medication definition resources are designed to cope with this sort of thing and have all the package detail you can want. May be more than you need for prescribing, but if you have a catalogue of medications then you are covered. It is common to have different medications in the same pack, forming one product. Thrush treatment and contraceptive pill are the most common examples. Have a look at http://build.fhir.org/medication-definition-module.html
Jean Duteau (Jul 21 2021 at 13:41):
Medication was not built to represent complex packages. It is intended to identify a manufactured product with a code and optional manufacturer, form, and batch information. Or it can represent a compounded preparation with the ingredient listing. But if you are trying to describe a manufactured product, then one of the other resources - MedicationKnowledge or MedicinalProductDefinition - should be used depending on your use case.
Maximilian Reith (Jul 21 2021 at 15:45):
Well i do know the new possibilities in r5, but i need a solution for r4. So an extension on rootlevel to link serveral medications would be a solution?
Lloyd McKenzie (Jul 21 2021 at 16:21):
If you're prescribing a combo product, generally you'd just specify the code for that combo product. Same thing for dispense. The dosage instructions would typically be just text. If you needed to, you could put an extension in the dosage instruction to refer to the distinct package components to allow you to convey distinct dosage instructions for each.
Jean Duteau (Jul 21 2021 at 16:46):
i'd need to understand your use case in more detail, but it doesn't sound like Medication is the proper resource for what you are describing.
Jose Costa Teixeira (Jul 21 2021 at 17:25):
I have somewhat different requirements in a project and I will look into MedicationKnowledge. For this I see an overlap with Medication which supports describing ingredients but the Medication resource is meant to describe that in transactional data - for example describing the ingredients when prescribing a magistral formula. For master data, MedKnowledge is more appropriate.
Jose Costa Teixeira (Jul 21 2021 at 17:26):
Besides the purpose, Medication has some omissions that make it less suitable for catalogs
Maximilian Reith (Jul 23 2021 at 05:31):
Jean Duteau said:
i'd need to understand your use case in more detail, but it doesn't sound like Medication is the proper resource for what you are describing.
At first complex packages are common in germany
I have two main use-cases:
-
An existing registry for medications (PZN-Number) ist not valid on its own. In addition to PZN packages have to be described completely (on a high level) by law. So in a case of prescription , we need to have these highly detailed packageinformations. So we can't use medication.code only.
-
If you want to know how long this medication will last (for one costumer) you need to know how many e.g. tablets are inside exactly. you can calculate when this customer will need the next package.
Jose Costa Teixeira (Jul 23 2021 at 09:13):
so what you are prescribing is a medication code, and you attach the detailed information about it.
Jose Costa Teixeira (Jul 23 2021 at 09:13):
if that is so, that is also a use case we need to solve in a project here, and that is a reason for adding a reference from Medication to MedicationKnowledge.
Jose Costa Teixeira (Jul 23 2021 at 09:14):
(as an extension until there is a core attribute for that)
Rik Smithies (Jul 23 2021 at 10:03):
@Maximilian Reith If you need more about packages than is in MedicationKnowledge (such as your requirement #2) R4 also has http://hl7.org/fhir/medicinalproductpackaged.html
Maximilian Reith (Jul 23 2021 at 15:32):
Jose Costa Teixeira said:
if that is so, that is also a use case we need to solve in a project here, and that is a reason for adding a reference from Medication to MedicationKnowledge.
Yes...medication.code or at least medication.text shall be filled. But i will have a deeper look into MedicationKnowledge even if its maturity is 0
Maximilian Reith (Jul 23 2021 at 15:34):
Rik Smithies said:
Maximilian Reith If you need more about packages than is in MedicationKnowledge (such as your requirement #2) R4 also has http://hl7.org/fhir/medicinalproductpackaged.html
Thanks, but this Definition should be used productive ( "At this time, is considered only as a draft resource not suitable for production implementation")
Lloyd McKenzie (Jul 23 2021 at 15:48):
You're free to adopt draft/maturity level 0 resources in production if they meet your requirements. Just be aware that, due to their low maturity, there's a risk they won't - and that there's also a higher risk of change going into the next release.
Rik Smithies (Jul 23 2021 at 15:57):
@Maximilian Reith you have to consider what the alternative to a level 0 resource is. You can make something up yourself, such as a lot of extensions, or (mis-)use something that is not really meant for that. Those would be below level 0 (level -1 :-)
Jose Costa Teixeira (Jul 23 2021 at 23:38):
Exactly. Misusing medication is not the best, although it might be an option. MedicationKnowledge is meant for such purpose (describing information about a product). It offers a good starting point for those concepts.
Jose Costa Teixeira (Jul 23 2021 at 23:38):
I am looking at the same concept. I can share the conclusion or the IG when it's up
Maximilian Reith (Jul 26 2021 at 09:22):
Jose Costa Teixeira said:
I am looking at the same concept. I can share the conclusion or the IG when it's up
Thanks that would be great.
Maximilian Reith (Jul 26 2021 at 09:27):
Jose Costa Teixeira said:
Exactly. Misusing medication is not the best, although it might be an option. MedicationKnowledge is meant for such purpose (describing information about a product). It offers a good starting point for those concepts.
i think: Usage of MedicationKnowledge will lead to a huge overhead, since (in my use-case) i would use .packaging only. The rest of this resource is not necessary. We will discuss this problem internally, but the "misuse-option" is an option.
Last updated: Apr 12 2022 at 19:14 UTC
