openEHR Release 1.0.1 UML Models


This page provides access to a tool-based UML expression of the openEHR Release 1.0.1 models. Two variants are available:

The Dictionary view from the browsable form provides text definitions of all classes and attributes.

The model is expressed in MagicDraw 9.5, and is available here in the standard zipped XML form used by MagicDraw. An XMI 1.0 file output from the tool is also available.



The models shown here are are derived from the official openEHR Release-1.0.1 architecture. The PDF specifications should always be treated as being correct. The current status of the UML published here is draft. Various sources of difference from the official specifications exist:

Please report errors in these models with respect to the online specifications to the openEHR webmaster.


The UML models available from this page are derived from the official online PDF documentation (available here). Although the UML models here are tool-produced there are a number of limitations of the tool (and these seem to be common with most tools on the market today) that have affected the fidelity of the representation in various small ways:

  1. List<T>, Set<T>, Array<T>, Hash<T,K>, Interval<T> were all explicitly modelled, since they are not directly supported in UML.  All uses of these "assumed types" were made though new Primitive types in MD such as List<String>, employing Binding Dependencies.

  2. Associations are shown with far-end role names and Navigation arrows.

  3. Constraint statements are syntactically very similar to the syntax used in the specifications, and nearly always pass OCL syntax checks. Differences are :

In addition, there are imperfections in the model due to the fact that we have used version 9.5 MagicDraw, which does not support UML 2.0. The XMI output of the current tool is at version 1.0. Version 10 of the tool does support UML 2.0 and XMI 2, but upgrading is a non-trivial exercise, both of the model itself (semantics of UML 2 are quite different in some places) and of the publishing process we use to generate the online documentation.

Lastly, the data entry work of putting the specifications into the tool of course carries the possibility of error.


In the medium term, the following things will probably happen:


This Herculean task has been carried out by David Lloyd, from CHIME, UCL in London, for the openEHR Foundation.

$LastChangedDate$   $LastChangedRevision$