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...) 2017-01-24 23:29 GMT+01:00 Bert Verhees <bert.verh...@rosa.nl>: > 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 > > Op 24-1-2017 om 23:29 schreef Thomas Beale: > > > > > > 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 > > > On 24/01/2017 11:45, Bert Verhees wrote: > > 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
