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
