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

Difference between revisions of "Open ATS Issues"

From HL7Wiki
Jump to navigation Jump to search
 
(14 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 +
{{INM Workitem}}
 
*Translations: add "derived from .. ID" attribute ?, much like acknowledgementOf. See also MCCI line-item 157.
 
*Translations: add "derived from .. ID" attribute ?, much like acknowledgementOf. See also MCCI line-item 157.
 
*[[Message.id]] "sameness" discussion after transformation by a Gateway.  
 
*[[Message.id]] "sameness" discussion after transformation by a Gateway.  
Line 4: Line 5:
 
**This has the consequence that the sameness of Transmission.id is not linked to the wider topic of semantic-transmission sameness.
 
**This has the consequence that the sameness of Transmission.id is not linked to the wider topic of semantic-transmission sameness.
 
*Use of the AttentionLine class to add route-tracing information in a Transmission that's being routed/gatewayed to its destination. Are Gateways/Bridges able to add their own information to the Transmission Wrapper in the form of an additional AttentionLine?
 
*Use of the AttentionLine class to add route-tracing information in a Transmission that's being routed/gatewayed to its destination. Are Gateways/Bridges able to add their own information to the Transmission Wrapper in the form of an additional AttentionLine?
 +
**20070919 WGM The specific use case calls for an item to consider route-tracing:  This is only relevant when an HL7 Application is involved.  The opinion of the committee is that the use of the AttentionLine is inappropriate.  An explicit means should be derived.
  
−
----
+
== ATS Concepts and Definitions ==
  
−
(Miroslav) Adding the defintions of the terms used throught ATS. The aim of this section is to identify the most important ATS notions and artefacts, and word smith their defintions. Once we reach the consensus, we'll transfer them to the normative material for official balloting.
+
The items and concepts that are listed below represent some of the major challenges for the ATS document. They are addressed within the Wrappers R2 project plus many Action Items with the InM as well.
  
−
*'''[[Transport]]''' (in regard to the ATS ballot reconciliation package line item 2, database record number 5)
+
*[[Transport]]
−
**Definition: "Transport is the abstract term used by the HL7 community for the infrastructure serving the HL7 messages transfer from the Sending Application Role to the Receiving Application Role. In other words, from the HL7 perspective transport refers to OSI layers 1-6. The OSI layers 1-6 are perceived by the HL7 applications as the unified interface for message transfer, meaning that a HL7 application is not required to (and usually doesn't) posses any specific knowledge for technology components residing at OSI layers 1-5."
+
*[[Message Exchange Pattern]]
−
**Discussion:
+
*[[Message Infrastructure Fault]]
−
*'''[[Message Exchange Pattern]]''' (Action Item 1026)
+
*[[HL7 Application]]
−
**Definition
+
*[[Sender]]
−
**also see [[Transmission Pattern]]
+
*[[Receiver]]
−
*'''[[Application Fault]]''' (in regard to the ATS ballot reconciliation package line item 49, database record number 61)
+
*[[Source]]
−
**Definition: "Application Fault (Section 2.2.1.2) is an abstract term for a communication error encountered at the Message Infrastructure Layer (MIL) that needs to be communicated back to the application layer. The reason for this need is that this error type cannot be solved by the MIL layer just by retrying to send the HL7 message, and therefore further decision making needs to be sent back to the business entities."
+
*[[Destination]] (unified glossary definition from both ATS as well as webservices perspective)
−
**Discussion: (Miroslav) We might want to look for another term to refer to this type of an error, since this error is not encountered at the business layer.
+
*Intermediaries Roles
−
*'''[[Gateway]], [[Bridge]], [[Interface Engine]], [[Transformer Bridge]], [[Message Broker]]''' (in regard to the ATS ballot reconciliation package line items 53-57)
+
**[[Gateway]]
−
**Defintion: "Gateway is an HL7-artefacts aware application which executes business rules, and forwards/ copies/ amends/ transforms interactions (messages or batched messages) based on those business rules. In order to perform those business rules, Gateway is always an HL7 application that is listed as the receiver of the incomming interactions and sender of the ourgoing interactions (just like any other HL7 application)"
+
**[[Bridge]]
−
**Definition: " Bridge is an application that contains 2 or more Messaging Adapters: it provides message protocol translation (i.e. relaying) and/or message routing capabilities. The primary purpose of HL7 Bridges is to provide transports protocol translation management (i.e. relaying) in heterogeneous healthcare communication environments. An example would be the relaying of messages from Web Services to ebXML transport and vice versa."
+
**[[Interface Engine]]
−
**Discussion
+
**[[Transformer Bridge]]
−
***(Miroslav) The same interface engine can sometimes play a role of a Gateway, and in other scenarios just be a Bridge or an Intermediary. The key distinction are the business level scenarios, interactions and use cases. If an interface engine is required to perform business rules and application level responsibilities, than it's a Gateway and is listed as the Receiver in the HL7 Message. If it just needs to transform from one ITS to another, it's a Bridge. If it needs to transform from one transport protocol to another, it's an Intermediary.
+
**[[Message Broker]]
−
***(Miroslav) Message Broker is yet again another interface engine that distributes the incomming messages to specified destinations according to the business rules. A Message Broker is usually required to perform a Bridge functionality. However, the question is, what role the Message Broker is playing if it needs to send an incomming HL7 message to x locations (e.g. as the notification that an lab order took place). It needs to change a HL7 message, list itself as the sender - therefore it's the Gateway role?
+
 
 +
Last change: --[[User:Miroslav|Miroslav Koncar]] 06:21, 2 May 2007 (CDT)

Latest revision as of 13:43, 19 September 2007

INM workitem.gif

This page documents an INM Workitem, i.e. an issue within scope of the INM Committee that either is still being discussed, or the resolution of which has not yet been included in an INM ballot.

  • Translations: add "derived from .. ID" attribute ?, much like acknowledgementOf. See also MCCI line-item 157.
  • Message.id "sameness" discussion after transformation by a Gateway.
    • New motion of MnM: 20060113: "At the semantic (or: business process level) the contents of the Transmission wrapper, with the exception of InteractionID, are not relevant when determining if 2 interactions are the same. At the transmission-level 2 Transmissions are the same if they have the same Transmission.id."
    • This has the consequence that the sameness of Transmission.id is not linked to the wider topic of semantic-transmission sameness.
  • Use of the AttentionLine class to add route-tracing information in a Transmission that's being routed/gatewayed to its destination. Are Gateways/Bridges able to add their own information to the Transmission Wrapper in the form of an additional AttentionLine?
    • 20070919 WGM The specific use case calls for an item to consider route-tracing: This is only relevant when an HL7 Application is involved. The opinion of the committee is that the use of the AttentionLine is inappropriate. An explicit means should be derived.

ATS Concepts and Definitions

The items and concepts that are listed below represent some of the major challenges for the ATS document. They are addressed within the Wrappers R2 project plus many Action Items with the InM as well.

Last change: --Miroslav Koncar 06:21, 2 May 2007 (CDT)

Retrieved from "https://wiki.hl7.org/w/index.php?title=Open_ATS_Issues&oldid=14049"