FHIR Chat · Determining Quantity.unit for UCUM quantity · implementers

Stream: implementers

Topic: Determining Quantity.unit for UCUM quantity

Erik Nielsen (Jul 24 2020 at 11:15):

Is there a recommended or best practice method to determine what value to use as unit in a Quantity specified using UCUM? This given that the proper UCUM code has been established.

It appears from e.g. https://www.hl7.org/fhir/observation-example-bloodpressure.json.html and other examples that the unit is not simply the UCUM code but rather the printSymbol from http://unitsofmeasure.org/ucum-essence.xml. One could parse that file using https://github.com/FHIR/Ucum-java and get the printSymbol that way, say, client-side, but is there a more centralized way, perhaps from a FHIR terminology service?

If provided through a FHIR terminology service, would a property or designation returned through a $lookup be one, standard FHIR way to obtain it?

(Incidentally, shouldn't the https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Quantity.20search.20and.20display.20units/near/164556273 example really be unit "a" instead of "yrs" as in:
"valueQuantity": {
"value": 7,
"unit": "a",
"system": "http://unitsofmeasure.org",
"code": "a"
})

Lloyd McKenzie (Jul 24 2020 at 11:46):

'unit' is the display value - it can be anything. I don't believe there's a formal algorithm for determining a 'display' value for UCUM units (as in most cases, the code and desired display value are the same - 'a' is an exception).

Erik Nielsen (Jul 24 2020 at 12:44):

even if the 'unit' is just a display value in Quantity, at some point you might want to present the Quantity content to a user. At this point, would you not expect the displayed unit to be accurate and completely correspond to the code so that e.g. blood pressure is presented as mmHg instead of what might or might not be available in unit?

Although presentation could be (maybe should be) solved client-side, the centralized FHIR terminology service solution also has its benefits.

Lloyd McKenzie (Jul 24 2020 at 12:47):

Absolutely - but that doesn't mean that UCUM defines a standard display value. A system might choose to display "cubic centimeters" or "cc" or
"cm^3" or "centimètres cubes" or any other string that the user would be expected to recognize. And 'unit' might not even be chosen by a computer - it could be the value a human filled in and the code came along later via a post-coding process. From a computability perspective, Quantity.unit is equivalent to CodeableConcept.text.

Lloyd McKenzie (Jul 24 2020 at 12:48):

i.e. while a correlation is expected, pretty much anything goes...

Erik Nielsen (Jul 24 2020 at 13:24):

Interesting - I can appreciate how that allows for a wide variety of applications. It also dawns on me that I am trying to solve presentation issues with a definition-oriented or API framework (which is awesome btw). The CodeSystem designation just seemed like an intriguing way to solve challenges in consistent presentation.

Are there better ways to solve this, say, if there were an international or a number of national "proper" or agreed unit corresponding to each UCUM code such as e.g. "centimètres cubes"?

Lloyd McKenzie (Jul 24 2020 at 14:39):

If there's an agreed display available in your terminology service, you can use that to populate 'unit' if you don't have something direct from the user.

Grahame Grieve (Jul 24 2020 at 20:51):

The ucum tests in the java code imply a standard presentation, but it's not actually standardised. There are print symbols in ucum-essence.xml, but how to combine them to reflect the grammar is not specified

note that there are other rules applying to Quantity.unit - for instance, due to historical handwriting concerns, it is not unusual to encounter a rule that the symbol µ cannot be used, and "mc" must be used instead. Professional societies, slow moving and dominated by pre-digital thinking are quite often still firmly attached to these rules, but any generated display based on ucum codes will lead to "µ".

And more generally, must systems will serve up a manually configured unit that may be mapped to UCUM. The older they are, the more likely that is true. But it's not reason that a new system has to

Colin E. (Aug 13 2020 at 18:04):

I am looking at this subject at the moment. UCUM is designed solely for machine communication, as stated in the spec. If a UCUM code string happens to be readable by a human being that is a happy accident, not a design requirement.

It is easy to construct, accidentally or by design, valid UCUM codes that would be dangerously confusing or misleading to a human reader (such as a clinician). This has clinical safety implications, so just using the UCUM code as a display format is not an acceptable option.

The "print format" capability in UCUM is incomplete, as @Grahame Grieve has stated. It also seems to be a problem for implementers, and seems to be either buggy, thinly-tested, or simply not present in some UCUM implementations (not sure about the FHIR implementation?), so it is not a suitable basis for the human display requirement.

