unit field limited by precoordinated ucum unit

[Rosnyni]

It is not possible to enter valid ucum unit in the unit field if they are not 'precoordinated' in the API used.

For exemple :

In such case, it leads to the following extension :

      "extension": [
        {
          "url": "http://hl7.org/fhir/StructureDefinition/questionnaire-unit",
          "valueCoding": {
            "code": "/mm3",
            "display": "/mm3"
          }
        }
      ]

it is of course possible to :

• convert the unit for precoordinated : /mm3 --> /ul
• discard the annotation :
  • wk{gestationnal} --> wk
  • I'm less confident in {pack}.a --> a ?

but we loose some convenient annotation and possibly some users used to one unit

Instead of relying on a limited precoordinated set of unit, it could be possible just to validate the unit filed by the user in the field ? Or just enriching the list of precoordinated units ? Or add an option in the formbuilder to fully specify unit (codesystem, code and display) ?

There is probably tons of solution...

[Rosnyni]

The unit management in the formbuilder also lead to error in IG publisher QA as the display used in the questionnaire-unit extension is not the one defined in UCUM :

and the log :

24

Request: 

POST http://tx.fhir.org/r4/CodeSystem/$validate-code? HTTP/1.0
Accept-Charset: UTF-8
Accept: application/fhir+json; fhirVersion=4.0
Content-Type: application/fhir+json; fhirVersion=4.0;charset=UTF-8
User-Agent: fhir/publisher

{"resourceType":"Parameters","parameter":[{"name":"coding","valueCoding":{"system":"http://unitsofmeasure.org","code":"cm","display":"centimeter"}},{"name":"default-to-latest-version","valueBoolean":true},{"name":"cache-id","valueId":"74767d00-d037-4845-93ac-eee9b1928d47"},{"name":"x-system-cache-id","valueString":"dc8fd4bc-091a-424a-8a3b-6198ef146891"}]}


Response: 

200
access-control-allow-methods:GET, POST, PUT, PATCH, DELETE
access-control-allow-origin:*
access-control-expose-headers:Content-Location, Location
cache-control:public, max-age=600
connection:keep-alive
content-length:866
content-type:application/fhir+json
date:Fri, 05 Apr 2024 14:00:16 GMT
last-modified:Fri, 05 Apr 2024 14:00:16 GMT
pragma:no-cache
server:nginx
strict-transport-security:max-age=157680000
x-request-id:136-86301

{"resourceType" : "Parameters","parameter" : [{"name" : "result","valueBoolean" : false},{"name" : "system","valueUri" : "http://unitsofmeasure.org"},{"name" : "code","valueCode" : "cm"},{"name" : "version","valueString" : "2.0.1"},{"name" : "display","valueString" : "cm"},{"name" : "message","valueString" : "Wrong Display Name 'centimeter' for http://unitsofmeasure.org#cm. Valid display is 'cm' (for the language(s) '--')"},{"name" : "issues","resource" : {"resourceType" : "OperationOutcome","issue" : [{"severity" : "error","code" : "invalid","details" : {"coding" : [{"system" : "http://hl7.org/fhir/tools/CodeSystem/tx-issue-type","code" : "invalid-display"}],"text" : "Wrong Display Name 'centimeter' for http://unitsofmeasure.org#cm. Valid display is 'cm' (for the language(s) '--')"},"location" : ["Coding.display"],"expression" : ["Coding.display"]}]}}]}

[plynchnlm]

The UCUM standard does not define a display string for "cm". FHIR does here: https://www.hl7.org/fhir/valueset-ucum-units.html, and the display string it lists is "centimeter". So, it looks to me like this error from the IG publisher is itself an error. Do you have a place to report problems with the IG publisher? If not, I could ask on chat.fhir.org.

[Rosnyni]

My understanding is that the display in the valueset can be specific :

while the display in coding (the datatype used in questionnaire-unit extension) is the one from codesystem :

We (APHP) use this extension because the unit was hard displayed in the questionnaire. Therefor, there is no use of a display in the extension.

We still have to think about, but a solution based on the LHC UCUM validator would resolve our two issues...

[plynchnlm]

With regard to the original issue here, I think there are two problems. The first is that the UCUM unit selector in the Form Builder does not behave quite like the one on https://ucum.nlm.nih.gov/ucum-lhc/demo.html, in that if you try to compose a second unit string with a first, the first is lost. Secondly, typing in a UCUM unit code without picking from the list does not result in a Coding with the UCUM code system set.

[plynchnlm]

There is a discrepancy between https://www.hl7.org/fhir/valueset-ucum-units.html (which defines display strings like "centimeter") and https://terminology.hl7.org/UCUM.html, which says the display strings are the unit codes. Apparently the latter page is the authoritative one, so we will adjust the Form Builder to use the codes for the display strings in the Questionnaire output.

[Rosnyni]

We are currently working on something that :

• validate any UCUM code (using https://ucum.nlm.nih.gov/ucum-lhc/demo.html)
• put the system for any UCUM validated code (not only those on the list)
• file the display with the code (for the coding types, initial.valueQuantity)

We will probably have something in one month if you can wait.

[plynchnlm]

I did create a internal task to work on these issues, but we probably would not start on it for a couple of weeks. My plan was to refactor the unit processing code for the list that appears on https://ucum.nlm.nih.gov/ucum-lhc/demo.html into a shared library to make it re-usable bu the form builder. That code (as you probably know) is currently on the gh-pages branch of the ucum-lhc repository. If you are taking a different approach, I am curious to know how you are using https://ucum.nlm.nih.gov/ucum-lhc/demo.html.

[Rosnyni]

I am curious to know how you are using https://ucum.nlm.nih.gov/ucum-lhc/demo.html

Nothing revolutionary

The idea is to:

• use the library you provide https://www.npmjs.com/package/@lhncbc/ucum-lhc to validate the unit string filed in the (repetable) unit field, and
• display, somehow, that the string is UCUM compliant or not. I don't know how yet, but I think something very explicit like :

May be using the color-code you already use :

[plynchnlm]

For getting the search autocompleter to work (so that it doesn't replace the full field value), I suggest looking at https://github.com/lhncbc/ucum-lhc/blob/gh-pages/demo/ucumDemo.js. Note that that file is more complicated than is needed here because it is the entire code for the ucum demo, and it is handling both the "convert" and "validate" tabs, but there should be some code that can be re-used (at least as a guide) for the form builder.