On 03/09/2016 10:34, Bert Verhees wrote:
On 03-09-16 18:17, Thomas Beale wrote:
WHERE
c/name/value='Current Problems'
AND diagnosis/data/items[at0002.1]/value/defining_code *matches*
{ http://snomed.info/id/42570301000090487|cancer Dx refset|}
That is a very OpenEHRish way to do it, is comparing the code.
But what if you also want to find the subtypes, lungcancer (30
sub-types), etc, if you want to know about SNOMED attributes.
For that purpose is the Expression Constraint language, and you need
to query the terminology to know what you need to compare your data with.
I'm not sure if it was clear from the above - the WHERE clause is
testing for membership of a code in some EHR data in a SNOMED ref set,
i.e. a value set of cancer diagnoses (or you could make it Lung cancer
if you want). The (fake) concept code 42570301000090487 stands for an
evaluated ref set, assumed to be known inside whatever terminology
service the AQL service talks to. How the membership comparison is done
may vary, with many possible implementations.
The best way to do it is not invent another way to do it, but embed
that language.
http://doc.ihtsdo.org/download/doc_ExpressionConstraintLanguageSpecificationAndGuide_Current-en-US_INT_20150820.pdf
When that is done well, you have the full power in one move.
the point is here that for already defined ref sets, we can just as the
terminology service (or some cache) to determine membership. If we want
inline ref set definitons then we need to potentially embed a ref set
definition in the query, hence my reference to that IHTSDO spec.
One interesting question is whether 'inline' refset definitions would
be allowed, e.g. using the SNOMED constraint grammar. We probably
should add this to AQL as a plug-in syntax, since IHTSDO standardised
it
<http://doc.ihtsdo.org/download/doc_ExpressionConstraintLanguageSpecificationAndGuide_Current-en-US_INT_20150820.pdf>.
What the solution is for ICDx I don't know.
I don know either.
There is more then just a plugin which does some separate work.
Because the ECL also works on subtypes and attributes, and the
attributes are not available. AQL must deliver them to the SNOMED
engine, because they are on another path. There is code infrastructure
needed.
some of the needed 'attributes' can potentially derived from the SNOMED
concept model and data might even be represented using SNOMED
expressions. But, don't forget, openEHR is for the whole world, not just
the SNOMED world. Much of the world doesn't use SNOMED CT. So such
mappings have to be done in archetypes, and only directly represented in
data for those locations that really do have SNOMED. We have not worked
out all the tricks to make it work for both worlds.
For example: Find systolics higher then 165, in the archetype the type
of the measurement can be in another element then the value of the
measurement.
This mapping between SNOEMD attributes and where they are in the
archetypes must be done in some elegant way.
Indeed. Ideally we would work more closely with IHTSDO on this (I spent
4 y on standing committees there), but I think there is not yet the
interest in this. There are still people who believe that a) SNOMED CT
on its own, with only trivial data structures is all that is needed
(that's a categorical error of thinking) and/or b) that the whole world
uses SNOMED CT and that therefore the only terminology approach is
SNOMED CT (an error today, and I suspect for years to come).
But there are certainly things we can do to improve on our side, including:
* tracking the outcomes of CIMI term-binding and applying them where
possible
* reviewing recent HL7 term binding thinking
<http://wiki.hl7.org/index.php?title=Binding_Syntax#Current_Working_Material>and
using what we can
* making sure we use all the IHTSDO new standards we can, e.g. URIs,
Constraint language as per above discussion etc.
Principally I think we need some openEHR community members to work on
some of this and make recommendations for improvements to AQL and
archetype terminology binding.
- thomas
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
