On 26-01-18 14:27, Thomas Beale wrote:
yes I agree with this. We should do something about it.
I am glad you think so too. Thanks to Silje for bringing it u initially.
I think, there is already much possible with only few changes, the ideas
expressed by Diego help a lot.
On the archetype side we need to define the UCUM-property for
constraint, and units mandatory.
On the dataset-side only the value and the unit name is necessary.
The dataset-validating software must then check against the
UCUM-definitions if the used unit and value can be used in the context
of the property.
This would be a great improvement because worldwide, every DvQuantity
value could be calculated to its appropriate value.
Fahrenheit and miles for some countries, and Celcius and Kilometer for
some other countries, and of course many other local used units.
The best way to achieve it, in my opinion, (but I am sure I don't see
the whole picture), would be to make units in DvQuantity of type STRING
*OR* by term-binding.
We already know alternative datatypes, which are sometimes used in
ELEMENT/value. So the use would then be to have to alternative values
for the ELEMENT, one for the string-type DvQuantity, one for the coded
type, so there would never be a problem with interpreting.
In this way it would remain backwards compatible and also allow to
support units to be checked against a (any) terminology.
It is also that, besides UCUM, SNOMED also defines units, and there can
be data, maybe from legacy systems, which use SNOMED-terms for a unit
(maybe there are also translated units, if so, SNOMED takes care for
that, and I also found on google there is a mapping between SNOMED and
UCUM coming up or already finished).
And the only thing needed to change in the RM would be an addition for
the DvQuantity-unit-type, without losing backwards compatibility.
I wouldn't have come tot his idea without the discussion this morning,
and I am sure there is more to it then I see.
But this kind of solution, I think is the best I can think of.
Bert
- thomas
On 26/01/2018 13:23, Bert Verhees wrote:
On 26-01-18 08:53, Sebastian Garde wrote:
This is where I think that not only it is stated that openEHR uses
UCUM (and not some part or “inspiration” of it), but also implies
that the case sensitive version of it is used (which in my view is
important to know at least for some of the units). I still think it
would be good to explicitly say that the case-sensitive version is used?
Just for the record, my point I wanted to make was that OpenEhr does
not define use of the facilities of UCUM (like properties and
conversions), as we see now in the discussion, which I think is very
useful and making use of UCUM facilities possible.
Quoting myself from a reply this morning:
> If it would, not only use the stringified units of UCUM, but also
would incorporate UCUM-defined functionality, it would also have, for
example, conversion routines from UCUM, which are usable for software
defined in the UCUM essence-file."
--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Team, Intermountain Healthcare
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation
<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer Society
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> | Culture blog
<http://wolandsothercat.net/>
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
