More generic reference model
daniel.karlsson at liu.se
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
> 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 lists.openehr.org
Daniel Karlsson, PhD, sr lecturer
Department of Biomedical Engineering/Health informatics
Ph. +46 708350109, Skype: imt_danka, Hangout: daniel.e.karlsson at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 356 bytes
Desc: not available
More information about the openEHR-clinical