FHIR Chat · Catalog of meds · implementers

Stream: implementers

Topic: Catalog of meds

Jose Costa Teixeira (Jan 19 2018 at 16:44):

After 2 years looking to describe "this medication concept includes/contains/refers to that other medication concept", and a few PSSs, it seems we now have abundance.
So, here are some requirements from implementing this.

• There is not a single master of drug formulary . this is federated data.
• The boundary between devices and medications is very thin and implementers cannot be forced to cross big borders between them. One thing is a device in one country and a medication in another.
• There is no universal concept of "a medication", nor which attributes are in there - in some places the medicine concept A is defined by manufacturer+substances+strenght. In other places, the medicine concept B is defined by all that + package size. in others, Medicine concept C is defined by all of the above except brand name. ISO IMP establishes 3-4 core concepts. But diversity is there and is to be supported.
• There is DEFINING a product and SPECIFYING a product. Those are different.
• There are additional more-or-less contextual attributes like classifications
• There are additional relations between items that are used in a specific scope/context.

I hope this helps

Jean Duteau (Jan 19 2018 at 17:11):

@Jose Costa Teixeira Can you be clear about what these requirements are for? I'm unsure if you are stating what you want for our MedicationKnowledge resource to handle or whether you are just stating some generic requirements. In any case, here are my comments:

A) I agree. There are multiple drug formularies across jurisdictions and even different formularies serving different purposes within a jurisdiction. In one jurisdiction that I have implemented systems, we have 1) a drug knowledgebase that lists all of the known products that can be prescribed and dispensed, 2) a formulary that lists everything that the government insurer will be paying for, including costs and other restrictions, 3) a catalog of restricted use products.
B) I totally agree with this. In Canada, we are actually using the existing Medication resource to convey anything that can be prescribed/dispensed because its existing attributes work for this. It loses the point of the name, but it works for our implementation. :)
C) I don't agree with this but it might because I don't see what point you are trying to make. I think it goes with the previous point that we will provide a resource that satisfies the use cases of our implementers and if they then use this resource for a bigger scope than we intended and it works for them, then kudos to them! :)
D) The Pharmacy WG has gone further and said that there are three different "views" of a Medication.
E) I disagree that classifications are contextual. You'll have to provide some examples of classifications that are contextual and are not inherent to the product itself. Perhaps this is just definitional of what we mean by classifications and what we mean by contextual.
F) Although I'm willing to admit that this might be true, I have been unable to find relations between items that are restricted to a specific scope. There are groupings that are restricted to a specific scope, but that is not relationships between entries.

We should have some very interesting discussions in New Orleans! :)

Jose Costa Teixeira (Jan 20 2018 at 07:15):

Good, we are finally discussing requirements. Thanks. These requirements are for catalog of meds&devices.
Catalog discussion in OO seems to conflict with medicationKnowledge in Pharm. I think it would be good to fix that.

Jose Costa Teixeira (Jan 20 2018 at 07:18):

for item c) see discussion on Concept Type https://chat.fhir.org/#narrow/stream/implementers/topic/concept.20type.3F
For the others we can discuss in the Catalog or in the medicationKnowledge(if we find a slot)

Jose Costa Teixeira (Jan 20 2018 at 07:24):

We needed to draft the entryDefinition resource and will be testing it next week. Feel free to comment on it, as well.
I will gladly contribute with comments on this Knowledge resource when it is there.
BTW, if there are different views, you may not be asserting knowledge, you may be asserting a local definition. So it would make me much more at ease if we call that resource medicationDefinition or medicineDefinition.

Jean Duteau (Jan 22 2018 at 06:02):

Good, we are finally discussing requirements.

We have actually been discussing requirements of the Medication Knowledgebase in Pharmacy for a few months now. And I'm sure that you've been involved in those discussions.

I think the main worry that I have is that it seems that your concept of what the Catalog is and the Catalog entry doesn't seem to match what I've seen from others, including the existing draft resources and profiles. I'm actually pleased with what I see in the current draft profiles where they leave the actual knowledge of what the catalog contains to domain-specific resources. The catalog and the catalog entry are very abstract things that just serve as another way of grouping resources. That totally fits the picture I have of a Jurisdictional Formulary that has sections as groupers. It also fits my knowledge of how First Data Bank catlogs their prescribable drug products.

In any case, the Pharmacy WG will continue to go forward in investigating what our MedicationKnowledge / MedicationDefinition resource will look like and how it fits in the continuum of products, medications, and such.

Jose Costa Teixeira (Jan 22 2018 at 08:52):

Catalog candidate resources have been designed based on the agreement that intrinsic attributes of product are in the product, and contextual stuff is on catalog. Don't see any issue with that, or why that is not clear.

Jose Costa Teixeira (Jan 22 2018 at 08:53):

There are some requirements that stem from openMedicine, as discssed a few years back and that gave origin to a couple PSSs

