Add units_system and units_display_name attributes to DV_QUANTITY

Description

Add fields to DV_QUANTITY for units system and units display name: String.

Values for units_system field: a URI, see FHIR (https://www.hl7.org/fhir/terminologies-systems.html).

Guidance: these are optional fields; either or both may be set. Units_display_name is for direct display.

If units_system is void, assume UCUM (i.e. that the value is 'http://unitsofmeasure.org')

If Units_display_name is not filled in, the application system has to convert units to the displayable form itself.

Activity

Show:
Diego Bosca
October 21, 2019, 11:06 AM

Name attribute usually is language-dependent and it’s not recommended to add name constraints in the archetypes, but would be filled in data instances/templates

Silje Ljosland Bakke
October 29, 2019, 11:15 AM

If I’m understanding you correctly, the Name attribute is different because it’s unique for each archetyped element. Unit names are the same across archetypes, based on the UCUM code and language, and therefore it makes no sense to spend time adding display names to archetypes. This should be handled in a lookup service.

Thomas Beale
October 29, 2019, 11:27 AM

The LOCATABLE.name attribute is a primary data item, settable in archetypes where needed. The units_display_name is a function of units and locale, i.e. always derivable from a service / lookup table that will differ per locale.

Ian McNicoll
October 29, 2019, 11:35 AM

Yesm, and if implementers wish to cache that ‘looked up’ name in local templates, or indeed in very local archetypes, that is a design decision but I agree with Silje that we should never do that in international archetypes , nor would I do it in e.g UK-specific archetypes.

Rong Chen
December 3, 2019, 8:35 AM

This issue with supporting both short label and a full URI of terminology/coding systems requires some thinking, it’s not just in dv_quantity. we have the same issue in dv_coded_text too. Here is a sample list of systems (see below). Historically we are handling the short labels (essentially IDs) but now we have to deal with the full URI type of IDs and need to convert them back to short IDs for readability.

 

Any thoughts on this?

 

{"CIE-10-CM-ES", "http://hl7.org/fhir/sid/icd-10-es"},

{"CIE-9-CM-ES", "urn:oid:2.16.840.1.113883.6.2"},

{"CIE-9-CM-ES", "http://hl7.org/fhir/sid/icd-9-es"},

{"ICD-10", "http://hl7.org/fhir/sid/icd-10"},

{"ICD-10-SE", "urn:oid:1.2.752.116.1.1.1.1.3"},

{"ICD-10-UK", "http://hl7.org/fhir/sid/icd-10-uk"},

{"SNOMED-CT", "http://snomed.info/sct"},

{"ATC", "http://www.whocc.no/atc"},

{"NPU", "urn:oid:1.2.752.108.1"},

Reporter

Thomas Beale

Raised By

Heath Frankel
Ian McNicoll

Components

Affects versions

Configure