UML ITS Tutorial

Grahame GrieveCfH / Jiva / HL7 Australia

co-chair Infrastructure & MessagingProject Lead, Eclipse OHF

Agenda

• Introductions / Background

• UML ITS Fundamentals

• A Model

• Unresolved Issues

• Where to now?

Why the UML ITS

• UML based representation of HL7 Models• A work in progress.

– RIM is “pure” UML– Datatypes are not– Models (RMIMs etc) are not

• “pure” UML means:– Standard o-o concepts– No stereotypes

CfH Implementation

• Message Simplification task force outcomes– Low Instance to other data ratio– Complex Structures– Unstable Wire Format– Unable to code generate productively

V3 Background

• 3 level modeling– RIM– Static Models– Templates

RIM

RIM: Interoperability

• The semantic requirements embedded in the RIM force models to be rigorous

• Modelers must carefully analyse their concepts and define them against the RIM classes and terminologies

• This provides a solid base for shared understanding

RIM Structural Codes

• A pattern over the top of the Class based RIM

• Each class carries key coded attributes that independently carry semantic meaning

• Can ignore type information (or not know it) and rebuild implicit meaning from the representation of the instances

Static Models

• A set of constraints on the RIM

• Presented as a Class Diagram

• Not proper UML– Clones– Choices– CMET mixins

Templates

• Express custom requirements on Models

• Differences between Static Models & Templates:– Templates are represented differently in the

instance– Templates are intended for implementation– Templates may be incomplete

Incompleteness

Types & Templates

• Template: A set of constraints on a type

• Type: A set of constraints on a type

• An artefact “conforms” to a template

• An artefact “is” of a type

• Type is a concept with exclusivity

Types & Templates

• So HL7 instances conform to many models at once

• One can be the type

• it’s derivation chain are super-types

• Others are templates

RIM

DIM

RMIM

MT

Template

Template

Template

V3 Processing Approaches

• V3 presents a rich plethora of options for processing instances– Structural code based– RIM Type based– Static Model based– Template based

• Many implementations combine these

V3 Processing Approaches

• Generic Processing– Process every instance without knowledge of

the static model upon which it is based– Uses structural codes to infer meaning

• Specific Processing– Processes instances based on the static model– Generally hand coded for the model

XML ITS issues

• Surprise attributes

• Representation transforms

• Datatypes complexity– Mixins– Clever data formats

• No final representation

UML ITS

• Goal: Give implementers what they expect

• What’s that?

UML ITS

Industry norms:

• Standard Object (o-o) Representation

• WYSIWYG – formally correct model of the wire representation

• Support for Model Driven Development

UML & XML

• UML is the preferred notation for modeling

• XML is the preferred format for interchange

• Need a tight relationship between UML and XML

UMLModel

XSDSchema

XMLWire

Fomat

XUM

• XUM – XML UML Model• A XUM is a model that describes, as both a UML

class diagram and an XML schema, an implementable form of a V3 instance based upon an Static Model. The XUM describes a particular wire format, and is also useful in terms of commercial tools use and ease of implementer understanding. The UML and XML forms of the XUM should be as isomorphic as possible.

XUM

• A definitions of classes with attributes and associations

• Associated implementation constraints and enumerations

• Artefacts and Constraints describe a static model as completely as possible

• Presented as a UML Model and an XML Schema (W3C)

UML Diagram Rules

• Classes with Attributes• Parameterized classes with one class parameter. All

parameterized classes are collections • Constraints using OCL in notations attached to the class. • Generalization associations • Named composition associations (represented as by value

in XML) • Named associations (represented as by reference in XML) • The stereotype <<enumeration>> for enumerations • The stereotype <<io>> for marking entry points. • The inbuilt types from the OCL 2 kernel, or any types

found in other XUMs which must be explicity accessed as UML packages

XSD Schema Rules

• Complex Types• Element and attribute definitions• Global elements for entry points• Simple Types for enumerations• Sequences & Choices• Schematron rules for constraints• The inbuilt types from the schema standard, or any

types found in other XUMs which must be explicity imported as schemas

• Comments in AppInfo annotations

XUMs are normative

• Current XML ITS schemas are not normative – they are wrong

• Accept that the wire format needs to be formally & correctly documented

• Make the wire format driven by the XUM model

Examples

• PdsAllocateNhsNumberRequest (PRPA_MT100101UK12)

• CareEventReport (REPC_MT150007UK05)

XUM Reference Package

• Enumerations• Data types

– ANY

– BL

– ED

– CD

– EN

– SET

– IVL

XUM Summary

• XUM – representation of what goes on the wire

• Suitable for– Documentation– Automatic processing– Model Driven Development

• Allow implementers to get started quickly

Unresolved Issues

• What transformations are performed when preparing the XUM?

• How well do we solve the problems?– Low Instance to other data ratio– Complex Structures– Unstable Wire Format– Unable to code generate productively

Are definitions required?

• The most significant question of all is:“Do you need the definitions to read the instance?”

Definitions Required

If definitions are required:• Instances define themselves in terms of reference

to the definition – Names need not be RIM or Static model names– Definition must map the names to RIM concepts

