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