SV: SV: Usage of Compositoin.Category

[Bjørn Næss]

On 11/04/2016 11:07, Bjørn Næss wrote:
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.

Yes - I think we need some kind of marked. We have been thinking about adding 
this to the link. Some kind of "link to self". Then to avoid duplicates you 
MUST include that in every AQL. This is why we ended up with the proposal of a 
Composition category which solely of re-used (copies) data.

I'm not sure if this has the flexibility you (we) really want thought does it? 
It means that the entire Composition has to be treated as duplicate info to be 
excluded from query evaluation.

BNA: No you are right. It doesn't give the right level of flexibility when it 
comes to generating a Composition. So it is a trade off with the problem of 
duplicates when querying. We are working on a pattern for the user-inteface to 
cope with this problem. Because the end-user would like to "feel like" he is 
editing like before. But what is actually is doing is to create entries which 
will be referenced as copies.

And as you said : all the content of a given Composition MUST be treated like a 
copy. Only the metadata and mostly author and context.start_time should be new. 
This is not an ideal requirement/design - but the best of many worse choices so 
far



The same pattern could be applied on several levels (ENTRY, CLUSTER). I.e. a 
Blood Pressure with an attribute 'is_copy' should by default be excluded from 
AQL queries.

Something like that?


Right. If we did it in the most general fashion possible, 
LOCATABLE<http://www.openehr.org/releases/RM/latest/docs/common/common.html#_archetyped_package>
 could have a Boolean flag 'is_copy'. But then you have a False Boolean on 99% 
of all data, which is not great data design. If we say that any copy has to 
have a LINK attached pointing to what it is a copy of, then your suggestion 
above is better (if I understand correctly) - put an 'is_copy' flag there. It 
could be argued that 'meaning' should encode whether something is a copy or 
not, but I think a separate flag would be better, and in any case 'meaning' 
might still carry different reasons for making copies.

BNA: Yes - I think we should maintain meaning to carry optional reason for 
making a copy. And then we need to have the specific flag to tell if it is a 
copy.

- thomas


Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10<tel:+47%2093%2043%2029%2010>

Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av Thomas Beale
Sendt: mandag 11. april 2016 12.42
Til: openehr-technical@lists.openehr.org
Emne: Re: SV: Usage of Compositoin.Category

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SV: SV: Usage of Compositoin.Category

[Thomas Beale]

On 16/03/2016 05:19, Bjørn Næss wrote:

The problem is not to filter in data. The most important feature to support is 
to filter out data.
The proposed solution is to add a new category code to add a new group of 
Compositions which by default is sorted out.
This could be done by archetypes. But that creates the need for the implementations to 
add new filters as new archetypes are developed. If we agree that there is a large group 
of "report" compositions with only referred data from their primary sources - 
then we should make this a first class citizen of the openEHR domain model.


we have thought in the past that we should do something directly in the 
RM to mark 'reports' and other 'derivative' content in some way, but 
never agreed properly on what to do. Probably your experience reports of 
trying to convert what I imagine are well understood DIPS data 
structures and querying capabilities will help us focus on some concrete 
changes we can make to the RM. Maybe it is as simple as another 
Composition category.


Another alternative is to define a marked in EHR_STATUS e.g. is_derived: 
Boolean that would enable report-like content to be detected, and 
ignored in normal querying. We already have some other markers there 
that affect querying, e.g. is_queryable (see here 
).


- thomas

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

SV: SV: Usage of Compositoin.Category

[Bjørn Næss]

The problem is not to filter in data. The most important feature to support is 
to filter out data. 
The proposed solution is to add a new category code to add a new group of 
Compositions which by default is sorted out. 
This could be done by archetypes. But that creates the need for the 
implementations to add new filters as new archetypes are developed. If we agree 
that there is a large group of "report" compositions with only referred data 
from their primary sources - then we should make this a first class citizen of 
the openEHR domain model. 

The discussions about links: 
Yes we could use links. But where should we add the links? From my point of 
view the only place to add these lnks would be on the composition root. But 
then you miss the opportunity to add relationship between links. And there is a 
large group of archetyped compositions that is added into to EHR , but they are 
transported to another system on some other information model (HL7, EDIFACT, 
PDF, Paper, etc.). The simple idea behind this proposal is to define a generic 
system to create openEHR compositions that is the primary source for all this 
kind of messages. The only needed thing is to either use TDD or some other 
transformation of a "compiled" composition.  As far as I can see now this is 
the simplest and most efficient way to handle this. Then the content may be 
archetyped and the transformation could work directly on the RM model to create 
the expected outcome.


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 Thomas Beale
Sendt: fredag 11. mars 2016 14.12
Til: openehr-technical@lists.openehr.org
Emne: Re: SV: Usage of Compositoin.Category


Currently I think we filter on 'report' COMPOSITIONs via something like:

FROM COMPOSITION c[openEHR-EHR-COMPOSITION.report.v1]
CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.body_weight.v1]

So that would not need any change to the COMPOSITION.category to be achieved. 
Not saying there are not reasons to do it, just that the normal way today seems 
to satisfy the requirement.

Secondly, just a mechanical AQL thing: it should normally be possible to do:

WHERE c/category/defining_code matches {[openehr::434]}

- thomas

On 10/03/2016 12:32, Bjørn Næss wrote:
> 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
>


___
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