Constraints Applied in Designs and Profiles

HL7 V3 is based upon RIM Derived models. These models, such as DMIMs, RMIMS, CIMs, and LIMs, express structural and vocabulary constraints on the class models defined in the RIM and the datatypes. Within these models there is a requirement for additional constraints that the structural and vocabulary language are not able to express.

Since this need was first identified, a number of languauges have been evaluated, including OCL, the datatype definition language used in the abstract specifications, another HL7 defined language, ADL, and XPath-based constraints. For a variety of reasons OCL is the only workable choice.

This document describes the rationale for the use of OCL, and then describes how OCL can be used with the HL7 models. Due to the nature of the HL7 modeling process, as defined by the HL7 Development Framework, application of OCL to these models is not enabled by the standard definition of OCL, and additional bindings and information is required, both to OCL and to the HL7 classes. By providing these definitions, this document enables the use of OCL as a constraint langauge by HL7 in the RIM derived models.

The fundamental goal is to enable the use of constraints in RIM derived models. This leads to the following requirements:

1. The language used should have a regular syntax and thorough semantic base

2. The constraints should be in a computationally ready form

3. The constraints should be meaningful to the modelers

4. The constraints should be useful to the implementers

5. The constraints should not be dependent on a particular implementation for the V3 models

6. The should be tooling (or the prospect thereof) to help with authoring and enforcing the constraints

In practice, these requirements, particularly the last requirement, suggest that the language should be some kind of industry accepted language, but this is not a primary requirement.

When the need for a constraint language was first identified, a short list of candidates was drawn up, with OCL at the top of the list. Since the need was first identified, a number of candidates have been considered. Because there were issues with using OCL, other languages were evaluated.

Using XPath based constraints has the apparent attraction of being immediately applicable. The model constraints and an XML instance can be fed into a validation engine and the constraints checked. However, this attraction is only apparent. As soon as another model is derived from the model that expresses the constraints, and the derived model is used as the basis for the XML, the constraints may no longer be valid as associations are renamed in the derivation process.

Though this is a general problem with any solution and is discussed in depth below in [Section], it applies most of all to XPath since using this as a solution implies that the evaluation engine will have no knowledge of the model derivation heirarchy, which is somehow involved in any solution to this problem.

In addition, XPath is not a suitable language with which to engage with the functionality of the datatypes. Finally, XPath is inherently bound to a particular ITS, and would not be applicable to any other ITS.

ADL is a powerful constraint language that is defined by the openEHR foundation and has been adopted by CEN and ISO as a constraint language for use in healthcare specifications. While ADL is a powerful constraint language, most of the ADL features overlap with the existing static model language. For the constraints that the static model does not provide, ADL provides a constrained version of OCL. Not only does this not address the unresolved issues with OCL, it introduces problems with resolving the overlapping functionality or defining alternates to the ADL syntax to avoid overlapping.

There are also issues mapping ADL to the datatypes. The abstract datatypes are based on interfaces and properties, where as ADL is based on classes and attributes. Though some ADL tooling exists, ADL is not maintained by a recognised SDO, and the prospects of tooling made suitable for HL7 use from within or without of the openEHR group appear minimal.

The Data Type Definition Language (dtdl) is the language defined in the abstract data types specification, and is the language in which the datatypes themselves are defined. As a language which is primarily a modeling language, it is imminently suitable for expressing datatypes constraints, but it is not so clear as to it's suitability for constaints outside the scope of the datatypes.

However dtdl is not widely understood, and while it has a thorough semantic base, things are often expressed in a rather round about fashion in order to keep the semantics rigorous and the inbuilt features lean. These are important features for the abstract specification, but render the language unsuitable (and unwelcome) as a choice for HL7's constraint language. In addition, there is no tooling support for this language (and no particularly like to be either).

It would be possible for HL7 to define a language perfectly suited to the role. In fact, a candidate language for this has already been defined and reviewed. Though the language was imminently suitable for use in expressing the constraints, and clear and natural for the modelers, as non-standard, the language had no proven base and tooling support. For these reasons, it was decided to avoid this approach. (The language definition can be found at [url], and may find use in implementations, as it is easy to understand and not too hard to implement.)

