UML Implementation Technology Specification - Data Types

The Abstract Data Types specification defines the semantics of the HL7 Data Types, which are the foundation of all HL7 Version 3 artifacts, including the Reference Information Model (RIM), Version 3 messaging artifacts, and the Clinical Document Architecture (CDA). The Abstract Data Types specification includes a Unified Modeling Language (UML) diagram that presents the semantic declarations of these data types in a standard UML fashion.

This UML ITS implements the semantics of the Abstract Data Types specification using UML in such a way that HL7 data types are mapped into the core UML and OCL kernel data types where such mappings are appropriate. In addition, this representation uses only established object-orientated formalisms. Since this specification shows how to implement the HL7 data types using the UML core data types and methodology, this specification is an ITS for the data types in UML

The desired outcomes from this specification include:

• A formally correct UML declaration of the HL7 Data Types

• Enable the use of Computer-Aided Software Engineering (CASE) tools for model validation, code generation, instance validation, etc

• Enable these same outcomes for downstream HL7 UML artifacts such as the RIM and message structures

This specification is based on the UML 2 standard. The UML version 2 is not fully released but the parts that this specification rests on, primarily the OCL part, have been released in their final form by the OMG [].

The abstract data types specification includes many invariant statements. Some of these invariant statements are used to make statements about the mathematical functions of basic operations such as multiplication, etc. A number of the statements are not relevent or not reproducible in OCL due to differences in approach between the 2 langauges. This specification attempts to reproduce only those OCL statements that have practical implications in HL7 usage.

In addition, the abstract data types specification includes many statements concerning ST literals and semantic meaning, which also are not reproduced in this specification. Readers should always consult the abstract data types specification for a full description of the behavior of the data types.

All classifier and operation names are case sensitive.

OCL declares a number of operations as infix operators. This list of operations applies to any HL7 types, so that if such an operation is declared on a tpye, it can be used as an infix operator. For example, the abstract specification for the HL7 INT type includes a plus() operation. In this specification this is renamed to the OCL functional equivalent operation, which is "+", so it is valid to write a + b = c where a, b, and c are HL7 INT types

In the OCL statements all operations used are shown with () according to the formal OCL language. In some uses and OCL implementations these are not required

The HL7 Data types specification defines flavors of Null. Any data type may have a flavor of Null and at the same time some of it's properties may have a value that still has significance. OCL defines the concept of void which maps to the application concept of a "null" or "nil" object. Any object may be void, in which case any attempt to reference its properties will also result in void. Although both UML and the HL7 abstract data types define the concept of a null value with appropriate 3-valued logic, the intent, implications and possible implementations clearly differ.

In choosing how to implement the data types and deal with flavors of null, the primary requirement was that an HL7 data type could continue to have flavors of null, but any attempt to access the HL7 data type at the OCL level would generate a void type if the HL7 type had a null value.

The selected implementation meets these requirements. The pattern of implementation for HL7 types with a direct equivalent in OCL is as follows:

• Declare the HL7 type using the shortname and generalization from the abstract data type specification

• Declare all properties of the OCL type in the HL7 type, but with HL7 type equivalents for parameters and return values instead of OCL types

• Add any missing operations or semantics that are declared in the HL7 type but not in the OCL type

• Add an agreggation with cardinality 0..1 to the OCL type

• Add a constraint that states that when the HL7 type is Null, then the aggregated OCL type is void

Note that this may mean that the UML "implementation" of an HL7 data type may end up with more properties than in the abstract data type specification

The OCL Collections Sequence, Bag and Set map directly to the HL7 Data Types LIST, BAG and SET. There is no HL7 equivalent for OrderedSet. Any operation valid for an OCL collection is also valid for the HL7 Collection types. An abstract type "COLL" has been introduced to match the OCL type collection.

There is a subtle difference in semantics between the OCL type "Set" and the HL7 SET. The HL7 SET can include non-discrete elements, but the OCL type can't. This specification does not deal with this issue, and implementers should be aware of this issue.

Not all the correctness constraints from the OCL specification concerning the collection operators have been reproduced in this specification but they should be assumed to apply

The OCL Specification does not provide any guidance on the question of whether all UML parameterised types should be treated as collections. For the purposes of this ITS, any parameterised types are treated as collections by OCL

Following the abstract specification, many declarations are recursive, with no explicit termination of the recursion. For example, ST has an operation language() : CS. Type CS has an operation code() : ST, etc. Where implementations are invoking invariants on all instances as they are encountered, this recursion will never terminate. Real world implementations will need to manage this recursion in some appropriate fashion.

The Abstract Data Types specification declares some data types as generic type extensions, also known as mix-ins. Mix-ins are generic data types that specialize the type of their parameter rather than containing a value of the parameter type. While this is a recognized pattern in object oriented programming, there is no standard notation for depicting this behavior in the UML. In addition, this is not implemented in many current object oriented programming languages. For this reason, a property expressing the type has been used instead of a pure mix-in.

The mix-in types defined in this fashion have a flavor of null, but since this does not exist in the abstract specification, it should not carry a null flavor

As described above, these mix-in types are treated as collections by OCL. These types carry an implicit constraint size() = 1; the have one and only one element of type T

It is intended that this notation should be suitable for code generation tools. To that end, an XMI file including a full declaration of the types will be included with future ballots.