Stream: BRR - Pharmacy model
Topic: Other Definitions of medicinal products
Jose Costa Teixeira (Oct 21 2018 at 19:04):
We have a few resources to convey "the relevant characteristics of a medicinal product".
Some resources for the top regulators, some resources for the clinical world.
Some resources aligned to IDMP, others not focused on that.
Out there, we will have variance. How is FHIR going to support it?
how do we support the several levels/concepts of medication? For one country, the top level is "generic" but for another it will be "active substance".
- RxNorm has 2 levels IIRC
- IDMP has several levels (4 concepts, but one of them has several levels)
- DCI / ICD has not levels, but just substances (and is still a target for national prescription)
- Countries have levels of granularity that can be Generic , Brand , Package, etc. this is not a small set.
They are all useful.
Jose Costa Teixeira (Oct 21 2018 at 19:05):
(sorry for repost)
Jose Costa Teixeira (Oct 21 2018 at 19:08):
in Open Medicine, we could (only?) solve the issue by having a "master medicinal product attribute set" from which we could select a couple of attributes to define a Pharmaceutical Product, or a substance, or a branded product... This avoided some ideas to prevent proliferation of concepts.
Jose Costa Teixeira (Oct 21 2018 at 19:08):
I personally am inclined towards a "master" definitional resource that can be profiled, rather than several resources with specific purposes.
This could include regulatory needs (e.g. a Pharmaceutical Product is a Medication Definition for which Substance, Strength, Dose Form... are present, medicinal Product is one where Manufacturer, brand... are present."
Jose Costa Teixeira (Oct 21 2018 at 19:08):
I know this will get interesting when looking at medicinal products that have two pharmaceutical products (e.g. oral contraceptives, or packages that have different types of antibiotics for a given schedule) but i just wanted to launch the need:
IDMP is one of the great things that happened in this topic, and we must support it, and provide a bridge to all the other "medicinal product definitions" that exist in local regulatory jurisdictions, or inside a given hospital, or inside the context of a given insurance plan...
Jose Costa Teixeira (Oct 22 2018 at 06:12):
Quoting @Dion McMurtrie
I've thought about this quite a bit too @Jose Costa Teixeira and it does seem a bit awkward at present. It seems FHIR currently has 3 concepts of medications -
* Medication - used for instance resources in prescribe/dispense...etc events
* MedicationKnowledge - used to provide reference and definitional information about medicines, e.g. from terminology
* "Medication Definition" resources - appear to be a FHIR rendering of IDMPI've spent time working on STU3 representing terminology definitions using Medication because I started before MedicationKnowledge existed. For my use case there were many required extensions to Medication to support what I wanted to do. You can see the latest results at https://medserve.online
Perhaps moving to MedicationKnowledge will resolve some of these extensions (I'm yet to do that analysis), but both Medication and MedicationKnowledge have this strange (to me) modelling with respect to "units" (like a tablet) versus packages (like a bottle of tablets) and the resulting consequence of being able to represent nonsense.
The "Medication Definition" resources are much more detailed in their modelling, separating out this concept clearly, but are also much more detailed than the use case I've got - I want to provide AMT and other medicines terminology content via an easy to consume API, and FHIR makes a pretty good candidate for this.
So I'm really interested where this goes, but I agree something that is probably more maximal than MedicationKnowledge (maybe split it in two first) and then profiled for various use cases makes sense...but that's just my thought.
I'd be interested to sit in on that discussion if possible...
@Melva Peters has provided the details of the calls. The BRR folks are in European time, so timing may be an issue.
Rik Smithies (Oct 25 2018 at 14:53):
Re this idea @Jose Costa Teixeira "I personally am inclined towards a "master" definitional resource that can be profiled, rather than several resources with specific purposes."
The issue with this is that by far the most commonly used subset as used in the Medication resource is very much smaller than the full set of data items.
We have, more or less, ruled out the idea of using an actual FHIR profile of some all encompassing SuperMedication for what the the day to day Medication resource is used for now. Done that way, everyone would need to use a profile of a huge resource, when only a small percentage users actually care about the other 90%.
Even as someone coming at this from a regulatory point of view, I feel that this puts the burden in the wrong place.
Having a profiled set of resources has some elegance in engineering terms but would make it hard for implementers. The commonly used things need to be as easy as possible to use.
Instead, the current thinking is to have a logical supserset model (not directly implementable) and do "logical profiles" of it, into Medication, MedicationKnowledge, and MedicinalProduct and the other "definitional" resources.
There will be overlap in physical terms, but this is mitigated by the logical model that documents this, and shows what belongs where. We do plan to refactor as much as possible so that there is little physical overlap between the MedicationKnowledge and MedicinalProduct resources.
There is perhaps some scope for other parts of the models to be collapsed together however, possibly for instance MedicinalProduct and MedicinalProductPharmaceutical.
Jose Costa Teixeira (Oct 25 2018 at 15:16):
Hi @Rik Smithies Not sure if I understand well, but i agree that we should have a logical superset model of whic the definitional resources are profiles.
Jose Costa Teixeira (Oct 25 2018 at 15:16):
It seems I missed a key point:
The "master definitional" would be definitional, so including PhP, MP, MedicationKnowledge... but not taking the role of the medication resource used in prescriptions, etc. - which is much smaller indeed.
Jose Costa Teixeira (Oct 25 2018 at 15:17):
i personally see that when that model exists, MedicationKnowledge could also be a profile of it.
Rik Smithies (Oct 25 2018 at 15:18):
Yes this logical model that we (in fact @Jean Duteau) is drafting, has all the content from PhP, MP, Medication Knowledge etc.
Jose Costa Teixeira (Oct 25 2018 at 15:18):
and you are correct (perhaps that is the point i missed), better than a master resource, we can have a logical pattern
Jose Costa Teixeira (Oct 25 2018 at 15:19):
ok that is what i mentioned before and my preferred approach. in Cologne I got convinced that it was way too early to think of patterns there, so i am happy we are going there
Rik Smithies (Oct 25 2018 at 15:20):
So maybe that is the key thing yes, it won't be a FHIR resource, just a UML model to explain how things fit together. So it won't be "profiled" in literal FHIR terms. But the effect will be similar.
Jose Costa Teixeira (Oct 25 2018 at 15:20):
btw, when we get there, I am pretty sure that the boundary between medication resource and medicationDefinition or whatever the name will not be very clear, so i am betting we can also do something there
Jose Costa Teixeira (Oct 25 2018 at 15:21):
i'd suggest a pattern that can be put in FHIR, like we have for request, etc.
Jose Costa Teixeira (Oct 25 2018 at 15:22):
(silly) example for boundary medication / medicationDefinitionalResource:
Patient states they are having a medication, which is the white and red capsule and is for the stomach. that is in a clinical workflow, but even there we are providing enough information about the medication.
Jose Costa Teixeira (Oct 25 2018 at 15:25):
better example for medication/Definition boundary: openMedicine. Across borders, you cannot point to a medication because a common code does not exist. But you can send all the characteristics you know and those will be used on the other side. In that case, it is a medication / definition thing.
(i know IDMP will solve all that, but this use case will stil exist, and we are taking advantage of the best of IDMP: A logical model with clearly defined elements.
Rik Smithies (Oct 25 2018 at 15:26):
I see Medication and MedicinalProduct (I think this is what you are calling MedicationDefinition) as somewhat like child and parent. Basic version and full version. (MedicinalProduct is really a set of resources "MedicinalProductEtc" however). MedicationKnowledge is perhaps more of a sibling of Medication, since it is a different set of information items, rather than more detail. But it's not that clear cut of course, and some of MK is in MPEtc (but some is not).
Jose Costa Teixeira (Oct 25 2018 at 15:26):
but perhaps we hold that for later. I am happy that we are going towards a UML pattern. That is good news.
So my question is: will we then have different resources? i don't see a need, they can be profiles.
Jose Costa Teixeira (Oct 25 2018 at 15:27):
this big supermodel of medication characteristics is what i call the medication definitional resource. same as "medKnowledge"
Jose Costa Teixeira (Oct 25 2018 at 15:31):
my main point is that I don't see how many resources we will have for the definition bit:
a) we have One single FHIR core resource, of which MP (regulatory), PHP (Regulatory), MK(drug databases), and other custom flavors, like US RxNorm concepts, and other national stuff like NationalProductDefinition, HospitalCodeDefinition, GenericPRoduct,... are profiles. We'd have one resource or pattern, and several profiles.
b) we have one resource for PharmProduct, one for MedProduct, one for PackagedPRoduct(IDMP), one for NationalPackageConcept, one for "National Code"... where will it end?
Jose Costa Teixeira (Oct 25 2018 at 15:32):
sure, medication is a special case. i am only about the definitions bit.
Jose Costa Teixeira (Oct 25 2018 at 15:34):
i also definitely don't want a big resource when it comes to instances (one resource on the server for each serial number of the product)...
Jose Costa Teixeira (Oct 25 2018 at 15:34):
i just think that we should have a way to have a superset of information elements and a proper structure,from which the 80% of the definitions of medications can be profiled. We profile a few core ones,
Rik Smithies (Oct 25 2018 at 15:36):
my main point is that I don't see how many resources we will have for the definition bit
That is being worked out now. It's too big for one resource though. For instance contraindication is part of this and that is surely a different resource to the product itself.
Rik Smithies (Oct 25 2018 at 15:45):
btw MedicationKnowledge is not the name of the superset, nor the same concept. Despite the name it is not "all the knowledge that exists" about a medication. It is designed to have the extra knowledge that is commonly needed to support day to day prescribing. That doesn't include all of the regulatory set of data items.
Jose Costa Teixeira (Oct 25 2018 at 16:29):
For instance contraindication is part of this and that is surely a different resource to the product itself.
I don't see how contraindication needs to be a resource. I see how it could be, not why it must be
Jose Costa Teixeira (Oct 25 2018 at 16:30):
btw MedicationKnowledge is not the name of the superset, nor the same concept. Despite the name it is not "all the knowledge that exists" about a medication. It is designed to have the extra knowledge that is commonly needed to support day to day prescribing. That doesn't include all of the regulatory set of data items.
That is what I suggested to align. I think the name "knowledge" is misleading, and I do know that there is no single way to define a product. Even inside a hospital there will be many medication concepts that need to be defined. Some regulatory, some logistic, some scientific.
Jose Costa Teixeira (Oct 25 2018 at 16:33):
for example in one implementation, we had to consider the "logistical definition" of "logistic aspirin (as it was seen from the ERP), the "scientific definition" of a "scientific aspirin" (as it was seen from the drug DBs), the "regulatory definition" of the "regulatory aspirinS" (as it was from the national catalogs) and the hospital's own definitions (as they were governed in the EHR)
Jose Costa Teixeira (Oct 25 2018 at 16:34):
all of these are different concepts, different granularities, different IDs.
Jose Costa Teixeira (Oct 25 2018 at 16:34):
so, for solving these kinds of issues, we need something that we can extend. Hence my idea that we should have one FHIR resource that can hold this information (and which we can constrain or extend)
Jose Costa Teixeira (Oct 25 2018 at 16:36):
one of the key enablers of openMedicine was to provide that bridge, from the IDMP concepts to "any" concept/granularity of medication.
Jose Costa Teixeira (Oct 25 2018 at 16:38):
and iirc that was one of openMedicine's requests to HL7:
support definitions of products, and make sure that FHIR supports conveying different kinds of product information, whether they are IDMP concepts or other concepts, without trying to model the entire set of medication concepts.
Rik Smithies (Oct 27 2018 at 14:01):
Well we do aim to cover that request. Let me know if you see that the current thinking does not fit with that.
There will definitely be some challenges with what to call things, that is inevitable and ultimately unavoidable. But good discussion and good documentation should mean we can land on names that work.
Why would contraindication not be a resource? it is a repeatable reusable chunk. You may want to add one to a product that already exists (possibly in some other repository or code system), hence it needs its own lifecycle. It may be about a Medication or a MedicinalProduct, or be part of MedicationKnowledge, or some other treatment, so that also points to something that is separate. Those all suggest it being a resource.
Hence my idea that we should have one FHIR resource
Can you describe which data items would be in this resource and what its scope is?
Jose Costa Teixeira (Oct 27 2018 at 18:59):
contraindication seems to be an attributed relation between a product and a condition (or something else). While it makes it interesting, I'm not sure this makes it a viable candidate for resource (but I can't really point at a clear reason, sorry).
Jose Costa Teixeira (Oct 27 2018 at 19:01):
You may want to add one to a product that already exists (possibly in some other repository or code system), hence it needs its own lifecycle.
In my opinion, this is not a valid conclusion. when we add a contraindication to a medication you are not altering the lifecycle of a medication, you are altering the actual medicinal product characteristics as they should be seen by whoever uses it. So it points at a characteristic of a product.
Jose Costa Teixeira (Oct 27 2018 at 19:04):
It may be about a Medication or a MedicinalProduct, or be part of MedicationKnowledge, or some other treatment, so that also points to something that is separate.
In fact, contraindications can be about any level of granularity of product.
This example is clearer and while I don't think a contraindication is a separately governed entity, i see why you are thinking of something that can be reused in several places.
But if the medication or medicinalProduct or ... are the same resource, the first half of the problem no longer exists - a contraindication can be a characteristic of a product, regardless of the level and type of the product.
Jose Costa Teixeira (Oct 27 2018 at 19:21):
I think there is one problem that is still not solved - a way to support non-IDMP regulated product definitions. Making one resource for each level is OK if we have 4 to 7 levels like IDMP, but will still need to be used in practice.
I think medicationKnowledge is closer to that and it reflects most of my ideas, so I am in favour of one MedicineDefinition resource or logical model, that contains information about:
. What level of granularity it is (PhP, MP, PCP, Generic, HospitalCode, RxNorm,...)
. A link to a base definition (what is the "parent" level product)
. The identifying attributes of all the IDMP levels. Substance, Strength, Package Size, etc. (http://www.open-medicine.eu/fileadmin/openmed/re_documents/openmedicine_deliverable_3.2_v1b_fin_after_atr.pdf#page=29)
. Standard extensions (if it is a resource) or core optional attributes (if it is a mode) for all the necessary IDMP regulatory stuff, and them some.
. Profiles (of resource) or
How to use:
If we want to define a PHP, we have one resource with Substance, route, etc filled in. No MAH, no package
If we want to define a MP, we have another resource that points to the PhP(s), and then we fill the rest of the stuff: MAH, Brand Name...
If we want to define any another granularity level, we pick their characteristics:
- a US NDC can point to the RxNorm(?) parent and provide the brand name and manufacturer...
- A European "Hospital Code" or "national dispense code" links to the PhP, adds package size '''without''' specifying the manufacturer.
..
Rik Smithies (Oct 27 2018 at 20:22):
hi Jose, we still have the basic issue that the most commonly used entity - Medication - should not be a profile of a much larger thing that is not of interest to most users. This I see as a fundamental blocker to all the more elegant designs where everything is profiled sub-type of some large model.
I think there is one problem that is still not solved - a way to support non-IDMP regulated product definitions.
Do you have specifics on why what we have drafted now doesn't work for that?
What is drafted now could be joined up into one super resource, but it would become a big monolith.
If I want to assert a contraindication or an interaction, I don't want necessarily want to update the product definition. I may not even have write access to that. Or I may only want to refer to the code for a medication. There may be no product resource for the contraindication to live in.
Jose Costa Teixeira (Oct 29 2018 at 15:19):
If I want to assert a contraindication or an interaction, I don't want necessarily want to update the product definition. I may not even have write access to that. Or I may only want to refer to the code for a medication. There may be no product resource for the contraindication to live in.
Ah, the way I see it, you do want to update the product definition. Not the "regulatory" product definition, but if you say "as of now I am stating that this may interact with that", you are defining a product characteristic
Jose Costa Teixeira (Oct 29 2018 at 15:21):
possibly the cause for some communication mismatch: Products will be defined along the chain - first by the manufacturers, then by the regulators (Regional and national) and then further defined or enriched in the hospital, then in the ward...
Jose Costa Teixeira (Oct 29 2018 at 15:22):
So if you consider that all products are defined at top level, then
a) it's hard to fit the continuum to medicationKnowledge in that picture
b) yes, you would need a big monolith
c) that is not what I am proposing.
John Silva (Oct 29 2018 at 15:32):
@Jose Costa Teixeira - how does an interaction complement or relate to an allergic reaction? Is the "interaction" product specific and not based on a specific patient whereas an allergic reaction is patient specific? (which brings up the related question of how do these contraindications and interactions relate to the AllergyIntolerance resource? In HL7 V2.x there seemed to be some overlap since an AL1 or IAM could be defined by the type, e.g. drug or food, etc.)
Rik Smithies (Oct 29 2018 at 16:26):
@Jose Costa Teixeira I am not disputing that an interaction is a characteristic of a product, just saying that it is not always good to have every characteristic of a product in one resource, for practical reasons.
Rik Smithies (Oct 29 2018 at 16:32):
@John Silva The idea of the current resource (MedicinalProductInteraction) is that it is definitional and refers to a known interaction that can happen. It is not any particular instance of it actually happening. It's what might be written on the piece of paper inside the packet of tablets.
Jose Costa Teixeira (Oct 29 2018 at 17:03):
@Rik Smithies agree that on an instance of the resource you may not want to have everything.
Jose Costa Teixeira (Oct 29 2018 at 17:05):
But I don't yet see a way to support the cascading and enriching of product definitions unless we have a pattern that can be instantiated differently in different instances
Jose Costa Teixeira (Oct 29 2018 at 17:08):
So concretely if a product is defined as having a contraindication on the regulatory side, when the hospital defines their own flavour of the product they would use the same resource type but trim down some of the attributes and create a new resource instance. And conversely if that internal redefinition means that a new granularity is defined and the new code is justified then they have this new instance of the same resource type but with other code
Jose Costa Teixeira (Oct 29 2018 at 17:12):
I can work out a better example, but please consider the national product concepts that include active substance, strength, package size. This is an official product definition, and not an idmp concept. And it will have attributes like contraindication and indication.
Jose Costa Teixeira (Oct 29 2018 at 17:15):
And then in the hospital they have what we called the"logistics product" whose definition is the ERP code, short name, distribution constraints, barcodes and what not.This is a catalogue the Hospital will publish regularly, and linking to the regulatory product definitions
Jose Costa Teixeira (Oct 29 2018 at 17:21):
@John Silva as Rik says here we are not looking at workflows. Only the product definition . FHIR allows us to make a very nice and clear distinction between a) a product being known for causing some allergies, b) a patient being known to have some allergies to some medication and c) a patient actually having an event of allergic reaction. This present discussion only covers item a)
John Silva (Oct 29 2018 at 17:40):
@Jose Costa Teixeira - OK, thanks for the clarification. I thought that the AllergyIntolerance was only for recording 'instance' info but wanted to clarify. (I guess I'm still trying to understand the workflow side of things so my questions lean towards that.)
Jose Costa Teixeira (Oct 29 2018 at 20:50):
For all the above definitions of product, I think that MedicationKnowledge is the one that provides a more versatile approach. it can support different levels of products in catalogs.
Rik Smithies (Oct 30 2018 at 16:38):
Remember that MedicationKnowledge, despite the name, was never intended to be the source of all knowledge of the product. It has a different scope. It's not intended to be huge model that can polymorphically represent all levels of products. Think of it as "MedicationPrescribingSupportData", or something. Yes we need something somewhere that has that it all, but let's not reuse the current definitions. I see this big model as a logical model, only, with concrete expressions that are cut to best match how users would like to use them, and in chunks that are palatable in size and ability to be comprehended. We don't want common product model back again :-)
Jose Costa Teixeira (Oct 30 2018 at 17:49):
I had the name "medicationDefinition" exactly because there is no central whole knowledge about a product.
But I would want to hav something that while not representing all levels, can represent any level - for the simple reason that this is how things are working and will work - there are lots of levels and we should not try to have one resource per level
Jose Costa Teixeira (Oct 30 2018 at 17:49):
starting with names that are not overloaded is always a good idea, yes :)
Jose Costa Teixeira (Oct 30 2018 at 17:52):
I am sure the model will work for the IDMP regulatory and prescribing cases, I just want to make sure that there is a continuum there. For scope, I assume that "product" can have many meanings, i.e. it can be defined at any level of granularity.
Rik Smithies (Oct 30 2018 at 18:28):
We do want to be able to cover products at all "levels". I suggest for now we see if the current models fit all the use cases we have. If not we need to re-think.
Jose Costa Teixeira (Oct 30 2018 at 18:38):
"all levels" should be part of "the use cases we have", right? (and by "all, i think you mean "any") I hope it is clear that no single resource instance should define more than one product in one level. but one resource type should support several levels
Jean Duteau (Oct 30 2018 at 18:56):
The determination of use cases is the task that FMG has put forward to us - Pharmacy and BRR - to determine. We obviously have implementer need for the current Medication resource and for the IDMP work that Rik is doing. What we haven't had is a solid implementer requirement for any other use case. Scott Robertson and I are heading to NCPDP next week to get some support for our current MK resource use case from the participants there and there has been some other work in Baltimore to find implementers who need what MK is proposing to provide. If there are other implementer needs/use cases that call for other representations, we need to find those out and determine what they need.
Jose Costa Teixeira (Oct 31 2018 at 14:54):
The clinical and regulatory use cases are not isolated, and there is the interoperability need . As long as we solve the continuum we should be ok.
Jose Costa Teixeira (Oct 31 2018 at 14:55):
Hence my bet on a more flexible resource that does not stick to a concept (medknowledge).
Jose Costa Teixeira (Oct 31 2018 at 15:04):
So, interoperability use case: "national regulator gets information about products, in the 3 idmp levels; they define national medication concepts of 2 different levels, none of them idmp concepts, and then drug database vendors enrich information at the appropriate levels - some knowledge is added at substance level like classification/schedule, other information is added at other levels such as average expected customer price. And hospitals add more information elements to define local concepts or add local characteristics.'
Jose Costa Teixeira (Oct 31 2018 at 15:06):
I am just drawing attention that imo this is not a matter of one scope Vs the other. This matter is hard enough to implement, standards should help by supporting the complexity
Jose Costa Teixeira (Oct 31 2018 at 15:13):
If needed I can produce an example, this is pretty common stuff
Jean Duteau (Oct 31 2018 at 15:17):
I've heard this use case a few times but no one can actually tell us of an actual implementer whose software handles all of these cases in one package. The closest that I've been provided is an implementer who has two different software packages - one for submitting regulatory information and a separate one for maintaining similar information for use in trials. But even that implementer admitted that it was separate packages and they didn't need one resource but rather just consistent representations.
Jean Duteau (Oct 31 2018 at 15:18):
If you know of European implementers who do have one package that handles the various levels and would push for one resource or profiles, getting them to come forward would be wonderful.
Jose Costa Teixeira (Oct 31 2018 at 15:19):
No software does it all (yet). First DB wanted to look at idmp so they may need to cover the entire spectrum.
Jose Costa Teixeira (Oct 31 2018 at 15:20):
Vidal is engaged with idmp so they will want to do that too - all the way to the hospital because they cover a broad part of that chain
Jose Costa Teixeira (Oct 31 2018 at 15:21):
I think they are involved in the catalog discussions. @François Macary @Lorraine Constable @Claude Nanjo ?
Jose Costa Teixeira (Oct 31 2018 at 15:22):
(sorry, missed post) perhaps check with the catalog discussions @François Macary@Lorraine Constable@Claude Nanjo
Jose Costa Teixeira (Oct 31 2018 at 15:26):
But my focus is that we need a continuum. This the experience I can bring from Integrating this in hospital and from openmedicine.
Jose Costa Teixeira (Oct 31 2018 at 15:27):
If someone is tasked to procure sufficient use cases so that the design is solid, this will surely emerge
Rik Smithies (Oct 31 2018 at 16:28):
Hi Jose. Help me understand this strong statement that all levels must be in one resource type.
I wonder if your statement comes from the requirement that we want to be able to prescribe at all levels? i.e. have one slot that can carry a code (or reference) to any of the levels.
That doesn't mean that you need the definition of a pack to be conflated with the definition of a product, only that you can point at either.
In the UK we can prescribe a pack or a product (manufactured by someone) or a pharmaceutical product (just the "drug").
You can use the code for any, but behind the scenes these have different properties.
People who support different levels in the definition will want to track the parts differently. EMA certainly do.
They want a list of packs (that make up products) to be different from a list of products.
Jose Costa Teixeira (Oct 31 2018 at 18:42):
Hi Jose. Help me understand this strong statement that all levels must be in one resource type.
Hi Rik. Perhaps it seems as such, i don't say it must be a single resource type. I think it should, becauseI don't see another way to have the flexibility I really think is needed. And perhaps my perspective is not clear, so i can try to explain better
Jose Costa Teixeira (Oct 31 2018 at 18:42):
(or perhaps it is clear and it is simply wrong - can well be the case)
Jose Costa Teixeira (Oct 31 2018 at 18:44):
I wonder if your statement comes from the requirement that we want to be able to prescribe at all levels? i.e. have one slot that can carry a code (or reference) to any of the levels.
Not only prescribe, but I would want to be able to point to a product at any level (not only the 3 or 7 IDMP levels, but any level
Jose Costa Teixeira (Oct 31 2018 at 18:50):
That doesn't mean that you need the definition of a pack to be conflated with the definition of a product, only that you can point at either.
Agree. i don't think we should combine the definitions. i actually think we should not try to do so. Defining one package is one resource instance, a product is another instance.
John Silva (Oct 31 2018 at 18:51):
From an 'outside perspective' it seems like the differences you are talking about is between a 'data model' and an 'workflow model' (or dynamic/interaction model). It appears that in order to come to an agreement on the 'data model' there needs to be an understanding of the 'workflow model' to discover what is needed in it. It would be very helpful if there were a set of workflow models (like the IHE Hospital Pharmacy profile) to help have some concrete use cases to 'test' this 'data model' against. (To my 'newbie eyes' the IDMP levels seem to be about granularity or specificity of the data model but still do not address the workflow model.)
Jose Costa Teixeira (Oct 31 2018 at 18:53):
People who support different levels in the definition will want to track the parts differently. EMA certainly do.
They want a list of packs (that make up products) to be different from a list of products.
I think that is the (only good) solution, yes. In my implementation, this was indeed the first thing we established to make the problem solvable - different concepts of product with different characteristics. There is a list of substances a list of packages, the list of "inventory items", all those were independent. our hospital catalog then just articulated all of those.
Jose Costa Teixeira (Oct 31 2018 at 19:00):
So, @Rik Smithies I think the only difference between what you are presenting and I am presenting seems to be this:
PhP, packs, products have a well-defined set of characteristics. So you can conceive three resource types for this, each having their characteristics. then you can share information about those products.
But the moment that you have something that contains a combination of characteristics from more than one level (the "official hospital product code" that is common in South Europe and is basically PhP + Pack size), I don't see how we would handle that - we send the PhP characteristics in a PhP resource and then an extension with the pack size? Or another solution I am not seeing atm? This is a simple example of why we must use IDMP as a reference but there are other definitions of products that do not match IDMP.
So I am orbiting to a solution that is one resource type, that, depending on what attributes are populated, can inform of a PhP, or a Pack, or a MP, or a "generic" or a "CIP" or whichever of the many levels are needed.
Jose Costa Teixeira (Oct 31 2018 at 19:01):
but that is because I don't see a clean way to do it otherwise. Perhaps there is.
Jose Costa Teixeira (Oct 31 2018 at 19:04):
(BTW, apologies if there is a bit of "impedance mismatch" - perhaps you have it well covered and I am just missing it; the fact that I had this discussion a few times may cause me to amplify and try to re-expain something you all are well aware of. But when it comes to the current design, I am still not seeing how this will work outside of the ideal future when everyone talks IDMP.)
Rik Smithies (Nov 01 2018 at 18:42):
hi @Jose Costa Teixeira , that's great. Thanks. That is just what we need.
Real uses cases that we can try to fit into the models and see if they work, and make changes if not. This is much better than working in the abstract.
Is this one coded item (for the predefined combination of pharmaceutical and pack), or two (with a second code or number for the pack size)?
Assuming the former, isn't that just a product? Perhaps you would call it a virtual one.
But a predefined combination of a drug and a pack size seems to me to fit fine into MedicinalProduct.
Sure it's not like the full use of IDMP where you have names and manufacturers etc, but that's no problem. None of that is mandatory.
Jose Costa Teixeira (Nov 02 2018 at 08:23):
it is one coded item. and it is defined by 4 attributes - substance, strength, dose form and pack size.
Jose Costa Teixeira (Nov 02 2018 at 08:25):
from what you have described, i did not see a way to have all these in one resource instance without pointing to other definitions.
Jose Costa Teixeira (Nov 02 2018 at 08:26):
thanks for looking at this - it makes understanding easier and alignment should be much better
John Silva (Nov 02 2018 at 09:22):
When this discussion starts talking about products and packaging it got me thinking that the (US) NDC codes do exactly that. Although your discussion has been about IDMP shouldn't the MedicinalProduct also consider NDC as well? The 3 segments of the NDC identify: the labeler, the product ,the commercial package size.
https://www.drugs.com/ndc.html
Rik Smithies (Nov 02 2018 at 17:51):
@Jose Costa Teixeira > did not see a way to have all these in one resource instance without pointing to other definitions.
That is right, but sometimes that is just how FHIR works. Data is split across resources. You often need more than one resource to represent complex things. If you really need one resource instance you can use contained resources. The data needs to be split for some use cases. It can easily be joined back together for other use cases, that is normal for FHIR. But you cannot easily split something that is too coarse grained. As well as the various MedicinalProduct series of resources, you may have DocumentReferences, Organizations etc. It cannot all be in one resource.
@John Silva Yes the MedicinalProduct certainly should consider NDC - as well as all similar international systems. It is no way meant to be limited to IDMP, it's just that that ISO standard has been developed specifically to cover a large subset of this sort of data (albeit coming at this from the angle of the regulators rather than the prescribing drug catalogues). The resources do have places for the labeller (I assume this is manufacturer, but let me know if not), the product, and the pack size.
John Silva (Nov 02 2018 at 18:01):
Thanks @Rik Smithies . Earlier Jose mentioned drug DB vendors like First DB and Vidal. Are any of these Drug DB vendors involved in the FHIR Pharmacy group or specifically this modeling effort? (e.g. bedsides above, Pepid, Elsevier, Wolters Kluwer, etc.) Seems like it would be good to have their input (and experience)
Jose Costa Teixeira (Nov 02 2018 at 18:09):
Hi Rik. Thanks. Then we understand each other's preference. Perhaps we can even agree on the solution or leave that open. But this common understanding is what I was missing.
Jose Costa Teixeira (Nov 02 2018 at 18:11):
I can understand that you have the "fundamental" characteristics of products split across resources - that is still not how I would start, but it does have the advantage of anchoring ti a common global conceptual model - the idmp model
Jose Costa Teixeira (Nov 02 2018 at 18:17):
My question now is: if we have those 2 or 3 "primary components", where do you combine them? In my example, you would have a contained PHP. Contained in what? which resource would you use ? I see a resource called medicineDefinition or medication knowledge or smth playing that role.
Jose Costa Teixeira (Nov 02 2018 at 18:18):
Otherwise if I am not mistaken, in my example you would be using a resource called "medicinalProduct" to represent something that is not an idmp medicinal product.
Rik Smithies (Nov 02 2018 at 19:45):
Contained in what? which resource would you use
Contained in MedicinalProduct.
MedicinalProduct is not synonymous with an IDMP medicinal product. Just because it is inspired by IDMP it isn't meant to only cover things that are exactly like IDMP - at all. That is just one of the data sets that it aims to cover. It covers things that are "products".
That is something that is prescribe-able, but is more than just a pharmaceutical or a substance. (A counter example might be "give 20mg morphine" - really just an active substance). A product is either something listed by a manufacturer, or something that is a "virtual" product, a combination that is a pharmaceutical and a pack size perhaps. It's a bit of a subtle definition but you know one when you see one :-) Your thing, if it is given a code and it is not just a pharmaceutical/substance/ingredient, is a product.
that is still not how I would start
It is not how I started either. But I soon realised it was way too big and unwieldy, and also that people want to use the pieces themselves. So it has to be broken up.
Rik Smithies (Nov 02 2018 at 19:51):
@John Silva Yes we aware of them and very much want to talk to those people. We did have some input in Baltimore, and there is to be some more outreach next week (think was mentioned earlier in the thread by Jean). If you have contacts with one of more of those you please invite them to be involved.
Last updated: Apr 12 2022 at 19:14 UTC