Jose Costa Teixeira (Jan 22 2018 at 08:54):

(btw, catalogEntry is now entryDefinition)

Jose Costa Teixeira (Jan 22 2018 at 08:58):

Other requirements from implementation:
G) Align with GS1 Catalog Item Notification - we did that in catalog, much of this is already there, child products and packaging.
H) Must support clusters (structured and ad-hoc groups)
I) Support segmentation (some attributes in context A are not the same as those attributes in context B).

Jose Costa Teixeira (Jan 22 2018 at 09:00):

i haven't seen medicationKnowledge yet, nor the discussions, sadly. So i exposed what we had in Catalog.

Jose Costa Teixeira (Jan 22 2018 at 09:03):

And i am glad the Catalog resources fit your vision. Any feedback from this discussion of from implementation is appreciated.

Lloyd McKenzie (Jan 22 2018 at 16:47):

I disagree with the notion that contextual information is catalog-specific. Price is not a notion that requires the use of catalogues. Lots of organizations establish, change and add new prices for things continuously and no catalogues are involved. Therefore in FHIR "price" should not be in a catalog-specific resource - it needs to live in it's own resource. The same argument applies to what products/services are available from a particular location, covered under a certain plan, etc. I can't think of a single piece of information that would be specific to catalogues that isn't already covered by Composition as metadata about creating the compilation of information for a particular catalogue publication.

Lloyd McKenzie (Jan 22 2018 at 16:49):

ItemInstance does not reflect information that is typically stored separately. Every database I've seen stores serial numbers and lot numbers in the device table or the medication table, not in a separate "instance" table. I'm fine with the notion of an ItemInstance pattern, but trying to separate things out because it makes for nicer modeling is not a good plan.

Jose Costa Teixeira (Jan 22 2018 at 17:05):

