my pleasure, I envision endless exiting conversations ahead;-) 2017-01-24 13:46 GMT+01:00 Bert Verhees <bert.verh...@rosa.nl>:
> Thanks, Luis, The following answer needs some reading in advance, I will > reply later to this. > > Bert > > Op di 24 jan. 2017 om 13:44 schreef 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:: >> 80146002Appendectomy424226004Usingdevice86174004Laparoscope]> >> >> >> 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- >> implementers_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 >> >> >> _______________________________________________ >> 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 >
_______________________________________________ openEHR-implementers mailing list openEHR-implementers@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
