I hope not, my interests are not of academical nature. But I am working on current practical real world problems.
Op di 24 jan. 2017 14:28 schreef Luis Marco <luisma...@gmail.com>: > 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::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
_______________________________________________ openEHR-implementers mailing list openEHR-implementers@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
