Re: Quantities of arbitrary units in openEHR
It would be good if OpenEhr RM would support the UCUM-properties fully
in the DvQuantity, then all problems regarding units would be over for
the next 20 years, and no maintenance on customer or OpenEHR-foundation
side is needed. UCUM is, I think, widely regarded as the most important
unit-registration system.
I haven't thought about which changes are needed to do this, sorry for
that, but I am sure the community is very well able to handle this.
By the way, if someone needs a UCUM-library for Golang, I have written
one in open source, find it here:
https://github.com/BertVerhees/ucum
Grahame Grieve and some FHIRT enthousiasts have written one for Java:
https://github.com/FHIR/Ucum-java
Best regards
Bert
On 24-01-18 10:52, Bakke, Silje Ljosland wrote:
Hi all,
I’m working on representing medication strengths in archetypes at the
moment. Most medications are thankfully measured in SI units such as
mg/ml or mg/{dose unit}, but others use arbitrary units that are not
derived from any other physical dimensional units. Examples of these
are standardized quality units (SQ-U), focus forming units (FFU),
European and American pharmacopoeia units, anti factor Xa units, or
international units (IU). There are seemingly an unlimited number of
these units, and they apparently make up new ones as they go along
(ref: SQ-T and SQ-HDM). See
http://unitsofmeasure.org/ucum.html#para-45 for more.
UCUM has a generic way of representing these, as “[arb’u]{whatever}”
(arbitrary unit, name of the unit), but openEHR doesn’t seem to have a
property in its Quantity data type for them. Could it be a possibility
to add an “Arbitrary” property to the openEHR support terminology for
unit properties?
Also, is it ok to model Quantity elements with a property set but the
units left unconstrained? I’ve just started trying to add these units
to an archetype (as a concentration, so got around the property
issue), and it’s just a never ending task.
Kind regards,
*Silje Ljosland Bakke*
**
Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no
___
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
Re: Quantities of arbitrary units in openEHR
Hi Silje,
I don't understand how adding an 'Arbitrary' term to the openEHR
terminology helps things. DV_QUANTITY.units is a UCUM String field.
Won't the strange units just turn up in the String form you quoted for
UCUM arbitrary units in that field?
(BTW, to ask for a new terminology term, just create a new issue on the
PR tracker with component=New Term Request - choose this from the dropdown).
Setting property and not units makes sense - and if we had a proper,
standardised units service, a runtime archetype evaluator would use it
to limit the actual units for property = pressure (say) to only pressure
units. I think we need to define such a service properly
- thomas
On 24/01/2018 09:52, Bakke, Silje Ljosland wrote:
Hi all,
I’m working on representing medication strengths in archetypes at the
moment. Most medications are thankfully measured in SI units such as
mg/ml or mg/{dose unit}, but others use arbitrary units that are not
derived from any other physical dimensional units. Examples of these
are standardized quality units (SQ-U), focus forming units (FFU),
European and American pharmacopoeia units, anti factor Xa units, or
international units (IU). There are seemingly an unlimited number of
these units, and they apparently make up new ones as they go along
(ref: SQ-T and SQ-HDM). See
http://unitsofmeasure.org/ucum.html#para-45 for more.
UCUM has a generic way of representing these, as “[arb’u]{whatever}”
(arbitrary unit, name of the unit), but openEHR doesn’t seem to have a
property in its Quantity data type for them. Could it be a possibility
to add an “Arbitrary” property to the openEHR support terminology for
unit properties?
Also, is it ok to model Quantity elements with a property set but the
units left unconstrained? I’ve just started trying to add these units
to an archetype (as a concentration, so got around the property
issue), and it’s just a never ending task.
Kind regards,
*Silje Ljosland Bakke*
**
Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
Thomas Beale
Principal, Ars Semantica
Consultant, ABD Team, Intermountain Healthcare
Chartered IT Professional Fellow, BCS, British Computer Society
Health IT blog
AW: Quantities of arbitrary units in openEHR
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
Regards
Sebastian
Von: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] Im
Auftrag von Thomas Beale
Gesendet: Donnerstag, 25. Januar 2018 10:25
An: openehr-technical@lists.openehr.org
Betreff: Re: Quantities of arbitrary units in openEHR
Hi Silje,
I don't understand how adding an 'Arbitrary' term to the openEHR terminology
helps things. DV_QUANTITY.units is a UCUM String field. Won't the strange units
just turn up in the String form you quoted for UCUM arbitrary units in that
field?
(BTW, to ask for a new terminology term, just create a new issue on the PR
tracker with component=New Term Request - choose this from the dropdown).
Setting property and not units makes sense - and if we had a proper,
standardised units service, a runtime archetype evaluator would use it to limit
the actual units for property = pressure (say) to only pressure units. I think
we need to define such a service properly
- thomas
On 24/01/2018 09:52, Bakke, Silje Ljosland wrote:
Hi all,
I'm working on representing medication strengths in archetypes at the moment.
Most medications are thankfully measured in SI units such as mg/ml or mg/{dose
unit}, but others use arbitrary units that are not derived from any other
physical dimensional units. Examples of these are standardized quality units
(SQ-U), focus forming units (FFU), European and American pharmacopoeia units,
anti factor Xa units, or international units (IU). There are seemingly an
unlimited number of these units, and they apparently make up new ones as they
go along (ref: SQ-T and SQ-HDM). See
http://unitsofmeasure.org/ucum.html#para-45 for more.
UCUM has a generic way of representing these, as "[arb'u]{whatever}" (arbitrary
unit, name of the unit), but openEHR doesn't seem to have a property in its
Quantity data type for them. Could it be a possibility to add an "Arbitrary"
property to the openEHR support terminology for unit properties?
Also, is it ok to model Quantity elements with a property set but the units
left unconstrained? I've just started trying to add these units to an archetype
(as a concentration, so got around the property issue), and it's just a never
ending task.
Kind regards,
Silje Ljosland Bakke
Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
Thomas Beale
Principal, Ars Semantica
Consultant, ABD Team, Intermountain
Healthcare
Chartered IT Professional Fellow, BCS, British Computer
Society
Health IT blog
Re: AW: Quantities of arbitrary units in openEHR
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 but it uses many
unit-strings which also are defined in UCUM, but has these strings for
OpenEhr-use listed in an own terminology-list. This list needs to be
maintained separately by the OpenEHR community. There is no validation
defined directly to the UCUM-services. 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.
There could be some RM redesign, as Thomas also hinted (on this subject
today) by using the UCUM-ordering of unit-strings to properties like
"pressure", "energy", etc and define DvQuantity so that archetypes could
constrain these properties instead of constraining the stringified units.
Best regards
Bert Verhees
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: AW: Quantities of arbitrary units in openEHR
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
.
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.
but it uses many unit-strings which also are defined in UCUM, but has
these strings for OpenEhr-use listed in an own terminology-list. This
list needs to be maintained separately by the OpenEHR community. There
is no validation defined directly to the UCUM-services. 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.
right, that's the sort of thing we need. I have not researched this for
a few years, so if anyone knows of a service and/or service definition /
API we can use and standardise on, please post some information.
- thomas
--
Thomas Beale
Principal, Ars Semantica
Consultant, ABD Team, Intermountain Healthcare
Chartered IT Professional Fellow, BCS, British Computer Society
Health IT blog
Re: AW: Quantities of arbitrary units in openEHR
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
.
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
Re: AW: Quantities of arbitrary units in openEHR
On 25-01-18 17:48, Bert Verhees wrote: 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 I must add a few small remarks, this github-repository is not a service (as I on one place indicated), but it is a library, so that is why the API is not visible in a simple way, and that is why I point to this testfile to learn about the API. The API, as said, is simple, it consist in about 10 or 15 API-calls. Refactoring the library to a service is (in Golang) also very simple, just put one file before it with service-calls ( in REST-calls, or if used as microservice maybe gRPC calls are possible (which are much faster)) and then use the library to feed the service. https://www.slideshare.net/borisovalex/grpc-vs-rest-let-the-battle-begin-81800634 ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
RE: Quantities of arbitrary units in openEHR
Hi all, thanks for your replies!
I'm sure the CKM would accept the unit string, but which property would the
Quantity have? Eg property = <[openehr::124]> for weight or property =
<[openehr::127]> for temperature? I don't think we have one of those codes for
"Arbitrary"?
I'm sure you're correct about the syntax, btw. :)
Regards,
Silje
Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På
vegne av Sebastian Garde
Sendt: torsdag 25. januar 2018 11:03
Til: For openEHR technical discussions
Emne: AW: Quantities of arbitrary units in openEHR
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
Regards
Sebastian
Von: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] Im
Auftrag von Thomas Beale
Gesendet: Donnerstag, 25. Januar 2018 10:25
An:
openehr-technical@lists.openehr.org
Betreff: Re: Quantities of arbitrary units in openEHR
Hi Silje,
I don't understand how adding an 'Arbitrary' term to the openEHR terminology
helps things. DV_QUANTITY.units is a UCUM String field. Won't the strange units
just turn up in the String form you quoted for UCUM arbitrary units in that
field?
(BTW, to ask for a new terminology term, just create a new issue on the PR
tracker with component=New Term Request - choose this from the dropdown).
Setting property and not units makes sense - and if we had a proper,
standardised units service, a runtime archetype evaluator would use it to limit
the actual units for property = pressure (say) to only pressure units. I think
we need to define such a service properly
- thomas
On 24/01/2018 09:52, Bakke, Silje Ljosland wrote:
Hi all,
I'm working on representing medication strengths in archetypes at the moment.
Most medications are thankfully measured in SI units such as mg/ml or mg/{dose
unit}, but others use arbitrary units that are not derived from any other
physical dimensional units. Examples of these are standardized quality units
(SQ-U), focus forming units (FFU), European and American pharmacopoeia units,
anti factor Xa units, or international units (IU). There are seemingly an
unlimited number of these units, and they apparently make up new ones as they
go along (ref: SQ-T and SQ-HDM). See
http://unitsofmeasure.org/ucum.html#para-45 for more.
UCUM has a generic way of representing these, as "[arb'u]{whatever}" (arbitrary
unit, name of the unit), but openEHR doesn't seem to have a property in its
Quantity data type for them. Could it be a possibility to add an "Arbitrary"
property to the openEHR support terminology for unit properties?
Also, is it ok to model Quantity elements with a property set but the units
left unconstrained? I've just started trying to add these units to an archetype
(as a concentration, so got around the property issue), and it's just a never
ending task.
Kind regards,
Silje Ljosland Bakke
Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
Thomas Beale
Principal, Ars Semantica
Consultant, ABD Team, Intermountain
Healthcare
Chartered IT Professional Fellow, BCS, British Computer
Society
Health IT blog
Re: Quantities of arbitrary units in openEHR
A bit unrelated perhaps, but in the 1.0.3 and 1.0.4 RM specification, there is
no property attribute or function present in dv_quantity, even though the text
says it can be conveniently constrained. There is a reference to the spec-95
jira issue, which says it has been removed. So there’s no way to constrain it -
unless the specification contains a mistake :)
It is present in the BMM variants of the RM though, as a mandatory field.
Regards,
Pieter Bos
Op 26 jan. 2018 om 08:19 heeft Bakke, Silje Ljosland
mailto:silje.ljosland.ba...@nasjonalikt.no>>
het volgende geschreven:
Hi all, thanks for your replies!
I’m sure the CKM would accept the unit string, but which property would the
Quantity have? Eg property = <[openehr::124]> for weight or property =
<[openehr::127]> for temperature? I don’t think we have one of those codes for
“Arbitrary”?
I’m sure you’re correct about the syntax, btw. ☺
Regards,
Silje
Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På
vegne av Sebastian Garde
Sendt: torsdag 25. januar 2018 11:03
Til: For openEHR technical discussions
mailto:openehr-technical@lists.openehr.org>>
Emne: AW: Quantities of arbitrary units in openEHR
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
Regards
Sebastian
Von: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] Im
Auftrag von Thomas Beale
Gesendet: Donnerstag, 25. Januar 2018 10:25
An:
openehr-technical@lists.openehr.org
Betreff: Re: Quantities of arbitrary units in openEHR
Hi Silje,
I don't understand how adding an 'Arbitrary' term to the openEHR terminology
helps things. DV_QUANTITY.units is a UCUM String field. Won't the strange units
just turn up in the String form you quoted for UCUM arbitrary units in that
field?
(BTW, to ask for a new terminology term, just create a new issue on the PR
tracker with component=New Term Request - choose this from the dropdown).
Setting property and not units makes sense - and if we had a proper,
standardised units service, a runtime archetype evaluator would use it to limit
the actual units for property = pressure (say) to only pressure units. I think
we need to define such a service properly
- thomas
On 24/01/2018 09:52, Bakke, Silje Ljosland wrote:
Hi all,
I’m working on representing medication strengths in archetypes at the moment.
Most medications are thankfully measured in SI units such as mg/ml or mg/{dose
unit}, but others use arbitrary units that are not derived from any other
physical dimensional units. Examples of these are standardized quality units
(SQ-U), focus forming units (FFU), European and American pharmacopoeia units,
anti factor Xa units, or international units (IU). There are seemingly an
unlimited number of these units, and they apparently make up new ones as they
go along (ref: SQ-T and SQ-HDM). See
http://unitsofmeasure.org/ucum.html#para-45 for more.
UCUM has a generic way of representing these, as “[arb’u]{whatever}” (arbitrary
unit, name of the unit), but openEHR doesn’t seem to have a property in its
Quantity data type for them. Could it be a possibility to add an “Arbitrary”
property to the openEHR support terminology for unit properties?
Also, is it ok to model Quantity elements with a property set but the units
left unconstrained? I’ve just started trying to add these units to an archetype
(as a concentration, so got around the property issue), and it’s just a never
ending task.
Kind regards,
Silje Ljosland Bakke
Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
Thomas Beale
Principal, Ars Semantica
Consultant, ABD Team, Intermountain
Healthcare
Chartered IT Professional Fellow, BCS, British Computer
Society
Health IT blog
AW: AW: Quantities of arbitrary units in openEHR
Von: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] Im
Auftrag von Thomas Beale
Gesendet: Donnerstag, 25. Januar 2018 17:34
An: openehr-technical@lists.openehr.org
Betreff: Re: AW: Quantities of arbitrary units in openEHR
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.
If there are tools and implementations that don't respect this, they are
non-compliant and will get found out ;)
[SG] The first reference
https://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_dv_quantity_class
is more an "inspiration": "Units were inspired by the Unified Code for Units
of Measure (UCUM), developed by Gunther
Schadow and Clement J. McDonald of The Regenstrief Institute."
The 2nd reference is clearer: "Stringified units, expressed in UCUM unit
syntax, e.g. "kg/m2", "mm[Hg]", "ms-1", "km/h"."
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?
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.
[SG] Agree - such a UCUM service may also be able to give a print version,
e.g. °C instead of CEL or °F instead of [degF]
Sebastian
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.
but it uses many unit-strings which also are defined in UCUM, but has these
strings for OpenEhr-use listed in an own terminology-list. This list needs to
be maintained separately by the OpenEHR community. There is no validation
defined directly to the UCUM-services. 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.
right, that's the sort of thing we need. I have not researched this for a few
years, so if anyone knows of a service and/or service definition / API we can
use and standardise on, please post some information.
- thomas
--
Thomas Beale
Principal, Ars Semantica
Consultant, ABD Team, Intermountain
Healthcare
Chartered IT Professional Fellow, BCS, British Computer
Society
Health IT blog
