Hi Thomas,
from my perspective, this approach (by not being explicit about the RM
classes (and semantics) that need to be supported by the Contains
keyword) led to a situation in which two vendors (Marand and DIPS) can
claim that they have a valid implementation of openEHR but are not
compatible. I can't even tell if Marand (not support Folders at all) or
DIPS (using questionable overloading of the semantics) is more right or
wrong with their approaches on this matter...
Birger
Am 21.08.2018 um 17:04 schrieb Thomas Beale:
Hi Birger,
Note that no openEHR RM types (COMPOSITION etc) are part of the AQL
spec - they are just used in examples. AQL doesn't actually know
anytthing about particular types. Seref's intention is that it stays
this way, and his proposed function, or some other equivalent resolver
mechanism would be a generic addition to AQL that would, for openEHR
structures be used for FOLDERs containing refs to COMPOSITIONs
(actually VERSIONED_COMPOSITIONs), and also any other similar
situation (e.g. in the demographic model).
- thomas
On 21/08/2018 15:52, Birger Haarbrandt wrote:
Hi Seref,
while I understand your argument regarding overloading of definitions
(and I agree with your reasoning), I see a clear need to not treat
folders as second class citizens in openEHR. Not including Folders in
the official AQL spec and leaving this to vendor-dependent functions
will not be helpful to allow portability. Especially, as the use of
folders (especially when it can contain data in an ITEM_STRUCTURE) is
becoming a common pattern to represent episodes of care.
Cheers,
--
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
*Birger Haarbrandt, M. Sc.
Peter L. Reichertz Institut for Medical Informatics (PLRI)
Technical University Braunschweig and Hannover Medical School
Software Architect HiGHmed Project *
Tel: +49 176 640 94 640, Fax: +49 531/391-9502
birger.haarbra...@plri.de
www.plri.de
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org