Maybe I'm being a little little nitpicking with this, but probably in templates (which are archetypes at the end) it makes more sense to have them
2017-01-24 13:43 GMT+01:00 Luis Marco <luisma...@gmail.com>: > Hi Bert, I did not say that we should avoid using post-coordination. I > only said that the archetype is not the appropriate place to insert them > and they should be published as an available resource widely accessible to > its users (openEHR or not). Setting them in the archetype, in my view, > establishes a mix of models (information and meaning, in the words of > Rector) that should be separated for maintenance and reasoning purposes > [1,2]. > > > > “if you say that post-coordination would not be something to save in an > archetype, then you say in fact the same about SNOMED concepts.” > > > > Yes and noJ please realize that setting a URL pointing to the SNOMED-CT > concept is, in fact, the same thing as setting the concept id. However, it > also allows placing the concept in an “appropriate” host (e.g. triple store > or reasoned capable to process it or the LOD cloud). Therefore it acts as a > common knowledge base for anyone sharing the repository pointed by the > URL. This are just principles of Linked Data. In fact, once a > post-coordinate expression is processed by the reasoned it will become > another concept appropriately classified in the terminology hierarchy. > > > > “Saying that post-coordinated expressions are slow ( aircraft carrier/ > speedboats analogy) is not a valid argument for terminology bindings in > an archetype, because they do not only serve to be processed for > subsumptions (which is possible, and will be faster processable when time > evolves, and clinical data will remain valuable for 50 years or more)” > > > > Using SNOMED-CT expressivity power, in fact, requires placing the concepts > in an external reasoned. Another argument in favor of the URL approachJ > As you say “slow” depends on the reasoned, this is well explained in [3]. > > > > > > [1] Rector AL. The Interface between Information, Terminology, and > Inference Models. vol. 84, London, UK: IOS press; 2001, p. 246–50. > doi:10.3233/978-1-60750-928-8-246. > > [2] Rector AL, Qamar R, Marley T. Binding ontologies and coding > systems to electronic health records and messages. Applied Ontology > 2009;4:51–69. doi:10.3233/AO-2009-0063. > > [3] Karlsson D, Nyström M, Cornet R. Does SNOMED CT > post-coordination scale? Stud Health Technol Inform 2014;205:1048–52. > > > > 2017-01-24 13:17 GMT+01:00 Bert Verhees <bert.verh...@rosa.nl>: > >> Hi Luis and others, >> >> I think we need post-coordinated expression binding. The purpose is to >> say in a future proof interoperable way what is meant with a term. Post >> coordination is used just a replacement for SNOMED concepts (which do >> sometimes not exist for some terms), if you say that post-coordination >> would not be something to save in an archetype, then you say in fact the >> same about SNOMED concepts. >> >> Sorry when this sounds offensive, I don' t mean it that way. I just try >> to get the thinking about this sharp. >> >> Saying that post-coordinated expressions are slow ( aircraft carrier/ >> speedboats analogy) is not a valid argument for terminology bindings in >> an archetype, because they do not only serve to be processed for >> subsumptions (which is possible, and will be faster processable when time >> evolves, and clinical data will remain valuable for 50 years or more), they >> can serve very well to be sure what is meant with a certain term. It is a >> challenge for the terminology-service designers not for the archetype >> designers. >> >> A tip, terminology service designers can cache often occurring post >> coordinated expressions. >> >> Bert >> >> Op di 24 jan. 2017 om 12:56 schreef Luis Marco <luisma...@gmail.com>: >> >>> Hi Bert, I posted a similar question last year. I paste it below. >>> After some developments in the topic [1] my view is that archetypes are >>> not the place for hosting post-coordinated expressions. Rather they should >>> point with a URL to a server in the cloud that hosts them (following Linked >>> Data principles). I recall that recently there was a ticket in openEHR >>> openedhr for including URLs in archetypes...but I cannot find it. Let me >>> know if you want to discuss this... >>> >>> [1] Marco-Ruiz L, Pedrinaci C, Maldonado JA, Panziera L, Chen R, >>> Bellika JG. Publication, discovery and interoperability of Clinical >>> Decision Support Systems: A Linked Data approach. Journal of Biomedical >>> Informatics 2016;62:243–64. doi:10.1016/j.jbi.2016.07.011. >>> ---- >>> >>> Hi, >>> >>> I am trying to annotate a set of archetypes with SNOMED-CT. I have >>> noticed that in the archetype editor, when I introduce a postcoordinated >>> expressions, the editor deletes the bars and creates a continuous >>> alphanumeric string. Do you know if postcoordinated expressions can be set >>> in the ontology section of the archetype? What are current approaches to >>> overcome this? >>> >>> A solution could be to insert an id representing the postcoordinated >>> expression and resolve it in my terminology server. However, this would >>> hide knowledge to other implementations based on that archetype outside the >>> domain of my server. >>> >>> >>> >>> Example: Let’s assume (without caring about the correctness of it) that >>> we had an archetype for the concept “Laparoscopic appendectomy” and we >>> annotate at000 with (80146002*|*Appendectomy*|*:424226004|Using device >>> *|*=86174004*|*Laparoscope*|*). >>> >>> The result in the ADL is: ["at0000"] = <[SNOMED-CT::80146002Appendect >>> omy424226004Usingdevice86174004Laparoscope]> >>> >>> >>> Thanks, >>> >>> Luis >>> Diego Boscá <yamp...@gmail.com> >>> 28/4/15 >>> para For, openeh >>> inglés >>> español >>> >>> Traducir mensaje >>> Desactivar para: inglés >>> Hello Luis, >>> >>> I think having available a terminology service is some kind of a >>> prerequisite (which I don't agree with). I think openEHR should >>> probably assume the IHTSDO postcoordination syntax for these cases. It >>> would be interesting to know if someone has used or is planning to use >>> this syntax for other terminologies. >>> >>> > _______________________________________________ >>> > openEHR-implementers mailing list >>> > openEHR-implementers@lists.openehr.org >>> > http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists. >>> openehr.org >>> >>> _______________________________________________ >>> openEHR-implementers mailing list >>> openEHR-implementers@lists.openehr.org >>> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists. >>> openehr.org >>> Thomas Beale <thomas.be...@oceaninformatics.com> >>> 28/4/15 >>> para openehr-implem. >>> inglés >>> español >>> >>> Traducir mensaje >>> Desactivar para: inglés >>> The original design of ADL in this area (influenced by my 4y on IHTSDO >>> standing committees, of which 2 on the Technical committee) was that: >>> >>> - we should not embed subset definitions inside archetypes, because >>> they might be >>> - wrong >>> - replicating the same thing in another archetype >>> - need to be developed and maintained by a terminology specialist >>> - in any case, we couldn't assume any particular syntax for >>> subset definitions; the current IHTSDO syntax applies only to SNOMED-CT. >>> >>> I happen to like the IHTSDO syntax, but I think unless people here can >>> convince themselves that all of the above is not true, it shouldn't go >>> directly in archetypes. However... terminology technology and use has >>> advanced far more slowly than many of us expected, and availability / >>> uptake of usable tools from IHTSDO has been a particularly limiting factor >>> (e.g. the IHTSDO Workbench is like an aircraft carrier, but what were >>> needed were speedboats). >>> >>> In ADL 2, with help from Harold Solbrig@ Mayo (who has worked >>> intensively on terminology over the years, and is at IHTSDO in CPH as I >>> write), we have changed the method of referencing terminology concepts to >>> URIs. These 'concepts' can be real concepts, or value-sets, whose >>> definition is somewhere in terminology land. >>> >>> Just to be clear, I don't have a personal issue with going one way or >>> the other on this, but I think people need to understand the issues - above >>> are some. There may be more of which I am not aware. >>> >>> A challenge is that establishing new value set definitions in IHTSDO's >>> model implies having a SNOMED CT extension. Now, maybe what we should do as >>> openEHR is to do that - apply for an extension and start using it. Who >>> would be interested in doing this? >>> >>> - thomas >>> >>> 2017-01-24 12:45 GMT+01:00 Bert Verhees <bert.verh...@rosa.nl>: >>> >>> Hi, >>> >>> Last week, I mentioned on this list that the Ocean archetype-editor does >>> not allow post-coordinated SNOMED expressions in terminology-bindings. I >>> also made some JIRA calls for this, also for an abnormality which was >>> related to this. >>> >>> I also found out that the LinkEHR archetype-editor has the same problem. >>> >>> So that made me suspicious, and I looked at the ADL 1.4 specifications, >>> and there it was, it is not allowed in ADL 1.4 tot use post-coordinated >>> SNOMED expressions in terminology-bindings. >>> >>> I think a repair is necessary, so I made also a JIRA call for this. But >>> I did not get any reaction at all. I think however, it is an urgent >>> problem, and it is not hard to repair. It is just a matter of allowing some >>> extra characters in the terminology-binding, and to do it right, changing >>> the spec a bit. >>> >>> Make it ADL 1.4.x (I saw there is a ADL 1.4.2) >>> >>> It is urgent because ADL 2.x won' t be active on the market very soon. >>> Most knowledge with modelers and tooling will be on ADL 1.4 for some more >>> time. >>> It is urgent because the Netherlands is very pro-SNOMED and many other >>> countries are also, and post-coordination is the way to create bindings for >>> items for which is no concept, and it is a future proof binding, because, >>> even, when the will come a concept for that expression, that expression >>> will remain valid. >>> >>> We really need it. >>> >>> Best regards >>> Bert Verhees >>> >>> >>> _______________________________________________ >>> openEHR-implementers mailing list >>> openEHR-implementers@lists.openehr.org >>> http://lists.openehr.org/mailman/listinfo/openehr-implemente >>> rs_lists.openehr.org >>> >>> _______________________________________________ >>> openEHR-implementers mailing list >>> openEHR-implementers@lists.openehr.org >>> http://lists.openehr.org/mailman/listinfo/openehr-implemente >>> rs_lists.openehr.org >> >> >> _______________________________________________ >> openEHR-implementers mailing list >> openEHR-implementers@lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr-implemente >> rs_lists.openehr.org >> > > > _______________________________________________ > openEHR-implementers mailing list > openEHR-implementers@lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr- > implementers_lists.openehr.org >
_______________________________________________ openEHR-implementers mailing list openEHR-implementers@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
