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.
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
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.
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.
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.
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?