• Instances can omit anything found in the definition

• Instances are smaller• You must read or “know” the definition to author

or understand the instance

Definitions Not Required

• If definitions are not required

• The instance must carry everything that defines it (by reference to the RIM)

• Instances will be larger (fixed values)

• Names must be RIM Centric

• Applications can understand the instance without consulting the definitions

Definitions Required?

• XML ITS is in the middle– Implicitly to allow reading with definitions– But omits fixed and default values, so definitions are

required – unless you have PSVI• JavaSIG – uses the definition to construct a RIM

graph, then ignores it• Eclipse – will allow either• Most implementers already have an architecture

based around XML tools, which don’t provide services like this

Definitions Required

• NHS project focused on moving as much as possible into the definitions

• “Interoperability is just a definition away”

UML ITS R2: Concepts

ImplementableUML Model

AutomatedTransforms

ConformanceProfile

Schemas (XML ITS)

AutomatedTransform

Msg

Msg

AutomatedTransform

HL7 Model

AnalysisModel

ManualMapping

*

Example

Example

ExampleAnalysis Model RMIM

NHS number subject.patientRole.id Sensitivity Indicator subject.patientRole.confidentialityCode Death Status subject.patientRole.subjectOf2.DeathNotification.value Date Of Death subject.patientRole.patientPerson.deceasedTime Gender subject.patientRole.

patientPerson.adminstrativeGenderCode Date of Birth subject.patientRole. patientPerson.birthTime Serial Change Number pertinentInformation.patientSerialChangeNumber.value Name.* [outstanding issue: we believe that names and Addr.* addresses are a special case that needs special handling.] Care Provider.Type ...patientCareProvision.code Care Provider.Provider Code

...patientCareProvision.healthcareProvider.id

Care Provider.Business Effective Dates

...patientCareProvision.effectiveTime

Comment.Value [missing – demonstrates the value of the process] Comment.Type …subjectOf1.value [based on narrative not shown here] Comment.Change Date …subjectOf1.effectiveTime Comment.Comments …subjectOf1.pertinentSupplementaryComments.value

Example

Example

Problems

• Real Analysis Models turned out to be unsuitable– Often have significant transforms between

Analysis and Communication– Do not address implementation issues

• NHS Implementers do generic processing, and can not easily consult the definitions

• Clinical Content was less malleable

Choice

Domain Project

Generate Implementable

Model

Level of AbstractionRMIM/RealmRMIMDomain / Realm

Generate Implementable

Model

Generate Implementable

Model

Generate Implementable

Model

Generate Implementable

Model

More Less

Level of AbstractionAbstractMore Interoperable

SpecificLess Interoperable

RMIM Reshaper

• Robert Worden has developed an RMIM reshaper

• It has been illuminated by the UML ITS analysis

• We expect that it will become more aligned with the UML ITS work

• May be part of the basis for exploring the pros and cons of reshaping

Choice

• Administrative – use reshaping techniques

• Clinical – leave as RIM

• No clear boundary

• Real price is in clinical content

• ? Still undecided how to progress

Unstable Wire Format

• Existing format is unstable because:– Constraints are represented in the instance– Constraints change between models and

versions because the concepts are described differently

– The concepts themselves change much less, and more slowly

Wire formats & SOA

Control the operation of your SOA with BPEL

Wire formats & SOA

Control the operation of your SOA with BPEL

What’s this?

Standardisation of data models & formats enables the SOA

Flocks of servers share the same document format

Wire formats & SOA

• HL7 has domain harmonised models• They are locked up within the V3

messaging context• Wider project with HL7: unlock the

concepts for services– HL7 Services Project (SOA)– UML ITS– MnM revisiting the dynamic model

Wire Format Stability

• HL7 instances conform to many models at once

• One can be the type – “the basis for serialisation”

• Higher up = more stable & more abstract

• Higher up = more work up front

• We lean towards DIM level

RIM

DIM

RMIM

MT

Template

Template

Template

Choices?

• The current HL7 V3 serialisation approach is a middle of the road approach

• There appears to be grounds for either more abstract or more specific formats

• More specific formats should be as specific as possible

CEN 13606

CEN 13606 Concept HL7 V3

EHR Philosophy Messaging

Reference model + Data Types

Reference Model RIM +

Data Types

ADL Constraint Formalism

Models

One wire format

Many wire formats

Wire format 1 wire format

Many wire formats

CEN 13606

• There is several movements towards harmonisation

• There is significant differences in the reference models

• There is real convergence in progress at the engineering level.

• CEN 13606 and HL7 V3 pose similar challenges to implementers

Where to now?

• Implementation Trial commencing with CfH suppliers

• XUMs are available for MIM 4.1.04

• We can experiment with messaging reshaping

• But not with Domain Model serialisation

Acknowledgements

• Charlie McCay• Lloyd Mackenzie• Gunther Schadow• Thomas Beale• Rene Spronk• Galen Mulrooney• Dave Carlson

• Laura Sato• Ken Lunn• Rik Smithies• David Markwell• Tim Benson• Joe Waller• Ann Wrightson

Many people have contributed to this work