Thanks Karen.
On the two issues you’ve raised:
1. “Further significant deviation from IDMP and EDQM”
I’d push back on the framing here. Compatibility and alignment with IDMP/EDQM does not require identical representation - and in fact, identical representation transplanted from IDMP or EDQM into SNOMED CT would be problematic. IDMP and EDQM are data models designed primarily for regulatory use cases. SNOMED CT is an ontology with a concept model, designed for clinical use cases. These are fundamentally different semantic frameworks.
What is required for interoperability is that each side - IDMP/EDQM on one hand, SNOMED CT on the other - has sets of concepts with equivalent meanings, represented using each system’s own semantics. These form anchor points of direct equivalence across the two systems. SNOMED CT’s own Medicinal Product Model specification acknowledges this explicitly - compatibility with the IDMP model
“does not entail full and exact compliance; there would be little value in exact duplication.”
Each system needs to achieve what it needs to achieve for its own use cases within its own semantic framework, while providing those anchors of equivalence for smooth interoperability.
It’s also worth looking at how IDMP is actually implemented in practice. FHIR’s AdministrableProductDefinition - which the spec explicitly states corresponds to the IDMP Pharmaceutical Product (ISO 11615/11616) - has routeOfAdministration (1..*) as a required element, bound to SNOMED CT Route Codes. There is no “intended site” element anywhere in the resource. The FHIR IDMP mapping page confirms that this maps to “Pharmaceutical Product.Route of Administration” in IDMP. Intended site is a characteristic used internally by EDQM (ISO 11239) to classify dose forms - it is baked into the dose form code itself, not a separate concept transmitted at the product level. When HL7’s Biomedical Research and Regulation work group built FHIR resources specifically to implement IDMP, they used route. And the same SNOMED CT Route Codes value set is used consistently across the entire FHIR medication model - from MedicinalProductDefinition.route through to MedicationRequest.dosageInstruction.route and MedicationAdministration.dosage.route. SNOMED CT dose forms using route of administration would therefore align more closely with how IDMP is actually realised in the interoperability standards everyone is implementing, not less.
The main interoperability surface between SNOMED CT and EDQM is on the dose forms themselves. We already have the EDQM-to-SNOMED CT dose form map with ~310 mappings, and many of these are straightforward because the dose form concepts often share identical names. If the dose forms are mapped (and they are), does the attribute used to classify those dose forms on the SNOMED CT side materially affect that interoperability? I’d genuinely like to understand: what specific problem does replacing intended site with route on SNOMED CT dose forms cause for IDMP/EDQM alignment? What does this “further significant deviation” actually break in practice?
As Stuart has already demonstrated, we’ve already deviated from EDQM in this space - building a hierarchy where EDQM has a flat list, using “intraocular” where EDQM uses “ocular”, and so on. I’m not aware that this has caused a significant problem. The question should be: does the proposed change make the dose form map harder to produce or use? I don’t think it does - but I’m open to hearing a concrete scenario where it would.
2. Clinical safety
This is an important consideration. Are you aware of any specific clinical safety concerns you can articulate? I ask because I think the clinical safety argument actually runs in favour of alignment with route. Clinical systems, FHIR resources, and prescribing workflows all use route of administration. The current disconnect between intended site on dose forms and route on prescriptions is itself a source of implementation complexity - and implementation complexity is where clinical safety risks tend to hide. Every national extension independently maintaining mappings between these two hierarchies is duplicated effort and duplicated risk.
On your point about different use cases
You’ve noted that intended site supports regulatory processes and route of administration pertains to clinical situations. I think this actually supports the proposal rather than argues against it. SNOMED CT is designed for clinical purposes. It has to work with standards like FHIR that are serving clinical use cases - MedicationRequest.dosageInstruction.route, MedicinalProductDefinition.route, AdministrableProductDefinition.routeOfAdministration. If intended site serves regulatory uses and route serves clinical uses, then SNOMED CT - as a clinical terminology - should be optimising for the clinical representation. We won’t be successful as a clinical terminology if we’re in lockstep with regulatory modelling at the expense of the clinical use cases and interoperability standards that are squarely in SNOMED CT’s wheelhouse.
To be clear on what’s being proposed: the replacement attribute on the dose form would represent the route(s) that the dose form is formulated for - what the form is designed and quality-controlled to support. This is exactly as fixed and definitional as the current intended site. An oral tablet doesn’t change its formulation-intended route any more than it changes its intended site. The pharmaceutical quality implications that Julie rightly highlighted - sterility, pH, osmolarity - are just as implied by the route as by the intended site. “Has applicable route = Parenteral route” carries the same sterility implication as “Has dose form intended site = Parenteral”. No information is lost. What varies clinically - the actual route used for a particular patient, including off-label use - is a separate concept that belongs on the prescription or administration record, not on the dose form definition. The proposal is to align the dose form’s fixed attribute with the terminology used everywhere else, not to introduce clinical variability into the dose form model.
Having our cake and eating it too
But I think we can go further than just replacing one attribute with another. Rather than framing this as “SNOMED CT deviates from IDMP”, we should be asking: can we infer the EDQM intended site from the stated route of administration? If so, the EDQM intended site link is preserved - it’s just derived rather than directly stated.
This seems very achievable. The EDQM intended sites are a small, flat list (fewer than 30 concepts, many of which are veterinary-only or edge cases). The mapping from route to intended site is largely systematic - oral route maps to oral intended site, parenteral routes (IV, IM, SC) map to parenteral intended site, ocular route maps to ocular intended site, and so on through vaginal, nasal, rectal, auricular, cutaneous, transdermal, pulmonary, dental, sublingual, buccal, and the rest. Some edge cases would need manual attention - oromucosal vs oral being the most obvious, and a few of the more specialised sites like gastric, gastroenteral, and intestinal (which relate to device-administered access) - but the bulk of the mapping is mechanical.
This could be implemented a few ways:
(a) A maintained reference set mapping each SNOMED CT route concept to its corresponding EDQM intended site. This is a small, relatively static artefact - the EDQM intended site list rarely changes, and the mapping is largely obvious from the semantics. This reference set could be maintained centrally.
(b) Hierarchy organisation - if the route of administration hierarchy were organised so that grouper concepts correspond to EDQM intended sites (e.g., a “Parenteral route” grouper subsuming IV, IM, SC etc.), then the intended site becomes inferrable via subsumption. This is arguably the most ontologically clean approach, though it would require creating some grouper concepts that don’t currently exist (notably “Parenteral route”).
(c) Computable rules / GCIs - a set of axioms asserting that dose forms with a given route necessarily correspond to a given intended site for the purposes of EDQM mapping. This keeps the mapping logic inside the terminology.
The fundamental question
But before we spend time designing inference mechanisms, I think the more fundamental question is: if SNOMED CT dose forms had route of administration instead of intended site, and there was no inferred intended site at all - given that the EDQM-to-SNOMED CT dose form map already exists and maps dose form to dose form directly - would that actually cause a problem for IDMP/EDQM compatibility or interoperability? The dose form code carries the intended site information implicitly (that’s how EDQM classifies its own dose forms internally). FHIR’s IDMP resources don’t transmit intended site as a separate element. So what concrete use case requires intended site to be separately computable on the SNOMED CT side?
If the group can identify such a use case, the inference approaches above show how it could be addressed. If no such use case exists, then we’re maintaining a parallel hierarchy that serves no interoperability purpose while creating real barriers to the clinical use cases that SNOMED CT was designed for.
I’d welcome concrete examples from anyone where this approach would fall short so I can understand the issue better.