On 27-01-18 11:16, Thomas Beale wrote:
Bert,
I don't disagree philosophically, but practically speaking, no SNOMED
service is going to be able to answer requests to do with unit
properties, unit conversions, or different forms of rendering, which
are all things we need to take care of properly.
I actually think units is one of the things we should just do
properly, and in only one way for openEHR. I can't imagine why anyone
would use SNOMED for units instead of a proper units service that
supported the above, even if they use SNOMED for everything else.
There is of course nothing preventing anyone adding bindings from
SNOMED to the units paths in archetypes.
I personally think that UCUM does a outstanding good job. One thing that
is missing is translations, this is important in countries which have
another script, like Arabs or Chinese or many many other. The majority
of the world population does not use the Latin alphabet.
And this is where SNOMED comes in, it is getting translated by the
people who use it. And I found somewhere on the internet a mapping from
UCUM to SNOMED, and when I looked again, I coudn't find it anymore.
SNOMED has infrastructure to take care of translations (done by the
national standard bodies). That is one of its important strengths. HL7
is quite America bounded, and UCUM is (as far as I know) a typical HL7
product, from this point of view.
Please correct me if I am wrong.
Most people of the world cannot read/write English and they also need to
use medical software/devices, and it is a good thing that translations
are delivered by an authority like a national standard body, instead of
vendors more or less educated
I think that is obvious that the mapping between SNOMED and UCUM will
come if it isn't there yet. So restricting the termbindings regarding
DvQuantity-property to UCUM may become a problem, although, promoting
the use is not wrong, like tooling promoted also the use of the OpenEhr
units-terminology
But it may be alright to define in the RM that the DvQuantity-property
is like the UCUM-property, but then without mentioning the word UCUM ;-)
And of course, that the unit-string must be restricted by the general
higher hierarchy of the property domain (like Mass, energy, etc)
Bert
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
