HL7 V3 message triggered from Sender are sent over their integration layer as HL7 Request to sender MSH (Message Service Handler). MSH is a piece of software used to send and receive ebXML messages. Figure below shows the functions of MSH.
The textual description of the services depicted above is given below
Ø MSH Service Interface – This is the abstract interface applications use to interact with MSH to send and receive messages.
Ø Header Processing – the creation of the ebXML Header elements for the messages sent from the applications. It also involves parsing of header elements and interactions with contract properties. [See below for Contract Properties]
Ø Security Services – this includes digital signature creation in the messages (which may be used in headers), verification, encryption, authentication and authorization.
Ø Message Packaging – this will perform the enveloping of an ebXML Message (ebXML header elements and payload) into its SOAP Messages with Attachments container
Ø Reliable Messaging Services – this service handles the delivery and acknowledgment of ebXML Messages. It also deals with persistence of messages, retry, error notification and acknowledgment of messages requiring reliable delivery.
Ø Transport Binding – This is the abstract interface between the MSH and the various protocol stacks.
Ø Error Handling – this handles the logging and reporting of errors encountered during MSH or Application processing of a message.
Contract Properties
To understand the exchange of messages between two MSH’s we need to understand the term “contract properties”
Each MSH processes the messages sent by the other MSH by the contracted interface properties. These properties describe Quality of Service (QoS) from reliability and security point of view. The MSH uses these properties to build the ebXML wrapper. The contract properties are defined during message definition process and agreed between two organizations or two system vendors who will exchange the messages. Contract properties are defined for each HL7 interaction. The contract properties given for each interaction are identified by a CPAId. The sender will use the CPAId that is relevant for that HL7 message interaction and agreed with the receiver.
Figure below shows the sequencing involved in ebXML message exchange
Let me explain the flow in the above sequence diagram
1. In a typical implementation the Sender builds the HL7 message with the HL7 Wrapper and passes it onto the sender MSH
2. The sender MSH looks at the message interaction id and looks up in the database for the contract properties for the message and builds the ebXML wrapper.
3. The ebXML message sent by sender MSH containing the HL7 message payload will get ebXML acknowledgement synchronously on the same connection over HTTP 202. The ebXML Acknowledgements are sent without a payload.
4. If the ebXML acknowledgement from Receiver MSH is not received within a time interval Sender MSH resends the message. The number of retries and retry time interval are dependant upon the contract properties attached with that message.
5. If the number of retries expires depending upon the message business functionality Sender MSH will report the error back to application which sent the message or enter into a HL7 slow retry method.
6. In case of ebXML errors Receiver MSH sends a message with the same end-point binding associated with ebXML acknowledgement service except that a Message Error will be sent.
7. The business responses or application acknowledgements from Receiver MSH in response to the message sent are received and processed by the Sender MSH exactly in the same fashion as Receiver MSH does on receiving a request from Sender MSH.
The above description is only for direct reliable message exchange between two MSH's ; we can have intermediary exchange with two MSH's communicating to each other using anothe MSH or we can also have direct unreliable message exchange. I have not discussed them here not i do intend to discuss them here.
No comments:
Post a Comment