This page provides access to a tool-based UML expression of the openEHR models. Two variants are available:
Browsable - good for online browsing and printing of single diagrams, classes etc.
Printable - good for printing the entire model (including diagrams), browsing in a serial fashion, and locating classes by name.
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.1 candidate (contains a small number of changes with respect to Release-1.0.) PDF specifications. The latter 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:
they contain some shortcomings due to using a UML 1.4 tool
limitations in UML itself to correctly represent object-oriented semantics occasionally affect the models
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:
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.
Associations are shown with far-end role names and Navigation arrows.
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: