Semantic Interoperability is possible only when each. distinct domain: has its own model has its own rules and always orthogonal to other models.
A terminology can be equated to a Dictionary. A terminology is never an Encyclopedia of everything. We need a terminology of concepts related to the Patient System. And we need a terminology for things not related, such as Units of Measurement. There will be more terminologies we need: basic archetype patterns for documentation, time-related concepts, medical devices, continuity of care, business modelling, etc. So I agree with Thomas. SNOMED must have bounderies. I fear that the SNOMED world is without a well defined scope. Gerard Freriks +31 620347088 gf...@luna.nl Kattensingel 20 2801 CA Gouda the Netherlands > On 26 Jan 2018, at 10:00, Thomas Beale <thomas.be...@openehr.org> wrote: > > 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 > 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