GELLO is effectively an adaptation of OCL for medical record querying. In the form that is defined, it offers nothing over plain OCL.

Although OCL does have some problems, it continues to be the best choice of the languages available. OCL is a well recognised standard supported by OMG, there is a number of commercial and open source implementations of tools for OCL, it is recognised standard for modeling constraints, and most OCL constraints are able to be executed by some sort of evaluation, or translated into executable code.

OCL is the best solution if the problems it poses can be resolved.

The definition of equality in OCL is "if self is the same object as object2". This differs from the definition of equals for HL7 objects, which excludes some properties from the definition of equality for an object, since two objects with different properties are not the same object. The HL7 definition is far more useful than the OCL one because it depends on the meaning of the objects rather than an implementation detail. The OCL definition does not discuss the (in fact most OCL users would be hard pressed to explain the difference because they mostly treat equals as if it behaved like the HL7 equals even though it doesn't).

Data types R2 defines a property on ANY called identical, which maps directly to the concept of equals in OCL. This is required in order to make constraints on uniqueness in Sets (DSETs in R2), because SET uniqueness constraints iterate the set twice, and enforce rules about the differences between any two different objects.

We could map OCL = to the HL7 identical routine and require that HL7 OCL users use .equal() rather than equal. However since the only use of the identity test in HL7 constraints in when specifying set uniqueness constraints, and the HL7 equals is otherwise appropriate, it is both more consistent and simpler for users if we map OCL = to the HL7 equal() property. Set uniqueness constraints must use .identical().

Note: Comment requested: We could define infix operator == for identical(), but my OCL engine reserves this for case insensitive comparison of strings, which is pretty useful, though the semantic basis for case insensitive comparison is weak].

In the abstract semantic model, there is really no such thing as a null object, only an object that is represented by a flavor of null. Though the word null is used in both contexts, there is a real difference in meaning.

In OCL, OclUndefined is the singleton instance of the type OclVoid which is a supertype of all other type. In the HL7 semantic model, the domain of nullFlavors is a generic domain extension of every other domain, including InfrastructureRoot itself.

For this reason, the OCL concept of null is not invoked when using OCL constraints in HL7 models. Specifically, instances of RIM classes or datatypes are never oclIsUndefined = true - they are always "Defined" in the OCL sense, though very often their nullFlavor will be NullFlavor.NI.

Note: One consequence of this is that care must be taken enforcing invariants inside an OCL evaluation engine. Although all the OCL constraints defined by this specification are executable, care must be taken to step in and stop executing the constraints on ANY itself, since these invariants never terminate because of the recursive nature of the definition of nullFlavor.

The OCL typing syntax is based on the UML Package syntax. The package names are as described in the MIF [reference!]. The rim and datatype packages are implicitly imported into every other V3 model. This means that any references to types defined in the RIM or the datatypes do not need to fully package qualified, just the simple name of the type can be used.

In OCL, datatypes are known by their shortname (the standard througout the rest of HL7 V3). In V3 generics are indicated using the syntax Type<Parameter>, which differs from the OCL syntax Type(Parameter). Both syntaxes are acceptable and have the same meaning.

The HL7 types defined in the RIM and v3 data types are properly defined types in the OCL sense, and they can be used as the types of parameters and variables. For instance, it makes sense to make the constraint Observation.value.oclisKindOf(REAL). x.oclIsKindOf(T) is a shortcut for saying x.dataType.imples(T). Therefore TYPE maps directly to the concept of type in OCL. When used against RIM derived models, any TYPE reference has the properties .shortName and .longName, though there doesn't appear to be any practical use for these.

The abstract datatypes derive all of the semantics from the definitions of ANY, TYPE, and BL. While this works really well in the abstract definitions, it presents a little bit of a problem when using OCL with the abstract datatypes. Specifically, OCL defines a set of prebuilt types calle the "Kernel Types" and these have features that are integrated with the syntax of OCL itself. The features of interest are:

• Literal values for boolean, int, string and real
• Infix operators
• Iterators for collections

The data types define the use of generic type extensions. These are generic types that extend their parameter rather than expressing properties of the type T (though they may do this as well). Generic Type Extensions are a challenge to implement (full implementation relies on Aspect Orientated Programming, and is outside this specification).

When OCL is used against RIM derived models, these generic type extensions work as defined in the data type specification. For instance, the value x of type PPD(REAL) has the property standardDeviation defined on PPD. In addition, x.oclIsKindOf(PPD) and x.oclisKindOf(REAL) are both true. Any class is a generic type extension if it carries the stereotype "mixin".

Flavors are named constraints on existing data types. Flavors can masquerade as data types but aren't true datatypes. For a value x of type CE.None, x.oclIsKindOf(CE), x.oclIsKindOf(CD), and x.oclIsKindOf(CE.None) are all true. What is different about flavors is that for x, x.oclIsTypeOf(CD) is true.

Note: In this sense, flavors are actually similar to generic type extensions. They behave rather similarly, but there is an alias for the combination. In the case above, CE.None is actually a generic type extension for CD, but instead of calling the combination CE.None(CD), it is simply called CE.None. Other than this aliasing, flavors are simply generic type extensions.

Note that for flavors, oclIsKindOf checks whether the type of the object is declared to be the flavor, not whether the flavors rules are actually met. To check that the instance conforms to a flavor, type cast the object to the flavor. If the result is non-Null, then the flavor's constraints are met. For example, if x has a type of CD, and a co-occurence constraint exists that under some circumstance y, x must be a CE.None, then this is the OCL to express this:

  inv: if y then x.oclAsType(CE.None)

When writing constraints, it is useful to be able to build datatypes in order to write useful constraints. It is generally true that any constraint an be expressed without needing to create any types, but these constraints can be rather long, indirect, and unwieldy. For this reason, we define a class factory that can create datatypes and RIM classes.

Note: It has been claimed that OCL is not able to create instances of classes, but this is not true. What OCL cannot do is change the existing system. Any classes created during the evaluation of OCL statements will cease to exist when the OCL statement evaluation is complete.

The class factory expresses one or more factory routines for each type or RIM class.

For datatypes, there may be routines to create the type from a literal, or routines to create the type that takes a specific list of parameters, or there may be a routine that takes a tuple.

All the RIM class factory methods take a tuple as a parameter. It must contain a named member for each attribute that should be populated on the class. Any attributes not represented in the tuple will be assigned a value of NullFlavor.NI. If the mandatory attributes are not represented in the tuple and they are not assigned a default value in the RIM, a partially valid object will be created, and it will have the NullFlavor OTH assigned as well as all the provided values.

   -- literal is abstract literal unless otherwise defined 
   BL - use literal
   ED new ED(Tuple t); -- named properties, including NullFlavor
   ST - use literal
   SC newSC(literal l, CV code );
   UID newUID(literal l);
   OID newOID(literal l);
   II newII(ST root[, ST extension[, CS scope, CS reliability]]]);
   TEL newTEL(literal l[, literal use[, GTS usablePeriod]]);
   EN newEN(literal l[, literal use[, IVL<TS> validTime]]);
   AD newAD(literal l[, literal use[, GTS usablePeriod]]);
   CD newCD(literal l); -- using terminology literal form defined below
   CD newCD(tuple); -- named properties (ones with no parameters), including NullFlavor
   CR newCR(CD name, CD value, BL inverted);
   CS newCS(literal l); -- using terminology literal form defined below
   CO newCO(literal l, INT v); -- using terminology literal form defined below
   TS newTS(literal l);
   INT - use literal
   REAL - use literal
   PQ newPQ(literal l);
   MO newMO(literal l);
   RTO newRTO(literal l);
   RTO newRTO(QTZ n, QTZ d);
   LIST newLIST(literal l);
   LIST newLIST([ANY i[, ANY i]n]);
   BAG newBAG(literal l);
   BAG newBAG([ANY i[, ANY i]n]);
   DSET newDSET(literal l);
   DSET newDSET([ANY i[, ANY i]n]);
   SLIST newSLIST(QTY origin, QTY scale, LIST<INT> digits);
   GLIST newGLIST(QTY inc, INT period, INT denominator);
   IVL newIVL(literal l);
   IVL newIVL(QTY q);
   IVL newIVL(QTY low, QTY high);
   PIVL newPIVL(literal l);
   EIVL newEIVL(literal l);
   QSD newQSD(QSET n1, QSET n2);
   QSI newQSI(DSET(QSET(ANY)) terms);
   QSU newQSU(DSET(QSET(ANY)) terms);
   HXIT newHXIT(ANY t, IVL<TS> validTime[, II controlAct]);
   PPD newPPD(ANY t, QTY stdDev, CS type);
   UVP newUVP(ANY t, REAL probability);
   
   -- you can also build DSET, LIST, and BAG using OCL collection syntax
   -- no constructors for flavors - just create a conformant instance of the real type

   Entity newEntity(Tuple t); 
   -- etc for every RIM class except infrastructureRoot
   
   -- if any of the parameters are null or have a nullFlavor, then the 
   -- Factory will construct a class of the desired type with the correct nullFlavor.

