On 25-01-18 17:34, Thomas Beale wrote:
On 25/01/2018 16:28, Bert Verhees wrote:
On 25-01-18 11:03, Sebastian Garde wrote:
Hi Silje,
I think this may ‘just’ be a modelling tooling issue, openEHR itself
supports this ok.
Speaking for CKM, if you upload an archetype with this to CKM, it
should validate the UCUM unit correctly for [arb'U]{whatever}.
However, [arb‘*u*]{whatever} or similar is (very slightly) incorrect
in my understanding:
1. Use the completely vertical ' not ‘ or similar (at least that is
my understanding).
2. openEHR uses (implicitly I think, but it may be hidden somewhere
in the spec), the case-sensitive version of UCUM – therefore the
U needs to be upper case, see e.g.
http://unitsofmeasure.org/ucum.html#para-45
As far as I know, Sebastian, OpenEhr does not use UCUM
it certainly specifies it
<https://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_dv_quantity_class>.
If there are tools and implementations that don't respect this, they
are non-compliant and will get found out ;)
The unit strings in the terminology are to help archetype tooling, but
I would say that all tools and systems in the future should be using a
'UCUM service' that does not yet exist, but knows about all unit
strings, properties and so on. This is something we could easily
specify and implement, if there is not already one in existence.
I wrote a UCUM-service for Golang in a two weeks, and had some debugging
afterwards, I needed it for a project. But I was lucky, the hard
thinking had already been done by some FHIR developers. I had the URL's
in my reply to this subject this morning.
A UCUM-service is quite simple, it has a simple API. You can extract it
from this testfile which you find here:
https://github.com/BertVerhees/ucum/blob/master/convey/ucum/UcumEssenceService_test.go
Bert
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
