Difference between revisions of "Messaging Adapter"
Rene spronk (talk | contribs) (add image) |
Rene spronk (talk | contribs) m |
||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
[[Image:Ats_architecture.gif|275px|right|thumb|Application Architecture]] | [[Image:Ats_architecture.gif|275px|right|thumb|Application Architecture]] | ||
| − | + | ||
| + | '''Important Notice''' - This page (and related pages) will be heavily rewritten according to the new HL7 Messaging architecture. This is elaborated in detail in the [[Abstract Transport Specification]] Document. | ||
| + | |||
| + | '''Glossary definition:''' a Message Adapter is a distinct module in the application layer to separate transport related actions from the actual creation/processing of HL7 composite messages, which are managed by the [[HL7 Application]] at the business level. It implements application level functionality tied to a specific [[Messaging Infrastructure]] (e.g. ebXML, Web Services, MLLP). | ||
| + | |||
| + | == Details == | ||
Message Adapters are not required to posses any HL7 specific knowledge other than one or more particular [[ITS]]s needed to support the message delivery environment. In particular, they are not required to know anything about HL7 static and dynamic modeling rules and mechanisms, other than being aware of the HL7 [[Transmission Wrapper]], which is where an HL7 application indicates the application level rules for message transport. | Message Adapters are not required to posses any HL7 specific knowledge other than one or more particular [[ITS]]s needed to support the message delivery environment. In particular, they are not required to know anything about HL7 static and dynamic modeling rules and mechanisms, other than being aware of the HL7 [[Transmission Wrapper]], which is where an HL7 application indicates the application level rules for message transport. | ||
| Line 13: | Line 18: | ||
Message Adapters in general do not act any differently on initial messages (e.g. unsolicited update, query) as they do on the [[Application Response]]s. It is not within the scope of Message Adapters to process the [[Receiver Responsibilities|receiver responsibility rules]] for interactions and their related responses; this is clearly the responsibility of the [[HL7 Application]] and appropriate [[Application Role]]s. | Message Adapters in general do not act any differently on initial messages (e.g. unsolicited update, query) as they do on the [[Application Response]]s. It is not within the scope of Message Adapters to process the [[Receiver Responsibilities|receiver responsibility rules]] for interactions and their related responses; this is clearly the responsibility of the [[HL7 Application]] and appropriate [[Application Role]]s. | ||
| + | |||
| + | |||
| + | [[Category:INM Glossary]] | ||
Latest revision as of 21:07, 10 September 2006
Important Notice - This page (and related pages) will be heavily rewritten according to the new HL7 Messaging architecture. This is elaborated in detail in the Abstract Transport Specification Document.
Glossary definition: a Message Adapter is a distinct module in the application layer to separate transport related actions from the actual creation/processing of HL7 composite messages, which are managed by the HL7 Application at the business level. It implements application level functionality tied to a specific Messaging Infrastructure (e.g. ebXML, Web Services, MLLP).
Details
Message Adapters are not required to posses any HL7 specific knowledge other than one or more particular ITSs needed to support the message delivery environment. In particular, they are not required to know anything about HL7 static and dynamic modeling rules and mechanisms, other than being aware of the HL7 Transmission Wrapper, which is where an HL7 application indicates the application level rules for message transport.
The Message Adapter may also play a role of serializing/deserializing transport-specific message representation into the application natively understood format. This could be as simple as passing through HL7 message as a string or as complicated as building a full object graph representing HL7 message before passing it to the application.
The Message Adapter may also play a role in the Validation process of interactions that it has received via the Messaging Infrastructure. The level of validation may vary from zero validation (in which case all validation is done by the HL7 Application), to a minimalist validation of syntax and interaction type, up to full syntactic validation (in which case the HL7 Application doesn't need to do any validation anymore).
A Message Adapter may generate its own HL7 error interaction: the Accept Level Reject (MCCI_IN000002). The Accept level Reject message only consists of a Transmission Wrapper; it contains neither a Trigger Event Control Act Wrapper nor a domain-defined payload. An Accept Level Reject may be generated by a Message Adapter if
- a transmission issue was detected, e.g. the interaction contains an unknown receiver identification, or the sender isn't considered to be a trusted application.
- a validation issue was detected, e.g. the interaction isn't supported, there are syntactical issues, or the interaction isn't formatted according to the agreed upon conformance profile. The level of validation is implementation dependent.
Message Adapters in general do not act any differently on initial messages (e.g. unsolicited update, query) as they do on the Application Responses. It is not within the scope of Message Adapters to process the receiver responsibility rules for interactions and their related responses; this is clearly the responsibility of the HL7 Application and appropriate Application Roles.
