On 03-05-17 12:36, Thomas Beale wrote:
The only missing part, now that I look at the SNOMED Compositional
Grammar <https://confluence.ihtsdotools.org/display/DOCSCG> and
Expression Constraint Language
<https://confluence.ihtsdotools.org/display/DOCECL> specs, is how to
create a URI (which is the type of a term binding in ADL2
<http://www.openehr.org/releases/AM/latest/docs/AOM2/AOM2.html#_terminology_package>)
from a post-coordinated expression or constraint expression. This
should be trivial, but I don't see where SNOMED has specified it.
True, I was looking for that also, a few days ago. I don't have time to
read much now, but there is a document on the SNOMED site on URI's,
maybe it is in there?
I can take a look later or look in my documentation, I have course
materials. I come back to this tomorrow if not someone else already has.
Bert
- thomas
On 03/05/2017 11:23, Thomas Beale wrote:
Hi Koray,
On 03/05/2017 10:41, Koray Atalag wrote:
Hi again,
I’ve been snowed under for a while and just now catching up with
this…I reckon there was a suggestion that we do not include SNOMED
codes within archetypes, or more specifically post-coordinated
expressions, if I understand correctly but to define these somewhere
else and then include the external URI instead. While this would be
a good solution for well-defined expressions, subsets etc. I think
if you think about the vast amount of potential expressions with
almost endless permutations of terms it quickly becomes too complex
and unmanageable. Therefore there will always need for including
specific expressions within archetypes and templates.
I’ve been doing a lot of terminology bindings using various
ontologies and terminology lately and I think we need urgently a
consistent way to make these bindings and get the tools support it.
For example when term bindings (for the purpose of defining
real-world meaning of a node) are done at archetype level you end up
with local at codes that refer to each binding and then it is
possible to link one or more terms from same or different
terminology systems. For the purpose of providing a valueset to a
DV_CODED_TEXT at archetype level we don’t have a very clear way – we
keep on saying we’ll put a terminology query but it is not really
usable or useful.
I'm unclear on the problem exactly. We can bind to a URI that points
to a SNOMED CT subset.
If we upgrade the binding syntax in ADL 1.4 as per this SPECPR-215
<https://openehr.atlassian.net/browse/SPECPR-215>, then we can
include SNOMED constraint expressions.
Let's assume we do this, and the tools follow suit.
What else is needed? (I agree that we need to address all this ASAP
by the way. It is already addressed in ADL2, but the user-base is
moving much more slowly than I expected towards it).
Tooling support is also not satisfactory. But when you do that at
template level (e.g. define a valueset for a DV_TEXT by further
constraining it to DV_CODED_TEXT or an existing DV_CODED_TEXT) it is
just a list of terms, code and terminology system with
version/release. It is not clear how we can refer to an external
list defined by a terminology query or refset – at least I couldn’t
figure out. There’s quite an inconsistency between archetype vs
template defined valuesets within .opt – whereas they should be
defined in the same way and share same semantics.
I don’t know how to fix it – my guess is that this is not a commonly
used feature so it was never a high priority for SEC group. I think
it is time to bring loose ends together as more and more countries
adopt SNOMED and there is clear pressure to do this. FHIR
terminology service is quite good and I think we should just start
using it. If we need further bells and whistles it can be extended.
I'm not sure how using the FHIR terminology service solves the above
problems. As far as I can see, the question of FHIR or CTS2 or xyz
terminology service is orthogonal to the question of representing
bindings to post-coordinated expressions.
- thomas
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
