Usage of Compositoin.Category

Ivar Yrke iyr at dips.no
Tue Mar 15 05:24:26 EDT 2016


"Preferred" data is a key issue here. I think "preferable" is an aspect of the scenario, not of the data itself. Therefore we must be able to be explicit in AQLs, so that each scenario can express its preference.

mvh
Ivar Yrke
Senior systemutvikler
DIPS ASA
Telefon +47 75 59 24 06
Mobil +47 90 78 89 33

-----Original Message-----
From: openEHR-technical [mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of Ian McNicoll
Sent: 14. mars 2016 18:50
To: For openEHR technical discussions <openehr-technical at lists.openehr.org>
Subject: Re: Usage of Compositoin.Category

Hi Ivar,

I have no issue with the result of link handling in AQL being explicit and predictable but I don't think this solves the problem of deciding which is 'preferred queryable' data. Where an active problem list is maintained, the preferred queryable data would, in many implementations (but not all) live at the end of a link/reference, rather than being in-line. From a clinical perspective, it really does not matter whether the problem list has been implemented as an in-line persistent-style composition with entries 'cloned' from their original event compositions or whether those original entries are simply referenced from the event compositions. I would agree that te latter approach is probably more elegant but from a clinical perspective, it is the Problem List composition that I choose to use as the preferred query route to retrieve problems, how it gets them is really up to the implementer. I would like to be able to express AQL statements agnostic to that underlying implementation choice.

Ian




Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: ian at freshehr.com
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnicoll at openehr.org Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL


On 13 March 2016 at 08:20, Ivar Yrke <iyr at dips.no> wrote:
> I said:
>
> "I can see that there possibly are needs for an AQL that resolves links, but I would rather see this as the special case"
>
> which is basically exactly what Thomas says in his rephrasing of my last statement. My key point is that link handling in AQL must be explicit and predictable. Your scenarios illustrate why this is important.
>
> mvh
> Ivar Yrke
> Senior systemutvikler
> DIPS ASA
> Telefon +47 75 59 24 06
> Mobil +47 90 78 89 33
>
> -----Original Message-----
> From: openEHR-technical 
> [mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of Ian 
> McNicoll
> Sent: 12. mars 2016 08:41
> To: For openEHR technical discussions 
> <openehr-technical at lists.openehr.org>
> Subject: Re: Usage of Compositoin.Category
>
> Hi Ivar,
>
> I'm not sure the situation is quite as clear-cut, in that I donlt think there is necessarilly a simple distinction between primary data which should normally be query-accessible and in-line vs. secondary data which is normally query-inaccessible and referenced.
>
> A few scenarios
>
> 1. Vital signs event - easy!! Primary, in-line and accessible
>
> 2. Diagnosis event. Primary, in-line but depending on whether a secondary problem list is maintained, you may not want to use these original diagnoses events for decision support.
>
> 3. Problem summary. Secondary and definitely need to be query-accessible, but may be in-line or referenced depending on implementation.
>
> 4. Discharge summary. Mostly secondary but may introduce new primary content and again, whether the content is in-lie or referenced is to some extent an implementation decision. DIPS have decided to use referencing, others do not.
>
> 5. End of Life Summary. The critical aspects of this document are primary e.g Resuscitation wishes but other aspects are secondary (though and may be in-line or referenced.
>
> I think the points raised are valid but we may need to tease out several axes here.
>
> Ian
>
>
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: ian at freshehr.com
> twitter: @ianmcnicoll
>
> Co-Chair, openEHR Foundation ian.mcnicoll at openehr.org Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
>
> On 11 March 2016 at 09:39, Ivar Yrke <iyr at dips.no> wrote:
>> Hi
>> An interesting discussion that touches the very concept of structured information, in my opinion. I wonder if the suggested solution looks at the problem from the best angle. So here is my angle:
>>
>> As a person with some SQL experience I would expect an AQL to return 
>> ONLY primary content unless told otherwise. Any content that lives in 
>> a Composition as a link I would not expect to see in that Composition 
>> as an entry. Resolving links is a task for the level "above"
>> (rendering on a screen etc.). I can see that there possibly are needs 
>> for an AQL that resolves links, but I would rather see this as the 
>> special case, much like joining in foreign keys in SQL is an explicit 
>> decision (the SQL analogy have some obvious flaws!)
>>
>> Why is this important? Because showing linked information in compositions where they were not originally recorded creates doubt about the origin of the information (source of truth). The duplication that Bjørn wants to solve is a symptom of un unhealthy structure that undermines an essential aspect of structured information. If a summary composition, like a discharge letter, only links information from other composition, there should be no duplication. So there should not be any need for later  special handling. There should be no problem to solve (well, there would be the need for the optional resolving, but this would be a feature rather than a problem).
>>
>> AQL should relate only to the data and how they are recorded, not to how they are used.
>>
>> With regards,
>> Ivar Yrke
>> Senior systemutvikler
>> DIPS ASA
>> Telephone +47 75 59 24 06
>> Mobil +47 90 78 89 33
>> -----Original Message-----
>> From: openEHR-technical
>> [mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of 
>> Bjørn Næss
>> Sent: 10. mars 2016 20:33
>> To: For openEHR technical discussions 
>> <openehr-technical at lists.openehr.org>
>> Subject: SV: Usage of Compositoin.Category
>>
>> Hi Ian
>> Great response.
>>
>> The most important thing for me is to precisely define the semantic meaning of the content in a composition. In this specific use-case the content of the composition is always a copy of the primary source.
>> This means that the Discharge letter only bring one new thing into the EHR - that is the fact that there is an approved discharge letter. But the entries in the composition is link and copies of entries in other primary sources.
>>
>> The requirements to the system is quite small:
>>
>> * Content of "report" documents MUST not be in the resultset when doing normal AQL queries.
>> * It MUST be possible to query for "report" compositions with specific content.
>>
>> The solution to this problem is simple and I can give an example with an AQL query. Below is a standard query for body weight. Look at the WHERE condition. Here I am looking for all body weights which are NOT part of a report composition. This WHERE condition will be the default filter on all queries.
>> If the client would like to query for all body weights in report document, then just change from NOT EQUALS 434 to EQUALS 434.
>>
>>         SELECT o/data[at0002]/events[at0003]/data[at0001]/items[at0004]/value/magnitude
>>         FROM COMPOSITION c
>>         CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.body_weight.v1]
>>         WHERE c/category/defining_code/terminology_id/value = 'openehr'AND c/category/defining_code/code_string != '434'
>>
>>
>> Given that we agree that there is a class of compositions which belongs to the "report" group.
>> Then we should add such semantic into the RM to make it precise and consistent.
>>
>>
>> Best regards
>> Bjørn Næss
>> Product owner
>> DIPS ASA
>>
>> Mobil +47 93 43 29 10
>>
>> -----Opprinnelig melding-----
>> Fra: openEHR-technical
>> [mailto:openehr-technical-bounces at lists.openehr.org] På vegne av Ian 
>> McNicoll
>> Sendt: mandag 7. mars 2016 18.16
>> Til: For openEHR technical discussions 
>> <openehr-technical at lists.openehr.org>
>> Emne: Re: Usage of Compositoin.Category
>>
>> Hi Björn,
>>
>> I finally got around to thinking a bit about this.
>>
>> It is an interesting problem and I think I can see the need to specify different data handling requirements but I am not sure that overloading composition.category is the best approach here.
>>
>> I suspect this will take a bit of teasing out (and other commit/query strategy metadata) - might it be better to put this in a cluster archetype in the Composition extension slot. That would let us play around with the requirements before pushing something definitive to the RM?
>>
>> So far I have 3 axes:
>>
>> 1. Normal commit strategy: persistence vs. event  i.e do we normally overwrite an existing composition.
>>
>> 2. Source-of-truth i.e. Should this document be regarded as the primary source of truth for certain kinds of data or otherwise e.g Does a system look into event compositions or e.g to a Problem list for 'current problems'
>>
>> 3. Is this a primary document or secondary document? e.g. a Discharge letter is a secondary document derived from other primary records.
>>
>> Just starting the discussion :)
>>
>> Ian
>>
>>
>> Dr Ian McNicoll
>> mobile +44 (0)775 209 7859
>> office +44 (0)1536 414994
>> skype: ianmcnicoll
>> email: ian at freshehr.com
>> twitter: @ianmcnicoll
>>
>> Co-Chair, openEHR Foundation ian.mcnicoll at openehr.org Director, freshEHR Clinical Informatics Ltd.
>> Director, HANDIHealth CIC
>> Hon. Senior Research Associate, CHIME, UCL
>>
>>
>> On 17 February 2016 at 21:59, Bjørn Næss <bna at dips.no> wrote:
>>> We are discussing the use of Composition.Category which is a DV_CODED_TEXT.
>>>
>>> There is a terminology:
>>>
>>>
>>>
>>> <group name="composition category">
>>>
>>>                                <concept id="431"
>>> rubric="persistent"/>
>>>
>>>                                <concept id="433" rubric="event"/>
>>>
>>>                 </group>
>>>
>>>
>>>
>>> Is it required to use only these categories or could an application 
>>> set any DV_CODED_TEXT?
>>>
>>>
>>>
>>> I think it would be ok to allow any category in this.
>>>
>>>
>>>
>>> To be concrete:
>>>
>>> The use-case is discharge summaries. These are Compositions which 
>>> only
>>> (“mostly”) contains links to existing entries. We will be using 
>>> links but since the Composition should be transferred to another 
>>> health provider it must be serialized and validated against an template.
>>> Technically this Compostions contains a lot of entries which is “link to self”.
>>>
>>>
>>>
>>> The idea we are considering is to introduce a category for these 
>>> Compositions. The content will not be part of AQL results for normal 
>>> use-cases. But IF you ask explicit for these categories you will be 
>>> able to query for discharge summaries which contains body weight above 120 kg.
>>>
>>>  If we only add the references as links it will not be possible to 
>>> add them into forms and neither use a Template to validate the content.
>>> This is the reason we are “thinking out of the box”.
>>>
>>>
>>>
>>> Any comments on this?
>>>
>>>
>>>
>>>
>>>
>>> Best regards
>>> Bjørn Næss
>>> Product Owner – Arena EHR
>>> DIPS ASA
>>>
>>> Mobil +47 93 43 29 10
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> openEHR-technical mailing list
>>> openEHR-technical at lists.openehr.org
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.op
>>> e
>>> n
>>> ehr.org
>>
>> _______________________________________________
>> openEHR-technical mailing list
>> openEHR-technical at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.ope
>> n ehr.org _______________________________________________
>> openEHR-technical mailing list
>> openEHR-technical at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.ope
>> n ehr.org _______________________________________________
>> openEHR-technical mailing list
>> openEHR-technical at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.ope
>> n
>> ehr.org
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open
> ehr.org _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open
> ehr.org

_______________________________________________
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


More information about the openEHR-technical mailing list