Transcript Message Simplification

Message Simplification
Making Version 3 as easy to implement
as Version 2 –
but with sound semantics
[email protected]
Leaf Node Counts
• One measure of the cost and complexity of
reading and writing a message
• The number of distinct node (types) which can
each carry a distinct piece of variable data
• Nodes you might need to map to a field in an
application database – or write a piece of
application logic to handle
Node Counts - Version 2
•
•
•
•
OBX segment – 225
ADT^A03 – 1885
ORU^R01 – 4412
OMP^009 – 5225
Node Counts - Version 3
• To keep the numbers down:
–
–
–
–
No recursive nesting
No nesting of data types
Ignore data type ANY
XML Attributes only
• Lab Result Event (POLB_RM004000UV01): 101,792
nodes
• Medication Order (PORX_RM010120UV): 38,882 nodes
• CCD: 10,284,480 nodes
Is This Message Size Useful?
• No application database has 50,000 columns
• No system has data to populate 50,000 nodes
• If it did, the costs of mapping the data to
50,000 nodes would be prohibitive
• The cost of writing business logic to handle
the data would be prohibitive
• Most example instances have at most a few
hundred node types populated
Why HL7 V3 is Difficult
• 50,000 node types is too many
• Finding the right nodes to read or write is not
easy
• To get to those nodes, you need to pass through a
large superstructure of semi-fixed stuff
• V3 is technically intricate; knowledge about it is
still scarce and debated
• The defining material is spread across many
places
All V3 Implementations are Partial
Implementations
V2: 3,000 nodes
V3: 50,000 + nodes
Interoperability happens in the overlaps
between implementations
The Simpler Way to Implement V3
• Interoperability depends on a group of suppliers
and purchasers agreeing which subset of a V3
message they need.
• The subset probably has no more than 1000 leaf
nodes
• Once this subset is agreed, it can be packaged
into a much simpler message
• The semantics of the simple message are fully
defined, by reference to V3 semantics
• Simple messages can be reliably converted to full
V3 Messages, and vice versa, by XSLT
Message Simplification – The Process
V3 RMIM
(MIF)
Templated
RMIM
(ECore)
Select
Rename
Annotated
RMIM
(Ecore)
Press
the
Button
Simple
Message
Schema
Skeleton
Simple
Message
Simple-Full
Transforms
(XSLT)
Simple-Full
Mappings
Simple Class
Model
(Ecore)
Uses of Simplification Products
Product
Uses
Simple message
schema
Validating simple messages; code generation
Skeleton instance of
simple message
Initial testing
XSLT transforms
Transform from simple messages to full V3
messages at runtime, and vice versa.
Testing message simplification, e.g. by round
trips
Mappings from simple
message to V3
Fully define the semantics of the simple
messages in terms of V3 RMIMs
Simplified class model
Define the semantics of the simple message, in
simpler, non–RIM-based terms.
Mapping to the simple class model is the easiest
way to build interfaces to simple messages.
Message Simplification Is Easy to Do
• Select the nodes you want to retain in the simple
message
• Rename attributes and elements
• Override automatic flattening rules (if you want)
• Do these either with a special editor, or by
annotating a message example
• The tools do the rest automatically
• The round-trip V3=>Simple=>V3 is easily tested
Using Simplified Messages
Application
A
Simple
XML
Simple-toFull
Transform
V3
Full-toSimple
Transform
V3
Application
C
Simple
XML
Application
B
Testing By Round Trips
Full-toSimple
Transform
V3
message
Simple
message
Simple-toFull
Transform
Should recover all you need of the V3 message, unchanged.
Potential
• This approach can greatly reduce the costs of
implementing Version 3 and CDA
• It can make V3 as easy to implement as V2 – but
with sound V3 semantics
• It can greatly increase the takeup of V3 and CDA
• This benefits everybody
• Suppliers and purchasers can collaborate to
define message simplifications, under the
auspices of HL7
• HL7 can make transforms and other deliverables
available to members