This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Sender"
Jump to navigation
Jump to search
(→Notes) |
(→Notes) |
||
| Line 3: | Line 3: | ||
== Notes == | == Notes == | ||
| − | *Question: Why | + | *Question: Why do we need to have[[Messaging Adapter]] embedded in the concepts of Sender and Receiver? |
| − | **Answer: The reason why we have included the [[Messaging Adapter]] to the Sender and Receiver is very simple - without the [[Messaging Adapter]] the [[HL7 Application]], which | + | **Answer: The reason why we have included the [[Messaging Adapter]] to the Sender and Receiver is very simple - without the [[Messaging Adapter]] the [[HL7 Application]], which by definition produces and consumes HL7 messages (including object representation and serialization using the HL7 ITS) would not able to send the message anywhere. The concept of [[HL7 application]] brings true value only if it is able to communicate with other applications, so no point of calling something "a Sender" where there's no sending or receiving associated to it. |
| − | *Question: If I want to identify and address HL7 Senders and HL7 Receivers, | + | *Question: If I want to identify and address HL7 Senders and HL7 Receivers in my HL7 message, what is the proper way to do that? |
| − | **Answer: The HL7 Sender and HL7 [[Receiver]] have the same identification as the HL7 Application | + | **Answer: The HL7 Sender and HL7 [[Receiver]] have the same identification as the HL7 Application. I.e. there's one to one mapping between [[HL7 application]] and HL7 Sender or [[Receiver]]. The identification value is contained in the Device.id attribute of the Transmission Wrapper, which is the logical start and end point of HL7 communication instance. The Device.id is never the identification of the [[Messaging Adapter]] (as the second concept in the Sender or [[Receiver]]). |
---- | ---- | ||
[[Category:ATS Glossary]] | [[Category:ATS Glossary]] | ||
Revision as of 09:09, 24 July 2007
A Sender in the context of HL7 embeds the sending HL7 Application and the Messaging Adapter responsible for Messaging Protocol configuration. A Sender implements business rules according to the HL7 Trigger Event and Interaction definition, and prepares the HL7 message for the delivery facilitated by the Messaging Protocol in the Messaging Infrastructure Layer.
Notes
- Question: Why do we need to haveMessaging Adapter embedded in the concepts of Sender and Receiver?
- Answer: The reason why we have included the Messaging Adapter to the Sender and Receiver is very simple - without the Messaging Adapter the HL7 Application, which by definition produces and consumes HL7 messages (including object representation and serialization using the HL7 ITS) would not able to send the message anywhere. The concept of HL7 application brings true value only if it is able to communicate with other applications, so no point of calling something "a Sender" where there's no sending or receiving associated to it.
- Question: If I want to identify and address HL7 Senders and HL7 Receivers in my HL7 message, what is the proper way to do that?
- Answer: The HL7 Sender and HL7 Receiver have the same identification as the HL7 Application. I.e. there's one to one mapping between HL7 application and HL7 Sender or Receiver. The identification value is contained in the Device.id attribute of the Transmission Wrapper, which is the logical start and end point of HL7 communication instance. The Device.id is never the identification of the Messaging Adapter (as the second concept in the Sender or Receiver).
