V3 Lite – Simplifying the Exchange of HL7 V3 Messages Robert Worden

Summary Large message size and complexity is holding back takeup of HL7 V3 A V3 message definition can be restricted and reshaped to make it smaller and simpler, without blurring semantics The RMIM Reshaping Tool does this, keeping mappings between full and reshaped messages XSLT transforms between full and reshaped messages can made automatically and accurately This gives a simpler way to read and write V3 messages from applications It can be used in several different scenarios It may be used to support a new ITS for V3

Complexity of HL7 V3

Why is HL7 V3 Complex and Difficult to Use? HL7 technical committees are trying to address many use cases, and to address them very thoroughly There are many intermediate ‘glue’ classes which add little to the semantics CMETs are designed for many use cases; using them adds complexity not needed for one use case Often a whole extra class has to be added, just to add one attribute HL7 ways of building models (meta-model, methodology) are complex and unlike vanilla UML RIM language is hard to understand, even for insiders Documentation is extensive and distributed HL7 tooling causes problems

XPath Counts – a Measure of Message Complexity The number of distinct types of information that can be carried in a message is roughly the number of distinct XPaths in the message structure You need to cut off recursion (self-nesting) to keep this number finite For some V3 message definitions, the XPath count is very large indeed: e.g. for a laboratory request message: –60,000 XPaths down to data type nodes –More than 4 million XPaths down to leaf nodes A typical message instance may use only a few dozen of these XPaths; finding them is hard V2 node counts are much smaller (and V2 is widely used…) Tree depth and branching does it. Try B D when D = 20

How to Implement V3 Messages From the HL7 WIKI - V3 Implementation FAQ: If you are working with XSLT you need to define an intermediate XML format for your data. This can be in "close to HL7" form or in "close to native" form. It's normally sensible to quickly export your data in a near-native format, and then encapsulate just the HL7 specifics in the XSLT. Application 1 Application 2 App 1 Native API App 2 Native API Intermediate V3 XSLT

Problems With This Approach You have really just split the problem up into pieces - not reduced it Transformations are needed in both directions 8 different transformations are needed for a round trip: [App 1 => App 2 => App 1] XSLT is not easy to write and test on this scale Will all 8 transformations be accurate?

HL7 V3 is like the National Grid; there is an Impedance Mismatch with Everyday Devices V3 = 132,000 Volts 240 Volts 1,000 Volts? 110 Volts Implementer Domain 1 Implementer Domain 2 How can we build accurate transformers without prohibitive costs?

Restricted Message Profiles HL7 encourages realms (e.g. UK) and implementors to constrain standard message definitions into more restricted Profiles before implementation Constrain means: reduce optionality and cardinality ranges; constrain data types; … A message instance of the constrained definition is an instance of the full definition The message skeleton remains more or less the same size (e.g. depth); there is less flesh on it

Restricting and Reshaping Message Definitions Restricting an RMIM means: restricting the cardinalities of attributes and associations (above and within data types) removing unused attributes and associations, fixing values of attributes Reshaping an RMIM means: collapsing associations which are 0..1 or 1..1; renaming classes, associations and attributes, removing fixed attributes. In this way, the reshaped object model (and its XML serialisation) can be made much simpler and more like a DAM (domain analysis model) These operations preserve semantic equivalence between the original and the reshaped model An instance of one can be transformed automatically to be an instance of the other

Overview of RMIM Re-shaping RMIM RMIM’ RMIM’’ Reshaped RMIM Target DAM MIF (reshaped) XSD RMIM Mappings XML Instances XML Translation XMI

RMIM Reshaper Tool: Screenshot/demo

Outputs of the Reshaping Tool (and associated tools) Tables of mappings between RMIM and reshaped class model MIF for reshaped class model XMI for reshaped class model XML Schema for reshaped XML messages Example message instances - for both full V3 XML ITS and reshaped XML XSLT transformations between full V3 XML and reshaped XML (both directions)

Simpler Reshaped Class Model This example is cribbed from a paper by Ken Lunn, (it is not output from the reshaping tool) and is purely illustrative. The main point is that the number of classes and attributes is much fewer than in an RMIM, and they have direct domain meanings.

Exemplar Message - Reshaped This is a Patient Admin ‘New Patient’ message, restricted and reshaped The exemplar was output from the reshaping tool Maximum depth of nesting is about 3 Message size is 667 bytes

