Proposed drug model

Over the years, we've had many meetings on the drug model. One thing has been overwhelming consistent: When use of the "all" restriction is proposed, an analysis of the pros and cons, and implementation issues has always led to a conclusion to not use the ALL restriction, and to just use the SOME restriction. I've attended several meetings on this topic. 

The assertion that "there are patient safety issues" with using "contains some" semantics over "contains only" semantics is just hyperbole. 

Fortunately, the IHTSDO cannot force us to use a model that contains the ALL restriction, and the VA will not adopt the model with this ALL restriction in place. 

I'd prefer that the IHTSDO not include the ALL restriction, so we don't have to work on an independent standard, outside of the IHTSDO, but that will be the result, where we will align closely with the Australian Medication Model that does not use the all restriction. I think the IHTSDO is better off implementing a model that contains a foundation that we all can agree to, rather than trying to promote a model that uses the ALL restriction over the objection of several members and organizations. 

Thanks for this feedback, Keith.

Couple of requests. Could you please be more specific about how the universal restriction would be an issue for you? Reason I ask is, the universal restriction can ensure that, e.g. “Product containing active ingredients A and B only” is classified as a sibling of “Product containing A only”. Do you want to avoid this classification result, or is it something else? Would you also comment on whether you/we want the (English) syntax that implies that, e.g., Product A has active ingredient A and only A, or that it contains A and possibly but not necessarily some other active ingredient?

The universal restriction is an issue because the description logic ALC, which includes universal and existential qualifications for building complex expressions is known to be PSPACE-complete with respect to satisfiability, and EXPTIME-complete with respect to logical implication...

Although we endorse the idea of moving toward OWL 2 EL profile with concrete domain capabilities, which does not have these PSPACE-complete and EXPTIME-complete computability issues with respect to satisfiability and Logical Implication, moving beyond OWL 2 EL profile with concrete domain is not something we can support, and would not adopt any standard that contained such a requirement.  

The proposed classification result:

     “Product containing active ingredients A and B only” is classified as a sibling of “Product containing A only”

Is not the way we would want medications organized for decision support capabilities. It is much more important to know what medications may (some restriction) contain an ingredient, and we see little to no value for taxonomic organization by containing only an ingredient (all restriction) using logical qualifications given the computational issues with it. There are other ways to distribute such information, using refsets as one example, where the delivery of such supporting knowledge does not impact the decidability of the T-Box content. 

Also, the concept "Product containing active ingredients A and B only" is not what you think it might be. The logical implication is that the ingredient is both A and B at the same time... Which implies existence of a molecule that does not exist (a molecule that is both A and B at the same time). We had a similar issue in the past, where some modelers where attempting to use the all restriction for modeling anatomic locations, and the result was anatomic locations that where both kidneys and lungs at the same time (modeling Goodpasture syndrome). 

These issues have been discussed extensively at previous pharmacy meetings on multiple occasions and rejected by the committee. Unfortunately, the author of this proposal chooses to ignore the previous actions, and does not provide adequate background on the reasons for the past rejection. Again, the concern "there are patient safety issues" with using "contains some" semantics over "contains only" semantics is just hyperbole. There are meaningful ways to manage any such patient safety concerns without resorting to a Universal restriction, and then providing a decidability impact on the entire system (and how safe is an undecidable system anyway?). 

The one (only?) use case I've encountered for rationalising the need to Universal restrictions was that a "dispensed medication must be an "exact" subclass of the prescribed medication" i.e. A script for "X product" can only be fulfilled with "Branded X product" NOT "Branded X + Y product".

That's a valid use case, but does not require universal restrictions  (though they might make it easier...). The Dispensing use case can still be satisfied with existing (existential) restrictions, through suitable implementation/queries - in dispensing systems. In AMT we might say "valid dispense TPUUs are that that are subtypes the prescribed MPUU, but not subtypes of some MPUU that isn't the prescribed MPUU". I think Keith's suggestion of reference sets might be similar.

