Stream: Medication
Topic: Image of Dispensed Drug
John Moehrke (Mar 27 2019 at 18:28):
I am working in the USA Veterans Admin on their Patient Portal. One of the features offered today to a Veteran is that they get to see a picture of the drug that was actually dispensed to them. This picture helps them identify which of the various pills they have is the pill of interest. This picture helps them identify to their clinican the pills they are taking. This picture helps their spouse or other helper understand the pills they need to give when.
When I look at the current FHIR Medications, I don't find a clear way to identify a picture of the drug as it was dispensed. There is MedicationKnowledge that seems useful, but it seems to be closer to what was Ordered. I need linkage to what was Dispensed.
Lloyd McKenzie (Mar 27 2019 at 18:48):
MedicationKnowledge is knowledge - it's tied to a drug code and could be at the ordered, dispensed/administered level
John Moehrke (Mar 27 2019 at 18:54):
But that is what is ordered... dispensed seems to not have the ability to be this specific.
Jean Duteau (Mar 27 2019 at 18:55):
MedicationKnowledge is agnostic on whether the medication was ordered, dispensed, or administered. It just describes a medication and the knowledge items around that medication.
Lloyd McKenzie (Mar 27 2019 at 19:17):
Dispensed just points to a code. You look up the code in MedicationKnowledge the same as you would for an ordered med
Melva Peters (Mar 27 2019 at 23:25):
MedicationKnowledge contain an image of a drug product
Jose Costa Teixeira (Mar 28 2019 at 02:46):
If the image needed is a standard catalog picture of the drug, this is the default use of MedicationKnowledge.
Say the use case is: prescription is for drug A (tablets), but pharmacy dispenses drug B (capsules).
Jose Costa Teixeira (Mar 28 2019 at 02:50):
if you want a "catalog" image of drug B, you use the medicationKnowledge of drug B which should be on the server somewhere.
if however you want a picture of your drug B (e.g. you want to take a photo of the individual bag or bottle that the drug was dispensed, for proof, or for whatever other reason, then you could use a contained a MedicationKnowledge (or an extension) with that photo.
Jose Costa Teixeira (Mar 28 2019 at 02:54):
(btw, name "knowledge" seems to help confusing here, as it is unclear whether it refers to the definition of the medicine, or to the facts that are known about a product instance or treatment..)
Richard Townley-O'Neill (Mar 28 2019 at 03:33):
I can't find an element for medication image in http://build.fhir.org/medicationknowledge.html
I think that Medication is the best place for the image, it is widely used to hold details of the medication that are not available from the coding. All it needs is an extension.
Lloyd McKenzie (Mar 28 2019 at 04:12):
If you're taking a patient-specific picture, I wouldn't bother with a contained MedicationKnowledge, I'd use an extension. (You'd need an extension to point to the MedicationKnowledge anyhow because just linking by code isn't enough for contained.)
Lloyd McKenzie (Mar 28 2019 at 04:15):
@Richard Townley-O'Neill It'd be drugCharacteristic.valueBase64Binary, though I agree it'd be useful for there to be a specific example code for 'image'. Medication is a weird duck. Sometimes it's used as the contained resource for custom compounds, IV concoctions, etc. and in those cases, an image is totally incorrect. In other cases, it's used for a drug masterfile and in those cases, an image is potentially reasonable. But, realistically, if you're going to capture an image for the drug, you'll probably have most of the other knowledge-base stuff too (indications, contraindications, recommended doses, etc.) Which means that you're really talking about MedicationKnowledge.
Jose Costa Teixeira (Mar 28 2019 at 04:47):
we mentioned this last monday call about product: medication resource is both definitional and instance. medicationknowledge is strictly definitional in the sense of all other ...definition resources
Jose Costa Teixeira (Mar 28 2019 at 04:48):
agree that an extension on medication could do it if it is a patient-specific (or rather instance-specific) picture.
John Moehrke (Mar 28 2019 at 16:40):
The image in the case of the VA is close to a catalog image. It is not an actual picture of the pills given. BUT it is very specific to the look of the pills dispensed at the pharamacy that dispensed that drug. I think the most likely case is where there are various possibilities that could fulfil the ordered medication, so that the image is what actually got dispensed. This might be different manufacture, might be because of pill strength available within that pharmacy, etc.... SImply recognizing that various pharmacy have various stock.
John Moehrke (Mar 28 2019 at 16:41):
so I think MedicationKnowledge might work.. but there needs to be a way to indicate in the MedicationDispense which MedicationKnowledge represents what was dispensec.
Jean Duteau (Mar 28 2019 at 16:44):
Yes, currently we have MedicationKnowledge pointing to a Medication, but a Medication does not point to a MedicationKnowledge. You'll have to use an extension for now, but I'll raise this as a tracker item. I'm thinking it would go like this: [Dispense|Request|Administration|Statement].medicationReference -> Medication.associatedMedicationKnowledge -> MedicationKnowledge.
Jean Duteau (Mar 28 2019 at 16:46):
https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=20624
John Moehrke (Mar 28 2019 at 16:54):
thanks
Jose Costa Teixeira (Mar 28 2019 at 18:27):
@Jean Duteau why not simply add a "medication.definition" (as in Device which had the same issue)?
Jean Duteau (Mar 28 2019 at 18:29):
That's what the tracker item says. For medication, there might be multiple knowledge resources that correspond to the same medication, but that will be for the committee to decide.
Jose Costa Teixeira (Mar 28 2019 at 18:30):
yes, i just looked at the name (to keep it consistent across all products) - medication.associatedMedicationKnowledge --> medication.definition
Jose Costa Teixeira (Mar 28 2019 at 18:35):
I know medicationKnowledge is a working name, i am not addressing that. Just that the reference should simply be called ".definition" - seems more straightforward for implementers. should i put these 2 cents in the tracker item comments?
Jean Duteau (Mar 28 2019 at 18:38):
You can, but I wouldn't find it persuasive. Unlike the other definitions, I would expect that multiple associated knowledge resources could be referenced here.
Lloyd McKenzie (Mar 28 2019 at 18:39):
The dispensed medication.code SHOULD be the detailed code for the specific manufactured product. The only time I can see that not being specific to a particular image would be if the manufacturer changed the appearance of the same formulation - some code systems wouldn't change the code if that occurred, but that would be rare. (And if it did occur, the MedicationKnowledge should have two images..)
Jean Duteau (Mar 28 2019 at 18:43):
for the use case of sending the image that corresponds to the dispensed drug, i agree that there would be one knowledge resource. we've discussed in the workgroup where you might have multiple associated knowledge resources corresponding to multiple formularies or knowledgebases.
Jose Costa Teixeira (Mar 28 2019 at 18:43):
if the manufacturer changed the appearance of the same formulation - some code systems wouldn't change the code if that occurred, but that would be rare. (And if it did occur, the MedicationKnowledge should have two images..)
you would best have two medicationknowledges, or two versions...
Jose Costa Teixeira (Mar 28 2019 at 18:44):
You can, but I wouldn't find it persuasive. Unlike the other definitions, I would expect that multiple associated knowledge resources could be referenced here.
not sure i understand what is missing, perhaps it stems from the idea of several definitions for one medication. Can one product can have many definitions?
Jose Costa Teixeira (Mar 28 2019 at 18:49):
i think that a medication can correspond to several definitions (as any other product), but i am not sure a 0..* is the best option. A medication can have not "some" definitions, but "a speciific set of definitions" Perhaps you have a different model in mind or different requirements, so i am not worried there, i know there will be a solution.
I just wanted to say that "associatedMedicationKnowledge is not straightforward, and "definition" would be better. Especially since MedicationKnowledge is a good resource but with an unclear name, and we do not want to spread that to some attributes.
Jean Duteau (Mar 28 2019 at 18:52):
MedicationKnowledge is not a definition of a medication in the traditional sense. It is the knowledge of a product that a formulary or knowledgebase contains. Thus I can send multiple resources corresponding to different formularies or knowledgebases. I could also send multiple resources corresponding to different levels of information. For example, if my Medication was AG-Amoxicillin 500mg Tablet, I could conceivably have the following associated knowledge resources: AG-Amoxicillin, Amoxicillin Trihydrate, and Amoxicillin. We have seen a knowledgebase where some of the information is inherited from higher levels. So the Amoxicillin contains knowledge about the interactions and indications, Amoxicillin Trihydrate gives further information about the specific salt and the AG-Amoxicillin gives information such as image, scoring, size, etc.
Jose Costa Teixeira (Mar 28 2019 at 19:00):
It is the knowledge of a product that a formulary or knowledgebase contains.
That is what i mean by definition. And "knowledgebase" is what I had to call "catalog" (or Formulary, or Livret Therapeutique). Marketeers call it knowledgebase.
Agree with the multiple links - i had to implement just that (and the "logistic product definition" on top of it), so I am happy to see that requirement. Still,
a) we should review the name. MedicationKnowledge is easy to confuse with "all we know about this patient's medication history" - hence my adjacent question to differentiate medicine/medication (médicament / médication).
b) to make that graph, it may b ethat we use 0..*, i just think it is not the only possibility and I would not anchor to a design just yet.
Just to be clear - there are several options, and I agree a medication can have its definition originating from different sources. How we fix that, is of secondary importance.
Lloyd McKenzie (Mar 28 2019 at 19:05):
If the only thing that changed was the appearance and the regulator didn't force a change of 'code', there'd be nothing "new" to have a distinct MedicationKnowledge for. Linkage to MedicationKnowledge in existing systems is exclusively via code. No systems point to medication knowledge in sources like First Databank by anything other than the medication code. So we can't reasonably expect systems to change that behavior with FHIR - nor can we expect knowledge sources to change their behavior either.
Lloyd McKenzie (Mar 28 2019 at 19:07):
Catalogue is a different thing. It implies "what's available". That's not a function of the knowledge resource, it's a function of what a particular organization chooses to put in its "list". (And the question of "what's available" can be highly dynamic.)
Jose Costa Teixeira (Mar 28 2019 at 19:09):
Yes, I am assuming that when the color of a product changes, there is a new version of the product. Perhaps not necessarily a new code, but AFAIK someone has to update the SPC to say "this is now pink instead of red").
Jose Costa Teixeira (Mar 28 2019 at 19:14):
Linkage to MedicationKnowledge in existing systems is exclusively via code.
via codes, yes, not sure if one code is sufficient.
- AG-Amoxicillin 500mg Tablet box 20 has one code (IDMP PackagedProduct ID)
- AG-Amoxicillin 500mg Tablet has its code (IDMP MedProduct ID)
- AG-Amoxicillin, another code
- Amoxicillin 500 mg Tablet, another code (IDMP Pharm Product ID)
- Amoxicillin Trihydrate, another code (Substance code?)
- Amoxicillin another
Jose Costa Teixeira (Mar 28 2019 at 19:14):
Catalogue means "what is defined for this context of use". As in "These are the amoxicillins we are using in this hospital this year".
Jose Costa Teixeira (Mar 28 2019 at 19:15):
I would separate "what is logistically available" (inventory) from "catalogue" (inventory is not only "in stock" it is way more dynamic. I had to implement things like "this tablet is available on your ward until 8pm in that department, after that only via central dispensing from automated dispenser 2)"
Jose Costa Teixeira (Mar 28 2019 at 19:18):
(just to show why my implementation experience makes me afraid of mixing those things).
Lloyd McKenzie (Mar 28 2019 at 19:27):
If there isn't a new code, then there won't be a new MedicationKnowledge. There might be a new version of the MedicationKnowledge, but it's extremely unlikely for there to be a new instance. The whole point is that at you use the code to look up the MedicationKnowledge isntance. The codes exist at different levels of detail and different codes will apply to products at different levels of granularity.
MedicationKnowledge has nothing to do with availability for use. I'd expect the hospital to have MedicationKnowledge resources for products they do not carry or dispense and have never carried or dispensed because the pharmacist might have a need to look up information about the product based on what an arriving patient has on their person or in their record.
Lloyd McKenzie (Mar 28 2019 at 19:28):
The "catalog" would be a List that points to the set of codes currently allowed to be dispensed. There might be a separate list that takes into account what's actually in stock and available.
Lloyd McKenzie (Mar 28 2019 at 19:29):
You could use the codes on that list to look up MedicationKnowledge resources if you wished.
Jose Costa Teixeira (Mar 28 2019 at 19:31):
If there isn't a new code, then there won't be a new MedicationKnowledge. There might be a new version of the MedicationKnowledge, but it's extremely unlikely for there to be a new instance. The whole point is that at you use the code to look up the MedicationKnowledge isntance. The codes exist at different levels of detail and different codes will apply to products at different levels of granularity.
i think there may be a difference between what triggers a new instance vs what triggers a new code. the latter is for the regulators to arbitrate, the former is technical. Not sure if it matters for interoperability but I think it's for regulators to chose.
Jose Costa Teixeira (Mar 28 2019 at 19:33):
I think it does makes sense to use the code as the link.
Jose Costa Teixeira (Mar 28 2019 at 19:36):
this just made me go back to the matter of 0..* - my starting view is that a medication is one unambiuous entity, with one code, one granularity. If a medication is a unambiguous entry with one granularity, it sounds confusing that it is defined by / linked to several "knowledges".
Jose Costa Teixeira (Mar 28 2019 at 19:37):
i am not too worried about whether it is a link or a code, as long as we do not introduce ambiguity.
Jose Costa Teixeira (Mar 28 2019 at 19:38):
The "catalog" would be a List that points to the set of codes currently allowed to be dispensed. There might be a separate list that takes into account what's actually in stock and available.
Agree. I thought you were putting them together - i misread.
Lloyd McKenzie (Mar 28 2019 at 19:54):
The code is the link for all existing software. It's not going to change just because FHIR might work differently. If a manufacturer changes the look of a product and the FDA doesn't assign it a different code, FDB is just going to update their software to show the new image (while hopefully retaining the old one). That's just the reality of what products do.
Lloyd McKenzie (Mar 28 2019 at 19:55):
No pharmacy is going to have links into their medication knowledge-base that work by anything other than the codes they use for ordering and dispensing.
Lloyd McKenzie (Mar 28 2019 at 19:55):
Same with EMRs and HISs.
Jose Costa Teixeira (Mar 28 2019 at 20:06):
true, the upstream decision "does this grant a new code or not" may not be coherent. European regulators have some discretion to define when a code must change, and of course they differ.
Jose Costa Teixeira (Mar 28 2019 at 20:11):
as well as medication formulary systems - their links to the outside are also the product / substance /... codes. Decent formularies handle a more or less complex graph of product info, all hopefully based on the many codes.
Jose Costa Teixeira (Mar 28 2019 at 20:12):
it just seemed taht this somehow clashed with the notion of one medication to N knowledges.
Jose Costa Teixeira (Mar 28 2019 at 20:14):
back to the image, yes, we should keep history, because for patient Fr. Jacques, I may dispense 10 tablets of the pink batch and 15 of the red batch. (whether they have the same code or not, if you want to look them up, you should have this somethere)
Lloyd McKenzie (Mar 28 2019 at 20:15):
A given Medication.code will only resolve to a single MedicationKnowledge (unless you have multiple knowledgebases). Though if you traverse the code hierarchy, you could potentially get others.
John Moehrke (Mar 28 2019 at 20:30):
Lloyd, are you asserting that for every RxNorm there is only one possible drug look? I thought that there were differences in manufacturing that may produce different looks, different manufactures, different potency, and generics.
Lloyd McKenzie (Mar 28 2019 at 22:18):
My understanding is that there are RxNorm codes for those different manufactured forms. RxNorm is a hierarchical code systems where there are codes for generics like "Amoxicillin" (RxNormCUI 723) as well as codes for specific manufactured products "Biomox 100 MG Oral Tablet" (RxNormCUI 791942) as well as codes for intermediaries like "Amoxicillin 100 MG" (791938) or generic formulations "Amoxicillin 100 MG Oral Tablet" (791939). There could be MedicationKnowledge entries at any of these levels. However, if Virbac changes the color of the pill and the FDA doesn't choose to issue it a different CUI, then the drug knolwedge bases would still attach the new image to "Biomox 100 MG Oral Tablet" (791942) as there isn't a more granular code to tie it to.
Josh Mandel (Mar 28 2019 at 23:38):
This is especially challenging for generic medications, which get lumped together by RXN.
John Moehrke (Mar 29 2019 at 12:41):
Hence why I started this thread that there is a need for the image of the "Dispensed" drug. I think MedicalKnowledge can be used, but the linkage is not through the RxNorm code, it must be more specific in some cases.
Lloyd McKenzie (Mar 29 2019 at 14:45):
How could it be with anything more specific? In the dispense record, you'll just have a code that reflects the dispensed drug. Unless the pharmacist takes a picture of the specific drug they're dispensing to each patient at each dispense (which I've never heard of a pharmacist doing), the only thing you can do is look up the code for the dispensed drug in the knowledgebase. (Note that the dispensed code is typically different from the prescribed code and is more detailed in terms of manufacturer, formulation, etc.)
John Moehrke (Mar 29 2019 at 15:20):
I think you might be agreeing. I am all for use of MedicalKnowledge as a catalog of actual drugs with a reference image of that specific one. I am simply indicating that this is more refined than RxNorm, as it must also cover manufacturing differences.
John Moehrke (Mar 29 2019 at 15:22):
In theory, there is no difference between theory and practice... but then reality steps in.
Lloyd McKenzie (Mar 29 2019 at 15:47):
And what I'm saying is that the only thing you'll have records for with associated pictures is an RxNorm or NDC code. If there are finer-grained manufacturing differences than that, no-one will have knowledge records or pictures because the systems involved don't track the finer granularity.
John Moehrke (Mar 29 2019 at 17:34):
From what you are saying, I need to create an extension... because this is a real world need.
Lloyd McKenzie (Mar 29 2019 at 17:41):
Can you explain the real-world need better? At the time of dispensing the only thing the pharmacy knows is the NDC code for the dispensed product. They might have a lot number, but there's no data source that provides lot number-specific information about a medication.
John Moehrke (Mar 29 2019 at 17:48):
The pharmacy knows the exact drug they dispensed. This is what I am looking to flow back. I have outlined many times, and others have confirmed, that what gets dispensed will be chemically identical to what was ordered; but might look different due to manufacturing differences etc. The LOOK of what was DISPENSED is what I am looking for. A reference library of MedicationKnowledge is fine, as long as it is specific to the variations in the look of what gets dispensed.
Lloyd McKenzie (Mar 29 2019 at 17:50):
They know the exact drug they dispensed how? By what identifier? Typically in the US, they know it by NDC code.
Lloyd McKenzie (Mar 29 2019 at 17:51):
Some newer systems might know it by RxNorm.
John Moehrke (Mar 29 2019 at 17:53):
GUID
Jean Duteau (Mar 29 2019 at 17:53):
In the pharmacy systems that I've seen that support images, they have the image of the specific drug that they are dispensing and they reference it by the code. In FHIR terms, they'd use that code to look up a MedicationKnowledge resource that contained the image of the drug they are dispensing.
Jean Duteau (Mar 29 2019 at 17:53):
GUID
I highly doubt that. No system I know of references drugs by GUID.
Lloyd McKenzie (Mar 29 2019 at 17:54):
Who assigns the GUID?
John Moehrke (Mar 29 2019 at 17:54):
Jean is right. it is not exactly GUID
John Moehrke (Mar 29 2019 at 17:55):
but there is a similar level of detail to identify manufacture, Lot, etc.
John Moehrke (Mar 29 2019 at 17:55):
yes, it requires tight relationship with Pharmacy.. which VA has, as they are the Pharamacy most of the time
Lloyd McKenzie (Mar 29 2019 at 17:55):
It has nothing to do with the pharmacy or the relationship.
Lloyd McKenzie (Mar 29 2019 at 17:56):
Drugs from the manufacturer come stamped with two codes - an NDC and a UPC code.
Lloyd McKenzie (Mar 29 2019 at 17:56):
Knowledgebases that have images are pretty-much all driven by the NDC code.
Lloyd McKenzie (Mar 29 2019 at 17:57):
And neither will tell you about manufacturing process changes that aren't sufficient for the FDA to force a distinct NDC code.
John Moehrke (Mar 29 2019 at 18:06):
but that could be the code used to index MedicationKnolwedge. right? If so, then that might be refined enough (I have homework).
John Moehrke (Mar 29 2019 at 18:07):
But that is not what is Prescribed, which is a much higher granularity. Which was my concern.
John Moehrke (Mar 29 2019 at 18:10):
I got confirmation NDC is sufficiently granular.
Jose Costa Teixeira (Mar 29 2019 at 19:09):
nice to see things are clear over there.
Jose Costa Teixeira (Mar 29 2019 at 19:10):
FWIW, i think there was an attempt to make the IDMP identifiers GUIDs. that was fun.
Jose Costa Teixeira (Mar 29 2019 at 19:14):
in general, there are N levels of granularity, which are overlapping, not harmonized across countries. Hospital pharmacies prepare their own products and new codes emerge. Some levels of granularity can be in a dispense, others not. Reducing it to RxNorm and NDC serves to demonstrate that we can (normally) retrieve the picture of the dispensed product from a catalog for pre-manufactured products.
As long as we conceive other codes, other granularities, the solution will still work.
John Moehrke (Mar 29 2019 at 19:25):
a GS1 barcode should be possible..
Jose Costa Teixeira (Mar 29 2019 at 19:34):
Good point. GS1 barcode is the carrier for the product identifier which is the GTIN. GTIN is at the lowest level of granularity (a package that changes color of the logo may get a new GTIN but may or may not require the regulator to grant a new Medicinal Product Identifier.
John Moehrke (Mar 29 2019 at 19:35):
that is what I meant to say when I said GUID... oops
Jose Costa Teixeira (Mar 29 2019 at 19:35):
Thus indeed, as long as we have a code, we can look up the medicine picture. But may be on whatever granularity code.
Jose Costa Teixeira (Mar 29 2019 at 19:35):
Ah ok. then I am glad. (but the GUID idea was in the air somer time ago)
Last updated: Apr 12 2022 at 19:14 UTC