Exemplar Message – Full V3 Bellamy James Mr Summers Adele Mrs …… Output from the reshaping tool, using the same instance data as before Maximum depth of nesting is about 8 This is only part of the message Full message size is 2431 bytes (4 times bigger than reshaped)

XSLT Translation and Round-Trips XSLT to translate from reshaped to V3, and back again, is generated automatically from the mappings Generated XSLT files are large and boring The XSLT is not optimised yet, but is not stupid either It does round trips (reshaped – V3 – reshaped) with 100% accuracy Fixed attribute values are put into the V3 (or not if you choose) XSLT is suitable, because there are no vocabulary lookups (values are the same for V3 and reshaped instances) Performance will be an issue for some high-volume applications; we will start optimising then.

Comparative Query Tool Can query a V3 message instance and a reshaped message instance, side by side in terms of the reshaped class model Highlights differences in semantic content, in colour A good way to check V3 messages for the content that matters A good test of the accuracy of translations In the example that follows, I have introduced a deliberate mistake (reshaped and V3 messages are not quite equivalent)

Comparative Query – Screenshot/Demo

Java API Using Reshaped Class Model Can build Java applications in terms of the reshaped (simpler, domain-like) class model The tools can generate skeleton Java classes for the reshaped class model Can read V3 messages into these applications, translating them automatically into the reshaped class model via the mappings Applications are insulated from changes in V3 This is like JavaSIG but uses the simpler class model

What This Means for Implementors You need a MIF definition of the RMIM to start with You can then restrict and reshape it quite quickly with the reshaping tool Illegal reshaping moves are forbidden by the tool XMI, XSD and XSLT are generated automatically The reshaped model becomes your intermediate XML You can then map your applications onto the (much simpler) reshaped model, and read or write fully conformant V3 into those apps. This saves a lot of effort It will increase the accuracy of your implementations It is fully V3-conformant, now

Usage Scenario – Fully V3 Conformant Application 1 Application 2 App 1 Native API App 2 Native API Intermediate V3 XSLT 1 XSLT 2 Using reshaping, XSLT1 and XSLT 2 are generated automatically and accurately Supplier 1 and supplier 2 can choose independently how to implement (e.g. whether to use reshaping, how to reshape)

Usage Scenario – Smaller Messages over the Wire Application 1 Application 2 App 1 Native API App 2 Native API Intermediate V3 XSLT 1 XSLT 2 Reshaped message instances are typically 3-4 times smaller Supplier 1 and supplier 2 can still choose independently how to implement (e.g. whether to use reshaping, how to reshape) Is that V3-conformant?

Usage Scenario – HL7.org defines reshaped messages (New ITS) Application 1 Application 2 App 1 Native API App 2 Native API V3 (New ITS)New ITS V3 (old ITS) XSLT 1 XSLT 2 HL7 defines reshaped RMIM as new ITS HL7 publishes XSLT to transform between them Suppliers can use either new or old ITS over the wire; both are conformant V3 Each supplier can choose independently whether to implement the new ITS or the old ITS

Usage Scenario – CfH defines reshaped messages Application 1 Application 2 App 1 Native API App 2 Native API New ITS V3 XSLT 1XSLT 2 CfH publishes full and reshaped RMIMs in the MIM CfH publishes XSLT to transform between them Suppliers can use either new or old ITS over the wire; both are conformant V3 Each supplier can choose independently whether to implement new or old ITS

V2-V3 Mapping Tool Pre-dates the reshaping tool, and has a similar user interface Read in a V2 definition and a V3 definition; then define mappings between them Translations can be generated automatically from the mappings If an application already has a V2 interface, you could use V2 XML as an intermediate XML on the way to V3 Some HL7 TCs and suppliers have made and are making V2-V3 mappings Mappings are exchangeable in the tool format

Current Status NPfIT are now evaluating approaches to message simplification and the new XML-UML ITS, including use of the RMIM reshaping tool Example messages being tested: GP summary, ETP, PDS, …. Results will be presented at the HL7 WGM in San Diego in January The RMIM reshaper will soon be available from the HL7 Homebase (tooling site)

What will be Open Source RMIM Reshaping tool V2-V3 Mapping tool Java API for messages Java class generator Comparative Query Tool

What will be Licensed XSLT Generator Run-time translation engine Translation compiler

Questions For full slides with notes, see the conference site. For further information,