“Abstract Transport Specification”
Proposal#901
For Discussion by CQ’s Transport TF
- Updated up to 2004-10-28 –
Editor : René Spronk,
The contents of this document have been placed in the public domain. Note that the images in this document are based on HL7 Artifacts, these are © HL7 Inc.
Content Page
1. Introduction 2
2. Transport Requiremens Specification 4
3. Transports v. Requirements 8
4. Abstract Services 8
4.1. Delivery 8
4.2. Reliable messaging 8
4.3. Addressing 9
4.4. Sequencing 10
4.5. Routing,relaying and forwarding of messages 11
4.6. Security 12
4.7. Attachments 13
4.8. Compression 15
4.9. Other issues 15
Introduction
Note: the enhancements in this document are for R2 (2006+) of the Infrastructure Management domain, not for R1 (2004).The v3 material describes the dynamic model. A discussion was started on the e-mail lists in an attempt to simplify and/or clarify the dynamic model in v3. As part of the discussion CQ has decided to create a “Transports Taskforce”.
(ADOPTED) Proposal #806.3 A taskforce to create a normative "requirements for transport specifications" document based on an agreed set of use cases will be created, with the goal of creating a common famework. The existing transport specifications should be reworked towards this common framework. The aim is to create a common end-to-end framework and to avoid interoperability issues.(20040506: CQ TC San Antonio: Proposal was adopted as stated above 13-0-0)
The purpose of the Transports Taskforce is to put together a “abstract transport specification document”, an abstract service specification for HL7 v3 transports. The abstract specification describes the functional characteristics of the Messaging Infrastructure (see below for a definition of Message Infrastructure)
The work of the taskforce will be mainly done by e-mail. This summary document serves as the focal point, and a s a summary, of that discussion. A t-con may be held 1 time a month to finalize the decision process on elements where consensus has been reached, or to reach concensus in areas that seem to be “stuck”.
Transport Requiremens Specification
Introduction
To fully understand the transports requirements specification, definition of some general terms and standards artefacts used throughtout the document need to be respected. Please refer to the HL7v3 standard specification for definition of HL7v3 concepts, like HL7 composite message, payloads, wrappers and application roles.
The following figure highlights the major concepts that will be used throughout the rest of the document:
Figure 1 Relation among the different components of the application architecture
The elements that make up the application architecture are defined as follow:
· Application: this is where all the logic for the generation, manipulation and consumption of HL7 messages resides. It consists of an HL7 application and a Messaging adapter (see Figure 1). Higher levels of the application might deal with business rules, workflow and other aspects of the particular implementation. The analysis and description of those layers is not in scope for this document.
· HL7 Application: refers to the implementation of a set of one to many HL7 application roles and their respective responsibilities as defined by the HL7v3 standard. HL7 Application is the single entity in the application architecture (Figure 1) that deals with the domain specific HL7 composite messages generation and management. Note that this definition is here put for reference only, since the entire application level business logic and HL7 application behavior is out of the scope of this document.
· Messaging Adapters: these components live inside the Application and provide the interface to the specific messaging stack being used. Messaging adapters are both aware of HL7 and the messaging stack being interfaced. Their role is to prepare the HL7 message for transmission by the messaging infrastructure.
· Messaging Infrastructure: these are the runtime components that implement a particular messaging protocol. These components are generally off-the-shelf implementations that have no knowledge of the specific payload being transported.
· Message Transport: this layer represents the mean by which the HL7 message is transported to the appropriate destination. Different protocols might use multiple transports, depending on the implementation, the degree of separation between the protocol and the transport and a number of other factors. As an example it is possible to transmit HL7 messages via HTTP using Web Services and ebXml, but not with MLLP, which by its nature is bound to serial transport protocols (e.g. TCP/IP, RS232) only.
Figure 2 shows the abstraction layers that the HL7 message traverses en-route to the destination:
Figure 2. Abstraction layers for message transmission
It is important to preserve isolation between the layers so that the application is independent from the particular protocol stack in use and that the protocol be independent from the specific transport, so that the same message can be routed through multiple different physical transports. Messaging adapters provide isolation between the application and the Messaging Infrastructure, while the latter provides isolation between the application and the physical transport.
As the message travels through the different layers is enriched with information that is used to deliver the message to the corresponding layer of the receiving application.
As an example as the HL7 application passes an HL7 Version 3 message to the Web Services Messaging Adapter, the appropriate metadata is added to configure the source, destination, delivery assurances, security characteristics and so on. Once the message is passed to the Messaging Infrastructure, the particular Web Services implementation will add the appropriate SOAP envelope and SOAP headers to meet the requirements of the application.
When the message gets to its destination, the SOAP envelope and headers are removed and the appropriate metadata is passed to the Web Service Messaging Adapter which takes ownership of the message and ultimately delivers it to the HL7 application.
Other concepts that will be used in the document are defined here:
· Sender: the Application that prepares the HL7 message and sends it to the Receiver. The Sender lives in the Application layer and embeds the Messaging Adapters for interfacing with the specific Messaging Infrastructure.
· Receiver: the Application that receives the HL7 message sent by the Sender. The Receiver lives in the Application layer and embeds the Messaging Adapters for interfacing with the specific Messaging Infrastructure.
· Source: the runtime component of the Messaging Infrastructure that transmits the message to the Destination. The Source leaves in the Messaging Infrastructure layer and implements the specific protocol. The communication between Source and Sender is through APIs provided by the implementation of the protocol (Java, .NET Framework, CORBA, COM…)
· Destination: the runtime component of the Messaging Infrastructure that receives the message from the Source. The Destination leaves in the Messaging Infrastructure layer and implements the specific protocol. The communication between Destination and Receiver is through APIs provided by the implementation of the protocol (Java, .NET Framework, CORBA, COM…)
· Intermediary: a node at the Messaging Transport level that sits between the Source and the Destination. The Intermediaries can provide message routing capabilities at the Messaging Transport level, and can function as interface between different physical transports as long as the Messaging protocol stays the same. Intermediaries are not allowed to change the HL7 composite message in any way. Intermediaries might change headers or metadata that is added at the Messaging Infrastructure level. Intermediaries can be trusted or non-trusted.
· Bridge: is an application that contains 2 or more Messaging Adapters: it provides transport protocol translation (i.e. relaying) and/or message routing capabilities. Bridges are not considered HL7 applications since they don’t implement any of the HL7 application roles. They are not allowed to change any elements in the HL7 composite message. They are however allowed a read-only access to HL7 composite message, where the level of HL7 awareness is site-by-site and implementation specific. A Bridge is never a final destination of a transaction.
· Gateway: is an HL7 application that implements delegating capabilities in a distributed healthcare environment. A Gateway performs business level functions in the name of other HL7 Applications. Note that, as they implement HL7 specific business logic, gateways are out of the scope of this document.
The “transport requirements document” is a abstract service specification for HL7 v3 transports.
Note that some of the abstract services listed in this table may actually be out of scope of a transport specification. As long as a service hasn’t been declared out of scope it will be listed in this table & document.
Messaging Infrastructure (MI) Capabilities:
· Addressing: the ability of a MI to individually address SENDERS and RECEIVERS at least at the same level of granularity of the HL7 Transmission Wrapper
o Routing: the ability of a MI to route the message from SOURCE to DESTINATION through multiple Intermediaries and physical transports
· Reliable Messaging: the ability of a MI to guarantee delivery of a message from SOURCE to DESTINATION
o In-Order delivery: the ability of the DESTINATION to deliver messages to the RECEIVER in the order in which they were sent by the SENDER
o At-Most-Once delivery: the ability of the DESTINATION to deliver messages to the RECEIVER at most once, discarding duplicate received messages
· Security: the ability of a MI to support the HL7 Security Model
o Integrity: the ability of a MI to preserve the integrity of the messages as they travel from SOURCE to DESTINATION, preventing voluntary or involuntary manipulation by Intermediaries
o Confidentiality: the ability of a MI to preserve the confidentiality of a messages as they travel from SOURCE to DESTINATION by preventing Intermediaries to inspect the HL7 payload of the message
o Non Repudiation: the ability of a MI to prevent that messages sent cannot be subsequently reputiated by the SENDER or RECEIVER
o Authorization: the ability to authorize parties in the communication before data is actually sent
o Authentication: the ability to prove that parties in the communication are who they claim they are
o Auditing: the ability to record all the activities concerning the HL7 MESSAGE from the time it is handed to the SOURCE from the messaging adapter until the DESTINATION delivers it to the RECEIVER’s messaging adapter.
o Encryption?
· Attachments: ability to embed binary attachments while trasmitting the HL7 MESSAGE from SOURCE to DESTINATION
· Compression: ability to compress the data stream at the protocol and/or transport level
Transports v. Requirements
This document describes a number of specifications of “abstract services” . This section aims to describe what services apply to what transports. In effect this will be the “factual comparison” between transports which was contemplated for the transports overview document.
At the moment HL7 version 3 describes the following transports: ebXML, Web Services, MLLP, and physical media.
All transports have to support reliable messaging (Statement 901.1). There may be other abstract services that have to be supported by all transports, e.g. attachments. The requirements for inter-enterprise transports may be different from requirements for intra-enterprise transports.
Abstract Services
This chapter describes the various abstract services (transports requirements) in detail. It contains proposal statements (which are created based on a consensus-opnion) and excerpts of e-mail discussions.
Delivery
This section describes a number of requirements related to the delivery of messages.
Reliable messaging
Reliable messaging ensures a hand-over of responsibility for the message between a sending and receiving system at the transports level.
(ADOPTED) Proposal #901.1 (aka #806.1) All HL7 v3 transport specifications shall provide reliable messaging without involving HL7 semantics. Reliable messaging in HL7 includes the notion of storing the message to reliable, recoverable, storage.(the above statement was adopted during the CQ teleconference of 2004-xx-yy, by a vote of 5-0-0)
Note (clarification of the proposal): All communications of errors related to message content require an accept response or an application response.
Note: Reliable messaging covers what is called the “commit ack” by some, which can be described as:
· (for receivers) If you have received and stored it, send a commit ack to the sending application.
· (for senders) Until you receive the commit ack, keep resending on the assumption they haven't gotten it yet.
(Andrew) .. ebXML acknowledgements are included in the HL7 ebXML transport profile and in the UK we are getting experience of using these with V3 implementations, in place of using HL7 Accept Acknowledgements.
(Lloyd) All transports editors need to be aware of/ to deal with the following use-case:
If one uses a one-way transport protocol (e.g. HTTP, FTP, ..) in a unidirectional fashion (e.g. a GP system only supports a HTTP client, not a HTTP server) then one has to make sure that the response to a synchronous HL7 request ends up being received by the sender of the synchronous request, without involvement of messages at the HL7 application layer. How transports accomplish this depends on the transport, and will be subject to detailed discussion in future.
A commit ack is a statement from the receiving system that the message (in this context: a sequence of bytes) has been recieved and stored in a secure and recoverable fashion. It doesn’t make any statement about its contents.
The v3 concept of commit ack used to be part of the v2 accept ack. In v2 the accept ack had a dual nature, one of which was the commit ack. The “v2 commit ack” aspect of the “v2 accept ack” has been separated into the v3 commit ack.
(in favor: Andrew, Kreso, Mike, Miroslav, Virginia, Lloyd)
Addressing
If a transport supports the concept of addressing (e.g. ebXML, WS) then the transport specification document in the v3 standard has to specify the relation between V3 Transmission Wrapper sender/receiver addresses and the transport use of these.
The HL7 Transmission Wrapper identifies the applications that are responsible for the sending/receipt of the message at the business level. In the HL7 wrapper the unique address of the sender and receiver is carried at the most granular level, e.g. the department level.
Consider the following use-case: If the transport architecture utilizes a ebXML Message Handling Service which fronts a number of systems and the EBXML wrapper requires the MHS Party ID to route the message to the handling service.The destination address in the HL7 wrapper and a transport do not need to be the same so long as the transport does not carry any greater detail than the HL7. In our use case, the sender would put the department address in the HL7 wrapper and the MHS Party ID, which is less granular, in the EBXML wrapper. On receipt by the MHS, the HL7 wrapper address will identify the actual recipient for the message.