SV: SV: Usage of Compositoin.Category

Bjørn Næss bna at
Wed Mar 16 01:19:55 EDT 2016

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 

Mobil +47 93 43 29 10

-----Opprinnelig melding-----
Fra: openEHR-technical [mailto:openehr-technical-bounces at] På vegne av Thomas Beale
Sendt: fredag 11. mars 2016 14.12
Til: openehr-technical at
Emne: Re: SV: Usage of Compositoin.Category

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


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
> 	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
> Mobil +47 93 43 29 10

openEHR-technical mailing list
openEHR-technical at

More information about the openEHR-technical mailing list