The types in the RIM and datatypes define only the properties required to clarify the semantic definitions of the types. There are a uumber of extra routines that are useful to complete the set of functions used in OCL.

This table summarises the OCL types and properties, and their equivalents in the V3 abstract datatypes. Where the types or properties have equivalents with different names, either name is acceptable and the meaning is the same in either case. However the V3 names are always preferred. Operation names in italics are defined in the abstract datatypes. Functions defined here adorn the V3 type within the OCL context. Their functionality is defined by the OCL specification.

The following table defines additional decorations that are useful for making real world constraints.

A number of the datatype properties and class attributes are bound to defined terminologies, or vocabulary domains. In the context of OCL, there is a class type for each vocabulary domain, and there is a one static method for each concept in the domain. The static method is identified by the code for the concept, and it returns a CD with the correct code, codeSystem, and codeSystemVersion populated. The displayName property will also be populated. In addition, each domain also has one extra method ST oid; which returns the oid of the code

As an example these constraints are valid:

• Act.classCode implies ActClass.OBS - classCode must be OBS or a specialization thereof
• Act.code.hasImplication(ActCode.DOSE) - somewhere there must be some code that implies a dose problem

Some features of OCL are not relevant when used with V3 models. This includes enumerations, messages, pre- and post-invariants, OclMessage, and OclInvalid. (This may change when we get further into dynamic models.)

allInstances is a property that is defined for use in HL7 V3 constraints, but constraints that use can generally not be evaluated, so users should avoid this if possible.

The Static Model diagrams represent a particular challenge to the use of OCL. OCL is a strongly typed language. Static models are widely regarded as Class Diagrams, and they do appear like class diagrams. The key to making the typing system work in this context is to understand that the Static models - other than the RIM and the data types - are not defining class models. This is not to say that there are not circumstances where it is useful to consider them as class models, but that in the context of OCL, we understand the static model diagrams to be visual declarations of constraint patterns on pre-existing RIM classes. The whole constraint methodology is geared towards ensuring that this is true, and it is possible to convert whole static models to OCL, which is not possible with genuine class models.

So static models are declarations of constraints on valid RIM graphs. The type of the object, when using oclIsKindOf, is the underlying RIM class type. The name on the "class" is the name of the constraint pattern. This sorts out the typing issue which is of great importance to OCL implementers but mainly an irritation for everyone else.

In order to make the OCL work in a practical fashion, we define a new binding technique for OCL (as allowed by the OCL standard itself). In this, we can associate constraints with a class that conforms to a pattern of constraints as named in an HL7 static model. So for this model:

The formal constraint in OCL would be

context BirthPlace
  inv: birthplace.name.isNull implies (addr.count > 0 and not addr.isNull);

Actually the words "addr must be valued" are a little ambiguous. The OCL constraint is not ambiguous, which demonstrates the advantage of formal statements.

CMET references represent something of a problem, because of type names. Ideally, we'd like to refer to the classes in the CMETs - at the very least, the classes at the entry points, by simple names, rather than having to invoke by a full path name, since the full path name is rather long. We can do this by importing the CMET models into the static model, or at least asserting that this is assumed to be true. The problem with this is that there is no guarantee that the CMET class names will be unique. In the case of a name clash (if it is realised), then the fully qualified package name must be used to solve the ambiguity.

Todo.

Todo.

Todo.