HL7 Version 3 – A new implementation direction Grahame Grieve CfH / Jiva / HL7 Australia co-chair Infrastructure & Messaging TS Project Lead, Eclipse OHF

A New Direction CfH experience shows that HL7 V3 is difficult to implement (but can be done) –All V3 projects have reported the same outcome Health IT is difficult to implement –But this should be due to content, not engineering issues

The UML ITS The UML ITS represents a vision: A new ITS based on o-o concepts Give implementers what they want Publish UML Models & Schemas Make them normative Support Model Driven Development Make V3 easy to implement!

UML ITS Overview RIM / datatypes Domain Models Other Stuff (HDF, etc) HL7 Stack XML ITS Schema Generator XML ITS Wire Format Schemas UML ITS XUM Generation & Transformation Wire Format XML Schema UML Model XUM

UML ITS Technical Side –Specification of the wire format using UML & XML Schema –Preparation of the reference package (data types etc) Policy Side –What Models are used –What Transformations are applied to the models?

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

Example: Static Model

Example: UML

Example: Schema <xsd:element name="PRPA_MT110101UK11.PdsRegistrationResponse“ type="PRPA_MT110101UK11.PdsRegistrationResponse" /> <xsd:element name="subject" type="PRPA_MT110101UK11.Subject“ minOccurs="1" maxOccurs="1" /> <xsd:element name="pertinentInformation" type="PRPA_MT110101UK11.PertinentInformation“ minOccurs="1" maxOccurs="1" /> <xsd:element name="inFulfillmentOf" type="PRPA_MT110101UK11.InFulfillmentOf“ minOccurs="1" maxOccurs="1" />

Example: Instance

Reference Package Enumerations –Structural Vocabularies –Data Type Vocabulary Domains Data Types –UML & XML design principles apply –O-O Implementation of Hl7 V3 data types –Cross Mapped to OpenEHR data types

Reference Package

Data Types

This approach to data types allows code generation This approach to datatypes is acceptable to CEN & ISO HL7 will bring the UML ITS datatypes forward as a candidate for the ISO datatypes ISO affiliates will be encouraged to submit ballot comments when the UML ITS is balloted (officially or privately)

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

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

Are definitions required? Yes: Instances defined in terms of the definition –Rename, collapsing, defaults omitted, smaller Applications need to find or know the definition No: Instances defined in terms of the RIM –RIM names & structures, no defaults, Applications can do generic processing

Definitions are not needed Administrative – use reshaping techniques Clinical – leave as RIM No clear boundary Real price is in clinical content ? Still to be finalised

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 –CDA has invested in a stable document format

Stable Wire Format Use Domain Models as a basis for serialisation Apply RMIMs, Message Types as Templates Policy development to make Domain Models more stable & reduce overlaps

Where to now? Implementation Trial commencing with CfH suppliers XUMs are available for MIM We can experiment with messaging reshaping Develop Domain Model for CfH Pharmacy

New Directions 1.Templates Specification (at last) 2.SOA – unlocking V3 content 3.Re-Tool HL7 – make the tools a strength 4.UML ITS – reduce cost of adoption 5.Collaboration with CEN 6.Work with OMG on long term engineering solutions

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