This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Sender"

From HL7Wiki
Jump to navigation Jump to search
Line 3: Line 3:
  
 
== Notes ==
 
== Notes ==
*Question: Why do we embed Messaging Adapter in the concepts of the Sender and Receiver as well?
+
*Question: Why did we embed [[Messaging Adapter]] 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 is by definition able to produce and consume HL7 message (including object representation and serialization using the ITS) is not able to send the message anywhere, so no point of calling something "a Sender" where there's no sending or receiving associated to it.
 
**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 is by definition able to produce and consume HL7 message (including object representation and serialization using the ITS) is not able to send the message anywhere, 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, how do I do that?
+
*Question: If I want to identify and address HL7 Senders and HL7 Receivers, how do I do that in HL7 layer?
**Answer: The HL7 Sender and HL7 [[Receiver]] have the same identification as the HL7 Application contained in specific scenarion. I.e. there's one to one mapping of [[HL7 application]] and HL7 Sender or [[Receiver]]. This identification is contained in Device.id class, which is never the identification of the [[Messaging Adapter]] (as the second concept in the Sender or [[Receiver]])
+
**Answer: The HL7 Sender and HL7 [[Receiver]] have the same identification as the HL7 Application contained in specific scenarion. I.e. there's one to one mapping of [[HL7 application]] and HL7 Sender or [[Receiver]]. Speaking strictly in HL7 terms, this identification is contained in Device.id attribute, which is never the identification of the [[Messaging Adapter]] (as the second concept in the Sender or [[Receiver]]).
  
 
--[[User:Miroslav|Miroslav Koncar]] 06:10, 2 May 2007 (CDT)
 
--[[User:Miroslav|Miroslav Koncar]] 06:10, 2 May 2007 (CDT)

Revision as of 11:13, 2 May 2007

HL7 Messaging Architecture

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 did we embed Messaging Adapter 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 is by definition able to produce and consume HL7 message (including object representation and serialization using the ITS) is not able to send the message anywhere, 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, how do I do that in HL7 layer?
    • Answer: The HL7 Sender and HL7 Receiver have the same identification as the HL7 Application contained in specific scenarion. I.e. there's one to one mapping of HL7 application and HL7 Sender or Receiver. Speaking strictly in HL7 terms, this identification is contained in Device.id attribute, which is never the identification of the Messaging Adapter (as the second concept in the Sender or Receiver).

--Miroslav Koncar 06:10, 2 May 2007 (CDT)