HL7 Version 3 – A new implementation direction

HL7 Version 3 – A new implementation direction

Grahame GrieveCfH / Jiva / HL7 Australia

co-chair Infrastructure & Messaging TSProject 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

DomainModels

Other Stuff(HDF, etc)

HL7 Stack XML ITS

Schema Generator

XML ITS

Wire Format

Schemas

UML ITSUML ITS

XUM Generation& Transformation Wire

Format

XMLSchema

UMLModel

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 <<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

Example: Static Model

Example: UML

Example: Schema

<xsd:element name="PRPA_MT110101UK11.PdsRegistrationResponse“ type="PRPA_MT110101UK11.PdsRegistrationResponse" />

<xsd:complexType name="PRPA_MT110101UK11.PdsRegistrationResponse"> <xsd:complexContent> <xsd:extension base="Clone"> <xsd:sequence> <xsd:element name="code" type="CV" minOccurs="1" maxOccurs="1" /> <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" /> </xsd:sequence> <xsd:attribute name="classCode" type="ActClass" use="required" fixed="REG"/> <xsd:attribute name="moodCode" type="ActMood" use="required" fixed="EVN"/> </xsd:extension> </xsd:complexContent> </xsd:complexType>

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 Packagecd All Datatypes

DataTypes

ANY

+ nullFlavor: NullFlavor [0..1]+ updateMode: UpdateMode [0..1]+ history: HXIT [0..1]- templateId: String

BL

+ value: Boolean [0..1]

Content

+ language: Code [0..1]

Data

+ charset: Code [0..1]+ compression: Compression [0..1]+ encoding: EncodingType = Raw+ mediaType: Code [0..1]+ value: Binary [0..1]

ED

+ reference: Ref [0..1]+ integrityCheck: Binary [0..1]+ integrityCheckAlgorithm: IntegrityCheckAlgorithm [0..1]+ thumbnail: Data [0..1]

ST

+ value: String [0..1]

Strings are in Unicode

SC

+ code: String [0..1]+ codeSystem: Uid+ codeSystemName: String+ codeSystemVersion: String+ displayName: ST

Term

+ code: String [0..1]+ codeSystem: Uid [0..1]+ codeSystemName: String [0..1]+ codeSystemVersion: String [0..1]+ displayName: ST [0..1]+ originalText: ED [0..1]+ qualifier: Sequence(CR)

CD

+ translation: Sequence(CD)

CR

+ name: CV [0..1]+ value: Term [0..1]+ inverted: Boolean [0..1] = false

CE

CVCO

There is no equivalentfor CS; it is not needed

II

+ root: Uid [0..1]+ extension: String [0..1]+ assigningAuthorityName: String [0..1]+ displayable: Boolean [0..1]+ use: Set(IdentifierUse)

Ref

+ details: Uri [0..1]+ useablePeriod: GTS [0..1]

TEL

+ use: CodeSet [0..1]

ADXP

+ type: AddressPartType [0..1]

AD

+ part: Sequence(ADXP)+ use: Set(PostalAddressUse)+ useablePeriod: GTS [0..1]+ isNotOrdered: Boolean [0..1]

ENXP

+ type: EntityNamePartType [0..1]+ qualifier: Set(EntityNamePartQualifier)

EN

+ part: Sequence(ENXP)+ use: Set(EntityNameUse)+ validTime: IVL(TS) [0..1]

TN PN ON

QTY

INT

+ value: Integer [0..1]

REAL

+ value: Real [0..1]

PQ

+ value: Real [0..1]+ units: Code [0..1]+ specialValue: SpecialPhysicalQuantity+ translation: Set(PQR)

TS

+ value: String [0..1]

RTO

+ numerator: N [0..1]+ denominator: D [0..1] MO

+ value: Real [0..1]+ currency: Code [0..1]

PQR

+ value: Real [0..1]

value is an ISO 8601 date time

T:ANY

LIST

+ item: List(T)

T:ANY

BAG

+ item: Bag(T)

T:QTY

GLIST

+ head: T [0..1]+ increment: QTY [0..1]+ period: Integer [0..1]+ denominator: Integer [0..1]

T:ANY

SLIST

+ origin: T [0..1]+ scale: QTY [0..1]+ digits: Sequence(INT)

HXIT

+ validTime: IVL(TS) [0..1]+ controlActIdRef: II [0..1]

GTS

+ literal: String [0..1]+ item: Sequence(IVL(TS))+ period: Sequence(PIVL)+ event: Sequence(EIVL)

PIVL

+ phase: TS [0..1]+ alignment: CalendarCycle [0..1]+ period: PQ [0..1]+ institutionSpecified: Boolean [0..1]

EIVL

+ event: TimingEvent [0..1]+ offset: IVL(TS) [0..1]

Kernel

String

Code

«Uri»Uri

Uid

T:QTY

IVL

+ high: T [0..1]+ highClosed: Boolean [0..1]+ highUnbounded: Boolean [0..1]+ low: T [0..1]+ lowClosed: Boolean [0..1]+ width: QTY [0..1]+ lowUnbounded: Boolean [0..1]

T:ANY

SET

+ item: Set(T)

«enumeration»NullFlav or

«enumeration»UpdateMode

«enumeration»Compression

«enumeration»IntegrityCheckAlgorithm

«enumeration»TelecommunicationAddressUse

«enumeration»IdentifierUse

«enumeration»AddressPartType

«enumeration»PostalAddressUse

«enumeration»EntityNamePartType

«enumeration»EntityNamePartQualifier

«enumeration»EntityNameUse

«enumeration»CalendarCycle

«enumeration»TimingEv ent

«Binary»Binary

+ content: Sequence(Octet)

Integer

Octet«enumeration»EncodingType

enum+ base64: + raw:

«enumeration»SpecialPhysicalQuantity

«import»

Data Types

Data Typescd Basic

ANY

+ nullFlavor: NullFlavor [0..1]+ updateMode: UpdateMode [0..1]+ history: HXIT [0..1]- templateId: String

BL

+ value: Boolean [0..1]

def: let isNull : Boolean = nullFlavor.oclIsDefined def: let isNotNull : Boolean = not isNull

-- these are defined in order to help control updateMode and history def: let noUpdate : Boolean = updateMode.oclIsUndefined def: let noHistory : Boolean = history.oclIsUndefined def: let noUpdateOrHistory : Boolean = noUpdate and noHistory -- these 2 assertions are uncharted waters. we disallow use of updateMode and -- history with null until convincing use cases arise inv "No UpdateMode on null ": isNull implies updateMode.oclIsUndefined inv "No History on null ": isNull implies history.oclIsUndefined

context BL inv "no value if null ": isNull implies value.oclIsUndefined

HXIT

+ validTime: IVL(TS) [0..1]+ controlActIdRef: II [0..1]

-- this constraint is not part of the abstract model . It may be relaxed -- if a use case presents inv "must have a valid time": validTime.oclIsDefined and validTime.isNotNull inv "no updateMode or History": (validTime.oclIsUndefined or validTime.noUpdateOrHistory) and (controlActIdRef.oclIsUndefined or controlActIdRef.noUpdateOrHistory)

There is no equivalent for BN, as it is a private Type

Data Types

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 4.1.04

• 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