70 likes | 183 Views
Services Oriented Transport / ITS (HL7v3 CQ / Transports) v 0.1. Darius Kemeklis Technical Direction / System Architecture Electronic Data Systems / U.S. Veteran Affairs Health Administration darius.kemeklis@med.va.gov. Intro: sample ebXML HL7 message. Duplicate Metadata Information.
E N D
Services Oriented Transport / ITS(HL7v3 CQ / Transports) v 0.1 Darius Kemeklis Technical Direction / System Architecture Electronic Data Systems / U.S. Veteran Affairs Health Administration darius.kemeklis@med.va.gov
Intro: sample ebXML HL7 message Duplicate Metadata Information HL7v3 Message XML representation with TrasmissionWrapper/ ControlWrapper/ Payload
Current HL7v3 state • Current HL7v3 state: • RMIM -> XML ITS • XML ITS -> transport binding • HL7v3 XML Message contains: • Transmission/Control wrapper • Message payload - ControlAct • Pros: • Comfort zone – been there, done that • Works well for simple transports (MLLP over the socket) • Cons: • Message header & payload are not well separated • The only message header extensibility is using AttentionLine.value (vs. JMS or WS built in extensibility at the Message/Header root level). • Duplicate data in Transport Header and HL7 Message header attributes. • Assumes HL7-only world
Real-life messaging needs • Real-life within-enterprise messaging needs: • Need to transport HL7 and non-HL7 messages using common infrastructure, tools and approaches • Need to define custom message header attributes • Need “quick” transport level API access to message metadata (header attributes) w/o having to parse HL7v3 XML message • Need to support multiple transports • Need to perform transformations from one transport to another
Real-life messaging implementation • Real-life within-enterprise messaging implementation: • Minimal usage of MSH and Transmission/Control wrappers – just enough to get by • Store all significant routing information in the transport specific headers (JMS / WS-* / ebXML etc) • Implement within-enterprise routing logic based on the information within the transport specific headers instead of MSH and Transmission/ControlWrappers • Implement support for multiple transports with custom transformation rules between each transport.
How HL7v3 could help • Continue using transmission/control wrappers for MLLP. • Use existing XML ITS: RMIM -> domain specific message payload (no control/transmission wrappers) • Define new ITS: • RIM -> direct mapping of transmission (and control ?) wrapper information into a transport-specific headers • Between-transport header transformation rules. • Pros: • No need to worry about extensibility – built-in into the advanced transports • No duplicate information within transport headers and HL7 wrappers • No need to create APIs to populate/read these fields. • Faster access w/o having to parse transport payload – HL7 XML message with wrappers inside.
Discussion ? Ideas ? ? Questions ?