SNOMED CT to UCUM map for units of measure (<767524001)

SNOMED Groups Drugs Extension User Group
1

Hi all,

We’re looking at building (or reusing) a SNOMED CT to UCUM concept map scoped to <<767524001 |Unit of measure|, and wanted to check with the group before duplicating effort.

A few questions:

  1. Has SI (SNOMED International) produced, or is it working on such a map (RF2 or FHIR ConceptMap)? I’ve heard something might exist, but not sure if that is current information.
  2. Has anyone in the group already built one internally, whether as a full RF2 map refset or a FHIR ConceptMap resource? If so, would you be willing to share the artefact, or at least the approach, even informally?
  3. If yes, How have you handled units of presentation that fall under <<767524001 but don’t correspond to a UCUM base or derived unit — for example, 732936001 |Tablet (unit of presentation)|? UCUM doesn’t really model discrete dosage forms as “units” in the same sense it models mass, volume or count, so I’m curious whether people have:

We (and at least one vendor) have a need for this, but a map of this kind seems like it would have broad international applicability rather than being something each member should build in isolation. If nothing exists, we’d be interested in collaborating on a shared artefact rather than everyone re-solving this problem independently.

Thanks,
Matt

1 Like
2

Hi Matt,

I started thinking about a SNOMED CT representation of UCUM about 10 months ago and put together a couple of preliminary slides on which to base a proposal. (See Attached)

As you know, UCUM is both a code system and a set of syntactical rules for generating precoordinated units of measure. If we handle this using a map, I think we lose a lot of the capabilities native to UCUM, like convertibility between units of measure.

My proposal was going to be to move the Units of measure out of the qualifier value hierarchy and into its own hierarchy with a “(uom)” or “(unit of measure)” semantic tag. The hierarchy would have its own logical model based significantly on the structure laid out in the UCUM specification. The UCUM unit of measure, when available, can be represented as an alternate identifier because it should be an exact representation of the UCUM unit of measure in SNOMED CT.

In UCUM, the units of measure are not associated with a unique concept identifier because the unit of measure is the unique string. This makes it a bit more difficult to represent the content as a standard map. In cases were there can be a link between UCUM and SNOMED, the UCUM string could be represented as an alternate identifier because the UCUM string should be identical to the FSN without the semantic tag. Granted, I need to look at the specification for the alternate identifier file and confirm that a character string is allowed in the “Alternate Identifier” field. It likely can because it supports the hypen in the LOINC code.

Handling this as a map presents additional issues when it comes to assigning a map equivalence. There should be no equivalency to assign since a unit of measure should be an exact representation in a different code system, otherwise it could be implied that “mg/dl” is not equivalent when represented in different code systems. Since UCUM intentionally does not represent all possible pre-coordinated units of measure, not all SNOMED Concepts in the units of measure hierarchy will have an alternate identifier. I would only expect those units of measure explicitly stated in the UCUM specification to be assigned as alternate identifiers in SNOMED CT. This will cause some unit of measure concepts in SNOMED CT to not have an alternate identifier, which may be a bit more appropriate than not having a mapped value.

I have not fully investigated the need for concrete value attributes to represent all aspects of logarithmic representations or conversion factors represented in the UCUM specification.

The attached Powerpoint slide deck is a very preliminary set of thoughts on the topic that is by no means a complete proposal. I thought it appropriate to share here to help round out the discussion.

Is part of the goal in this work to properly represent units of measure in alignment with UCUM for proper modeling of medicinal products? If so, then cleaning up the units of measure content in SNOMED and using the alternate identifier may be a better path, even though it will have a longer runway to achieve.

UCUM_SNOMEDCT2.pdf (138.1 KB)

3

Thanks John,

At first I thought that draft was too complicated, but I quickly did find a few things appealing.

  • The has symbol - seems unecessary - more a syntax/rendering element than a feature.
    A recent example raised here was “g/L” and “g.L-1” - these are the same unit of measure. Just different renderings. (Though in reality, only one is typically used in a given use case/context).
  • The “prefix” I feel might be more useful as concrete domains with multiple of 10 (relative to the “atomic unit”) - to support conversions.

Though I think a lot of this (unit conversion) is already supported by UCUM

My use case was really that we have medicine concepts modelled using SNOMED CT:
e.g. 322280009 |Product containing precisely paracetamol 500 milligram/1 each conventional release oral capsule (clinical drug)| uses 258684004 |milligram (qualifier value)|

But medication resources (Prescriptions, Dispense record) generally use UCUM for the Quantity datatype - “The preferred system is UCUM, but SNOMED CT can also be used (for customary units) or ISO 4217 for currency.”

So I’m just after a simple mechanism to switch back and forth / identify equivalence between the two codeSystems.

BTW, we’ve already added 2 UoM properties in our extension
e.g 258798001 |Milligram/milliliter (qualifier value)|

image
image296×105 2.4 KB

It’s very basic, but provides a little bit of meat for us to run some content validations (e.g. liquid medicines always use a volumetric deminoator for their strength).

4

Thanks @mcordell ,

I know it was overkill for your use case. It was more designed to enhance the representation of LOINC and probably NPU content in their extensions.

One comment in your response that stuck out: “So I’m just after a simple mechanism to switch back and forth / identify equivalence between the two codeSystems.”

two questions:

  1. Can the alternate identifier fulfill this role if the alternate identifier is the UCUM code? (I think to maintain integrity, this only works if the unit of measure is either a base or atomic unit and not a precoordinated unit.)
  2. To the best of my knowledge there is no EHR based implementation of UCUM as a code system and syntax, meaning that the system validates user generated units of measure on the fly. The computerized world is based on precoordinated units and there isn’t one single authoritative source for all precoordinated units that is regularly updated. Does it make sense to have a single authoritative source for precoordinated units of measure and if so does it make sense to have it in SNOMED CT in order to support LOINC, NPU, and medicinal products?