Comparison of HL7 V3 MDF and UML Elements
February 15, 2002
Tony Mallia
Principal Consultant
800 W. Cummings Park, Suite 2000
Woburn, MA 01801
Tel 781 932-9925 x243
Concept
Class
Attribute
Identification
UML
A class is a description of a set of objects that share the
same attributes, operations, methods, relationships, and
semantics.
Objects do not contain values corresponding to
BehavioralFeatures or class-scope Attributes; all Objects of
a Class share the definitions of the BehavioralFeatures from
the Class, and they all have access to the single value stored
for each class-scope attribute.
An attribute is a named slot within a classifier that describes
a range of values that instances of the classifier may hold.
In the metamodel, an Attribute is a named piece of the
declared state of a Classifier, particularly the range of values
that Instances of the Classifier may hold.
UML class instances are assumed to have an internal
identifier as part of instantiated objects and therefore do not
need to have an explicit identification attribute. There is no
problem using state attributes to provide labeling.
HL7
A class is an abstraction of things or concepts that are
subjects of interest in a given application domain. All
things or concepts subsumed under a class have the same
properties and are subject to and conform to the same
rules. Classes are the people, places, roles, things, and
events about which information is kept. Classes have a
name, description, and sets of attributes, relationships,
and states.
The instances of classes are called objects. Where classes
represent categories of concepts, people and things,
objects represent the individual things themselves.
Class attributes are the core components of the
information model. The attributes are the source for all
the information content of HL7. The majority of
attributes are descriptive attributes that depict aspects of
classes that are important for communication between
healthcare systems. Besides the descriptive attributes
there are three special kinds of attributes in the
information model:
 identifier attributes
 classifier attributes
 state attributes
