Message Simplification Making Version 3 as easy to

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

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^A 03 – 1885 ORU^R 01 – 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_RM 004000 UV 01): 101, 792 nodes • Medication Order (PORX_RM 010120 UV): 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 HL 7 V 3 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 • V 3 is technically intricate; knowledge about it is still scarce and debated • The defining material is spread across many places

All V 3 Implementations are Partial Implementations V 2: 3, 000 nodes V 3: 50, 000 + nodes Interoperability happens in the overlaps between implementations

The Simpler Way to Implement V 3 • Interoperability depends on a group of suppliers and purchasers agreeing which subset of a V 3 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 V 3 semantics • Simple messages can be reliably converted to full V 3 Messages, and vice versa, by XSLT

Message Simplification – The Process V 3 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 V 3 messages at runtime, and vice versa. Testing message simplification, e. g. by round trips Mappings from simple message to V 3 Fully define the semantics of the simple messages in terms of V 3 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 V 3=>Simple=>V 3 is easily tested

Using Simplified Messages Application A Simple XML Simple-to. Full Transform V 3 Full-to. Simple Transform V 3 Application C Simple XML Application B

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

Potential • This approach can greatly reduce the costs of implementing Version 3 and CDA • It can make V 3 as easy to implement as V 2 – but with sound V 3 semantics • It can greatly increase the takeup of V 3 and CDA • This benefits everybody • Suppliers and purchasers can collaborate to define message simplifications, under the auspices of HL 7 • HL 7 can make transforms and other deliverables available to members