openEHR Release 1.0.1 UML Models

Introduction

This page provides access to a tool-based UML expression of the openEHR Release 1.0.1 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.

Status

Summary

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:

• 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

• may contain human errors

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

Detail

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 :
   

•         Class constraints use the Inv: keyword followed by an OCL-compliant expression
•         Function constraints use Pre: instead of require and Post: instead of ensure, or Inv:
•         Double quotes are changed to single quotes
•         Embedded spaces inside quoted strings used as parameters are changed to underscore
•         Multiple clauses inside one Constraint statement are supported using separate Inv: or Pre: or Post: keywords
•         Class constraints have names, Function constraints often do not.

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.

Future

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

• the models will be migrated fom MagicDraw 9.5 to MagicDraw 10
• the publishing scripts (currently XSLT) will be migrated to MagicDraw 10 (Python)
• due to this migration, an XMI 2 expression of the model will become available

Acknowledgements