Dose Form Intended Sites vs Routes of Administration

I think the 'Intended sites' (which should probably be renamed to 'intended routes', as they are not anatomical sites, like |Nose structure|, but rather routes like 'nasal') and the 'routes of administration' are both different subsets of the same type of concept. The 'intended sites' used to define a dose form are typically more general concepts, while the actual route by which the drug is administered to the patient needs often needs to be expressed at a greater level of detail. However, they are both conceptually referring to routes of administration - In the information model, one of these routes is the 'intended route' for that drug, and the other route is the 'intended and then actual route' for that patient administration event.

In comparing the 2 lists in SNOMED CT (a) subtypes of 736479009 |Dose form intended site (intended site)| [33 concepts] and (b) subtypes of 284009009 |Route of administration value (qualifier value)| [166 concepts], the main differences are:

1. The 'Route of administration value' list adds the word "route" to the end of the PT
2. The 'Route of administration value' list is mostly a superset of the 'Dose form intended site' list (if you just look at the PT and remove the word "route"), except for:
   1. |Parenteral| appears in the 'Dose form intended site' list, but not in the 'Route of administration value' list. This is obviously used as a grouper concept, but is still referring to a category of routes.
   2. |Pulmonary| is used in the 'Dose form intended site' list, while |Respiratory tract route|, |Lower respiratory tract route| and |Intrapulmonary route| etc are used in the 'Route of administration value' list ... once again the 'intended dose form' acts more like a grouper.
   3. |Intestinal| is used in the 'Dose form intended site' list, while |Gastro-intestinal stoma route| is used in the 'Route of administration value' list.

Combining these lists into a single set of routes of administration (with subsets to use for each case if necessary), would simplify implementations that need to compare the 'intended route' of a drug with the actual route of an administration event to a patient (for various reasons). At the moment this requires everyone to do their own mapping exercise between the 2 lists.

Completely agree with Linda (and have communicated such, the past 2 years).

For EDQM mapping - What are the specific requirements for that? Who is using the map? Do the attributes all need to map also? Or is mapping the Forms sufficient?

I've copied my previously submitted SNOMED CT/Implemenation Use Cases below.

When we try and give implementation guidance to users of the terminology.

Imagine a UI for creating dose instructions or prescriptions.

1. The clinician selects “Paracetamol” (90332006)
2. Then clinician selects the “route of administration”

Which set of values should be used here?

Intended site – Oral (738956005), Rectal (738986003)

              Or

              Route of administration - Oral route (26643006) , Rectal route (37161004)

A route of administration value set already exists Valueset-route-codes - FHIR v5.0.0 (hl7.org), and is referenced for Medicines, allergies and procedures (re-used).
However, these codes have no relationship for the medicines terminology.

If we used the range (whatever that might be) for “Dose form intended site”, we can actually leverage the terminology within our implementation!
e.g. a backend “ECL template” <@MedicinalProduct@: |Has manufactured dose form|=(<|dose form|:| Has dose form intended site|=<<@Route@)

User enters “Paracetamol” + “Oral” -  (<90332006:411116001=(<736542009:736474004=<<738956005))

User enters “Paracetamol” + “Rectal” -  (<90332006:411116001=(<736542009:736474004=<<738986003))

It might be possible to get away with using a "mapping between intended sites and routes" - but this is just another barrier to implementation. Either somehow incorporating the mapping into ECL or client side processing...
This stuff is hard enough already without adding hoops to jump through.

For clinical implementations there's many gaps in SNOMED CT for forms - particularly for abstractions that are useful clinically.
For example we have groupers like 778317004|Amoxicillin only product in oral dose form| and 385268001|Oral dose form|
But we don't have an single concept like |Amoxicillin only product in oral liquid| or |tablet/capsule dose form| - which are useful in prescriptions where the prescriber doesn't care if it's a tablet or capsule, or if they patient has trouble swallowing.