More generic reference model

Daniel Karlsson daniel.karlsson at
Fri Sep 2 08:28:38 EDT 2016


if I understand your issue correctly, I believe that some sort of "code 
index" is needed in openEHR persistence implementations. This "code 
index" would link all codes used with the (full) path to the node where 
the code is used. There are several considerations to be made when 
implementing such an index, including making certain that the 
information context is clear (e.g. a code in an exclusion archetype vs. 
one in the problem archetype), which other pieces are needed to build 
the index, like archetypes and templates used in the path, which codes 
to index (archetype- and template-bound codes as well as coded values). 
I assume the brilliant people on the openEHR lists knows more about such 
things than I do :)


On 2016-09-02 09:41, Bert Verhees wrote:
> 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 non-member-country)
>> 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.
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at

Daniel Karlsson, PhD, sr lecturer
Department of Biomedical Engineering/Health informatics
Linköping university
SE-58185 Linköping
Ph. +46 708350109, Skype: imt_danka, Hangout: daniel.e.karlsson at

-------------- next part --------------
A non-text attachment was scrubbed...
Name: daniel_karlsson.vcf
Type: text/x-vcard
Size: 356 bytes
Desc: not available
URL: <>

More information about the openEHR-clinical mailing list