At the October DEUSG and JAG meetings in Antwerp, we discussed a proposal to model multi-component Clinical Drugs (CDs) as a ‘Packaged Clinical Drug’ without the quantity. For example:
{Contains clinical drug = |Clotrimazole 10 mg/g vaginal cream|}
{Contains clinical drug = |Clotrimazole 500 mg vaginal tablet|}
One thing we did not discuss at the time, was a semantic tag for these multicomponent clinical drug concepts. So, we would like to get feedback and agreement on a suitable semantic tag to use. Possible options include:
(multicomponent clinical drug)
(clinical drug combination)
(clinical drug group)
I’m currently favouring “(clinical drug group)”, as this sounds like something that could potentially contain only a single clinical drug (if needed). This would allow countries to represent both single and multi-component packs at this level (i.e. a pack without the pack size) for consistency - if they choose to. We’re planning to only use these concepts for multi-component products … but I suspect we shouldn’t rule out their use for single-component products if this is required.
We would love to hear your thoughts or suggestions on this topic.
A different semantic tag, especially if used in the same hierarchy should ideally come with different modelling. I think this is the case so should be fine. Otherwise the semantic could still be ‘(clinical drug)’.
The UK’s dm+d uses ‘combination product’ as the terminology
A combination product contains two or more components each of which is a virtual medicinal product in its own right although it may not be available or prescribable.
Though this does often get confused with a single tablet with two ingredients in. So I can’t recommend ‘clinical drug combination’.
(clinical drug group) may well be the best option, assuming there is general support for a different semantic tag.
While I can see the usefulness in identifying a multiple drug package, I am unsure of the value of creating a specific semantic tag. What would be the specific use cases to support this and would it not open the door to requests for more new semantic tags that represent differences in packaging?
I thought we had agreed in Antwerp that the multi-component CD concepts you need are not actually Clinical Drugs, but rather abstract Packaged Clinical Drug concepts without quantities, as you noted.
Since they aren’t clinical drugs but abstract packages, I’m not sure it makes sense for their semantic tags to include the words “clinical drug”, as that would create confusion.
They are still concepts that package (contain) Clinical Drug concepts, just without stating the number of each packaged item. I’m not clear on why the existing semantic tag for packaged clinical drug concepts wouldn’t be sufficient for these, or what a new, unique semantic tag would enable that we can’t already achieve. Could you share some examples of what you have in mind?
My instinct is that adding more semantic tags risks increasing complexity more than it helps, so I’d like to understand the benefit against that cost.
The FSN should reflect all the detail of the modelling (or at least enough to be unambiguous). I posit that most concepts would be unambiguous without the semantic tags. Where it’s useful is for concepts like: 429040005|Ulcer (disorder)| vs 56208002|Ulcer (morphologic abnormality)|.
The Drug project is responsible for all the new semantic tags introduced. But I’m not sure most are necessary. All subtypes of 373873005|Pharmaceutical / biologic product| could have the semantic tag “(product)”.
I think sometimes it’s used to help with search. Especially when suitable “grouper” concepts don’t exist, or ECL isn’t an option.
There was some analysis a from UK (Ed or Jeremy?) a while back on the use of semantic tags, but I’m not sure where that is now.
The main reason for suggesting a new semantic tag for this new class is consistency. Every other class in the drug extension model (defined by SNOMED International) has (a) its own modelling pattern, and (b) its own semantic tag. There is:
(medicinal product)
(real medicinal product)
(medicinal product form)
(real medicinal product form)
(clinical drug)
(real clinical drug)
(packaged clinical drug)
(real packaged clinical drug)
I am not aware of why this was done. Maybe it was felt that it was easier to quickly identify all concepts at a particular drug level (to support a specific medication use case) - rather than always needing to use a (potentially) complex ECL? Or maybe it was felt that it clearly disambiguated the FSN of drug concepts at each level? Perhaps someone from SNOMED International could provide the history behind these semantic tags?
So, we were following the existing precedence. Otherwise, these would be the first class in the drug model not to have their own semantic tag.
You are correct that in Antwerp we agreed that multi-component CD concepts would be represented as an abstract packaged clinical drug - as demonstrated in the example modelling I showed above.
Please note that the existing semantic tags in this hierarchy are “(packaged clinical drug)” and “(real packaged clinical drug)”, which both contain the words “clinical drug” - which I think is what you’re suggesting will cause confusion. However, I’m guessing from your comment, that you’re not a fan of the “(multicomponent clinical drug)” option, because it sounds like you’re calling it a clinical drug? But perhaps that would be a reason to prefer the “(clinical drug group)” option - because this isn’t describing a single clinical drug, but instead a group of clinical drugs. Although maybe “(packaged clinical drug group)” might address your concerns better?
In terms of the ‘risks’ and ‘costs’ of adding a new semantic tag - I don’t think there’s any risk or cost for countries who do not adopt this new class (which I assume will include Australia). Conversely, for those countries who do adopt this new class, is there a risk and/or cost to this one being the only class in the drug model that does not have its own semantic tag?
From the perspective of the other country I know that will be using the multi-component clinical drug idea (Argentina), we think that a new semantic tag makes sense since there is no simple ECL to identify this class, and as Linda says, it produces no harm to those that don’t use it. On the other hand, the semantic tag should be abstract enough to be reusable and understandable. It will not always be a group or combination (some countries have 95% of their multicomponent VMPs with a single component and might prefer to use this approach for consistency), and as Dion says, it could not be a “multicomponent clinical drug”, it has to be a more abstract package. I don’t have a good suggestion. Internally in our team, we call this class a “virtual pack” or “virtual packaged clinical drug (VPCD) to avoid confusing it with a PCD. But we would consider anything that avoids the implication that it should contain more than one CD while making it clear it contains CDs, it is not a CD.
Again, I’m not against semantic tags if they’re useful/necessary. But cautious about perpetuating the proliferation just because the drug project started doing it, kinda… (AMT does have different tags for the classes, but that’s partly a hangover of it’s evolution)
Noting. the current semantic tag of 781405001|Medicinal product package (product)|
And note the below use of semantic tags - the first 6 are all just “product”. Should they be something else?
Concept Id
Fully Specified Name
Semantic Tag
373873005
Pharmaceutical / biologic product (product)
product
763158003
Medicinal product (product)
product
763760008
Medicinal product categorized by structure (product)
What if we were to keep it really simple, and just use “packaged product” and “real packaged product” for these upper classes of the packaging hierarchy? Any takers?
We talked about this internally with SNOMED Argentina, and the packaged product and real packaged product semantic tags are acceptable to us under the acceptance criteria already discussed above. Argentina is considering using the proposed model and semantic tags for publishing kits in the near future. In general, the proposal discussed in Antwerp and the follow-up in this forum removes blocker issues for countries requiring virtual packages or a way to represent multi-component package composition without stating the pack size and units. The logical model behind it can support this approach to represent virtual packs as “packaged products” that is needed by Canada, and produces no harm to those countries not adopting the approach.
There are a few other considerations: in the near future, we expect adapted versions of the packaging model to also accommodate devices supporting initial use cases like 1) adding an administration device to the package; 2) having a packaged product containing a device that cointains an active ingredient (like stents) or “substances” (like a container product to collect blood samples that also contains an anticoagulant or preservative for the specimen); and 3) eventually pure device packages with references to physical objects/devices. While most of those device use cases require significant discussions and consensus-building, the packaged product category seems reasonable and abstract enough for us. We would even consider changing the semantic tag of 781405001 |Medicinal product package (product)|
Finally, while we agree that limiting the scope of Canada’s original proposal to represent multicomponent clinical drugs as packaged products instead of also being a kind of CD has allowed us to make significant progress, our position in Argentina is that it is still worth exploring the option of representing multi-component clinical drugs as a kind of clinical drug and descendant of an MPOnlyForm class having Medicinal product as proximal primitive. The packaged product approach represents the same logical model and enables us to move forward, but in some use cases we might prefer to see it as a CD product. That approach is more controversial as it would require changes to the core concept model and extensive testing, so it is a long term discussion in another thread.
I’m a bit confused that you’re talking about multi component clinical drug concepts @greynoso. I thought we all came to the understanding that
descendants of 763158003 | Medicinal product | are the individual formulated products (capsules, tablets, solutions etc.) - the thing that goes in/on the patient and has the therapeutic effect
descendants of 781405001 | Medicinal product package | are collections of 763158003 | Medicinal product |s in some form of packaging containment for storage, organisation and distribution (bottles, blister packs, kits etc)
I thought we agreed that “multicomponent clinical drugs” and their abstractions were really abstractions of 2, not 1. I.e. a multicomponent thing is a type of 781405001 | Medicinal product package | containing multiple types of 781405001 | Medicinal product package |, not a 763158003 | Medicinal product |.
A 781405001 | Medicinal product package | concept can only be formulated one way, it is one single thing. A Clinical Drug can’t contain or compose other Clinical Drugs. But a pack can, that is their purpose.
To AMT, a “multicomponent product” is a package (type of 781405001 | Medicinal product package |) that contains more than one type of 763158003 | Medicinal product |. So a pack that contains 6 blue pills and 10 red pills, or a pack that contains a tablet and a tube of cream. So a component in a multicomponent product is a formulated drug product - a type of 781405001 | Medicinal product package |.
I think @lbird2‘s desire for abstractions of multicomponent products (e.g. without strength or form) was resolved in Antwerp as abstractions of medicinal product package concepts which can contain multiple products, not medicinal product concepts which are inherently a single thing.
Is that not the case? Do you have use cases and example products where this doesn’t work? Could you share the details if so?
The extra level we have in AMT for 781405001 | Medicinal product package | is sub-package modelling so packages can contain other packages. This is useful (at least for us) to model kits and important internal packaging details in some cases (examples below). But they are still packages and therefore subtypes of 781405001 | Medicinal product package |.
Hi Dion, I clarified my statement in a DEUSG meeting discussion. We think that what was agreed in Antwerp is the way forward and sufficient to enable short term implementations using the packaging model. Actually, while clinical drugs are medicinal products in a general sense, they are really medicinal product components that get defined in a package, so using abstract packages makes sense, in addition to them being aligned with FHIR multi-component medicinalProductDefinitions that might contain one or more manufacturedItemDefinition (more or less equivalent to RCD or CD levels in SNOMED but also including packaged devices supporting kits, co-packaging, etc.). We did have requests from some implementations to support multi-component clinical drugs at some point in time, but currently the Antwerp decision is implementable (while MCCDs are not without significant changes that are probably more disruptive than beneficial and thus favoring the packaging option that we have already agreed and lets us move forward and be forward compatible with future FHIR resource implementations.
Yes from memory I think we arrived at the conclusion there are two separate things
the drug itself that goes in/on the patient - one distinct drug component
packages of one or more of the former
Those two things are definitely different things - you can’t (shouldn’t?) swallow a blister pack but you can swallow the things in it (assuming they are oral tablets/capsules).
You could make the argument that 763158003 | Medicinal product | (which has no text definition) could mean (1) above, or it could mean both (1) and (2) above - in which case 781405001 | Medicinal product package | should be moved under 763158003 | Medicinal product |. The words “medicinal product” could subsume one or both things.
But either way I’d say “multi-component products” means more than one of (1) above - multiple distinct drug products you put in or on a patient. In this case I think that’s clearly a subtype of 781405001 | Medicinal product package | even if it is quite abstract and doesn’t include the number of or packaging of the components.
In short, a group of multiple components is a modelled as a package, even if that is a very abstract virtual package.
From the Argentine perspective, we have products with one or more components (co-packaging, multi-phase combinations, and kits combining different products like creams and tablets), and those products are dispensed in packages. An example package contains starter pack contains 11 white varenicline 0.5 mg tablets and 42 light blue 1 mg varenicline tablets. But the product level is varenicline 0.5 mg tablets and light blue 1 mg varenicline tablets, very much like two clinical drugs combined. We can view them as a virtual combination package, but at the end of the day we refer to them as products. We also have packages of 1 mg varenicline tablets, but since it is not a combination, they are appropriately represented by just one clinical drug and viewed as medicinal products. I would argue that both are products, with one or more components. I think the Antwerp agreement let us move forward (we have already started publishing using that model) but still there is room for discussion about what is a product. However, we would not discuss this now because a) we also agreed to better define the product hierarchy to accommodate other kinds of products like device packages, and combination medicinal product+device packages. I am sure we will have productive discussions and increased experience to converge in the mid-term. Again, happy to move forward with the very abstract virtual package idea, particularly as it aligns well with other abstractions. They do not need to be entirely semantically correct representations of reality or clinical jargon, they have to be clinically useful, understandable, reproducible, and also reusable abstractions.
Sorry, I know you say we should not talk about it now, but there seems to be an unresolved issue you are talking about that I genuinely don’t understand and would like to.
I don’t really mind how broad or narrow we want to define the term “medicinal product”, but to me there are two quite distinct types of things we are talking about.
drugs intended to provide a therapeutic benefit
packages those drugs are wrapped up in and combined in for supply chain and patient/administration handling - collections of different numbers and types of (1) above
I can see how they can both be thought of as “medicinal products”, but SNOMED CT’s current definition of the concept that goes by that name means (1), not both (1) and (2). That’s why 781405001 | Medicinal product package | isn’t a subtype of 763158003 | Medicinal product |. Perhaps 763158003 | Medicinal product | could do with a text definition because it is a very vague FSN.
I can’t wrap my head around how (1), a type of drug concept, could represent more than one component - to me a type of (1) can only represent one type of component of a package. The most confounding example to me is a pack that contains a tablet and a cream - how can a single drug concept have two forms? How can it be both a cream and a tablet? That’s where a package containing two different drug concepts, a tablet and a cream, makes much more sense - containment (part of), not subsumption (is subtype of).
I can see in the Argentinian extension you have the package you mention containing different quantities of two different real clinical drugs
This makes sense - you have two different real clinical drugs, one each for the 1mg and 500mcg tablets, and two package concepts, one for the combination of both tablets 11 and 42 and the other just containing one strength.
One more thought - this separation (in my head) is that (1) are the actual medication that goes in/on the patient, and (2) is the packaging.
For me that makes concepts like unit dose vials or ampoules as (1) concepts really weird to me. To me, the (1) concept is the solution inside the vial/ampoule, and the vial/ampoule is the (2) concept - regardless of whether it is “intimate” or not, it is still part of the packaging you discard and doesn’t stay in/on the patient.
That’s why I find concepts modelled with unit of presentation = vial really awkward. I can understand describing a quantity of a solution as (1), but not the container. To me the (1) concept should be the solution in the vial, not the packaging as well - that should be a (2) concept that packages the (1) concept.
But AMT still does this as well - one of the many things that irks me still about AMT.
Not sure how others feel about that…but I feel like the nature of those two things is quite different.
