Gerard Freriks +31 620347088 [email protected]
Kattensingel 20 2801 CA Gouda the Netherlands > On 19 Feb 2018, at 12:07, Thomas Beale <[email protected]> wrote: > > > note that a key problem I want to address is that templates based on > COMPOSITIONs don't really make sense as models of data retrieval/display > forms - they are really only useful for data capture forms (or messages, or > documents), because COMPOSITION is a container for committing data to the > EHR. > Or any interface be it for committing, querying, display, data entry, documents, messages, clinical decision support interactions? These all can be dedicated kinds of Template/Interface > Displaying data is a different question - it may be EHR data, it may be > demographic data, and it may be something else entirely. So the data items we > want to mention in templates are mostly of ENTRY level, and will be the > results of queries; the relevant queries could be included in such templates. > > So the starting point for many forms won't be a COMPOSITION - it is instead a > different logical container that groups data that result from one or more > queries, into a 'use group', i.e the group of data items intended to be > visualised or used as a report etc. > > Unless the COMPOSITION is the description of any interface. > One problem today is that people trying to define screens for visual > applications are forced (more or less) to create templates starting with > COMPOSITIONs, which is incorrect; my impression is that such templates are > only used for data capture and that other display forms are modelled in > various non-standard ways, or not at all. > > I think annotations (based on paths) will be useful, but I not completely > adequate to achieved what is needed. > Why? > - thomas > >
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
