More generic reference model

Thomas Beale thomas.beale at
Sat Sep 3 15:30:36 EDT 2016

On 03/09/2016 10:34, Bert Verhees wrote:
> On 03-09-16 18:17, Thomas Beale wrote:
>>     c/name/value='Current Problems'
>>     AND diagnosis/data/items[at0002.1]/value/defining_code *matches* 
>> {|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.
> 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 
>> <>. 
>> 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
  * reviewing recent HL7 term binding thinking
    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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the openEHR-clinical mailing list