# post coordinated expressions **Category:** [Implementers (archive)](https://discourse.openehr.org/c/implementers-archive/158) **Created:** 2017-01-24 11:45 UTC **Views:** 2 **Replies:** 25 **URL:** https://discourse.openehr.org/t/post-coordinated-expressions/15466 --- ## Post #1 by @system 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 --- ## Post #2 by @yampeku Yes, as you say ADL1\.4 doesn't support this, so we opted to go the URI way --- ## Post #3 by @system 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. --- ## Post #4 by @system 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 --- ## Post #5 by @system Hi Diego, I wonder how you get SNOMEDpostcoordinated expressions to fit into the specs of ADL 1.4.x. I think an URL even has more illegal characters. Bert --- ## Post #6 by @yampeku In the specifications there are two different classes for binding: Term\_binding\_item and Query\_binding\_item\. When using the second one, you can point to arbitrary URIs\. Any character can be included in a URI, as long as it is encoded\. e\.g\. http://diebosto2.pc.upv.es:8888/SnomedQuery/ws/JSONQuery?query=%3C%3C118234003%20%7C%20%20%7C%20MINUS%20(%3C%20404684003%20%20%7C%20%20hallazgo%20cl%C3%ADnico%20%20%7C%20%20:%7B%20[3..*]%20363698007%20%20|%20%20sitio%20del%20hallazgo%20%20|%20%20=%20%3C91723000%20%20|%20%20estructura%20anat%C3%B3mica%20%20|%20%20%7D\)&cache=true --- ## Post #7 by @system Thanks Diego, that looks like a valid possibility. It is not very readable ;-) But still I hope for a fix of the issue Thanks Bert Verhees --- ## Post #8 by @yampeku In fact, the URI becomes more readable the less text you put in the expressions ;\) --- ## Post #9 by @system 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. --- ## Post #10 by @system Thanks, Luis, The following answer needs some reading in advance, I will reply later to this. Bert --- ## Post #11 by @system my pleasure, I envision endless exiting conversations ahead;-) --- ## Post #12 by @yampeku 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 --- ## Post #13 by @system 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 and deployed separately... --- ## Post #14 by @system 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... --- ## Post #15 by @system I hope not, my interests are not of academical nature. But I am working on current practical real world problems. --- ## Post #16 by @system That is exactly my plan --- ## Post #17 by @michael.lawley I have to agree with Bert \- semantically a single SNOMED code and a post coordinated expression are exactly the same, so if a code is a valid option, then an expression should be to\. Yes, you need a reasoner or other system to be able to test subsumption, but that's also the case for a single code, just a lot simpler to implement with a precomputed lookup\. Michael --- ## Post #18 by @system I am a bit late getting to this discussion (and I did see the PR, it's just that Bert's and my idea of a 'quick reaction' are different ;) ... Michael Lawley's comment is technically the right theoretical understanding. And maybe we should enable it, but first I would want to have a small discussion on the following issues: - does it make data less interoperable, on the basis that some recipients don't know what to do with post-coord expressions, but they can deal with single concepts? - I think there is a potential of canonical form for post-coord expressions, but I must admin I can't remember the rules about this; - as Luis pointed out, are some expressions complex enough that we should treat them as shared resources rather than putting them inside archetypes or templates? - what does a post-coord expression look like as a URI? I'm inclined to think we could technically enable it in ADL 1.4 (I assume that the URI binding form in ADL 2 takes care of the need there), but I think we need to provide some implementation guidance. Interested in further thoughts. Bert - do you have examples of kinds of actual post-coordinated expressions you want to support? Who builds them, what do they represent etc? - thomas --- ## Post #19 by @system 1) Customers just demand SNOMED code, Nictiz gives them in their specifications, and some customers want those specifications to be used. It are not very complicated expressions, some examples, written by Nictiz: #### Excision of lymph node: Procedure context (attribute)58347006:408730004=410534003 <-- Not indicated 58347006:408730004=262008008 <-- Not performed 58347006:408730004=385671000 <-- Unsuccessful 2) The canonical form was in one of the emails today. I never use it. 3) arbitrary 4) see an email of Diego today, it is very ugly because of all the percent-signs. Sorry, I must get up very early tomorrow. Best regards Bert Verhees --- ## Post #20 by @yampeku I gave you an extreme case ;D For example, these queries are completely correct, totally understandable, and can also be stored in current ADL\. http://diebosto2.pc.upv.es:8888/SnomedQuery/ws/JSONQuery?query=404684003:363698007=39057004 or even the subset http://diebosto2.pc.upv.es:8888/SnomedQuery/ws/JSONQuery?query=<404684003:363698007=39057004 Weird codification happens with some symbols, and specially with spaces or accents on texts\. Maybe we just need to come with an standard way of expressing these uris \(which I believe Snomed already provides a syntax for that\.\.\.\) --- ## Post #21 by @system I think SNOMED does provide a syntax, I saw it once somewhere. I think it is in the tig.pdf but I am not sure --- ## Post #22 by @mikael Hi, I can just agree\. A SNOMED CT expression can contain one concept \(and then we call it a pre\-coordinated expression\) or more than one concept \(And then we call it a post\-coordinated expression\), but both are semantically just expressions\.   Regards   Mikael \-\-\-\-\-Ursprungligt meddelande\-\-\-\-\- --- ## Post #23 by @mikael Hi, The SNOMED CT Compositional Grammar is specified and explained in the “Compositional Grammar - Specification and Guide” at the address [https://confluence.ihtsdotools.org/display/DOCSCG/Compositional+Grammar+-+Specification+and+Guide](https://confluence.ihtsdotools.org/display/DOCSCG/Compositional+Grammar+-+Specification+and+Guide) . The syntax itself is specified in chapter “5 Syntax Specification” at the address [https://confluence.ihtsdotools.org/display/DOCSCG/5+Syntax+Specification](https://confluence.ihtsdotools.org/display/DOCSCG/5+Syntax+Specification) . Regards Mikael --- ## Post #24 by @system I wonder what the decision will be. Will the current ADL specs be adjusted to support also post coordination? The grammar change is trivial. Several organizations in the Netherlands would really welcome that. Can we have an indication about this? This also, because the migration to ADL 2.0, also after it is ready defined, will take several years. Thanks Bert --- ## Post #25 by @system we will certainly look into doing this one as quickly as possible\. --- ## Post #26 by @system That is very nice, Thomas Thanks Bert --- **Canonical:** https://discourse.openehr.org/t/post-coordinated-expressions/15466 **Original content:** https://discourse.openehr.org/t/post-coordinated-expressions/15466