Using OCL with Static Models

Introduction

OCL is an adjunct expression language suitable for use with UML. The expression language can be used for expressing queries and constraints.

This document describes how OCL is used with static models, using OCL 2.0 (see OCL v2 specification). This document does not describe OCL or how it works, it only deals with how OCL 2.0 is used to express constraints in HL7 V3 Static Models.

See also: Constraint Language

Binding to Static Models

HL7 Static models are not strictly UML diagrams. Although they have some similarity in presentation, they are actually statements of constraints against a formal UML model, which is the RIM. (This is discussed in more detail elsewhere (in the template specification).

In a static model, each of the "clones" is actually a statement of constraints on a properly defined RIM class (properly defined in the RIM sense). OCL constraints express additional rules that apply to the clone. In HL7 static models, OCL statements are applied to the clone - in other words, OCL statements are applied to the RIM class only when it is subject to the constraints defined in the clone.

In order to use OCL with HL7 static models, a new binding mechanism must be described by HL7 (This is an expected extension to the OCL langauge). The syntax for this is simple:

context [Clone Name]

(This looks similar to the standard OCL binding syntax: context [Class Name] In the standard OCL binding syntax, the constraints are bound to the class, and may be applied to the class at any time. The HL7 binding syntax only applies the constraints in a narrowed context.)

Typing considerations

The type of any clone class is the type of the underlying RIM class. This is important for the inbuilt methods oclIsKindOf() etc, but these methods are not expected to be important for HL7 use.

Data Types

The abstract datatypes are too abstract for use with HL7. The core issue is that the actual content of the types, particularly strings and simple types such as INT, BL, etc is never surfaced in a way that can be addressed by OCL. The best solution is to write the OCL against the UML datatypes, which provide a custom binding between the OCL kernel datatypes and the HL7 datatypes.

Gello

Gello is a subset of OCL which is used for developing queries. Gello is (probably) a proper subset of OCL use as described in this document.

CTS interface

One key element of HL7 models is a strong dependence upon terminologies. The value of the code element of a coded datatype is not a string that stands on it's own, but a reference into a predefined terminology. In order to facilitate proper constraint mechanisms on terminologies, a simplified CTS interface will be defined to support constraints on coded datatypes.

Example

Here is an extract from the patient admin D-MIM:

The constraints become

 context EntityChoiceSubject
  inv: (not determinerCode.implies("QUANTIFIED_KIND")) implies (quantity.isNull)

 context NonPersonLivingSubject
  inv: id.hasContent or name.hasContent

 context Person
  inv: id.hasContent or name.hasContent

So these last 2 could be summarised as

 context EntityChoiceSubject
  inv: id.hasContent or name.hasContent

 context Group
  inv: id.hasContent or name.hasContent

 context BirthPlace
  inv: (birthplace.isNull or not birthplace.name.hasContent) implies address.hasContent

-- For Lee

 context Person
  inv: name.parts->count(type.implies("FAM"))) <= 1