1. Message Simplification Making Version 3 as easy to implement as Version 2 – but with sound semantics rpworden@me.com

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

3. Node Counts - Version 2 OBX segment – 225 ADT^A03 – 1885 ORU^R01 – 4412 OMP^009 – 5225

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

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

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

7. All V3 Implementations are Partial V2: 3,000 nodes V3: 50,000 + nodes Interoperability happens in the overlaps between implementations Implementations

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

9. Message Simplification – The Process V3 RMIM (MIF) Templated RMIM (ECore) Annotated RMIM (Ecore) Simple Message Schema Skeleton Simple Message Simple-Full Transforms (XSLT) Simple-Full Mappings Simple Class Model (Ecore) Press the Button Select Rename

10. Uses of Simplification Products ProductUses Simple message schema Validating simple messages; code generation Skeleton instance of simple message Initial testing XSLT transformsTransform 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 modelDefine 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.

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

12. Using Simplified Messages Application A Simple-to- Full Transform Application B Application C Full-to- Simple Transform Simple XML Simple XML V3

13. Testing By Round Trips Simple-to- Full Transform Full-to- Simple Transform V3 message Simple message Should recover all you need of the V3 message, unchanged.

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