Identifier attributes can be used to identify an instance of
a class. Sometimes more than one attribute may be
needed to identify an instance of a class. The identifier
attributes always have a value. The values of identifier
attributes are unique among all instances of the class.
Since identity is static, values of identifier attributes
never change. Identifier attributes are assigned the
Instance Identifier (II) data type and generally have a
name ending in "-ID".
Comments
UML has a constraint
that all objects of a
Class have the same
semantics. This is a
fundamental conflict
when using RIM
classes and Class_cd to
specify semantics.
UML only allows
attributes to be state.
The Classifier attribute
is closer to reflective
property on an actual
class.
Identifier attributes
would be considered
regular UML attributes.
Concept
Generalization
UML
A generalization is a taxonomic relationship between a more
general element and a more specific element. The more
specific element is fully consistent with the more general
element (it has all of its properties, members, and
relationships) and may contain additional information.
Association
An association defines a semantic relationship between
classifiers. The instances of an association are a set of tuples
relating instances of the classifiers. Each tuple value may
appear at most once.
Association Ends
An association end is an endpoint of an association, which
connects the association to a classifier. Each association end
is part of one association. The association-ends of each
association are ordered.
Starting from a specific object, we can navigate an
association on the class diagram to refer to other objects and
their properties. To do so, we navigate the association by
using the opposite association-end:
object.rolename
When a rolename is missing at one of the ends of an
association, the name of the type at the association end,
starting with a lowercase character, is used as the rolename.
If this results in an ambiguity, the rolename is mandatory.
This is the case with unnamed rolenames in reflexive
associations. If the rolename is ambiguous, then it cannot be
used in OCL.
HL7
A generalization relationship is a connection between
classes (as opposed to instances). The generalization
relationship expresses that one class (called the
superclass) is a generalization of another class (called the
subclass). Conversely, the subclass is a specialization of
the superclass. Instances of a subclass are also instances
of the superclass. Conceptually, the superclass does not
have a separate related instance to the instance of the
subclass, although implementation-wise this may be
different. Conceptually, generalization relationships are
associations between classes, not between instances.
Comments
Rolenames appear to be verbs.
OCL strings do not
make sense when
constructed from HL7
RIM associationend
names
Concept
Extension
Mechanism
Constraints
UML
The UML provides a rich set of modeling concepts and
notations that have been carefully designed to meet the
needs of typical software modeling projects. However, users
may sometimes require additional features beyond those
defined in the UML standard. These needs are met in UML
by its built-in extension mechanisms that enable new kinds
of modeling elements to be added to the modeler’s
repertoire as well as to attach free-form information to
modeling elements. The principal extension mechanism is
the concept of Stereotype. It provides a way of defining
virtual subtypes of UML metaclasses with new
metaattributes and additional semantics.
A fundamental constraint on all extensions defined using the
profile extension mechanism is that extensions must be
strictly additive to the standard UML semantics. This means
that such extensions must not conflict with or contradict the
standard semantics. In effect, these extension mechanisms
are a means for refining the standard semantics of UML and
do not support arbitrary semantic extension.
In order to write unambiguous constraints, so-called formal
languages have been developed. The disadvantage of
traditional formal languages is that they are usable to
persons with a string mathematical background, but difficult
for the average business or system modeler to use.
OCL has been developed to fill this gap. It is a formal
language that remains easy to read and write.
OCL is a pure expression language; therefore, an OCL
expression is guaranteed to be without side effect. When an
OCL expression is evaluated, it simply returns a value. It
cannot change anything in the model. This means that the
state of the system will never change because of the
evaluation of an OCL expression, even though an OCL
expression can be used to specify a state change (e.g., in a
post-condition).
HL7
HL7 is already a metamodel in the M2 space
Constraints may be specified in the RIM, D-MIM, RMIM or HMD. If specified in the RIM, the constraint is
relevant for an attribute in all messages containing the
attribute. If specified in the D-MIM or R-MIM, the
constraint is specific to all of the messages derived from
that D-MIM or R-MIM. Constraints may also be
specified within the HMD where they can be made
specific to a particular set of message structures.
Constraints specified in a higher level (e.g., the RIM)
may be further constrained in a lower level (e.g., D-MIM
or HMD). However, the subordinate constraint must
conform to the constraint on the higher level. Higher
level constraints cannot be undone on a lower level.
Comments
HL7 is therefore by
definition a conflict
with UML unless the
semantics and notation
are word for word with
UML or add non
conflicting extensions.
Even then these
extensions would
require special tools to
process them.
The Profile mechanism
is the way to maintain
UML compliance with
extensions and use
existing tools.
Concept
PowerType
Mood
UML
«powertype» Specifies that the classifier is a metaclass whose
instances are siblings marked by the same discriminator. For
example, the metaclass TreeSpecies might be a power type for the
subclasses of Tree that represent different species, such as
AppleTree, BananaTree and CherryTree.
The closest to a Mood in UML is the Generalization
Discriminator
HL7
Classifier attributes are used in generalization hierarchies
to indicate which of the specializations is the focus of the
class. The classifier attribute is placed in the superclass
and contains a code value declaring the subclass type.
There may be multiple classifier attributes in a
superclass, indicating multiple independent
generalization hierarchies. In a fully enumerated
specialization hierarchy, classifier attributes are needed
in order to specify the specialization class in a message.
The classifier attributes are a critical aspect of the classes
forming the backbone of the RIM (Entity, Role, and
Act). The classifier attributes are named "Class_cd". The
classifier attributes provides a great amount of flexibility
and extensibility in the information model. The
vocabulary domains for classifier attributes include an
entry for each specialization of the backbone class. For
example the vocabulary domain specified for
Entity.Class_cd includes Living subject, Organization,
Place and Material. The vocabulary domain may also
include entries that are not explicitly expressed as classes
in the model. For example, Group is a valid Entity class
code (or specialization of entity) but does not appear in
the model as a class. This provides the flexibility and
extensibility capability.
Comments
It is assumed that
Stereotype is a better
alternative for RIM
classes when aligning
with UML.
Mood_cd defines semantics
As it stands, Mood
appears to conflict with
UML class semantic
rules.
It is possible that
mood_cd becomes a
vocabulary constraint
for specialization
discriminator
Concept
Clone
Stereotype
Vocabulary
UML
There is no direct equivalent to the clone other than making
a copy into a different namespace (e.g. package). The two
classes are then semantically independent.
A stereotype is, in effect, a new class of metamodel element
that is introduced at modeling time. It represents a subclass
of an existing metamodel element with the same form
(attributes and relationships) but with a different intent.
Generally a stereotype represents a usage distinction. A
stereotyped element may have additional constraints on it
from the base metamodel class. It may also have required
tagged values that add information needed by elements with
the stereotype. It is expected that code generators and other
tools will treat stereotyped elements specially.
In UML vocabulary can be represented in a number of
different ways:
<<Enumeratiom>> of literals,
Domain.allinstances set of Domain codes
OCL declaration - let fruit = Set { ’apple’ ,
’orange’, ’strawberry’ }
OCL can apply at the Class or Instance level of the model.
At the class level it would be used as a constraint in the
Stereotype to allow only certain names in the model (e.g.
participation_cd)
HL7
Like the RIM, the D-MIM's building blocks are the RIM
classes and their attributes. However, in the D-MIM, the
same class may appear multiple times in a diagram with
different constraints or associations. These multiple
instances of the same class are referred to as 'Clones'. For
example, a D-MIM might have numerous clones of the
Participation class, some for 'Author' participations,
others for the 'Subject' participation, etc. Other classes
may not appear at all. Only those classes, attributes and
relationships that are required to build the messages for a
particular domain are included in the D-MIM.
When the Act, Entity and/or Role classes are included in
a D-MIM, the class_cd attribute as well as its value
always appears as the first attribute in the class. The
class_cd attribute identifies the Vocabulary neumonic or
domain name associated with the class.
Comments
The closest thing that
exhibits similar
function might be the
application of a
Stereotype to a class.
A vocabulary domain is a constraint applicable to code
values. Vocabulary domains define the set of possible
values for a code value. Hence, vocabulary domain
constraints are largely defined in terms of sets and
subsets rather than using predicates. The data types code
value and concept descriptor, without a domain
specification, have an infinite domain that includes all
concepts that man can ever conceive of. In other words,
code values are useless without some guidance provided
by constraints to their value set.
Multiple alternative to
be considered. There
are no real conflicts
here. It would be an
advantage to have the
dictionary contained
within the UML model
as enumeration or
constraint.
This is all part of
alignment options to get
HL7 compliant in UML