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
