The thing I am not a fan of is that units themselves become part of
terminology. This is a SNOMED direction but I think a wrong one. The
reason is that the ontology of units isn't the same as the ontology of
findings, medications and so on. In fact they all have different
ontologies, and trying to jam them all into SNOMED CT under a single
meta- model is problematic at best.
But units are so clearly different that they deserve their own service -
for a start, UCUM unit strings are post-coorindatable according to the
UCUM grammar, and then you have the classification of units under
properties, synthetic properties under basic properties, strange stuff
currently called 'arbitrary' (which is still real, and must have a place
inside the ontology); units conversion rules and algorithms and so on.
So while a mass unit code like 'kg' might not see much different for a
code for pneumonia, even this simple example is already a
pre-coordination of 'k' and 'g' according to a units ontology, something
that clearly doesn't apply to 'pneumonia', at least not in the same way
(i.e. 'viral pneumonia' is a particular that is described by a disease
ontology).
Thinking a bit more about 'arbitrary', I think I agree with Diego - to
sort it out properly needs a proper ontology.
- thomas
On 26/01/2018 08:41, Diego Boscá wrote:
I think there are several potential problems with this, and IMHO we
are stepping too much on what should be done in a terminology service
(We are literally talking about a 'public available UCUM service').
You can also ask the terminology service what kind of unit code you
have. Your implementation could answer "arbitrary" for these new units.
In my opinion, saying "here comes a mass unit code" is not much
different from "here comes a diagnosis code", and we say these in a
completely different way (a better way, if you ask me).
Also, I'm not a big fan of "arbitrary" property, as feels like a
"other" kind of terminology code that is potentially dangerous as
knowledge or terminology advances, thus coexisting 'arbitrary' and
'new shiny type of measurements' all mixed up. That's why I also
expect these properties to be as derived from the codes and not the
other way around.
--
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
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
