More generic reference model

Bert Verhees bert.verhees at
Sat Sep 3 12:14:29 EDT 2016

On 03-09-16 08:51, Thomas Beale wrote:
> On 02/09/2016 04:04, Bert Verhees wrote:
>> On 02-09-16 11:18, Daniel Karlsson wrote:
>>> Terminologies typically do not specify which pieces of information 
>>> are needed in a given situation.
>> Hi Daniel, I don't have at the moment opportunity to reply to all you 
>> write, so excuse me for cherrypicking one idea of your message.
>> I thought SNOMED specifies which information is needed in a given 
>> situation, but maybe I misunderstand you?
> It does various things, but this is not one of them, except by 
> accident ;-)
OK Thomas, SNOMED has attributes, those attributes pinpoint to other 
concepts, in the end there might sometimes be data-values, concepts from 
the qualifier value-hierarchy, and build in that way an information 
structure. I don't think if every trace inside SNOMED ends up at a 
qualifier value, not even half or less. A good example is how the 
mapping to LOINC is preferred on the market. LOINC orders the 
lab-research, and SNOMED gives the answer. It think it must be over 
attributes, one (or one group) defining what the answer means, and the 
other a qualifier value which points to a datavalue.

I don't say that SNOMED can replace archetypes, I suggested that a few 
months ago, but I came back from that thought. But SNOMED has a lot of 
information, which is more then just a concept ID for every clinical idea.

So maybe we can leave that subject, as we both agree largely on this.

More important, therefore is the following subject.

There are problems in using SNOMED in combination of OpenEHR, that is 
what I want to discuss, you can give a conceptID to a clinical term, but 
that is about it. When OpenEHR wants to be a success it needs to be able 
to do more. But I do not know what more.

I think, embedding expression constraints in AQL will be a good one. 
This is not an easy one, but it is very powerful. The potential of 
SNOMED comes alive in AQL. That will be a major drive to use OpenEHR.

On the other side, if in OpenEHR the SNOMED integration will not be 
enhanced, there will be work done outside OpenEHR, because clinicians 
and governments want to use the power of SNOMED, with or without 
OpenEHR. So it is an urgent matter.
And does the OpenEHR-use create difficulties doing SNOMED work outside 
OpenEHR, while using archetyped data?
I think this can happen, that could be a showstopper. Sorry for the 
strong language, but that is what I think.

But on the other hand, OpenEHR has it in it to support SNOMED, it can be 
used the right way. This also needs to be discussed, what is the right 
way, and is it really necessary to do it in that way? Are there no escapes?

I asked a question in my previous email to this list. I ask it again.

Besides embedding SNOMED expression constraints in AQL, are there other 
ways to integrate SNOMED in openEHR?

Best regards

> SNOMED is on the right-hand (ontological) side of the is-about 
> relation, EHR information (defined by archetypes) is on the left 
> (epistemological) side.
> So terminology codes within EHR information can indicate what the 
> items 'are about' (in terms of real world categories) but the 
> structures and data types of information items are not generally known 
> within the terminology. Terminology doesn't say why pulse is a good 
> surrogate for heart rate, or in what circumstances MAP BP would be 
> used, or the structure of data in a liver function test. These are 
> generally contingent relations and substitutions, based on cultural, 
> economic and other factors. Terminologies (if well defined) mostly 
> deal in necessary / invariant relations between entities. At the next 
> level out, EHR data relates to situations, which are full of 
> accidental relationships; terminology doesn't easily deal with these 
> either.
> - thomas
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at

More information about the openEHR-clinical mailing list