Update from Grahame (MnM call, 20061110) on constraint language:
- challenge finding a way to create a constraint language on the abstract datatypes when they're as abstract as they are
- OCL might actually possible, though it wouldn't be easy to use. Would bind to the RIM types rather than the D-MIM/R-MIM/HMD/template/etc.
- no significant progress on the HL7-specific constraint language discussed in May
- challenge translating between constraint formats (OWL, OCL, X-path/Schematron, custom HL7) because they have radically different reference models
- there's good potential for moving models back and forth between MIF, OWL and ADL (because they all operate at a similar level). Harder to find way to assert predicates
- integration with CTS is something few languages can handle easily (most systems think about codes as strings, not true concepts that are specializable)
- recommendation that we look at OCL again
What is needed
- write OCL spec (Can do by San Diego - need at least 1 quarter)
- get approval of specification (seek for May 2007 ballot as "DSTU")
- authoring environment (~ 1 person year, through HTC)
- author the actual constraints (need 1-2 hour tutorial)
- enforce (1-2 months)
- leverage constraints into existing designs (will happen over time)
Using OCL for Constraints
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.
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 templates specifications).
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).
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). 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.
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.)
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.
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 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.
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.