Other use cases (such as adverse reaction / contraindications) benefit from the "some" restriction - though in fairness if implemented with only you could probably work with it too (although it'd be more complex).

Additionally, nowhere else in the terminology has universal restrictions been a requirement (that I'm aware of) . Introducing it, just seems an unnecessary complication.

Are the requirements and benefits of universal restriction worth the effort and complexity?

Human language in general is "open world" and recipients interpret the intent based on the context. "The patient has a rash" doesn't exclude the patient also having diabetes. "A request for some procedure" doesn't entitle/prohibit some other related or unrelated procedure.

If you asked most people "Is Panadeine Forte a codeine product?" I expect most people medical or otherwise would reply yes. (I actually ran this as a survey several years ago)

Our national extension is modelled using universal restriction style hierarchy. For example all paracetamol only products having a Medicinal Entity parent concept of Paracetamol. All Paracetamol and Pseudoephedrine products having a Medicinal Entity parent of Paracetamol + Pseudoephedrine. And their being no parent-child relationship between the two Medicinal Entity concepts.

 As Matt notes this facilitates the prescribe / dispense and reimbursement process which is the primary use case of our extension. It also means that we have a single layer for the concept class that is equivalent to Medicinal Entity. Since our model has a fixed 3 layers plus pack concepts structure it does not support the sort of recursive relationship that multiple layers within a concept class would require . But this fixed model does simplify implementations.  Adverse reactions and contraindications we would expect to be driven by the ingredients/substances information modelled for the products.

We do not use a classifier to achieve our hierarchical structure but a templated authoring tool and a rigorous editorial policy.

Either way I would make a plea for a consistent approach , whatever it may be.

Emma, 

The NHS creation of the hierarchy though non-classifier means gracefully sidesteps the complexity issue. So I think the NHS is currently working with a reasonable strategy. 

Creating Refsets that contain dispensable manufactured products given a generic prescription is a readily attainable solution, that preserves a prescriber-oriented presentation, as well as an ability to support a dispenser-oriented presentation and other means of checking correctness of dispensing a particular manufactured product. 

The goal of eliminating the ALL restriction is not to limit functionality, and eliminating the ALL restriction won't limit functionality. It's just to arrive at the functionality in a decidable and tractable way, that is consistent with the rest of SNOMED. As Matt points out, no where else in SNOMED is the ALL restriction used, so not introducing the ALL restriction enables consistency, tractability, and decidability. 

Since 2007 there has been a deadlock on this subject because the “clinical use cases” considered SCT products to mean p containing x, and the “prescribing/dispensing use cases” assumed the implied meaning was "product containing only x". For that reason, initial efforts to fully define products using existential restrictions were rolled back after input from the Pharmacy SIG alerting about the undesirable classification results for their use cases. That was the reason the products were kept primitive for years. The use case Matt mentions seems persuasive, though.

In 2010 we realized it was not a matter of arguing what was the meaning of those concepts, but a matter of recognizing they were ambiguous across clinical and pharmacy use cases. So we discussed the option of retiring all "product" as ambiguous and create two concepts for each one, (containing and containing only x), but we got into the limitations to support universal restrictions if we were to fully define the pharmacy perspective.

In 2014, the DCM alpha model (in OWL) was incorporating the two flavors as distinct concepts. Instead of using universal restrictions, a workaround using a count of the ingredients was used to simulate the universal restriction using an existential one. The resulting inferences (for this particular aspect) were fine, although the approach would require some further experimentation to ensure consistency and creates some potential liabilities that could be controlled with QA rules or pre-processing (and probably some further evaluation of role inheritance consequences on distributed normal forms –the Alpha contained no RF2, just OWL, and there were many other new constructs unrelated to this thread). I think it would be worth exploring alternatives on that path, as it supports the clinical use case and provides an alternative to support the pharmacy use case, avoids the need to support pure universal restrictions, and does not affect the clinical use cases. Beyond that, as Keith mentions, the complexity of using universal restrictions could get worse in multi-component products and require further plumbing (eg nested expressions).

In recent versions of the core content, many products are fully defined with existential restrictions (still not uniformly applied), so the 2010 discussion (what was the meaning) appears to have been resolved for assuming "aspirin product" means "product containing aspirin" (the clinical perspective). While FSNs should be clarified to avoid ambiguities, I would propose we agree on that direction as I don't think it is controversial and is a necessary building block. Since post classification the "counting-as-a-proxy-to-only" products would become descendants of the "containing" ones, I do not think they affect the clinical use case transitive closure [is A a kind of B?] (it might affect most specific subsumers [is A a direct subtype of B?]). From a realistic standpoint, both the clinical perspective and the “ambiguous” perspective were not usable for the pharmacy perspective, and therefore their work have evolved in parallel lines meeting their requirements. However, there is an opportunity for convergence in the mid-term, at least in the upper layers of the model.

After having a uniform understanding of this first level of the core, I think further experimentation, testing and consensus building can take place on the "counting-as-a-proxy-to-only" use case, perhaps initially on an extension or a different module. That would make the model more reusable. 

For the discussions on regional drug models sharing an interoperable layer where equivalencies and hierarchy placement could be inferred, it is critical that the upper layers of the product hierarchy are fully defined and computable. It is possible to maintain the hierarchy manually, as a set of primitives, without assistance from a classifier. However, that approach would not be efficient in a shared layer to which multiple regional extensions might refer to.

I would also comment on the layers above and below these levels but that would probably belong to another thread (therapeutic/functional grouper support and concrete domain support)

In summary, I would recommend:

a)     That it is made clear that existing “products” (e.g. aspirin) actual meaning is “product containing …”, in alignment with their modeling as sufficiently defined using existential restrictions and ingredients.

b)    That the FSNs for those concepts are expanded to unambiguously represent that meaning.

c)     That consultation is considered with NRCs as to whether this initial step would be acceptable. I understand it would likely be, as the pharmacist use case was not supported either way and therefore the implementations aligned with the need for universal restrictions were resolved by other means. Agreement to uniformly represent one of the meanings would facilitate the research and testing of alternatives to support the other.

