Project Management

Team

The following people are involved in the work reported on this page. Please email the project leader if you would like to be involved, or post on the openehr-technical mailing list.

Development process

The specifications proposed on this page have been developed after 2 years of experience of building template tools by Ocean Informatics, and 18 months (since feb 2007) use of templates at the UK NHS. During this time, a simple template XML schema has been used which has continually been enhanced over this period; the templates created according to this schema are known as .oet (openEHR Template) files. The proposals here do not re-use this schema directly, since it is of an organic nature rather than being created due to a proper design process that considered the existing openEHR specifications. Rather, the functional characteristics of this schema have been incorporated into an update of ADL, which will become version 1.5 of ADL, and a new specification for templates. This latter specification will give rise to a new schema (even simpler than the proprietary one in current use as it happens) as well as a formal object model of templates, in the same manner as we already have the Archetype Object Model (AOM) for archetypes. This will enable the construction of interoperable open source and commercial template tools for openEHR.

During the process of developing the new specifications, the proposed models and syntax for templates will be implemented in the Archetype Workbench and/or other freely available tools so that a) the specifications can be validated and b) the community can see them in action. The acceptance of the specifications will occur by the normal review and voting process of the openEHR Architecture Review Board.

Ocean Informatics undertakes to provide a conversion mechanism for all templates created with its current tools into the new openEHR format defined in this specifications.

Delivery Plan

Overview

Supporting templates in openEHR entails semantics related to specialisation. In general there are various ways in which a model can act as a 'specialised' or further constrained version of a previously defined model. A specialised archetype for example further constrains another archetype (which may itself be specialised); an openEHR template uses some specialisation semantics plus other semantics such as 'slot-filling' and default values.

The artefacts involved are shown in the figure. The main thing to be aware of is that an 'openEHR Template' is an artefact that references archetypes, and adds its own constraints with respect to each reference, whereas an Operational Template is the result of evaluating a Template against the Archetype library to generate a self-standing artefact which is like a single big archetype.

This wiki page contains specification proposals that support archetype specialisation and templates. The work is summarised as follows:

• additions to the ADL 1.4 specification to properly define specialisation semantics - this will be ADL 1.5
• additions to the Archetype Object Model (AOM) version 2.0.1 corresponding to the ADL 1.5 changes - this will be AOM 2.1
• additions to the ADL syntax that support template-specific semantics. These allow templates to be expressed in an extended form of ADL called TDL, Template Definition Language
• a new Template Definition Model specification that defines the semantics of templates as an object model - just like the Archetype Object Model (AOM)
• a new Operational Template specification, which defines

Archetype Definition Language (ADL)

Various additions are made to the ADL 1.4 specification to define the specialisation semantics needed by both specialised archetypes and by templates.

• draftof ADL 1.5 spec.

The changes for ADL 1.5 include:

• the semantics of reference model subtype matching are now described;
• rules are provided for when node identifiers (at-codes) are required in archetypes;
• the ability to state a path rather than just an attribute, allowing redefinition blocks deep in the structure to be stated with respect to a path rather than having to be nested within numerous containing blocks on which no redefnition occurs;
• new keywords for defining the order of specialised object nodes within container attributes;
• an explanation of how to use the negated match operator (~matches, or œ) to define value set exclusions in specialised archetypes;
• rules for the construction of node identifier at-codes in specialised archetypes;
• a description of the semantics of 'inheritance-flattened' archetypes.

Nearly all the changes occur in the section on cADL - Constraint ADL on page 49 or the new section Specialisation on page 106.

Archetype Object Model (AOM)

Some small additions are made to the AOM corresponding to the changes to ADL (see spec draft above). See the draft of the new version of the AOM. The additions are as follows:

• Added C_ATTRIBUTE.differential_path: String - this allows cADL 'blocks' within the definition of a specialised archetype or template to be located deep within the structure by using a path to say where, rather than having to descend into the structure.
• Added C_ATTRIBUTE.match_negated: Boolean, which allows the ~matches ("not matches") operator to be represented, which enables exclusions to be represented in specialised archetypes and templates (an exclusion is another kind of 'differential' constraint representation)
• Added C_OBJECT.specialisation_level: Integer - this is not strictly necessary in the model,  but helps to define formally the notion of specialisation level.
• Added ARCHETYPE_CONSTRAINT.is_same_as(...): Boolean - a function to allow archetype nodes to be compared to corresponding nodes in parent archetypes, in order to know if nothing has changed, even if things are restated (due to the way tooling works etc). For example many current specialised archetypes restate occurrences and existence when they don't need to. This function defines the semantics for sameness, and its use allows specialised archetypes to be serialised out in the leanest possible form.
• Added C_OBJECT.sibling_order attribute and SIBLING_ORDER class

These changes will entail some minor changes to the archetype XSD.

Template Specification

The template specification (draft) consists of:

• the model (TOM), which consists of additions to the AOM that make it work for expressing templates,
• the Template Definition Language (TDL), an extended form of ADL
• the Operational Template Model (OTM)

When this model is finalised, an XML schema will be defined, mostly by reusing the AOM XSD, and this will become the openEHR XSD for Template Definitions.