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