That leaves a major gap to be filled. Ideally there would be a fully readable (usability tested) display formatting translation available for UCUM with it's own set of display "atoms" and syntax. I could see the potential for at least two rendering styles- (1) a "Single Line" style could be implemented quite easily using just Unicode characters and basic HTML for superscripts+subscripts. This would render in any modern web browser; (2) a block or "maths book" style (multi-line) would need to be defined in something like LaTeX or MathML. Unfortunately MathML support in browsers is patchy at the moment and many clinical systems are far from leading-edge in terms of platform technology, so this one might be a step too far for today's systems.

In the absence of such a solution I am considering the option of having to have a predefined + curated set of approved UCUM codes mapped to an (also equally manually maintained) set of human display forms. That loses one of the key benefits of UCUM (unlimited expressivity) and is going to be slow and costly to maintain.

If there are better options out there, and/or if people have experience of implementing either the manually curated approach or another option, I wold be very interested to hear about it.

Michele Mottini (Aug 13 2020 at 18:12):

We rely on the display value, if that's not present usually the code is pretty reasonable (_if_ your have a UCUM unit to begin with...)

Grahame Grieve (Aug 13 2020 at 20:04):

have you looked at the predefined curated set in the standard itself?

Colin E. (Aug 13 2020 at 22:14):

Grahame Grieve said:

have you looked at the predefined curated set in the standard itself?

Good question. I have looked at a couple of curated UCUM value sets, including the "Common UCUM Units" list from the LOINC site, and another from the HL7 organisation in Germany (hl7.de). There seem to be some inconsistences between these (beyond just being different selections of units that is), although I can't claim to have run every list through a UCUM parser or checker to see whether things that look odd to me are actually incorrect usage or not.

I found the FHIR info harder to folow. The description at https://www.hl7.org/fhir/valueset-ucum-units.html says the valueset includes "All codes from system http://unitsofmeasure.org", but as UCUM is a non-finite expression language, that implies that the valueset is infinite. That could be true if the "valueset" is not actually a set of values, but instead a validation function (the UCUM parser), and the "expansion" is only a curated subset, but the documentation leaves it unclear whether the list of ~1000 units shown is __THE__ FHIR list, or whether there is another larger and more definitive list somewhere else but the link to it is missing.

All of these lists lean heavily on the use of annotations (the curly bracket syntax) which seems to me one of the more problematic aspects of UCUM. For example a quick count in excel indicates that 402 of the 1000 UoM in the FHIR list of UCUM codes contain annotations. Given that (a) UCUM is designed for calculation/computation with units; and (b) annotations are non-semantic items in the UCUM syntax, it seems worth asking why so much effort is being put into information that the machine processing will specifically ignore.

My guess is that most of these comments (which is effect what they are) are there to make human readers happier reading the units, but then as discussed above UCUM is not designed for humans to read, so that seems like an attempt to make it do something it's not designed to do.

Colin E. (Aug 13 2020 at 22:54):

My concern with institutionalising the use of annotations, if raw UCUM is ever shown to users, is that you are effectively training users to believe and rely on the information in the curly brackets.

One of the major uses of annotations seems to be to inject names for countable entities (white blood cells, red blood cells, bottles, bowls, base pairs etc.) into a system where the maths doesn't need them (the unit of a countable item is "1") but the users want to have them (again, UCUM isn't for users...). This usage at least doesn't raise obvious safety concerns as anything in curly braces in UCUM is equivalent to "1" by definition .

What is more concerning is the prospect of, say- "(ng/g)" being transmitted (or read) as "{ng/g}", or vice-versa, and the machine and the human interpretations being different by a factor of a million.