(Leaving itemInstance out, because I don't see it as part of this discussion (is it?))
A catalog of meds will not be only about the product, but how the product is seen in that specific context.
Pricing is one of those things that can live in the product itself but will be shared as part of the catalog.

Jose Costa Teixeira (Jan 22 2018 at 17:07):

so, we can step back in the analysis: we can say that product-specific things are in the product, and that information that is contextual will eventually be transmitted in a catalog (and other places too, i'm sure).
I recall an example where reference price is in the prescription. It's not defined there, but it comes from the catalog.

Jose Costa Teixeira (Jan 22 2018 at 17:11):

Lots of organizations establish, change and add new prices for things continuously and no catalogues are involved.

Perhaps the word Catalog has different perspctives to it.
The idea of Catalog is to support "the following characteristics and relations of these items, as updated today, are:... ".
Or better put - regardless of how we call it, hospitals need to get data about product updates. Can be a full document, can be a differential product definition update.

Lloyd McKenzie (Jan 22 2018 at 17:16):

I don't think anything "comes from" a catalog. A catalog is a way of presenting information that already exists elsewhere. When hospitals get information about product updates, the "data" would be in the definition resources. Whether those get delivered in a document, via pub-sub, via query or something else doesn't matter.

Jose Costa Teixeira (Jan 22 2018 at 17:18):

I don't think anything "comes from" a catalog. A catalog is a way of presenting information that already exists elsewhere. When hospitals get information about product updates, the "data" would be in the definition resources. Whether those get delivered in a document, via pub-sub, via query or something else doesn't matter.

i can agree with that - have a different idea of a catalog, but it works here too.

Aleksandra Pavlyshina (Apr 08 2019 at 21:38):

Hi all,
we're modeling a catalog of medications (formulary) for medical organizations in a region.
Could you please direct me if there are any guidelines on how to do it?

Currently, we consider 4 options of the modeling:
1. Medication resource (for branded medications that can be ordered in a med org, with information about manufacturer, primary and secondary package and amount in the package, etc., that reference generic medications (actually, substances with form and strength) + CodeSystem resource (catalog of generic medications with form, strength, units of measure for consumers, reference costs, different classifications, etc.)
2. Medication resource (for branded) + Medication.ingredient.itemCodableConcept (for generic)
3. Medication resource (for branded) + Medication.ingredient.itemReference(Medication) (for generic)
4. Medication resource (for branded) + MedicationKnowledge (for generic)

Jose Costa Teixeira (Apr 08 2019 at 21:54):

I would use medicationKnowledge for all levels- branded and generic. except substance definitions. so for example "paracetamol 500 mg tablets" is a medicationknowledge. "paracetamol" is a substance.

Jose Costa Teixeira (Apr 08 2019 at 21:55):

not sure why you would use medication to define a product in a catalog.

Aleksandra Pavlyshina (Apr 09 2019 at 08:42):

We're going to define medication products in a catalog as the Medication resource because these medications will be used in the prescription workflow, and the reference from the MedicationRequest and MedicationDispense resources is only to the Medication resource. Is it correct?

. medication[x] Σ   1..1        What medication was supplied
.... medicationCodeableConcept          CodeableConcept
.... medicationReference            Reference(Medication)

Jose Costa Teixeira (Apr 09 2019 at 08:48):

The catalog is a collection of definitional resources, so it should be the medication definitional resource (currently called medicationKnowledge)

Jose Costa Teixeira (Apr 09 2019 at 08:49):

each medication that you prescribe will have a code which should then allow you to look up the medication in a catalog of MedicationKnowledge

Jose Costa Teixeira (Apr 09 2019 at 08:51):

say you prescribe 10 tablets of a drug that comes in boxes of 20, or that you prescribe a soluble drug... what you prescribe is what medication is for. How the drug is defined in the catalog that is the medicationknowledge.

Jose Costa Teixeira (Apr 09 2019 at 08:53):

i am leaving out the matters of medicinalproduct and others which are WIP.

Jose Costa Teixeira (Apr 09 2019 at 08:54):

but if you want to define a product, there are lots of fields that you do not have in medication but do have in medicationKnowledge.

Jose Costa Teixeira (Apr 09 2019 at 08:58):

if the reason for chosing medication would be because the workflow resources point to it, that should not be a reason.
I am curious how many people have implemented drug catalogs while we did not provide clear consistent guidance how to do it (not that this would be bad, it is just just that we have to chase things a bit).

Lloyd McKenzie (Apr 09 2019 at 15:07):

It's ok to have a registry of just Medication instances. MedicationKnowledge is only relevant if you're going to actually capture the 'knowledge' information. If what you care about is having a dropdown you can select meds from to prescribe, dispense or administer, Medication gives you what you need. If you need the knowledge information, then quite typically, that would be the only thing in your registry (unless you're also wanting to store custom compounds). You'd look up the code in the MedicationKnowledge and then just send that code in the MedicationRequest/MedicationDispense/etc. and not bother with Medication.

Melva Peters (Apr 11 2019 at 16:31):

@Aleksandra Pavlyshina you can use Medication instances, but if you need more details that is included in the Medication resource, I suggest you look at MedicationKnowledge. The MedicationKnowledge was developed with formularies and drug knowledge bases in mind.

John Silva (Apr 11 2019 at 16:47):

Thinking about MedicationKnowledge and the 'drug DB companies' --- how does the modeling done so far deal with the fact that the drug DB companies regularly update their info (DBs)? How does is 'lifecycle' of the drug info handled, e.g. I would imagine that the history of the drug info needs to be maintained for past administrations that have already been given -- or is that left to the DBs themselves and not for FHIR MedKnowledge to worry about?

Jean Duteau (Apr 11 2019 at 16:48):

We are still in the process of getting the companies to come to the table and tell us how they use FHIR, but I suspect that is not something that the resource needs to worry about - other than perhaps a status field.

John Silva (Apr 11 2019 at 17:17):

@Jean Duteau - I suppose if the DB companies have a product that puts up a FHIR facade then they can maintain the historical (or recalled) drugs while only exposing the current/active drugs to the prescribers and fulfillers (those who perform MedAdmin). However, there may need to be something more than just status (active/inactive/withdrawn/recalled) because previous Med resources that reference the old drug info may need to retain that for historical (and in the US and other countries) legal reasons. (maybe FHIR version history can solve this as long as the business identifier remains the same?)

Jose Costa Teixeira (Apr 11 2019 at 17:58):

The history of a catalog is maintained in the catalog itself

Jose Costa Teixeira (Apr 11 2019 at 17:59):

they would expose the "current release of the catalog" (a snapshot) using Composition.

Jose Costa Teixeira (Apr 11 2019 at 18:07):

and i think so, the business identifiers should remain the same. that should enable to show the history of the meds and also the relations between the meds and other stuff (e.g. between a med and a device)

Jose Costa Teixeira (Apr 11 2019 at 18:10):

I'm told of one french drug db vendor that is making a FHIR façade for their catalog.

Aleksandra Pavlyshina (Apr 14 2019 at 17:02):

Thank you all for your answers!
Now, we’re considering the following solution:

• To use the MedicationKnowledge resource for drug formulary.
• To use the MedicationRequest resource for simple medication prescriptions specifying the medication code from MedicationKnowledge (MedicationRequest.medicationCodeableConcept = MedicationKnowledge.code).
• To use MedicationRequest with inlined (contained) Medication resource for complex medications (such as drug solutions) where Medication.ingredient.itemCodeableConcept will hold the MedicationKnowledge.code and an amount of the medication will be captured in the Medication.ingredient.strength.numerator element.

Could you please verify?

Jean Duteau (Apr 14 2019 at 18:52):

Yes, that is how the Pharmacy workgroup intended the resources to be used.

Last updated: Apr 12 2022 at 19:14 UTC