Hi, we had quite a few papers recently about ontological aspects of clinical information models. I'd be quite interested to hear from these authors - it'd be a great contribution. I really think we need to merry Semantic Web / Linked Open Data and openEHR approaches.
Cheers, -koray From: openEHR-clinical [mailto:[email protected]] On Behalf Of Thomas Beale Sent: Friday, 3 April 2015 2:30 a.m. To: openehr-clinical at lists.openehr.org Subject: Re: one-to-many term bindings in archetypes oops - he did - but I missed in the formatting that he was being properly precise (and I can't even claim ignorance, I know the syntax well, I've been one of the reviewers of the drafts over the years). So this puts a different cast on the question. One of the things I believe we most urgently need to do in the ontology / terminology area is to actually establish an ontology whose concepts correspond to each archetype as a whole, and whose english-language mnemonic names are understood to be the short names we use in the archetype identifiers (i.e. things like 'apgar_score'). As mentioned in the Knowledge Artefact Identification <http://www.openehr.org/releases/trunk/architecture/am/knowledge_id_system.pdf> document, this ontology could potentially be situated under a new version of IAO<http://www.ontobee.org/browser/rdf.php?o=IAO&iri=http://purl.obolibrary.org/obo/IAO_0000027>. Note that all archetypes in openEHR (and I would argue in health) are information objects _about_ some X, where X is some ontological entity. I.e. the general epistemic X IS-ABOUT ontological X relation. In this sense, 'blood_pressure' doesn't mean blood pressure in the real world, it means 'result of observation of blood pressure'. Things like Apgar are tricky because they are a first order information item, even in the real world. So the Apgar_result archetype isn't really 'about' Apgar result in the same sense. It's 'about' the health status of a newborn. I'm not sure what the ontologist's view of this is... - thomas On 02/04/2015 14:05, Erik Sundvall wrote: Hi! I think Daniel used the << operator in the example without explaining it. Page 16 in the document that Mikael recommended says: "<< A" Either the compositional grammar expression A or an expression that is a valid subtype of it SHALL be used. Now read Daniel's message again. I do not think he by... OBSERVATION --> term-bind to <<386053000 | evaluation procedure (procedure) | ...means that we should bind the general OBSERVATION class to "evaluation procedure", but rather that specific observation-archetypes' root nodes often could be bound to specific children/descendants of "evaluation procedure". In the same way regarding... ELEMENT --> term-bind to <<363787002 | observable entity (observable entity) | I interpret this suggestion as: When looking for suitable bindings to ELEMENTS within OBSERVATIONs it might be wise to primarily look among children/descendants of "observable entity". Am I guessing right? I also guess this should be recommendations rather than strict rules. Daniel, where do such discussions within CIMI occur? Is there any publicly readable discussion or document? A set of such recommendations would be useful during the current archetype sprint and creation of new archetypes, and I believe that IHTSDO does not mind answering specific questions during creation of such a set of recommendations or questions occurring when applying them. In a related off-list discussion in October 2014, Linda Bird at IHTSDO said: "It's great to hear that the openEHR community is looking to perform SNOMED CT terminology bindings to a library of archetypes. While we would be happy to offer advice, the IHTSDO does not have the resources to perform or fund this work. The CIMI models (as mentioned by Tom) however can be used as an example of a possible SNOMED CT binding approach." ...and... "You can send queries to info at ihtsdo.org<mailto:info at ihtsdo.org> and they will be redirected to the appropriate person. Terminology binding questions, however, are likely to be redirected to me." So after looking at what CIMI is doing in this area we should probably start drafting a recommendation document. Perhaps it could be a joint effort with CIMI? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150403/6098723c/attachment-0001.html>
