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 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? Best regards, Erik Sundvall Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or 010-1036252 in Sweden) Region ?sterg?tland: erik.sundvall at regionostergotland.se (previously lio.se) http://www.regionostergotland.se/cmit/ Link?ping University: erik.sundvall at liu.se, http://www.imt.liu.se/~erisu/ On Thu, Apr 2, 2015 at 1:51 PM, Thomas Beale < thomas.beale at oceaninformatics.com> wrote: > > Hi Daniel, > > On 31/03/2015 08:54, Daniel Karlsson wrote: > > Then, within those boundaries terminologies can be used, through term > binding [ADL2, 8.11.4], to add external references to the meaning of > archetype nodes. *If the meaning of the archetype node is not clear, > neither will any term binding be.* > > > this is an important point. I suspect that the meaning of archetype nodes > (as defined by the internal coded terms) is 'pretty clear' in the sense > that it assumes the encapsulation that the archetype provides. For example, > the Apgar archetype has the following: > > ["at0009"] = < > text = <"Respiratory effort"> > description = <"Observation of the infant's > respiratory effort."> > > > > Here the meaning of 'respiratory effort' (id10 in the ADL2 converted form) > is clear within the encapsulating context of 'Apgar score', but wouldn't be > on its own. One of the major differences between codes in archetypes is > that they are (as far as I know) always defined on this relative basis, > whereas SNOMED codes have to be defined on a fully qualified basis. > > I don't claim that this makes archetype node meanings 100% clear, but it > must go close in many cases, since one test is being able to classify real > world data elements as matching (or not) the various elements, and I would > suggest that by this extensional method, the 'definition' of nearly every > archetype node is indeed accurate. > > Term binding is not only useful when > comparing data to other IM frameworks, e.g. Act.code is often used > corresponding to an ELEMENT term binding, but also to maintain a larger > set of archetypes by allowing e.g. terminology-based queries. > > In the example presented, there are at least three alternatives for term > binding OBSERVATION archetypes to SNOMED CT: a procedure, a finding, and > an observable entity. We would just have to agree on a set of patterns > for how (and if) to bind to ENTRY-ies, ELEMENTs etc. based on our > understanding of the meaning of the archetype nodes. A very tentative > such pattern for OBSERVATIONs could be: > OBSERVATION --> term-bind to <<386053000 | evaluation procedure > (procedure) | > ELEMENT --> term-bind to <<363787002 | observable entity (observable > entity) | > > > > I'm not sure if we should be doing this (maybe we should...), but the > suggestion for OBSERVATION could be right, if 'evaluation' means something > like 'measuring' or 'observing'. If it means something like 'assessing' or > 'diagnosing' then I would say not (but I assume the former, if it is a > 'procedure'). > > ELEMENT is used ubiquitously in openEHR (and 13606) models and would only > correspond to an 'observable entity' in some. For example, it wouldn't > where it turns up in demographic structures like addresses etc, nor inside > Instructions where it represents elements of orders, drugs etc. > > - thomas > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150402/7c7c2dd3/attachment-0001.html>
