these examples from Ian illustrate exactly why we never figured this out
before - because of the possible mixture of original content, referenced
content, and sometimes copied content e.g. in a discharge summary. The
problem is that 'derived' content can occur at a lower granularity than
Composition.
Unless... we impose a discipline that says otherwise. For example, if
there is /only/ original content and references (links, DvEhrUris) then
everything is easy. As far as I can see, the problem is if content is
/copied inline /from e.g. a lab result or Dx list into the discharge
summary. For a physician, this is pretty natural, and it's easy to see
how a nice UI can enable it.
But if we want to avoid double results in querying, we need some sort of
'is_derived' or 'is_copy' marker (and a link to original content) on the
copy. At least that's where I got to the last time I thought about it.
- thomas
On 12/03/2016 07:40, Ian McNicoll wrote:
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 <i...@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-boun...@lists.openehr.org] On
Behalf Of Bjørn Næss
Sent: 10. mars 2016 20:33
To: For openEHR technical discussions <openehr-technical@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-boun...@lists.openehr.org] På
vegne av Ian McNicoll
Sendt: mandag 7. mars 2016 18.16
Til: For openEHR technical discussions <openehr-technical@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: 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 17 February 2016 at 21:59, Bjørn Næss <b...@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@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open
ehr.org
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
*Thomas Beale*
Management Board, Specifications Program Lead, openEHR Foundation
<http://www.openehr.org>
Chief Technology Officer, Ocean Informatics
<http://www.oceaninformatics.com>
Chartered IT Professional Fellow, BCS, British Computer Society
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> Culture blog
<http://wolandsothercat.net/>
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
