Making Version 3 as easy to implement as Version 2 – but with sound semantics rpworden@me.com
• 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
• OBX segment – 225
• ADT^A03 – 1885
• ORU^R01 – 4412
• OMP^009 – 5225
• 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
• 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
• 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
V3: 50,000 + nodes
Implementations
V2: 3,000 nodes
Interoperability happens in the overlaps between implementations
• 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
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)
Product Uses
Simple message schema
Skeleton instance of simple message
XSLT transforms
Validating simple messages; code generation
Initial testing
Transform from simple messages to full V3 messages at runtime, and vice versa.
Testing message simplification, e.g. by round trips
Fully define the semantics of the simple messages in terms of V3 RMIMs
Mappings from simple message to V3
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.
• 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
Application
A
Simple
XML
Simple-to-
Full
Transform
V3 Full-to-
Simple
Transform
Simple
XML
Application
B
V3
Application
C
Full-to-
Simple
Transform
V3 message
Simple message
Simple-to-
Full
Transform
Should recover all you need of the V3 message, unchanged.
• 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