Annotations also seem to be being used as a sticking plaster solution for the fact that the UCUM standard itself has not changed in several years, and it appears some things are needed but not present. For example a "Mac Lagan Unit" [mclg'U] is a real unit in UCUM, with a definition in the unit system. It is a procedurally defined unit (arbitrary in UCUM terms), so it won't take part in unit conversions, but it will be preserved in calculations. Conversely an Erlich Unit {Ehrlich'U} is a comment, and can be lost in a calculation at any point. Note- some UCUM implementations seem to drop annotations whenever a calculation is done, I don't know whether the FHIR implementation preserves them by default, but I assume it will happily convert "{Ehrlich'U}/s" to "s-1" when asked, as the demonstrator at https://ucum.nlm.nih.gov/ucum-lhc/demo.html does.

Grahame Grieve (Aug 13 2020 at 22:56):

• the value set is infinite.
• what is unclear about "only a selection (1000 codes) of the whole set of codes is shown"?
• I agree about annotations. I think it shows that people are confused by the way CDA didn't have a display for the units (mea culpa)
• the value set I was actually referring to is https://www.hl7.org/fhir/valueset-ucum-common.html
• I'm not sure about 'the FHIR implementation', since there isn't one

Colin E. (Aug 14 2020 at 00:52):

• the value set is infinite

Thanks for the confirmation. That was my guess but I wasn't sure.

• what is unclear about "only a selection (1000 codes) of the whole set of codes is shown"?

The implication that there is a "whole set" somewhere, that could potentially be available but it's just too large to display. I accept that mathematically the idea of an infinite set is not a problem, but my first reaction to that description was to think of a set as a list- a finite thing, and not a validation function with unlimited input and output domains.

• I agree about annotations. I think it shows that people are confused by the way CDA didn't have a display for the units (mea culpa)

I don't have the history/background to comment i'm afraid. I came to this relatively recently and I am doing my best to make sense of it, and steer a path that allows machine processing to add value without compromising usability of the data for clinicians and patients

I do note that the full FHIR common units list contains both-

a) mg/d/(173.10*-2.m2)
b) mg/d/{1.73_m2}

I would say most human readers are liable to see these as describing the same unit, in both magnitude and dimensionality. To the computer they are completely different. The second version (b) not only wraps the numeric factor of "1.73" in a comment meaning it actually evaluates to "1", but also manages to lose the "per metre squared" component of the dimension inside the annotation as well. Version (b) means "mg/d" to UCUM.

That is apart from the fact that UCUM doesn't deal with decimal numbers (not in the units field). The decimal point always indicates multiplication in UCUM syntax, so that seductive-looking "1.73" number (which is what is actually what the author was trying to convey, that number is used in UK clinical practice) means "1" to UCUM when it is inside curly braces, and "1x73" == "73" anywhere else. The one thing it NEVER means to UCUM is 1.73!

This seems to me to be a problem, and a source of clinical risk. I would be interested in other views.

• the value set I was actually referring to is https://www.hl7.org/fhir/valueset-ucum-common.html

Is there a reason why there are two pages, http://hl7.org/fhir/ValueSet/ucum-units and https://www.hl7.org/fhir/valueset-ucum-common.html that are similar but not the same, and don't appear to link to each other?

It looks like I picked up the shorter of the two (the subset), which comes up first on a site search for "ucum valueset", but they are very similar so the comments on principles would be the same. The specific differences are interesting though, I can't help wondering what clinical environments would have identified British long tons [lton_av] and links for Gunter's chain [lk_br] as essential to their work. Is there an audit or governance trail for the common units that would show how items came to be identified as "common"?

• I'm not sure about 'the FHIR implementation', since there isn't one

Hmm that's interesting. It's been roughly two years since I last looked at this area, and back then I formed the impression that there was a UCUM implementation in Java, and possibly also one in .Net that was distributed through or somehow supported by HL7. Looking back through my notes I can't see exactly how I came to that conclusion, which is annoying. There is a link on the UCUM web site (at the bottom of https://unitsofmeasure.org/trac) that refers to an "HL7Connect" implementation, but that links to a holding page (dead site) so i'm not sure whether that that would have been the original source of that idea.

The original implementation of UCUM was written in Java (per the original paper by Gunther Schadow, Clement McDFonald et. al.) and according to that that paper it was open source. I have tried to trace what happened to that original source package. I wondered whether it was in the ancestry of any of the current implementations, including the "HL7 FHIR" implementation that it now seems I may have invented out of thin air...

Grahame Grieve (Aug 14 2020 at 01:36):

there is a package in maven: https://mvnrepository.com/artifact/org.fhir/ucum. I did write it. And I did the UCUM tests as part of writing it. And I still maintain it. But it's not (in spite of having FHIR in it's org name), an official FHIR UCUM implementation

Grahame Grieve (Aug 14 2020 at 01:36):

I don't know about a .net implementation

Grahame Grieve (Aug 14 2020 at 01:41):

we have 2 value sets for UCUM:

• http://hl7.org/fhir/ValueSet/ucum-units - includes any ucum unit that is valid.
• https://www.hl7.org/fhir/valueset-ucum-common.html - I made this by merging the valuesets from the LOINC common units, the Canadian health infoway unit value set, and 2 unpublished sources: Intermountain, and Google. Then I removed the 10% of codes that weren't actually valid. It's defined in order to be a relatively comprehensive enumerated list of units people use, to serve systems that can't deal with the infinite list that the first value set represents. If you want to propose improvements to it, feel free.
• I guess that part of the language that implies the value set isn't infinite could be improved. Do you know how to make a FHIR change proposal?

Colin E. (Aug 14 2020 at 09:44):

Grahame Grieve said:

there is a package in maven: https://mvnrepository.com/artifact/org.fhir/ucum. I did write it. And I did the UCUM tests as part of writing it. And I still maintain it. But it's not (in spite of having FHIR in it's org name), an official FHIR UCUM implementation

I was probably thinking of the FHIR/UCUM-Java package on GitHub https://github.com/FHIR/Ucum-java. Is that the same thing? (You are listed as a contributor)

If yes, was this written from scratch directly from the UCUM spec, and is the same true for any validation code? As noted, I'm curious to know if any of the current implementations are derived from the original source, including the validation suite the UCUM paper references, or whether all the current implementations are effectively "clean sheet" designs.

Colin E. (Aug 14 2020 at 10:03):

I think I have made one documentation change request before, I'll see if I can remember the process.

I would be happy to recommend some updates to the common units list. Initially that would be informal, but if we do go down the curated list route, that data would be public and it would be desirable to closer to the default FHIR valueset instead of further apart.

My first inclination would be to delete all the annotations, which would probably be a bit extreme for existing users, even though it would make no difference to the actual meaning of the content to UCUM.

As an aside, implementing a validation rule that says that the content of a UCUM annotation cannot itself be a valid UCUM expression would seem reasonably easy to implement.

However, removing annotations that LOOK like valid UCUM syntax to humans, or are otherwise confusing, would still need to be done manually. There probably aren't many of those in the common list, so it sounds like a reasonable aim.

I'm about to take a week's holiday. When I get back I will see if I can put some time into coming up with a set of recommended changes, and submit that for consideration.

Grahame Grieve (Aug 14 2020 at 20:13):

yes, that's the one I meant. mine was written from scratch. there was a .Net translation of it, but I don't know whether that was the heritage for the current .net one

Grahame Grieve (Aug 14 2020 at 20:14):

what's the logic for saying annotations shouldn't be valid UCUM syntax? (because as you pointed out above, the syntax might be correct, but the semantics very different)

Alexander Zautke (Aug 15 2020 at 08:19):

The current .Net implementation can be found here: https://github.com/FirelyTeam/Fhir.Metrics

It’s also a written from scratch. It shares a set of common tests with the Java implementation, so it should behave the same. And yes, annotations are not retained in the canonicalization process.

Colin E. (Sep 04 2020 at 21:24):

Grahame Grieve said:

what's the logic for saying annotations shouldn't be valid UCUM syntax? (because as you pointed out above, the syntax might be correct, but the semantics very different)

Because annotations are "non semantic" to UCUM, or rather any text in an annotation always has exactly the same meaning, i.e. "1" (the Unity). So annotations that communicate non unit information (i.e. actual comments) are just "line noise" and maybe a visual distraction, but not actually harmful.

Similarly, referring to countable items, e.g. {RBC}, {CFU} might be unnecessary for the maths, but the unit of a countable entity is "1", so it resolves to the right answer, even if by almost acccident.

However, if I send 37.2{mg/g} when I should have sent 37.2(mg/g) a machine will happily process the second version as being 1000x smaller than the first, but my guess is a busy clinician might not.

At the moment i'm not aware of a valid use case that requires the content of the annotation braces to be itself a valid UCUM unit code, and the downsides are potentially serious. Having an editorial rule that says "an annotation string should never represent, or appear to represent, a valid UCUM unit expression" seems one of the few ways to easily define what NOT to do in annotations, which are otherwise freeform and therefore wide open to error and/or abuse.

Colin E. (Sep 04 2020 at 21:46):

Looking at ways to implement a solution based on looking up a display form for a UCUM code I can see two places where we would need to publish a relationship mapping between code sets.

