openEHR Specification ProjectRelease 1.0 - Road Map

Overview

The following table describes the deliverables of the openEHR specification project and indicates the current status of each. The meanings of the statuses are as follows:

Reading the Documents

Most links in the table below are to Adobe PDF files. All files are in colour. If you do not see them in colour or have other problems reading them, we suggest upgrading to the latest Acrobat Reader. If you still experience problems with reading PDF files, your browser configuration may need to be adjusted. See the Adobe Acrobat support page for more help.

Deliverable

Description

Status

Comments

General
Introducing openEHR First introduction to the openEHR Foundation and its activities. Stable
CM Plan Technical document describing how versioning, changes, and releases are made. Describes the workflow of the Architectural Review Board (ARB). Stable

Requirements
ISO 18308 Conformance Statement Document describing conformance of openEHR architecture to ISO TS 18308, "Requirements for EHR Architectures". Stable

Architecture
Architecture Overview “Read me 1st” document for the whole architecture. provides a summary of the reference, archetype and service models, and describes global semantics. Stable This is a new document containing some content from the old "roadmap" document as well as new content describing the key semantics of the openEHR reference model.
Modelling Guide Describes the use of UML and other related issues in object-oriented modelling. Stable
Terminology Documentary form of the openEHR terminology, which is a set of vocabularies and code sets used by the reference and archetype models. Stable

Reference Model
EHR IM The information model of the openEHR EHR  Stable
EHR Extract IM The information model of the EHR Extract, which is a serilialisation of content from an EHR. Under Redevelopment The EHR Extract Information Model has to be redeveloped due to changes in semantics in the other models, including the Folder structure, version identification and so on. It is scheduled
for Release 1.1
Demographic IM The openEHR demographic model. Stable
Common IM Information model containing common concepts, including the archetype-enabling LOCATABLE class, party references, audits and attestations, change control, and authored resources. Stable
Data Structures IM Information model of data structures, incuding a powerful model of HISTORY and EVENT. Stable
Data Types IM Information model of data types, including quantities, date/times, plain and coded text, time specification, multimedia and URIs. Stable
Support IM Support model containing low-level concepts, assumed types, and terminology interface specification used in the rest of the models. Stable
Integration IM Model supporting expression of legacy data in a free form for further processing into and out of openEHR information structures. Draft

Archetype Model
Archetype Principles Semantic principles of archetypes and templates. Stable
Archetype Definition
Language 1.3 (ADL)		 Syntax specification for archetypes. Stable ADL 1.3 remains the current ADL syntax in use, and most current tools only process ADL 1.3. Some improvements that were done as part of the ADL 2 work will be reverse-engineered into ADL 1.3 in the near future; these are mainly to do with pathing.
Archetype Definition
Language 2.0
(ADL2)		 Improved syntax specification for archetypes. Draft ADL version 2.0 is an improved syntax for expressing archetypes, and is has two important
features over ADL 1.3: it is extensible without the syntax needing to be changed, because in ADL2,  an archetype is a dADL document; and due to being in dADL/embedded cADL  format, it can more easily be converted to and from XML.
The current version of this specification has not yet been fully implemented or tested. Implementors of this specification should consider engineering backwards compatibility for ADL 1.3 in their tools.
Archetype Object
Model (AOM)		 Object model of archetypes. Stable
Template Object Model (TOM) Object model of templates. Forthcoming The templates document has been partially completed and will be included in Release 1.1.
openEHR Archetype Profile (OAP) openEHR plug-in additions to the generic archetype object model. Stable
Archetype System Description of system of archetype management and governance. Under Redevelopment This document will change as a result of current work on archetype ontologies, governance, and logistical management.

Service Model
EHR Kernel API API of a client component that provides a virtual EHR interface, including fine-grained archetype-based data manipulation, and querying. Forthcoming
EHR Service Coarse-grained service specification for EHR back-end providing check-out, Contribution check-in, querying. Forthcoming
Demographic Service Service specification for demographic back-end. Forthcoming
Archetype service Archetype repository service specification. Forthcoming

Computable
UML computable form of model Expression of openEHR models in tool-based UML; published in XMI format. Draft
Terminology as an XML file Terminology in computable XML form. Draft

ITS
XML schemas XML-schema expression of the reference model. Draft
Java ITS Guide Guide to java implementation of openEHR. Draft

Release Strategy

With the advent of Release 1.0 of openEHR, more rigorous change management rules come into play. These are designed to protect developers and users from adverse effects of changes, and to allow them to upgrade in an orderly fashion. Future releases will follow a 3-digit numbering scheme similar to many open source projects, e.g. Apache, using identifiers like 1.0.1 etc. The meaning of a change in each digit is as follows:

Changes to Documentation

Where changes to documentation are made, e.g. due to a request to clarify an explanation, fix a typographical error, a CR will be raised, and the revision number of the affected document(s) will change, but there will not be a new release number.

Error corrections

Where the changes made are to correct an error in a model, parsing rules or some other aspect of the formal semantics of the specifications (and possibly accompanying changes to explanatory text), an error-correction release will be made.

Compatible Additions

Where the changes have the effect of adding a new specification or other artifact which is completely compatible with the current release, an enhancement release is made.

Major Changes

Where changes actually alter semantics of existing artefacts (other than for minor error corrections), a new major release is declared. Such changes would normally be grouped into as few such releases as possible.

Change Management

As with pre-1.0 releases, change management will remain a disciplined process.  Two types of online document, the Problem Report (PR) and the Change Request (CR),  are used to track problems and changes. These are used as follows:
From Release 1.0 onward, the way CRs  are processed will change slightly. All changes to the specifications, apart from document text changes (e.g. improving explanations, fixing typos) will be signalled to the community via the openehr-technical mailing list, and a period of time given for the community to inspect the proposed changes and provide feedback. This is particularly aimed at allowing implementers to indicate the knock-on effects of changes. In the process of such discussions it may turn out that the proposed change will not go ahead, or that it will go ahead in a later release than originally planned. In this way, the community will be able to ensure that releases into the future remain stable and occur at a reasonable rate.

All changes in the Release 1.0 mainline must also be implemented in at least one instance of software, schemas or other appropriate formal expression before being accepted as a change to the specifications.
$LastChangedDate: 2006-03-16 13:37:42 +0000 (Thu, 16 Mar 2006) $ $LastChangedRevision: 96 $