More generic reference model

Bert Verhees bert.verhees at
Fri Sep 2 03:41:34 EDT 2016

Sorry, this was a mix-up of two concerns

> We are stating in an archetype that we are doing an observation on 
> blood pressure, and we state that again using SNOMED and LOINC. LOINC 
> to define the observation and SNOMED to support the 
> observation-result-definition.

One is the redundancy. The problem with redundancy is that it can be 
error prone when there is a slight difference in meaning of the content 
and archetype ID. When the reference model suggest that the archetype 
clincial idea is a part of group of clinical idea's (f.e. Observations), 
and a internal coding suggest something which has difficulties fitting 
exact in the OpenEHR entry-types and suggest something slightly 
different. Which one is then to follow? Better, I think, would be to 
assign a  generic structure, so there can be no misunderstanding and let 
a terminology-coding decide what the archetype is about. Notice that I 
do not specify the term "terminology-coding", so it does not have to be 
SNOMED if there are strong reasons to not use it. (f.e. a 

> Except from redundancy, there may also be a problem of not using the 
> potential of SNOMED.

This one is a bit harder to explain, but the problem is that when you 
don't know the path to a terminology code, because it differs in 
different archetypes, you cannot query for that code.
The query consists of the archetype ID and the path inside the 
archetype. So there are two problem parts.

In the FROM part: The archetype ID is a representation of the clinical 
idea which is represented in the archetype. I understand it is possible 
to use regular expressions in a query in the FROM part, and in this way 
have a selection from more then one archetypes to query in one time. But 
regular expressions operate on series of characters, not on clinical 
hierarchies. So it is not possible to query in archetype ID's on 
hierarchy of clinical ideas.

In the WHERE part: When the path to a terminology coding is not known, 
and this is the case when there are more entry-types, and even in a 
generic entry-type this can be a problem. So there should be a fixed 
location which can be reached by AQL where coding occurs, so the 
potential of SNOMED in relations and hierarchies can be guaranteed 
successfully used in AQL queries. As it is now, we cannot be sure that 
we miss something in a query which is in a obscure archetype. This is 
especially the case when the number of used archetypes outreaches the 
human comprehension limits, for example the idea when more EPD's are 
queried in one time, or are compiled in regional cooperation of 
healthcare facilities or hospital mergers.

So, that are my concerns, I hope I explained them well, I see that 
yesterday I made a few jumps in my thoughts which where hard to follow 
for others. Excuse me for that

Best regards
Bert Verhees

On 01-09-16 11:20, Bert Verhees wrote:
> Thank you for your reply, Diego.

More information about the openEHR-clinical mailing list