The first, and hopefully simplest, is a mapping from a UCUM unit expression in machine readable (MR) form to a corresponding human-readable (HR) display form. The "to" side of the mapping could be a reference to a SNOMED term, but that is TBC depending on whether SNOMED can accommodate the definition of the display form. This mapping would probably be defining a 1:1 synonym relationship, at least initially. I think this could potentially 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-

1. Support many to many relationships (each UoM is used for many tests, and each test may allow for more than one valid UoM)
2. 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

SNOMED doesn't handle many-to-many relationships it seems, so I had originally thought this looked like a ConceptMap as well, although there are a couple of areas of uncertainty-

• The ConceptMap 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.

• The question of many to many relationships isn't directly addressed 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 3rd party that ConceptMap is not the appropriate solution, and 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

I'm still inclined to say this application would fall into the ConceptMap space, as 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. 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.

Does that sound like a reasonable rationale, or am I missing some other key factor in this?

Lloyd McKenzie (Sep 05 2020 at 02:00):

The bracketed content is more problematic than just line noise. Most systems that deal with codes don't necessarily have any knowledge of the underlying code systems. As a result, "1", "1 {dose}", "1 {tab}" and "1 {tablet}" are all going to be treated as distinct units, rather than as equivalent from a computable perspective - and will result in errors when checking against value sets, etc. Stripping such comments from the 'computable' code is best practice. There's a separate element to capture the human-readable view of the unit.

Colin E. (Sep 05 2020 at 07:36):

What you say makes perfect sense Lloyd, but it does beg the question, if the annotations are problematic for machine processing and best removed, and the UCUM code isn't the thing we want to put in front of human users, then what exactly IS the purpose of all those bracketed annotations in most of the published unit lists?

There does seem to be a cultural inclination in the Chemistry (and maybe Biology?) disciplines to treat the units field as a place to put additional non-unit info. Often this is data that ought to be part of the "what is being measured and how" field. IMHO if a result description contains, say "Concentration of Red Blood Cells in whole blood" then the units are a number per Litre (L^-1), not something containing "red blood cells" or "RBC" in any form. The same applies to "spillover" of other aspects like the method, {fasting} etc. If these things are significant enough to note, they need to be in the procedure or observation where they will be visible and persist.

Colin E. (Sep 05 2020 at 07:55):

By the way, much of my concern over some of the thornier aspects of UCUM are because if a suspicion / guess, that in the absence of a widely accepted alternate syntax for human display that can be produced by either an algorithmic transform of UCUM or a code lookup, implementers are likely to just put the same UCUM code in both the code and display fields. I don't have any evidence for that view, and I see in other comments a different assumption, that the display will default to a manually entered display form for the unit.

Is that second view based on experience? Are implementers seeing live systems running, at least in the design stage, where hand-cranked (and locally entered) readable forms for units will be flowing beside UCUM in the code field?

Grahame Grieve (Sep 05 2020 at 09:48):

diagnostic labs in melbourne are quite familiar with this issue and won't just default. They pay a great deal of attention to these things. I'm not sure about other contents

Lloyd McKenzie (Sep 05 2020 at 13:58):

UCUM long precedes FHIR and historically, many systems had no ability to capture both human-readable and computable units. UCUM's design tries to span both spaces, with the cost of imposing additional expectations on the computability side of things. With FHIR, we have the flexibility to separate computable and display and that changes 'best practice' around what should go in the computable unit. That doesn'tmean that you can't use bracketed content with UCUM and FHIR, just that it's better to avoid if possible. I can't speak to what's typical in terms of rendering units - there are many options. The most common would likely be that internally units are something other than UCUM and get mapped for exchange

Colin E. (Sep 06 2020 at 21:51):

If anyone is, or has, looked at options for rendering units for human interpretation I would like to hear about it. Any kind of reference link or contact point would be appreciated.

Colin E. (Sep 06 2020 at 22:19):

Lloyd McKenzie said:

...With FHIR, we have the flexibility to separate computable and display...

True. What we don't appear to be able to do is provide two or more separately identified coded units, e.g. a UCUM one for the machine readable side and a SNOMED code (or some other reference) for the human-readable.

This is unlike a CodeableConcept where-

1. There can be any number of "translations" of the same concept
2. Each translation is a first class citizen, with a coded reference and a display form

In the case of UoM, as I read the spec., there can be only two representations, and the human-readable one is a second class citizen with a display form but no coded reference. This does seem limiting.

