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: i...@freshehr.com
twitter: @ianmcnicoll
Co-Chair, openEHR Foundation ian.mcnic...@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 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-boun...@lists.openehr.org]
> On Behalf Of Ian McNicoll
> Sent: 12. mars 2016 08:41
> To: For openEHR technical discussions
> 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: i...@freshehr.com
> twitter: @ianmcnicoll
>
> Co-Chair, openEHR Foundation ian.mcnic...@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 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 late
