Bert,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 :)
Cheers, Daniel On 2016-09-02 09:41, Bert Verhees wrote:
Sorry, this was a mix-up of two concernsWe 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 thatBest regards Bert Verhees On 01-09-16 11:20, Bert Verhees wrote:Thank you for your reply, Diego._______________________________________________ openEHR-clinical mailing list [email protected]http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
-- Daniel Karlsson, PhD, sr lecturer Department of Biomedical Engineering/Health informatics Linköping university SE-58185 Linköping Sweden Ph. +46 708350109, Skype: imt_danka, Hangout: [email protected]
<<attachment: daniel_karlsson.vcf>>
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
