post coordinated expressions

Implementers (archive)
1

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

2

Yes, as you say ADL1.4 doesn't support this, so we opted to go the URI way

3

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.

4

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

5

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

6

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=<<118234003%20|%20%20|%20MINUS%20(<%20404684003%20%20|%20%20hallazgo%20clínico%20%20|%20%20:{%20[3..*]%20363698007%20%20|%20%20sitio%20del%20hallazgo%20%20|%20%20=%20<91723000%20%20|%20%20estructura%20anatómica%20%20|%20%20}\)&amp;cache=true

7

Thanks Diego, that looks like a valid possibility.
It is not very readable :wink:

But still I hope for a fix of the issue

Thanks
Bert Verhees

8

In fact, the URI becomes more readable the less text you put in the
expressions :wink:

9

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.

10

Thanks, Luis, The following answer needs some reading in advance, I will reply later to this.

Bert

11

my pleasure, I envision endless exiting conversations ahead;-)

12

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

13

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…

14

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…

15

I hope not, my interests are not of academical nature. But I am working on current practical real world problems.

16

That is exactly my plan

17

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

18

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 :wink: …

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
19

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

  1. The canonical form was in one of the emails today. I never use it.

  2. arbitrary

  3. 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

20

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=&lt;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...)