Hi Diego, maybe, but only of the post-coordination is used locally. But I guess may introduce scalability problems for large developments...In my view the terminology should be governed separately...
2017-01-24 14:20 GMT+01:00 Diego Boscá <yamp...@gmail.com>: > 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-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
