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- > implementers_lists.openehr.org >
_______________________________________________ openEHR-implementers mailing list openEHR-implementers@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org