For example if this time around we decide on a human-readable representation that is not that different from UCUM, i.e. still something largely text based that fits in a single line on a display, maybe in future we might work on a more advanced "maths book style" display form using something like MathML. If UoM were CodeableConcepts we could just add the new form as a third translation beside the existing two, and give implementers the option to display it if they can. As it is I presume this would require a FHIR extension.

Grahame Grieve (Sep 06 2020 at 22:31):

yes extension for sure. I certainly would not recommend using a Snomed unit; I can only imagine that being an idea in UK, though I suppose I'm about to be proven wrong.

What I have done is added a best-practice check to the validator when it sees annotations in UCUM codes

Kevin Mayfield (Sep 07 2020 at 07:41):

Would UK do anything different???? https://simplifier.net/guide/DigitalMedicines/DM-Medication-Units
(note simplifier displays the excluded codes before the expansion)

Kevin Mayfield (Sep 07 2020 at 07:41):

^^ Is also draft

Grahame Grieve (Sep 07 2020 at 07:55):

yes see. I mean, why? I don't see snomed bringing value right here.

Colin E. (Sep 07 2020 at 21:15):

I'm not wedded to the idea of using SNOMED for the display form, but that does seem to be an option. Is that a "UK thing"?

Some possible arguments for-

• It's an existing tool we're working with. With FHIR, ucum and snomed already in the mix, not sure we want to add another one.
• Display forms could be overlayed on existing concepts as snomed synonyms
• In the future, it might be possible to use snomed structures to fill out more of a measurement model, e.g. a property hiearchy.

On the other hand, I have been told (but I don't know) that the snomed unit data is something of a mess, and there may be an existing property (kind of quantity) hierarchy in there that doesn't fit with the need to support mathematical processing. I don't know enough about the snomed content yet.

If there's a better option out there, I'd like to hear about it.

Grahame Grieve (Sep 07 2020 at 21:34):

tbh, I'm not sure why unit has any value coming from a code system. It's a human display. The thing worth making computable is the system/code, and that is the infrastructure. It's true we didn't cater for more than one code, since that's very unusual. There's always extensions.

As for SNOMED units... I've always thought that fits into the category of a hammer looking for a nail. It's just a list of possible units, with no structure or semantics.

The semantics of a measurement, otoh, seems like a more worthy investment, but that's really a mix of terminology and information models

Richard Kavanagh (Sep 07 2020 at 22:33):

As for SNOMED units... I've always thought that fits into the category of a hammer looking for a nail. It's just a list of possible units, with no structure or semantics.

I'm not wedded to the idea of using SNOMED for the display form, but that does seem to be an option. Is that a "UK thing"?

Yes - very much so ... :unamused:

Colin E. (Sep 09 2020 at 10:54):

There's been quite a bit of discussion on this thread on the content of a UoM display value (which has been very useful and illuminating BTW), but my other question above-

https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Determining.20Quantity.2Eunit.20for.20UCUM.20quantity/near/209144016

on how to do the associated mappings, especially when one should use ConceptMaps vs. Codesystem Supplements, has seen no responses. I'm not sure if I have tripped over board protocol by introducing another thorny (but related!) question into an existing thread. If so I'm happy to start a new topic, but I also as a newbie don't want to offend by double-posting, which is frowned upon in many groups.

So, I would appreciate a steer by the 'gods' of the board on how best to present the question.

I don't think it has an obvious answer, because the use case seems to sit awkwardly across the boundary between the intended use of these two as described in the documentation. I can read the docs and try to make sense of them, however I am not a FHIR developer myself so it is very hard for me to judge how using the API might differ if we chose one construct over the other.

Grahame Grieve (Sep 09 2020 at 12:08):

it's probably a #terminology question.

Colin E. (Sep 09 2020 at 14:50):

Grahame Grieve said:

it's probably a #terminology question.

I wondered about that, but again wary of double-posting as that is a major faux-pas on many boards. Thanks, i'll try on the Terminology stream.

Grahame Grieve (Sep 09 2020 at 17:29):

agree that it's a faux-pas but we also know that there's lots of places to ask questions, so we don't mind if it's done for that reason and with awareness

Lloyd McKenzie (Sep 09 2020 at 21:44):

Best practice is that if you're not sure where to ask is to pick one and ask if it's better covered elsewhere or raise in more than one, but include a reference to the other discussion locations - and once one kicks off, note in the other that primary discussion is happening in the other place.

Last updated: Apr 12 2022 at 19:14 UTC