Stream: terminology
Topic: Mapping applicable Units of Measure to Result Codes
Colin E. (Sep 09 2020 at 15:21):
Note: Topic moved here from #implementers as it was suggested this might be a more appropriate forum.
I am looking at how best to implement a solution for Units of Measure in Pathology. This would involve two main mappings-
- Looking up a human readable display/presentation form for a Unit of Measure (UoM) from the UCUM code
- A mapping of relationships between UoMs and result codes
The first of these would probably be defining a 1:1 synonym relationship, at least initially. I think this could be done either in SNOMED (maybe as a SimpleMap) or as a ConceptMap in FHIR.
The second map would define relationships between SNOMED codes for test results (either Observable Entity or Procedure codes), and corresponding "recognised" units of measure. This second map would need to-
- Support many to many relationships (each UoM is used for many tests, and each test may allow for more than one valid UoM)
- Support metadata / properties on the relationship, e.g. allowing us to define a unit as Preferred, Allowed or Deprecated when applied to a specific test
I had originally thought this also looked like a ConceptMap, although there are a couple of areas of uncertainty-
The ConceptMap doc page mostly talks about defining mappings between items of similar meanings (synonym-ish) rather than "item A when has applicability X when performing a function on item B", but it's not clear the latter use is disallowed either. As I understand it Concept only has attributes defining similarity, plus a "related to" option, so for our use we would need to extend the relationship types.
The question of many to many relationships isn't directly addressed in the docs either, but the ConceptMap itself looks like a joining table, with attributes, so it seems to be the right shape for the job.
However, I was advised by a knowledable individual to look at a CodeSystem Supplement instead.
Having looked at the guidance on the *CodeSystem *page-
Both Code System supplements and Concept Maps may be used to define relationships between concepts in different systems. ConceptMaps are assertions of the relationships between different concepts that are associated with particular contexts of use, while CodeSystem supplements are used to define inherent properties and semantics of the concepts in the code system
A Pathology report (our use case) is a "context of use" that defines the preference for a specific limited choice of UoM for a certain test type. That would argue for using a ConceptMap. There are "inherent properties" of tests and UoMs, around the associated Kinds-of-Quantity and Scale types, but that not what we are aiming to describe in this case.
However I believe using a CodeSystem Supplement may make it easier to put additional properties on the relationships, and also provide different API features around code set expansion etc.
Our use case seems to sit in a space where either model could probably be made to work, which makes it hard to make a choice. I would appreciate insights, especially from anyone who has actually implemented either of them, as to what the advantages and disadvantages of either choice might be.
Does that sound like a reasonable rationale, or am I missing some other key factor in this?
Christof Gessner (Sep 09 2020 at 15:45):
Not directly related to FHIR or pathology, but on units, UCUM and mapping result codes: http://rtmms.nist.gov
Grahame Grieve (Sep 09 2020 at 17:18):
Looking up a human readable display/presentation form for a Unit of Measure (UoM) from the UCUM code
This sounds like a supplement to UCUM to me
Grahame Grieve (Sep 09 2020 at 17:19):
A mapping of relationships between UoMs and result codes
For LOINC, this is already a core property of LOINC codes. (LOINC is what you would be using if you were not in UK, which it sounds like you are). So if you were asserting additional relationships, you would do that as a LOINC supplement
Grahame Grieve (Sep 09 2020 at 17:21):
you can also use a ConceptMap, yes. It is in scope for a concept map. There is some overlap between ConceptMaps and Supplemental properties, this is quite true, and it's not an xor choice between the two.
Grahame Grieve (Sep 09 2020 at 17:22):
What is not clear to me is how you would best express the nature of the relationship in a ConceptMap. I think this is unfinished business.
Grahame Grieve (Sep 09 2020 at 17:22):
but given that LOINC already has a property for this, I think that it suggests Code System Supplement.
Christof Gessner (Sep 09 2020 at 21:49):
for human readable display/presentation ISO/IEC 80000 might be a good source (if you believe in international standards for the purpose)
Colin E. (Sep 11 2020 at 00:29):
Thanks for all the comments so far, all very helpful. Yes I am in the UK, hence some aspects of the requirement are distinct as we are aiming to use SNOMED as the terminology in Pathology.
Re. ISO80000 etc.- Some of the justification given by the authors for the work done on UCUM includes the fact that, at least at the point when UCUM was instigated, ISO style standards were still largely designed to be published in print and read by humans. This led to some major issues that UCUM was intended to address-
-
Specs written by/for human readers tend to contain ambiguities or gaps that a thousand human readers might not notice, but a developer writing code (or their code itself) will trip over PDQ. (The example is given of "da" meaning both the decametric prefix and deci-are, which maybe went unnoticed until someone tried to code it)
-
They tend to focus on the metrology and specification of the individual unit "atoms", but then rather lose interest and leave the specification of how to combine those syntactically into unambiguous expressions and then render them for display in the hands of the typesetters and/or the mathematical knowledge of the readers. Again the UCUM docs mention one of the major standards requiring superscripted characters to meet the presentation specification, without any information on how this should be stored or shared.
I can't claim to have done anything like the research they would have done, but the examples in the UCUM docs of ambiguities and name clashes they had to deal with all seem real and relevant, and as far as i'm aware a rigorous character-level syntax specification for how to write unit expressions is not something the major standards bodies get involved in.
This is a big part of the value that UCUM adds, and it's undoubtedly a significant contribution. It's just a shame that the work wasn't extended to an equally rigorous specification for a human-friendly display form.
The standards bodies like ISO, IUPAC still don't get down to the level of things like character sets (beyond ASCII) or markup. Their print documents might well be typeset in LaTex, but that detail isn't part of the publication, and the same rendered presentation could be achieved many different ways, so exactly how a unit expression is turned into something "display ready" with (say) Greek letters, mathematical symbols, superscripts and subscripts etc. is left undefined.
When we start considering how to display a particular complex unit expression we will definitely be looking at the standards from ISO, IUPAC. maybe others, to set the target output, but when it comes to defining the character-level specification of the text and markup we need to store to render them I suspect we will be on our own. I'd love to be proven wrong on this and find a fully specified international standard with browser-ready definitions for the unit displays, but I haven't found one so far.
Colin E. (Sep 11 2020 at 00:34):
Christof Gessner said:
Not directly related to FHIR or pathology, but on units, UCUM and mapping result codes: http://rtmms.nist.gov
Thanks for the link, at first glance this looks like a very interesting resource.
Colin E. (Sep 11 2020 at 00:41):
Grahame Grieve said:
Looking up a human readable display/presentation form for a Unit of Measure (UoM) from the UCUM code
This sounds like a supplement to UCUM to me
I take the point from a logical/technical perspective. I don't know if this might be problematic in terms of the UCUM license terms. UCUM is "free as in beer" not "free as in speech" and the Terms of Use are restrictive when it comes to adapting, modifying or merging the content. This one of several areas where the choice to implement UCUM starts to become more complex when you look under the covers. Whether it could be claimed a UCUM supplement constituted an extension or a derivative product of the original I don't know.
Grahame Grieve (Sep 11 2020 at 02:10):
it looks to me like a code system supplement specifying correct displays for particular expressions as a supplement falls squarely into category 7. Taking the definition narrowly and precisely (as one must do when dealing with lawyers), then any expression which happens to be a primitive unit that you include in your supplement, you must include code, definition, value, and unit. But since there's no reason to provide a display for a primitive, you wouldn't be doing that. Hence, you just include the expressions, and the copy right statement, which seems reasonable to me
Colin E. (Sep 15 2020 at 15:07):
Thanks for the comments Grahame. Is there a precedent for meeting license notice requirements of the type specified in the UCUM Terms through an API like FHIR? Is the expectation is that access to the API will itself require agreement to Terms of Use (e.g. to get an access token), and that is where the upstream terms are cascaded down?
For example, the US NLM service at https://ucum.nlm.nih.gov/ucum-service.html provides open access, doesn't appear to include the license terms either on the landing page(s) or in the responses from the web service. Given the high profile of that site one would assume it's likely to be compliant in licensing terms.
Re-
Grahame Grieve said:
...But since there's no reason to provide a display for a primitive, you wouldn't be doing that. Hence, you just include the expressions, and the copy right statement, which seems reasonable to me
Not sure about that. Just because a display form and a UCUM code might be the same in some cases ("m" for metres for example will probably be the same as a code and a display) doesn't mean there might not be value in other aspects of the mapping. For example if the map was to a SNOMED code (and I accept that's not a universally popular idea) then you have access to the other capabilities of the target terminology, like defining synonyms.
Carol Macumber (Sep 16 2020 at 14:14):
Copying in @Swapna Abhyankar from Regenstrief/LOINC and UCUM. HTA is currently working with Swapna to finalize a External Terminology page for UCUM on HTA Confluence, located here: https://confluence.hl7.org/pages/viewpage.action?pageId=91986468
Last updated: Apr 12 2022 at 19:14 UTC