d)    That the document/presentation we are commenting would evolve into five threads:

1. The use case analysis
2. The elaboration of potential models for national extensions, including some corrections to the logical models being discussed and replacing the assumptions regarding IHTSDO support by the actual level of support the International Edition would provide at least as a starting point or interoperability layer.
3. The continuation of the current core modeling effort to complete coverage and ensure consistency.
4. Research and testing of alternatives to support the pharmacy perspective either in the core or as an extension, by using:

                                               i.     A workaround that avoids the usage of universal restrictions

                                             ii.     Eventually, universal restrictions applied to a modularization or to an extension of the product-related content rather than to the full SNOMED.

5. Start discussing the alternatives for using concrete domains for representing strength, exploring workarounds, potential simplifications, minimizing the impact on RF2 distributions. If possible, features enabling more efficient and consistent maintenance of the terminology might not necessary mean changing the way the terminology is consumed by current users.

Consider that evolution of SNOMED CT should be friendly with its ecosystem: the realization of some use cases should not prevent the realization of others, the meaning should be preserved as reusable building blocks. SNOMED CT provides multiple mechanisms to add usability by extending, sub setting or modifying how it is viewed/consuming, without hacking the meaning or the subtype hierarchy to realize a use case and ruin it all for other use cases.

I feel much the same way as Keith Campbell, Matt Cordell, Guillermo Reynoso and now Alejandro Lopez Osornio have expressed.

First and foremost, I think that there has been much confusion caused due to the ambiguity of the current FSNs. If the FSNs had been clear when they were created years ago we'd probably not be having this debate! So I think it is imperative that the ambiguity is addressed, otherwise we'll be at this again one day...

I think the key is to understand the use cases driving the demand for these concepts to determine what we actually mean by them...nothing new there for any SNOMED CT content development. Above there's some alluding to that with the prescription case versus allergies. When I say "don't give this person aspirin" I mean don't give them anything containing aspirin. When I say "give this person aspirin" I probably mean only aspirin, or at least by not saying more than that I've got an expectation that no more will happen.

What immediately occurs to me is...what's special about medications? The rest of SNOMED CT is modelled using existential quantification, are there not similar problems elsewhere?

I think the answer is the open world assumption, and my statement above "...at least by not saying more than that I've got an expectation that no more will happen".

Prescriptions (at least in Australia) don't say anything about being limited to the ingredients specified by the prescriber, they are as ambiguous as the current FSNs of the concepts. But when prescriptions are interpreted and administered/dispensed if the prescriber didn't explicitly specify ingredients they can't be provided. It isn't that the prescriber specifically excluded other (or all other) active ingredients - the prescription is strictly ambiguous in that way and the prescriber might be fine with other ingredients, depending upon what they are - but the key is they didn't say anything about them.

So my opinion is that the existential quantification used in modelling these concepts is actually a good match for what has actually been said in the prescription case, and is certainly required for some cases (e.g. allergies). To argue the case to depart from this modelling as used in the rest of SNOMED CT there needs to be a compelling use case(s) articulated which can only be met with the "only" style modelling.

That would result in us needing both sets of modelling, as the "containing" modelling is required. That's two complete sets of concepts modelled, which is quite a burden and shouldn't be done lightly.

If it is required, there are work arounds which would allow us to avoid using universal quantification by using concrete domains and thus avoid the associated computational penalty. Michael Lawley came up with the idea of adding a datatype property specifying the number of ingredients to each concept which will achieve the required meaning and classification - e.g. "product with two ingredients containing paracetamol and codeine". But again I'd suggest this is only done once we understand exactly why we need to go to this length, something not clear at present.

I think actions are

1. Fix the FSNs of the current concepts to mean "containing" which matches their current hierarchy - either retire and recreate them (ouch) or by broad consolation and warning agree to rename the FSNs (dodgy but maybe necessary given the potential impact, analysis required).
2. Document use cases for the medication content and use these use cases to determine if another modelling to above is actually required. These use cases are needed for these concepts completely separate from this specific debate, but are the only way to put this debate to bed.
3. If a need for the "contains only" style modelling is identified, potential solutions and impacts need to be researched and analysed.

In the meantime as Guillermo Reynoso says, there are ways for us to progress using concrete domains for other parts of the model which have minimal impact on current RF2 users - we should pursue these and use them.

In at least the US, the notion that a dispensed product must have an exact match to the active ingredients in the prescribed medication is not correct. A pharmacist may legally perform a "therapeutic substitution," wherein a pharmacist may legally switch a prescribed medication to a dispensed product that does not contain the same active ingredients  — without telling the patient or the physician (sometimes they are administratively required to make the switch). The therapeutic substitution is different than a generic substitution. One common example is inhaled corticosteroids.

If any of the below medications are prescribed—other than Fluticasone—the below table is used to provide a required therapeutic substitution to Fluticasone, within the Upper Peninsula Health System.