Stream: BRR - Pharmacy model
Topic: Link MedicationKnowledge to an resource instance
Rik Smithies (Mar 09 2020 at 17:44):
The "subject" of a MedicationKnowledge is MedicationKnowledge.code.
This is a logical reference, perhaps to a (non-FHIR) code system (e.g. RxNorm or SNOMED etc).
I assume this can be used to link to a Medication resource, which has the same code. I think there is practical value in linking to an actual FHIR Medication instance (or a MedicinalProductDefinition instance). That's the normal way to link in FHIR, when the data is available in FHIR.
So I suggest changing MedicationKnowledge.code to be a CodeableReference(Medication|MedicinalProductDefinition). Then it can be used to add "knowledge" - prices, protocols etc etc to any FHIR medication.
Also, and this is independent, we could consider changing the name of "code" to "subject" to show that this is information about another medication (wherever that may be, FHIR or otherwise), and not the code of the actual knowledge, which is how it can be read now.
Jose Costa Teixeira (Mar 09 2020 at 17:55):
Why would we link a medicationKnowledge (Definition) to a medication? Normally you'd have the definitional resource first, right?
Jose Costa Teixeira (Mar 09 2020 at 17:55):
and what is MedicationDefinition?
Rik Smithies (Mar 09 2020 at 18:10):
sorry, thanks, that was meant to say MedicinalProductDefinition, now corrected :-)
I would ask why we would not want to link the knowledge to the medication? That is what we do now, but by code. The Medication can be a definition, and the MedicinalProductDefinition is (more obviously) a definition.
Rik Smithies (Mar 09 2020 at 18:12):
We could point the Medication at the knowledge, but it seems to make sense that the knowledge is about the medication rather than the other way around.
Jose Costa Teixeira (Mar 09 2020 at 18:30):
I assume the medication resource is the one that is created latest, not the medicationknowledge. There will be many medications "instanciating" the definitional resource
Jose Costa Teixeira (Mar 09 2020 at 18:33):
perhaps I'm missing something but I cannot figure out how to do the simple use cases with this data architecture.
Jose Costa Teixeira (Mar 09 2020 at 18:35):
I believe the 80% we need is for a hospital or system to have a medicine definition, and to be able to refer to it (by kind or instance).
Jose Costa Teixeira (Mar 09 2020 at 18:36):
why would we need to point a medicationKnowledge (definition) to a medication?
Jose Costa Teixeira (Mar 09 2020 at 18:37):
and I try to understand how you'd say "knowledge is about medication" @Rik Smithies - do you mean that we build a "knowledge" resource around a predefined, pre-existing MedicinalProductDefinition?
Rik Smithies (Mar 09 2020 at 18:44):
hi Jose
There are use cases where you want to define a product and you want to say about the package and the shape of the tablet, and also its kinetics and price. That needs both MedicinalProductDefinition and MedicationKnowledge, but there is no way to join them. Other than by code. Code is not precise enough, because you don't know if it points to the code in the code system itself, or to some resource that happens to use that code. If this is not needed for Medication (which, in my view, can be definitional - it states that in its description in fact), then maybe not, but it is needed for MedicinalProductDefinition.
Jean Duteau (Mar 09 2020 at 18:46):
we already have a means to link a MedicationKnowledge to a Medication via the associatedMedication data element
Rik Smithies (Mar 09 2020 at 18:48):
ah I see yes. Well that could be extended to allow reference to MedicinalProductDefinition. But I see that as similar to the"code". Maybe better to collapse into a CodeableReference, which seems the preferred pattern to link things that may be codes or instances
Jean Duteau (Mar 09 2020 at 18:49):
we can add a separate data element to link to a medicinalproductdefinition if we feel that is needed
Rik Smithies (Mar 09 2020 at 18:49):
why not collapse all 3 though? conceptually the same no?
Rik Smithies (Mar 09 2020 at 18:50):
then casual observers like me may not fail to spot the "other" one
Jean Duteau (Mar 09 2020 at 18:51):
because they are different elements that do different things.
Jose Costa Teixeira (Mar 09 2020 at 19:10):
Rik Smithies said:
hi Jose
There are use cases where you want to define a product and you want to say about the package and the shape of the tablet, and also its kinetics and price. That needs both MedicinalProductDefinition and MedicationKnowledge, but there is no way to join them.
I don't think we are making a good design if we need 2 (or more?) resources for that. But if we do, which one is the main one?
Jose Costa Teixeira (Mar 09 2020 at 19:11):
and we have 3 resources that are potentially medication definitions
Jose Costa Teixeira (Mar 09 2020 at 19:12):
I fail to imagine how this would work in a real example, end-to-end.
Jose Costa Teixeira (Mar 09 2020 at 19:13):
and what is associatedMedication? @Jean Duteau
Jean Duteau (Mar 09 2020 at 19:14):
and we have 3 resources that are potentially medication definitions
no we don't. Medication is not a "definitional" resource. it is an identifying resource of something that was ordered, dispensed, or administered.
and the scope for these three resources is quite well-defined in their proposals. it just needs to get conveyed in the spec itself.
Jose Costa Teixeira (Mar 09 2020 at 19:14):
well, I relied on Rik's statement that medication could be definitional
Jean Duteau (Mar 09 2020 at 19:15):
and what is associatedMedication? Jean Duteau
The data element on MedicationKnowledge that links to Medication resources that can be used in a MedRequest/Dispense/Administration/Statement.
Jose Costa Teixeira (Mar 09 2020 at 19:16):
The starting point (for me) in 2016 was from openMedicine: we may need to define a product by any set of characteristics - anywhere from shape, dose form, excipients, etc. This question is still not answered (but we have time for that)
Jose Costa Teixeira (Mar 09 2020 at 19:18):
Jean Duteau said:
The data element on MedicationKnowledge that links to Medication resources that can be used in a MedRequest/Dispense/Administration/Statement.
The definition of the element is strange/poor
Jean Duteau (Mar 09 2020 at 19:19):
Pharma company creates a new medication product. They need to submit their product reference information to a registrar such as the EMA or the FDA. They use MedicinalProductDefinition as their resource as this contains all of the reference information that a registrar needs to evaluate, register, and authorize medication products.
The product is now on the market and a drug knowledgebase such as Medi-Span or First Data Bank includes it in their product. Regional health authorities and drug insurance companies list the product in their formulary. They all use the MedicationKnowledge resource to convey their knowledge information.
Finally, the product is ordered, dispensed, and administered. The Medication resource identifies the product that was used in all of those cases.
Jean Duteau (Mar 09 2020 at 19:19):
The definition of the element is strange/poor
Jose Costa Teixeira (Mar 09 2020 at 19:20):
yes, so why does a MedicationKnowledge need to point to a Medication?
Jean Duteau (Mar 09 2020 at 19:21):
yes, so why does a MedicationKnowledge need to point to a Medication?
The use case we have had from implementers is that they have a formulary that is used to select a drug and then they want to go from the formulary to the Medication resource. Although we had first given guidance that they could use the code, this request kept popping up so we added this ability.
Jose Costa Teixeira (Mar 09 2020 at 19:22):
and (old question) can I not use MedicationKnowlege instead of MedicinalProductDefinition? I'd say a profile should suffice if we slice it well enough and if MedicationKnowledge does its definitional job well
Jose Costa Teixeira (Mar 09 2020 at 19:23):
(sorry for opening can of worms, but I was assuming that things were clear and I just missed it, but this seems to be lacking some hammering while it is warm)
Jean Duteau (Mar 09 2020 at 19:23):
and (old question) can I not use MedicationKnowlege instead of MedicinalProductDefinition? I'd say a profile should suffice if we slice it well enough and if MedicationKnowledge does its definitional job well
Nope. Too many different elements in each. They really are different scopes.
Jean Duteau (Mar 09 2020 at 19:24):
(sorry for opening can of worms, but I was assuming that things were clear and I just missed it, but this seems to be lacking some hammering while it is warm)
You didn't understand my explanation of how the three different resources are used above? That seemed clear to me.
Jose Costa Teixeira (Mar 09 2020 at 19:24):
Jean Duteau said:
and (old question) can I not use MedicationKnowlege instead of MedicinalProductDefinition? I'd say a profile should suffice if we slice it well enough and if MedicationKnowledge does its definitional job well
Nope. Too many different elements in each. They really are different scopes.
- A single resource type with profiling seems actually an advantage there.
- How do we handle that regulators in different countries will have their own variety of required information?
Jean Duteau (Mar 09 2020 at 19:27):
- A single resource type with profiling seems actually an advantage there.
- How do we handle that regulators in different countries will have their own variety of required information?
1) That question was settled by the FMG. I do not think any group wants to revisit that question.
2) Strangely enough, the regulators in different countries have been working together and created the IDMP specifications which is what MedicinalProductDefinition is based on. We have active work being done on investigating implementation of these resources by the FDA and the EMA, so that should drive out all of the requirements.
Jose Costa Teixeira (Mar 09 2020 at 19:28):
This is why I bring this input - based on the work we had to put IDMP to work in these cases. And no, in my experience, the regulators alone will not drive the requirements for the end-to-end information flow
Jean Duteau (Mar 09 2020 at 19:29):
This is why I bring this input - based on the work we had to put IDMP to work in these cases. And no, in my experience, the regulators alone will not drive the requirements for the end-to-end information flow
Maybe I don't understand what you mean by "end-to-end information flow" but the regulators will certainly drive the requirements for the MedicinalProductDefinition resources.
Jose Costa Teixeira (Mar 09 2020 at 19:30):
Regulators thought that IDMP was all that is needed all the way until prescription and pharmacovigilance. We showed them it was not the case.
Jose Costa Teixeira (Mar 09 2020 at 19:31):
Actually the things that I am mentioning were validated in a session with the FDA and FDB, where people understood how this would all work together. So I am just giving the same input I gave and collected a few years ago.
Jose Costa Teixeira (Mar 09 2020 at 19:33):
As for the FMG revisiting a decision, it's ok to assume that the est decision was made given the information available. But if there is challenging information, FMG can and should revisit decisions while things are in maturity level 1...
Jean Duteau (Mar 09 2020 at 19:33):
Rik Smithies said:
I assume this can be used to link to a Medication resource, which has the same code. I think there is practical value in linking to an actual FHIR Medication instance (or a MedicinalProductDefinition instance). That's the normal way to link in FHIR, when the data is available in FHIR.
Back to the original question, I could possibly see a knowledgebase pointing to the regulatory submission, but does that actually happen in existing implementations? That I haven't seen but I'm not as in the loop with those implementations as I could be.
Jose Costa Teixeira (Mar 09 2020 at 19:40):
well, I get the point.
I maintain my concerns and I do not know how to express them within the group(s). It's a methodological question - it's easy to point small inconsistencies in the standard, but very hard to discuss broad design issues. Which is frustrating because none of this is mature, so in my opinion we should be a bit more flexible.
Jose Costa Teixeira (Mar 09 2020 at 19:41):
We have a big project coming again on this topic, so perhaps in a few years this will be clearer. From these discussions I realize it will be better to convince EMA and FDA first and then they will convince the rest of the participants incl SDOs.
Jean Duteau (Mar 09 2020 at 19:44):
Jose Costa Teixeira said:
well, I get the point.
I maintain my concerns and I do not know how to express them within the group(s). It's a methodological question - it's easy to point small inconsistencies in the standard, but very hard to discuss broad design issues. Which is frustrating because none of this is mature, so in my opinion we should be a bit more flexible.
To point it back at you, we've had this conversation before and finally nailed it down and all groups are now trying to move forward and get something that can be implemented and tested. I'm pretty sure that you were involved in those discussions. That is why your questioning seems counter-productive to us. We don't want to go backwards when all groups (BR&R, Pharmacy, and FMG) have agreed on a path forward. This is quite new ground for the Pharma community so it might be that, once we get actual implementers involved in all of these resources, that some coalescing might occur. But we haven't seen that yet and we do seem to have three different implementer communities (as I expressed earlier in my scope examples) that don't actually share information between them as much someone would think.
Jose Costa Teixeira (Mar 09 2020 at 20:08):
Ok, then please move forward. I maintain my concerns. I was partially involved shortly after I proposed such a topic in Orlando (it was rejected at first), and my input has been documented and has not changed much since.
I truly am sorry if you see this as counter-productive, but my questioning remains the same as from the time of openMedicine, where we explored these requirements. This is why I eventually stopped being involved. Perhaps we need another project like openMedicine. :)
Rik Smithies (Mar 09 2020 at 21:03):
oh yes so that associatedMedication link to Medication is not a subject, that I am looking for, so that is a different issue. It's another related medication (could do with a "type" for the link maybe).
The link to MedicinalProductDefinition would not be that but would be like the code. Those two seem conceptually the same. That could usefully have Medication there too I would say, but if that isn't wanted then I don't have that use case.
Medication can be definitional I think - it says that in the very first line of its page. You could set up a load of medications and point a series of prescriptions at them. You don't need one per script. But if people aren't going there then no problem.
Rik Smithies (Mar 11 2020 at 00:32):
@Jean Duteau Is the associatedMedication intended to be the medication that the knowledge is about? I see the definition has changed, substantially. Maybe it was never meant to be as it was documented, but the new definition looks like it is the "subject" of the knowledge?
Jean Duteau (Mar 11 2020 at 02:58):
no, it is intended to be Medication resources that represent the medication that the MedicationKnowledge is about. it points to resources that can be used in the other resources.
Jean Duteau (Mar 11 2020 at 03:00):
to be honest, i'm not convinced we need this attribute. I really don't think there will be an actual link between the three resources. In all of the prescribing and dispensing systems I've seen so far, they are all using the medicationCodeableConcept or using a contained Medication for compounds. No one yet is actually referencing an external Medication resource.
Rik Smithies (Mar 11 2020 at 12:27):
so it is Medication instantiations of the definitional medication (somewhere) that this knowledge is about. I cant see any need for that, because the Medication resources themselves have that, via Medication.code.
Rik Smithies (Mar 11 2020 at 12:32):
Is it the case that the MK is about a coded item (not in FHIR) and the Medication is an instance of the same coded item (not in FHIR) but the MK is not about the Medication itself. There is pointer from MK to M, but its not an "about" relationship it's a "these two things are based on the same definition" link.
Jean Duteau (Mar 11 2020 at 14:54):
I'd say rather, "these two things are describing the same physical medication" link
Rik Smithies (Mar 11 2020 at 15:36):
But that is redundant information, given that you can find it by looking at the medications that have the same code. I'm not against it, but can't see the point really.
Rik Smithies (Mar 11 2020 at 15:37):
Anyway if that is not a link to a definitional medication, would it be acceptable to add a different reference to MedicinalProductDefinition?
Jean Duteau (Mar 11 2020 at 21:10):
yep, I agree, this my concern about whether we really need this attribute. And it might make sense to add a reference the Definition. Can you make a JIRA item for that?
Rik Smithies (Mar 11 2020 at 22:32):
I can add one for the reference yes. But I am thinking that the logical thing is to treat the code (pointer to an external definition) and the new reference to a MPD (pointer to an internal definition) as the same concept, namely the "subject". You could have a choice of code or reference to MPD but then it doesn't make sense to still call it "code".
Jean Duteau (Mar 11 2020 at 22:33):
maybe. but that in your jira item and we'll discuss it at the next pharmacy call
Rik Smithies (Mar 11 2020 at 22:33):
will do
Rik Smithies (Mar 11 2020 at 23:41):
Jose Costa Teixeira (Mar 26 2020 at 10:58):
With my excuses for missing the discussions (i don't know where those are), @Rik Smithies you added an ingredient.function.
But is the function of an ingredient an intrinsic characteristic of the ingredient? I think it is a characteristic of the product it is used in. Which means I don't see how this will be managed in real life - if an ingredient can have two different functions in two different products, you think we should have 2 instances of the Ingredient resource?
Rik Smithies (Mar 26 2020 at 12:15):
Hi Jose. Discussions are on the weekly BR&R calls, where we review the Jira change requests. I will try to copy them to here though in future. This one was raised by FDA.
Yes the function of an ingredient is an intrinsic characteristic of an ingredient, because a FHIR ingredient is always in the context of a product (or at least some other thing that it is a part of). Otherwise it would be little more than a substance.
Ingredients have strength, and this naturally is in the context of its use in something else - no ingredient truly has a strength in and of itself. The function is in the context of the same thing.
If an ingredient has two different functions in two different products then yes that would be two ingredients. If it had a different strength in those two products then it would already be two different ingredient resources. The same substance can be an excipient or an active ingredient, and again that would be two different ingredients.
Jose Costa Teixeira (Mar 26 2020 at 13:46):
Ok that is clear. Taking your starting point (that this is complex enough to deserve a bunch of different resources) then this makes sense.
(This does not mean I don't have my reservations with some parts of the design, but that's another question).
Jose Costa Teixeira (Mar 26 2020 at 13:46):
Perhaps it could be clearer in the scope statement of the resource, but I can't formulate a better description than you did in your reply.
Last updated: Apr 12 2022 at 19:14 UTC
