UML ITS Tutorial Grahame Grieve CfH / Jiva / HL7 Australia co-chair Infrastructure & Messaging Project 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

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 UML Model XSD Schema XML Wire 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 > for enumerations The stereotype > 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 Implementable UML Model Automated Transforms Conformance Profile Schemas (XML ITS) Automated Transform Msg Automated Transform HL7 Model Analysis Model Manual Mapping *

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 DomainProject Generate Implementable Model Level of Abstraction RMIM/RealmRMIMDomain / Realm Generate Implementable Model Generate Implementable Model Generate Implementable Model Generate Implementable Model MoreLess Level of Abstraction Abstract More Interoperable Specific Less 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

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 ConceptHL7 V3 EHRPhilosophyMessaging Reference model + Data Types Reference ModelRIM + Data Types ADLConstraint Formalism Models One wire format Many wire formats Wire format1 wire format Many wire formats

CEN 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 and HL7 V3 pose similar challenges to implementers

Where to now? Implementation Trial commencing with CfH suppliers XUMs are available for MIM 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