Acknowledgement Reference Model OCTOBER 2010

Acknowledgement Reference Model OCTOBER 2010 ASC X12C/2012-xx Copyright © 2012, Data Interchange Standards Association on behalf of ASC X12. Format...
Author: Maximilian Bell
2 downloads 2 Views 437KB Size
Acknowledgement Reference Model OCTOBER 2010

ASC X12C/2012-xx

Copyright © 2012, Data Interchange Standards Association on behalf of ASC X12. Format © 2012 Washington Publishing Company. Exclusively published by the Washington Publishing Company. All Rights Reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without prior written permission of the copyright owner. All rights reserved.

RELEASE • 006020

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

Table of Contents 1. Preface ..................................................................................................................... 1 2. General .................................................................................................................... 3 3. Purpose and Scope ................................................................................................. 5 4. Reference and Related Standards ........................................................................... 7 5. Comments ................................................................................................................ 9 6. Introduction ............................................................................................................ 11 7. Definitions of Terms ................................................................................................ 21 8. Data Flow Model .................................................................................................... 27 8.1. Data Flow Model - Point-to-Point ..................................................................... 27 8.1.1. Data Flow Models - Point-to-Point for Health Care Insurance Transaction Sets ................................................................................................................ 30 8.2. Data Flow Model - Clearinghouse ................................................................... 41 8.3. Data Flow Model - Single VAN ........................................................................ 44 8.4. Data Flow Model - Multi VAN .......................................................................... 47 8.5. Entity/Process Interfaces ................................................................................ 51 8.5.1. A Necessary Implementation (Example) .............................................. 53 8.5.2. A Sufficient Implementation (Example) ................................................ 53 8.5.3. Implementation in the Marketplace ...................................................... 54

OCTOBER 2010

iii

RELEASE • 006020

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

1 Preface For many years X12 messages have been transmitted between business entities. As industries increased the complexity of these messages, the need for a uniform approach to acknowledging these interchanges of data was evident. This document’s intent is to provide that guidance to any business entity that needs guidance on the foundational concepts of the intended use of the control structures and transactions sets that are used in auditing and tracking of EDI messaging. This document is not meant however to be industry specific, but rather meant to meet the needs of the entire X12 EDI community. Implementation of these control structures and transaction sets is optional. Some of these standards are heavily used in EDI environments today, while use of other standards is less common. This document reviews the intended integration of these standards that results in a detailed audit trail of the data migration from the interchange sender to the interchange receiver. Your specific industry sector may have also published guidance documents that give further specificity concerning the exchange of named transactions that are utilized within that industry sector.

OCTOBER 2010

1

RELEASE • 006020

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

2 General This document is an X12 Type 2 Technical Report, commonly referred to as a reference model. It was developed by the X12C/TG4, the Management Messages Task Group of the X12C Communications & Controls Subcommittee.

OCTOBER 2010

3

RELEASE • 006020

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

3 Purpose and Scope The purpose of this document is to summarize the use of the ASC X12 control structures and standards for the acknowledgment and tracking of EDI interchanges and to provide guidance to organizations implementing X12 for business processes or industries requiring receipts or acknowledgements. This document reviews long-standing control structures and practices, such as the Interchange Acknowledgement Segment (TA1), the Functional Acknowledgment Transaction Set (997), and more recent standards, such as X12.56 Interconnect Mailbag Structures (TA3), and the Implementation Acknowledgement (999). ASC X12 has defined and approved several control structures and transaction set standards intended to augment EDI auditing and control systems. It is the intent of these standards to provide a tracking mechanism for EDI data as it moves through the transmission cycle. Through the implementation of these tracking tools, and analysis of the resulting information, delays or failures in delivery can be identified and corrected. This document is to give guidance on the implementation of these tools. ASC X12 has published a number of transactions for the purpose of acknowledging a transmission. This document hopes to clarify the use and requirement of the various X12 published acknowledgment transactions.

OCTOBER 2010

5

RELEASE • 006020

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

4 Reference and Related Standards This Technical Report is used with the ASC X12 family of standards on electronic data interchange. This document reviews and clarifies the long-standing X12 control structures and practices. This reference model is not based on, or dependent on, any particular version of the ASC X12 Standards referenced; information is useful for applications regardless of which version/release of the standards is being used. It is noted however, that at the time of writing this document, the current standard utilized and referenced was 005010. ASC X12 transaction sets and other standards referenced in this document include: X12.5, Interchange Control Structures X12.6, Application Control Structure X12.56, Interconnect Mailbag Structures X12.1, Data Status Tracking Transaction Set 242 X12.1, Functional Acknowledgment Transaction Set 997 X12.1, Implementation Acknowledgement Transaction Set 999 X12.1, Health Care Information Status Notification Transaction Set 277 X12.1, Application Advice Transaction Set 824 In addition, other potentially applicable transaction set standards are listed in section 6. These standards are available from the ASC X12 Secretariat, DISA, found within section 5 of this document.

OCTOBER 2010

7

RELEASE • 006020

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

5 Comments Comments, questions, and suggestions for improvement of this document may be submitted to the ASC X12 Secretariat, DISA; they will be forwarded to the appropriate X12 subcommittee. Forward comments to: Director, Publications & Standards DISA 7600 Leesburg Pike Suite 430 Falls Church, Virginia 22043 USA Phone: 703-970-4480 Fax: 703-970-4488

OCTOBER 2010

9

RELEASE • 006020

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

6 Introduction ASC X12 has published a number of acknowledgement and/or response transaction sets. These transaction sets are used at various points in the lifecycle of an X12 transmission. One or more may be sent as a response to a single transmission. Each acknowledgment serves its own unique purpose as the original transmission moves through the various systems the receiver may employ to digest the transmission. Some of these acknowledgements are used across industries, while others are designed to be implemented for a particular industry. Industry-specific acknowledgements have implementation guidelines prepared by an industry group to solve a particular business need. In order to prevent infinite looping of acknowledgement standard transmissions, the following acknowledgement indications or messages must never be acknowledged: TA1, TA3, 997 and 999 This paper discusses the non-exhaustive list of acknowledgement transaction sets and standards listed below, with specific reference to the financial and health care industries’ acknowledgments. Interchange Envelope Conformance and Acknowledgement Reports basic envelope validation at the interchange level (i.e. ISA/IEA) and simple acknowledgement of the transmission. Respond to this validation layer with the TA1 or TA3 segments or both. • TA1 (Interchange Acknowledgment) An Interchange Acknowledgment segment (TA1) is used to report the receipt of the contents of one interchange control header and trailer envelope where that envelope surrounds one or more functional groups. This acknowledgment is transferred between the interchange receiver and sender as addressed in the interchange header. The TA1 reports the results of the syntactical analysis of the interchange control header and trailer. There is no acknowledgment for the TA1, thereby preventing an endless loop of acknowledgments. The TA1 Interchange Acknowledgement is sent at the request of the Interchange Sender. • TA3 (Interchange Delivery Notice) To provide a notice from the receiving service request handler to the sending service request handler that an interchange was delivered or not delivered to the interchange receiver's mailbox, or some other ancillary service was performed, and that the interchange receiver retrieved, refused, or purged the interchange; TA3 is exchanged only between service request handlers; use of the TA3 segment is optional.

OCTOBER 2010

11

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

RELEASE • 006020

X12 Standard Conformance Reports X12 standard syntax validation at the functional group and transaction set levels (i.e. GS/GE & ST/SE). Respond to this validation layer with either the 997 or 999 transaction sets, but not both. • 997 (Functional Acknowledgment) This X12 Transaction Set can be used to define the control structures for a set of acknowledgments to indicate the results of the syntactical analysis of the electronically encoded documents.The encoded documents are the transaction sets, which are grouped in functional groups, used in defining transactions for business data interchange. This standard does not cover the semantic meaning of the information encoded in the transaction sets. • 999 (Implementation Acknowledgment) This X12 Transaction Set contains the format and establishes the data contents of the Implementation Acknowledgment Transaction Set (999) for use within the context of an Electronic Data Interchange (EDI) environment. The transaction set can be used to define the control structures for a set of acknowledgments to indicate the results of the syntactical and relational analysis of the electronically encoded documents, based upon a full or implemented subset of X12 transaction sets.The encoded documents are the transaction sets, which are grouped in functional groups, used in defining transactions for business data interchange. This standard does not cover the semantic meaning of the information encoded in the transaction sets. In this instance, the transaction set is utilized for X12 Standard Conformance. Note Only one acknowledgement can be sent for each functional group. The acknowledgment can be either a single Transaction Set 997 or a single Transaction Set 999 as mutually agreed upon by the trading partners. Different Functional Groups may have different acknowledgements, e.g. some Functional Groups, within the same interchange, may be acknowledged with the 997 and others with the 999. Implementation Guide Conformance Reports functional group or transaction set validation against implementation guidelines (GS/GE & ST/SE). Respond to this validation layer with the 999 transaction set. The Implementation Guide conformance includes the verification of X12 standard syntax conformance, because the Implementation Guide must conform with X12 standard syntax. • 999 (Implementation Acknowledgment) This X12 Transaction Set contains the format and establishes the data contents of the Implementation Acknowledgment Transaction Set (999) for use within the context of an

12

OCTOBER 2010

RELEASE • 006020

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

Electronic Data Interchange (EDI) environment. The transaction set can be used to define the control structures for a set of acknowledgments to indicate the results of the syntactical and relational analysis of the electronically encoded documents, based upon a full or implemented subset of X12 transaction sets.The encoded documents are the transaction sets, which are grouped in functional groups, used in defining transactions for business data interchange. This standard does not cover the semantic meaning of the information encoded in the transaction sets. In this instance, the transaction set is utilized for Implementation Guide Conformance. Note Only one acknowledgement can be sent for each functional group. The acknowledgment can be either a single Transaction Set 997 or a single Transaction Set 999 as mutually agreed upon by the trading partners. Different Functional Groups may have different acknowledgements, e.g. some Functional Groups, within the same interchange, may be acknowledged with the 997 and others with the 999. Application Validation and Processing Reports validation at the application level. Respond to this validation layer with the appropriate response transaction,for example the 824, 151, 271, 277, 278, 301, 426, 832 or other application response transaction sets. It is possible to use an application transaction to respond as the acknowledgement of a failed implementation validation. For example an 832 catalog response with a AAA segment responding to an invalid 832 catalog request. This is to make it clear that some application transactions normally used as “work complete” responses can also be used as response at this level of acknowledgement. • 824 (Application Reporting) This X12 Transaction Set contains the format and establishes the data contents of the Application Advice Transaction Set (824) for use within the context of an Electronic Data Interchange (EDI) environment. The transaction set can be used to provide the ability to report the results of an application system’s data content edits of transaction sets. The results of editing transaction sets can be reported at the transaction set, batch, or item levels. It is designed to accommodate the business need of reporting the acceptance, rejection or acceptance with change of any transaction set.The Application Advice should not be used in place of a transaction set designed as a specific response to another transaction set (e.g., purchase order acknowledgment sent in response to a purchase order).

OCTOBER 2010

13

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

RELEASE • 006020

• 271 (Eligibility, Coverage or Benefit Information) This X12 Transaction Set contains the format and establishes the data contents of the Eligibility, Coverage or Benefit Information Transaction Set (271) for use within the context of an Electronic Data Interchange (EDI) environment. This transaction set can be used to communicate information about or changes to eligibility, coverage or benefits from information sources (such as - insurers, sponsors, payors) to information receivers (such as - physicians, hospitals, repair facilities, third party administrators, governmental agencies). This information includes but is not limited to: benefit status, explanation of benefits, coverage, dependent coverage level, effective dates, amounts for co-insurance, co-pays, deductibles, exclusions and limitations. In this instance the transaction set is utilized as a application acknowledgement. • 277 (Health Care Information Status Notification) This X12 Transaction Set contains the format and establishes the data contents of the Health Care Information Status Notification Transaction Set (277) for use within the context of an Electronic Data Interchange (EDI) environment. This transaction set can be used by a health care payer or authorized agent to notify a provider, recipient, or authorized agent regarding the status of a health care claim or encounter or to request additional information from the provider regarding a health care claim or encounter, health care services review, or transactions related to the provisions of health care. This transaction set is not intended to replace the Health Care Claim Payment/Advice Transaction Set (835) and therefore, will not be used for account payment posting. The notification may be at a summary or service line detail level. The notification may be solicited or unsolicited. • 151 (Electronic Filing of Tax Return Data Acknowledgment) This X12 Transaction Set contains the format and establishes the data contents of the Electronic Filing of Tax Return Data Acknowledgment Transaction Set (151) within the context of an Electronic Data Interchange (EDI) environment. This transaction set is used to electronically acknowledge receipt of each tax return filed using the Electronic Filing of Tax Return Data Transaction Set (813) and may indicate any error conditions. This transaction set can be used by a federal, state, or local taxing authority to acknowledge the status of an electronically filed tax return which has been electronically filed using Transaction Set 813. • 832 – (Price/Sales Catalog) This X12 Transaction Set contains the format and establishes the data contents of the Price/Sales Catalog Transaction Set (832) for use within the context of an Electronic Data Interchange (EDI) environment. The transaction set can be used to provide for customary and established business and industry practice relative to furnishing or

14

OCTOBER 2010

RELEASE • 006020

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

requesting the price of goods or services in the form of a catalog. In this instance the transaction set is utilized as an application acknowledgement. • 855 – (Purchase Order Acknowledgment) This X12 Transaction Set contains the format and establishes the data contents of the Purchase Order Acknowledgment Transaction Set (855) for use within the context of an Electronic Data Interchange (EDI) environment. The transaction set can be used to provide for customary and established business and industry practice relative to a seller's acknowledgment of a buyer's purchase order. This transaction set can also be used as notification of a vendor generated order. This usage advises a buyer that a vendor has or will ship merchandise as prearranged in their partnership. Work Complete Work complete does not mean accepted, it simply means that all work efforts for that transaction are done – it’s a state. Work complete is referenced as informational only. There are a number of response transactions, including, but not limited to the following: • 242 (Data Status Tracking) This X12 Transaction Set contains the format and establishes the data contents of the Data Status Tracking Transaction Set (242) within the context of an Electronic Data Interchange (EDI) environment.This management transaction set is the vehicle by which the transmission status information is conveyed by a service request handler to the interchange sender, interchange receiver, or both; it can be used to provide status information regarding interchange as it flows from an interchange sender through one or more service request handlers to an interchange receiver during its transmission cycle. It can be used by the interchange sender or interchange receiver to request from a service request handler ad hoc or periodic reports containing status information regarding interchanges. • 271 (Eligibility, Coverage or Benefit Information) This X12 Transaction Set contains the format and establishes the data contents of the Eligibility, Coverage or Benefit Information Transaction Set (271) for use within the context of an Electronic Data Interchange (EDI) environment. This transaction set can be used to communicate information about or changes to eligibility, coverage or benefits from information sources (such as - insurers, sponsors, payors) to information receivers (such as - physicians, hospitals, repair facilities, third party administrators, governmental agencies). This information includes but is not limited to: benefit status, explanation of benefits, coverage, dependent coverage level, effective dates, amounts for co-insurance, co-pays, deductibles, exclusions and limitations. In this instance the transaction set is utilized as a response transaction.

OCTOBER 2010

15

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

RELEASE • 006020

• 277 (Health Care Information Status Notification) This X12 Transaction Set contains the format and establishes the data contents of the Health Care Information Status Notification Transaction Set (277) for use within the context of an Electronic Data Interchange (EDI) environment. This transaction set can be used by a health care payer or authorized agent to notify a provider, recipient, or authorized agent regarding the status of a health care claim or encounter or to request additional information from the provider regarding a health care claim or encounter, health care services review, or transactions related to the provisions of health care. This transaction set is not intended to replace the Health Care Claim Payment/Advice Transaction Set (835) and therefore, will not be used for account payment posting. The notification may be at a summary or service line detail level. The notification may be solicited or unsolicited. • 278 (Health Care Services Review Information) This X12 Transaction Set contains the format and establishes the data contents of the Health Care Services Review Information Transaction Set (278) for use within the context of an Electronic Data Interchange (EDI) environment. This transaction set can be used to transmit health care service information, such as subscriber, patient, demographic, diagnosis or treatment data for the purpose of request for review, certification, notification or reporting the outcome of a health care services review. • 301 (Confirmation – Ocean) This X12 Transaction Set contains the format and establishes the data contents of the Confirmation (Ocean) Transaction Set (301) for use within the context of an Electronic Data Interchange (EDI) environment. The transaction set can be used to provide all the information necessary for an ocean carrier to confirm space, container, and equipment availability in response to the Reservation (Booking Request) (Ocean) Transaction Set (300); or to notify other parties such as terminal operators or other ocean carriers. • 426 (Rail Revenue Waybill) This X12 Transaction Set contains the format and establishes the data contents of the Rail Revenue Waybill Transaction Set (426) for use within the context of an Electronic Data Interchange (EDI) environment. The transaction set can be used to respond to a request for a rail revenue waybill (Transaction Set 425). Revenue waybill information includes movement, rates, and charges information required to collect revenue from the paying party or parties. • 754 (Routing Instructions) This X12 Transaction Set contains the format and establishes the data contents of the Routing Instructions Transaction Set (754) for use within the context of an Electronic

16

OCTOBER 2010

RELEASE • 006020

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

Data Interchange (EDI) environment. This transaction set is used to communicate routing instructions to a supplier for a specific shipment. It can be used also to respond to a Request for Routing Instructions Transaction Set (753). • 832 – (Price/Sales Catalog) This X12 Transaction Set contains the format and establishes the data contents of the Price/Sales Catalog Transaction Set (832) for use within the context of an Electronic Data Interchange (EDI) environment. The transaction set can be used to provide for customary and established business and industry practice relative to furnishing or requesting the price of goods or services in the form of a catalog. In this instance the transaction set is utilized as a response transaction. • 835 (Health Care Claim Payment/Advice) This X12 Transaction Set contains the format and establishes the data contents of the Health Care Claim Payment/Advice Transaction Set (835) for use within the context of the Electronic Data Interchange (EDI) environment. This transaction set can be used to make a payment, send an Explanation of Benefits (EOB) remittance advice, or make a payment and send an EOB remittance advice only from a health insurer to a health care provider either directly or via a financial institution. The 835 produces a status of work complete when it’s being used as an advice of payment received Note The X12 response transactions are included in the diagram for reference only. Response transaction implementation advice is not within scope of this document. Work complete is referenced as informational only. Refer to individual implementation guides for the use of these transaction sets.

OCTOBER 2010

17

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

RELEASE • 006020

Figure 1a This diagram depicts the acknowledgement model utilizing the 997 Functional Acknowledgement. This diagram depicts the exhaustive acknowledgment model. Some transactions noted within the model are optional. Note The Implementation Guide Conformance check is not present – see Figure 1b. *The X12 response transactions are included in the diagram for reference only. Response transaction implementation advice is not within scope of this document. Work complete is referenced as informational only and is not within scope of this document.

18

OCTOBER 2010

RELEASE • 006020

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

Figure 1b This diagram depicts the acknowledgement model utilizing the 999 Implementation Acknowledgements with Implementation Guide Conformance. This diagram depicts the exhaustive acknowledgment model. Some transactions noted within the model are optional. *The X12 response transactions are included in the diagram for reference only. Response transaction implementation advice is not within scope of this document. Work complete is referenced as informational only and is not within scope of this document. Note Only one acknowledgement can be sent for each functional group. The acknowledgment can be either a single Transaction Set 997 or a single Transaction Set 999 as mutually agreed upon by the trading partners

OCTOBER 2010

19

RELEASE • 006020

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

7 Definitions of Terms New terms have been defined in ANSI ASC standards body to describe the EDI standards and models. As these terms are utilized by other organizations, they tend to take on multiple meanings. The following definitions are based on the ANSI ASC X12 Standards documents listed above or have been introduced within this document. For a complete and detailed discussion of these definitions, please refer to the originating documents listed in section 4 of this document. Application Advice A Transaction set (TS824) that provides the ability to report the results of an applications system's data content edits of transaction sets. Application Specific Acknowledgment A family of transaction sets that provides for the application level acknowledgment and reconciliation of business data. These transaction sets are generated by the interchange receiver in response to a sender's interchange. Application Validation and Processing The level to which the data carried within the transaction set is compared and evaluated to the application requirement and or/business level. The articulation of application validation or processing is expressed with transactions that are not dependent on the functional group and are capable of the reporting of application layer communications. Examples (not limited to):TS824 Application Advice or TS277 Health Care Information Status Notification. Cross Functional Transaction Set A Transaction set that is used to relate information about a preceding transaction set, and is designed to support transactions sets independent of functional grouping. Examples: TS824, Application Advice, TS277 Health Care Information Status Notification DST (Data Status Tracking) A management transaction set (TS242) used to provide status information regarding interchange flow from an interchange sender to the interchange receiver. It is the vehicle by which the status information is conveyed by a service request handler to the interchange sender, interchange receiver, or both. Deliver The action whereby the original interchange is made available to the interchange receiver. An interchange is considered "delivered" when it has been successfully conveyed to the mailbox, or, if a mailbox is not in use, to the interchange receiver.

OCTOBER 2010

21

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

RELEASE • 006020

It is important to recognize that, for the context of this document, deliver does NOT mean retrieved by the receiver, nor does it mean that an Agent (such as a VAN) has accepted receipt of the data. Functional Acknowledgment A Transaction Set (TS997) that provides the control structures for a set of acknowledgments to indicate the results of the syntactical analysis of the electronically encoded documents. Implementation Acknowledgment A Transaction Set (TS999) that provides the control structures for a set of acknowledgments to indicate the results of the syntactical analysis of the electronically encoded documents as well as the implementation guide conformance of the structures. Implementation Guide Conformance The level to which a transmission is compared and evaluated to an implementation guideline syntax at the functional group level and transaction set level (GS/GE and ST/SE). The Implementation Guide conformance includes the verification of X12 standard syntax conformance, because the Implementation Guide must conform with X12 standard syntax. The articulation of the conformance is expressed with a transaction set that is capable of the reporting the syntactical analysis electronically. This conformance checking is also dependent on the functional grouping. Example: TS999 Implementation Acknowledgement Interchange The basic control structure designed to satisfy the basic requirements of enveloping and routing the included electronic business document. Interconnect Entity Any organization that communicates EDI data with another organization where neither communicating party is responsible for processing and acting upon the semantic data (business transactions which may be contained in the mailbag). Interchange Receiver The interchange receiver is the entity that is the intended recipient of the interchange as specified by the interchange sender in the interchange header segment. Interchange Sender The interchange sender is the entity that constructs the interchange header, interchange trailer, and interchange service requests.

22

OCTOBER 2010

RELEASE • 006020

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

Mailbag (Interconnect Mailbag Control Structure) This standard provides control structure and an audit mechanism to facilitate the exchange and receipt acknowledgment of EDI Data between interconnecting entities. The original sender and the ultimate receiver of the data contained in the mailbag have no responsibility for creating, managing, or removing the interconnect mailbag segments. This standard is solely for use between sites acting as interconnect entities. This standard is also referred to as Interconnect Mailbag. Mailbox A mailbox is an entity capable of providing protected storage under the control of an interchange receiver for an interchange in transit between the interchange sender and interchange receiver. A protected receiving location with a unique address such that, once an interchange is placed in the mailbox of the receiver, it may only be retrieved by the receiver. Normative Is a term used to describe the use of a standard when there is consensus and the standard is appropriate for the particular business need. Receipt and Safe Storage An interconnect mailbag is received and safely stored when: (a) the control numbers in the interconnect mailbag header and trailer match; (b) the control totals listed in the interconnect mailbag trailer are consistent with the number of interconnect mailbag acknowledgments and interchanges in the interconnect mailbag; and (c) the entire interconnect mailbag has been successfully stored such that its contents can be obtained in their entirety at some later time for processing or delivery or both. An interchange or transmission is received and safely stored when its contents can be obtained in their entirety at some later time for processing or delivery or both. Refuse The action taken on an interchange which has been delivered to a mailbox and cannot, or will not, be retrieved.. Retrieve The successful conveyance of an interchange from a mailbox to the interchange receiver. Service Provider Any process or set of processes that accepts an interchange from a sender and conveys it to a mailbox that represents the addressed receiver. Direct connections between senders and receivers involve no service providers.

OCTOBER 2010

23

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

RELEASE • 006020

Service Request Handler A service request handler is an entity, intermediate to the interchange sender and interchange receiver, capable of acting upon one or more optional service requests or delivery notifications. TA1 (Basic Interchange Acknowledgment) This segment is used to report the receipt of the contents of one interchange control header and trailer envelope where that envelope surrounds one or more functional groups. This acknowledgment is transferred between the interchange receiver and sender as addressed in the interchange header. The TA1 reports the results of the syntactical analysis of the interchange control header and trailer. TA3 (Interchange Delivery Notice) Is a service segment exchanged between service request handlers to inform the sending service request handler of actions taken on the interchange. The TA3 reports the delivery and retrieval of the interchange, and also reports the unsuccessful delivery or retrieval of the interchange and identifies the error condition. Transmission Life Cycle of an EDI document The processes through which an EDI document passes as it is transferred from the interchange sender, through interconnect entities, to the interchange receiver and processed through its application processing system. Work Complete Refers to the state at which all actions that may be applied to this transaction have completed. It is a state that implies receipt of the data and does not infer acceptance or rejection of the data contained within the transaction set. The articulation of the work complete status is not dependent on the interchange, the functional group or even the transaction set and is able to respond to a specific piece of data that is business related or a work unit. There are a number of response transactions, including, but not limited to the following examples: TS271 Eligibility, Coverage or Benefit Information Response, TS754 Routing Instructions. X12 Standard Conformance The level to which a transmission is compared and evaluated against X12 standard syntax at the functional group level (i.e. GS/GE) level and transaction set level (ST-SE). The articulation of the conformance is expressed with a transaction set that is capable of the reporting the syntactical analysis electronically. This conformance checking is also dependent on the functional grouping. Examples: TS997 Functional Acknowledgement Set, TS999 Implementation Acknowledgement Set.

24

OCTOBER 2010

RELEASE • 006020

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

Note For the purpose of this paper, the reader may consider a Value Added Network (VAN), a Service Provider, an Interconnect Entity, and a Service Request Handler (SRH) as synonymous. There are two basic categories of SRHs: • The interchange sender's Service Request Handler (synonymous with Sender's Service Request Handler, Sender's SRH, or Sender's VAN) provides services at the request of the interchange sender. • The interchange receiver's Service Request Handler (synonymous with receiver's Service Request Handler, receiver's SRH, or receiver's VAN) provides services at the request of the interchange receiver.

OCTOBER 2010

25

RELEASE • 006020

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

8 Data Flow Model This document describes several data flow model examples to illustrate the uses of control structures in various EDI transmission life cycles. These models depict specific examples of the EDI transmission life cycle. Many other models are possible, some requiring fewer exchanges of data, some requiring more exchanges of data. These models are not normative (not part of the standard) and are pictorial representations of the ANSI ASC X12 control mechanisms, and as such ignore the concepts of interchange bundling and data accumulation for processing effectiveness. While important, they are outside the scope of this document.

8.1 Data Flow Model - Point-to-Point Figure 1 outlines the control and audit structures utilized throughout the transmission cycle of an interchange. This figure represents a point-to-point configuration where the interchange is created and transmitted by the interchange sender directly to the interchange receiver. It should be noted that the use of the control audit structures described below is voluntary. The operational environment must be mutually agreed upon by all parties involved in the generation, transmission, receipt, and processing of the control and auditing structures. The following model depicts the situation where all parties have mutually agreed to full use of the ANSI ASC X12 standards, and have agreed on the operational environment.

OCTOBER 2010

27

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

RELEASE • 006020

Figure 2 Action 1 The interchange is created and transmitted by the interchange sender to the interchange receiver. Action 2 If the interchange sender requested an interchange acknowledgement (i.e. a value of 1 in the ISA14), the interchange receiver reports the Interchange Envelope Conformance and Acknowledgment of the sender's interchange envelope by generating a TA1 segment enveloped in an ISA/IEA enveloping structure addressed to the sender. This interchange is then transmitted by the interchange receiver to the interchange sender. The TA1 is the first end-to-end acknowledgment of receipt of the sender's interchange. The interchange sender processes and reconciles the TA1 with the sender's internal auditing systems.

28

OCTOBER 2010

RELEASE • 006020

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

Action 3 The interchange receiver reports the X12 Standard Conformance of the sender's interchange by generating one or more 997 or 999 functional acknowledgments (one for each functional group in the received interchange) enveloped in an ISA/GS/GE/IEA enveloping structure addressed to the sender. This interchange is then transmitted by the interchange receiver to the interchange sender. The interchange sender processes and reconciles the functional acknowledgment with the sender's internal auditing systems. Through the processing of the functional acknowledgments, the interchange sender ascertains the status of the data within the receiver's EDI system. Note Only one acknowledgement can be sent for each functional group.The acknowledgment can be either a single Transaction Set 997 or a single Transaction Set 999 as mutually agreed upon by the trading partners Action 4 The interchange receiver reports the Implementation Guide Conformance of the sender's interchange by generating one or more 999 implementation acknowledgments (one for each functional group in the received interchange) enveloped in an ISA/GS/GE/IEA enveloping structure addressed to the sender. This interchange is then transmitted by the interchange receiver to the interchange sender. The interchange sender processes and reconciles the implementation acknowledgment with the sender's internal auditing systems. Through the processing of the implementation acknowledgments, the interchange sender ascertains the status of the data within the receiver's EDI system. Action 5 The interchange receiver reports the Application Validation and Processing of the sender's interchange by generating one or more 824 application reporting transaction sets or other appropriate application acknowledgments (832, 271, 278, 277, 301, 151) enveloped in an ISA/GS/GE/IEA enveloping structure addressed to the sender. This interchange is then transmitted by the interchange receiver to the interchange sender. The interchange sender processes and reconciles the transaction sets with the sender's internal auditing systems. Through the processing of these transaction sets, the interchange sender ascertains the status of the data within the receiver's EDI system.

OCTOBER 2010

29

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

RELEASE • 006020

Action 6 Depending on applications, available standards, and the transaction set(s) received, the receiver returns an application specific response transaction set (such as the Purchase Order Acknowledgment or Eligibility Benefit Response). This transaction set is then enveloped in an interchange and transmitted by the interchange receiver to the interchange sender. The interchange sender processes and reconciles the application specific response with the sender's internal auditing systems.Through the processing of these transaction sets, the interchange sender ascertains the status of the business data in the receiver's application system.

8.1.1 Data Flow Models - Point-to-Point for Health Care Insurance Transaction Sets 8.1.1.1 Interchange Sender Sends X12 835 Health Care Claim Payment Figure 3 outlines the control and audit structures utilized throughout the transmission cycle of an interchange. This figure represents a point to point configuration where the interchange is created by the interchange sender and transmitted to the interchange receiver. In this health care insurance example, the interchange sender can be the health care payer or health plan. The interchange receiver can be, but is not limited to, the health care provider (e.g. a physician or physician group, hospital, laboratory, urgent care center, ambulatory surgery center, radiology centers, etc.). A clearinghouse, billing agent or vendor may act on behalf of the health care provider. The control audit structures described below are voluntary, and the operational environment must be mutually agreed upon by all parties involved in the generation, transmission, receipt, and processing of the control and auditing structures. The following model depicts the situation where all parties have mutually agreed to full use of the ANSI ASC X12N standards, and have agreed on the operational environment.

30

OCTOBER 2010

RELEASE • 006020

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

Figure 3 Action 1 The 835 interchange is created and transmitted by the Interchange Sender to the Interchange Receiver. Action 2 The Interchange Receiver sends the TA1 to the Interchange Sender to report the results of the syntactical validation of the 835 interchange envelope. Action 3 The Interchange Receiver sends the 999 to the Interchange Sender to report the results of syntactical and relational analysis as specified by the 835 implementation guideline (TR3), or to acknowledge receipt of an error-free 835 transaction set. There must be one 999 functional acknowledgment for each functional group in the received 835 interchange. Action 4 The Interchange Receiver sends the 824 to the Interchange Sender to report the results of application edits performed on the 835 transaction set. One 824 application reporting transaction set is sent for each functional group in the received 835 interchange.

OCTOBER 2010

31

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

RELEASE • 006020

8.1.1.2 Interchange Sender Sends X12 820 Premium Payment or X12 834 Benefit Enrollment and Maintenance Figure 4outlines the control and audit structures utilized throughout the transmission cycle of an interchange. This figure represents a point to point configuration where the interchange is created by the interchange sender and transmitted to the interchange receiver. 820 Premium Payment: In this health care insurance example, the Interchange Sender can be any entity that collects payroll deducted and other group insurance premiums and reports those payments on the ANSI ASC X12 Premium Payment Order/Remittance Advice (820) Transaction set. The Interchange Receiver can be an insurance company, health care organization or government agency receiving premium payments using the 820 transaction set. 834 Benefit Enrollment and Maintenance: In this health care insurance example, the Interchange Sender can be the sponsor (employer, third party administrator, government agency, etc.) of health care insurance benefits. The Interchange Receiver can be the health care payer or the health care plan. The control audit structures described below is voluntary, and the operational environment must be mutually agreed upon by all parties involved in the generation, transmission, receipt, and processing of the control and auditing structures. The following model depicts the situation where all parties have mutually agreed to full use of the ANSI ASC X12N standards, and have agreed on the operational environment.

32

OCTOBER 2010

RELEASE • 006020

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

Figure 4 Action 1 The 820 or 834 interchange is created and transmitted by the Interchange Sender to the Interchange Receiver. Action 2 The Interchange Receiver sends the TA1 to the Interchange Sender to report the results of the syntactical validation of the 820 or 834 interchange envelope. Action 3 The Interchange Receiver sends the 999 to the Interchange Sender to report the results of syntactical and relational analysis as specified by the 820 or 834 implementation guideline (TR3), or to acknowledge receipt of an error-free 820 or 834 transaction set. There must be one 999 functional acknowledgment for each functional group in the received 820 or 834 interchange. Action 4 The Interchange Receiver sends the 824 to the Interchange Sender to report the results of application edits performed on the 820 or 834 transaction set. One 824 application reporting transaction set is sent for each functional group in the received 820 or 834 interchange.

OCTOBER 2010

33

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

RELEASE • 006020

8.1.1.3 Interchange Sender Sends X12N 837 Health Care Claim Figure 5 outlines the control and audit structures utilized throughout the transmission cycle of an interchange. This figure represents a point to point configuration where the interchange is created by the interchange sender and transmitted to the interchange receiver. In this health care insurance example, the Interchange Sender can be, but is not limited to, the health care provider (e.g. a physician or physician group, hospital, laboratory, urgent care center, ambulatory surgery center, radiology centers, etc.); and clearinghouse, billing agent or vendor acting in behalf of the health care provider. The Interchange Receiver can be the health care payer or health care plan. The control audit structures described below are voluntary, and the operational environment must be mutually agreed upon by all parties involved in the generation, transmission, receipt, and processing of the control and auditing structures. The following model depicts the situation where all parties have mutually agreed to full use of the ANSI ASC X12- standards, and have agreed on the operational environment.

Figure 5

34

OCTOBER 2010

RELEASE • 006020

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

Action 1 The 837 interchange is created and transmitted by the Interchange Sender to the Interchange Receiver. Action 2 The Interchange Receiver sends the TA1 to the Interchange Sender to report the results of the syntactical validation of the 837 interchange envelope. Action 3 The Interchange Receiver sends the 999 to the Interchange Sender to report the syntactical and relational analysis as specified by the 837 implementation guideline (TR3), or to acknowledge receipt of an error-free 837 transaction set. There must be one 999 functional acknowledgment for each functional group in the received 837 interchange. Action 4 The Interchange Receiver sends the 277CA to the Interchange Sender to report the results of pre-adjudication analysis performed on the 837 transaction set. (The level of editing in pre-adjudication analysis will vary from receiver to receiver.) One 277CA transaction set is sent for each 837 transaction set received.

8.1.1.4 Interchange Sender Sends X12N 270 Health Care Eligibility Benefit Inquiry, 276 Health Care Claim Status Request, or 278 Health Care Services Review Request Figure 6 outlines the control and audit structures utilized throughout the transmission cycle of an interchange. This figure represents a point to point configuration where the interchange is created by the interchange sender and transmitted to the interchange receiver. In this health care insurance example, the Interchange Sender can be, but is not limited to, the health care provider (e.g. a physician or physician group, hospital, laboratory, urgent care center, ambulatory surgery center, radiology centers, etc.); and clearinghouse, billing agent or vendor acting in behalf of the health care provider. The Interchange Receiver can be the health care payer or health care plan. The control audit structures described below is voluntary, and the operational environment must be mutually agreed upon by all parties involved in the generation, transmission, receipt, and processing of the control and auditing

OCTOBER 2010

35

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

RELEASE • 006020

structures. The following model depicts the situation where all parties have mutually agreed to full use of the ANSI ASC X12 standards, and have agreed on the operational environment.

Figure 6 Action 1 The 270, 276, or 278 Request interchange is created and transmitted by the Interchange Sender to the Interchange Receiver. Action 2 The Interchange Receiver sends the TA1 to the Interchange Sender to report the results of the syntactical validation of the 270, 276 or 278 Request interchange envelope. Action 3 The Interchange Receiver sends the 999 to the Interchange Sender to report the results of syntactical and relational analysis as specified by the 270, 276 or 278 Request implementation guideline (TR3), or to acknowledge receipt of an error-free 270, 276 or 278 Request transaction set. There must be one 999 functional acknowledgment for each functional group in the received 270, 276 or 278 Request interchange

36

OCTOBER 2010

RELEASE • 006020

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

Action 4 The Interchange Receiver sends the 271, 277 or 278 Response to report the results of application edits performed on the 270, 276 or 278 Request transaction set, or to respond to the 270, 276 or 278 Request.

8.1.1.5 Interchange Sender Sends X12N 270 Health Care Eligibility Benefit Inquiry, 276 Health Care Claim Status Request, or 278 Health Care Services Review Request Figure 7 outlines the control and audit structures utilized throughout the transmission cycle of an interchange. This figure represents a point to point configuration where the interchange is created by the interchange sender and transmitted to the interchange receiver. In this health care insurance example, the Interchange Sender can be, but is not limited to, the health care provider (e.g. a physician or physician group, hospital, laboratory, urgent care center, ambulatory surgery center, radiology centers, etc.); and clearinghouse, billing agent or vendor acting on behalf of the health care provider. The Interchange Receiver can be the health care payer or health care plan. The control audit structure described below is voluntary, and the operational environment must be mutually agreed upon by all parties involved in the generation, transmission, receipt, and processing of the control and auditing structures. The following model depicts the situation where all parties have mutually agreed to full use of the ANSI ASC X12N standards, and have agreed on the operational environment. In the real-time environment, the Interchange Sender will send a single transaction per functional group per interchange.

OCTOBER 2010

37

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

RELEASE • 006020

Figure 7 Action 1 The 270, 276, or 278 Request interchange is created and transmitted by the Interchange Sender to the Interchange Receiver. Action 2 If errors are encountered during the syntactical validation of the 270, 276 or 278 Request interchange envelope, the Interchange Receiver sends the TA1 to the interchange Sender to report those error results, processing stops, and Actions 3 and 4 will not occur. Action 3 If errors are encountered during syntactical or relational analysis edit processes and the Interchange Receiver sends the 999 to the Interchange Sender, processing stops, and Action 4 does not occur. If the 270, 276, or 278 Request transaction is accepted for further processing, a 999 is not sent. Action 4 The Interchange Receiver sends the 271, 277, or 278 Response to the Interchange Sender.

38

OCTOBER 2010

RELEASE • 006020

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

8.1.1.6 Interchange Sender Sends X12 837 Health Care Claim Figure 8outlines the control and audit structures utilized throughout the transmission cycle of an interchange. This figure represents a point to point configuration where the interchange is created by the interchange sender and transmitted to the interchange receiver. In this health care insurance example, the Interchange Sender can be, but is not limited to, the health care provider (e.g. a physician or physician group, hospital, laboratory, urgent care center, ambulatory surgery center, radiology centers, etc.); and clearinghouse, billing agent or vendor acting in behalf of the health care provider. The Interchange Receiver can be the health care payer or health care plan. The control audit structures described below is voluntary, and the operational environment must be mutually agreed upon by all parties involved in the generation, transmission, receipt, and processing of the control and auditing structures. The following model depicts the situation where all parties have mutually agreed to full use of the ANSI ASC X12 standards, and have agreed on the operational environment. In the real-time environment, the Interchange Sender will send a single claim transaction per functional group per interchange.

OCTOBER 2010

39

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

RELEASE • 006020

Figure 8 Action 1 The 837 interchange is created and transmitted by the Interchange Sender to the Interchange Receiver. Action 2 If errors are encountered during syntactical validation of the 837 Interchange envelope, the Interchange Receiver sends the TA1 to the Interchange Sender to report those error results, processing stops, and Actions 3, 4, and 5 will not occur. Action 3 If errors are encountered during syntactical or relational analysis processes and the Interchange Receiver sends the 999 to the Interchange Sender, processing stops, and Actions 4 and 5 do not occur. If the 837 transaction is accepted for further processing, a 999 is not sent. Action 4 If errors are encountered in the pre-adjudication analysis processes, the Interchange Receiver sends the 277CA to the Interchange Sender to report

40

OCTOBER 2010

RELEASE • 006020

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

error results. If the Interchange Receiver sends the 277CA to the Interchange Sender, Action 5 does not occur in this real-time model. Action 5 The Interchange Receiver sends the 835 to the Interchange Sender.

8.2 Data Flow Model - Clearinghouse Figure 9 outlines the control and audit structures utilized throughout the transmission cycle of an interchange.This model is based on a healthcare clearinghouse.This figure represents a point-to-point configuration where the interchange is created and transmitted by the interchange sender directly to the interchange receiver. It should be noted that the use of the control audit structures describes below is voluntary, and the operational environment must be mutually agreed upon by all parties involved in the generation, transmission, receipt, and processing of the control and auditing structures. The following model depicts the situation where all parties have mutually agreed to full use of the ANSI ASC X12 standards, and have agreed on the operational environment.

Figure 9

OCTOBER 2010

41

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

RELEASE • 006020

Action 1 The interchange is created and transmitted by the interchange sender to the clearinghouse’s interchange receiver function. Action 2 The clearinghouse’s interchange receiver reports the receipt and syntactical validity of the sender's interchange envelope by generating a TA1 segment enveloped in an ISA/IEA enveloping structure addressed to the sender. This interchange is then transmitted by the interchange receiver to the interchange sender. The TA1 is the first end-to-end acknowledgment of receipt of the sender's interchange. The interchange sender processes and reconciles the TA1 with the sender's internal auditing systems. Action 3 The clearinghouse’s interchange receiver reports the syntactical validity and translatability of the sender's interchange by generating one or more functional acknowledgments enveloped in an ISA/GS/GE/IEA enveloping structure addressed to the sender. This interchange is then transmitted by the interchange receiver to the interchange sender. The interchange sender processes and reconciles the functional acknowledgment with the sender's internal auditing systems. Through the processing of the functional acknowledgments, the interchange sender ascertains the status of the data within the receiver's EDI system. Note Only one acknowledgement can be sent for each functional group.The acknowledgment can be either a single Transaction Set 997 or a single Transaction Set 999 as mutually agreed upon by the trading partners Action 4 The clearinghouse delivers the translated business data to the appropriate processing application. Depending on clearinghouse applications and available standards, the clearinghouse’s interchange receiver may return a cross-functional transaction set (such as the Application Advice) or an application specific acknowledgment transaction set (such as the Purchase Order Acknowledgment). This transaction set is then enveloped in an interchange and transmitted by the clearinghouse interchange receiver to the interchange sender. The interchange sender processes and reconciles the Application Advice or application specific acknowledgment with the sender's internal auditing systems. Through the

42

OCTOBER 2010

RELEASE • 006020

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

processing of these transaction sets, the interchange sender ascertains the status of the business data in the receiver's application system. Action 5 The clearinghouse recombines the business data into a one or more new transaction sets. The recombination is based on the ultimate interchange receiver, of which there can be multiple. Action 6 These transaction sets are then enveloped in interchanges and transmitted by the clearinghouse interchange sender to the interchange receivers. Action 7 Similar to Action 2, each interchange receiver reports the receipt and syntactical validity of the clearinghouse’s interchange envelope by generating a TA1 segment enveloped in an ISA/IEA enveloping structure addressed to the clearinghouse. Action 8 Similar to Action 3, each interchange receiver reports the syntactical validity and translatability of the clearinghouse's interchange by generating one or more functional acknowledgments enveloped in an ISA/GS/GE/IEA enveloping structure addressed to the sender. Note Only one acknowledgement can be sent for each functional group.The acknowledgment can be either a single Transaction Set 997 or a single Transaction Set 999 as mutually agreed upon by the trading partners Action 9 Similar to Action 4, each interchange receiver delivers the translated business data to the appropriate processing application. Depending on applications and available standards, the receiver returns a cross-functional transaction set (such as the Application Advice), or an application specific acknowledgment transaction set (such as the Purchase Order Acknowledgment). This transaction set is then enveloped in an interchange and transmitted by the interchange receiver to the clearinghouse’s interchange sender. Action 10 Similar to Action 5, the clearinghouse recombines the business data from cross-functional transaction set into a one or more new transaction sets. The recombination is based on the original interchange sender. The transaction sets are

OCTOBER 2010

43

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

RELEASE • 006020

then enveloped in an interchange and transmitted by the clearinghouse to the original interchange sender.

8.3 Data Flow Model - Single VAN Figure 10 outlines the control and audit structures utilized throughout the transmission life cycle of an interchange. This figure represents a single VAN configuration where the interchange is created by the interchange sender, flows through a service request handler (SRH), and is ultimately retrieved and processed by the interchange receiver. It should be noted that the use of the control audit structures described below is voluntary, and the operational environment must be mutually agreed upon by all parties involved in the generation, transmission, receipt, and processing of the control and auditing structures. The following model depicts the situation where all parties have mutually agreed to full use of the ANSI ASC X12 standards, and have agreed on the operational environment.

Figure 10

44

OCTOBER 2010

RELEASE • 006020

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

* Interchange Acknowledgement, Functional Acknowledgement, Implementation Acknowledgement and Application acknowledgement transmitted by the Interchange Receiver through the SRH and ultimately to the interchange sender representation out of SRH in this model is for clarity only. Action 1 The interchange is created and transmitted by the interchange sender to the service request handler (SRH). Action 2 A DST (Data Status Tracking) may be returned to indicate the success or failure of the receipt and safe storage of the sender's interchange or transmission by the SRH. This is the initial opportunity for the SRH to provide feedback on a specific interchange or document.The interchange sender processes and reconciles the DST with the sender's internal auditing systems. The SRH may provide subsequent DSTs based on a prior agreement with the sender. Some examples of potential trigger mechanisms include: timing triggers, status updates, and the expiration of anticipated reporting data. Some of the potential reporting statuses include: delivered, retrieved, purged, and refused. Action 3 The SRH processes the sender's data and safe stores the documents in the receiver's mailbox for retrieval. Action 4 The interchange receiver retrieves the sender's interchange from the receiver's mailbox on the SRH. Action 5 With no additional tracking information expected to be provided by the service request handler, the final DST can be provided to the interchange sender.The sender processes and reconciles the DST with the sender's internal auditing systems. Action 6 The interchange receiver may also receive a DST from the SRH, providing tracking information from the SRH's initial receipt of the interchange through the retrieval by the receiver. The receiver processes and reconciles the DST with the receiver's internal auditing systems.

OCTOBER 2010

45

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

RELEASE • 006020

Action 7 The interchange receiver reports the receipt and syntactical validity of the sender's interchange envelope by generating a TA1 segment enveloped in an ISA/IEA enveloping structure addressed to the sender. This interchange is then transmitted through the SRH to the interchange sender. The TA1 is the first end-to-end acknowledgment of receipt of the sender's interchange. The interchange sender processes and reconciles the TA1 with the sender's internal auditing systems. Action 8 The interchange receiver reports the syntactical validity and translatability of the sender's interchange by generating one or more functional acknowledgments enveloped in an ISA/GS/GE/IEA enveloping structure addressed to the sender. This interchange is then transmitted through the SRH to the interchange sender. The interchange sender processes and reconciles the functional acknowledgment with the sender's internal auditing systems. Through the processing of the functional acknowledgments, the interchange sender ascertains the status of the data within the receiver's EDI system. Note Only one acknowledgement can be sent for each functional group.The acknowledgment can be either a single Transaction Set 997 or a single Transaction Set 999 as mutually agreed upon by the trading partners. Action 9 The interchange receiver reports the syntactical validity and translatability of the sender's interchange by generating one or more implementation acknowledgment enveloped in an ISA/GS/GE/IEA enveloping structure addressed to the sender. This interchange is then transmitted through the SRH to the interchange sender. The interchange sender processes and reconciles the implementation acknowledgment with the sender's internal auditing systems. Through the processing of the functional acknowledgments, the interchange sender ascertains the status of the data within the receiver's EDI system. Note Only one acknowledgement can be sent for each functional group.The acknowledgment can be either a single Transaction Set 997 or a single Transaction Set 999 as mutually agreed upon by the trading partners.

46

OCTOBER 2010

RELEASE • 006020

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

Action 10 The receiver delivers the translated business data to the appropriate processing application. Depending on applications and available standards, the receiver returns a cross-functional transaction set (such as the Application Advice), or an application specific acknowledgment transaction set (such as the Purchase Order Acknowledgment). This transaction set is then enveloped in an interchange and transmitted through the SRH to the interchange sender. The interchange sender processes and reconciles the Application Advice or application specific acknowledgment with the sender's internal auditing systems. Through the processing of these transaction sets, the interchange sender ascertains the status of the business data in the receiver's application system.

8.4 Data Flow Model - Multi VAN On the following page, Figure 11 outlines the control and audit structures utilized throughout the transmission cycle of an interchange. This figure represents a multi-VAN configuration where the interchange is created by the interchange sender, flows through the sender's SRH to the receiver's SRH, and is ultimately retrieved and processed by the interchange receiver. It should be noted that the use of the control audit structures described below is voluntary, and the operational environment must be mutually agreed upon by all parties involved in the generation, transmission, receipt, and processing of the control and auditing structures. The following model depicts the situation where all parties have mutually agreed to full use of the ANSI ASC X12 standards, and have agreed on the operational environment.

OCTOBER 2010

47

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

RELEASE • 006020

Figure 11 * Interchange Acknowledgements, Functional Acknowledgement, Implementation Acknowledgement and Application Acknowledgement are transmitted by the Interchange Receiver through the Receivers through the Receivers SRH, the Sender’s SRH and ultimately to the Interchange Sender. Representation outside of the SRH, in this model is for clarity only. Action 1 The interchange is created and transmitted by the interchange sender to the sender's service request handler (SRH). Action 2 A DST may be returned to indicate the success or failure of the receipt and safe storage of the sender's interchange or transmission by the sender's SRH. This is the initial opportunity for the SRH to provide feedback on a specific interchange or document. The interchange sender processes and reconciles the DST with the sender's internal auditing systems. The sender and the sender's SRH may agree to use additional status reports. The ANSI ASC X12 standards are mute on the requesting mechanism. Some examples of

48

OCTOBER 2010

RELEASE • 006020

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

potential trigger mechanisms include: timing triggers, status updates, and the expiration of anticipated reporting data. Some of the potential reporting statuses include: delivered, retrieved, purged, and refused. Action 3 The sender's SRH processes the sender's data and safe stores the documents in a mailbox for forwarding. Action 4 The sender's interchange is mailbagged by the sender's SRH in preparation for transmission to the receiver's SRH. The mailbag, with its contents of one or more interchanges and/or mailbag acknowledgments, is then transmitted to the receiver's SRH. Action 5 The receiver's SRH provides for the receipt and safe storage of the mailbag, and generates a Mailbag Acknowledgment.Within mutually agreed upon times, the receiver's SRH transmits the Mailbag Acknowledgment to the sender's SRH, who processes and reconciles the audit trails. Action 6 The receiver's SRH processes the sender's data and safe stores the documents in the receiver's mailbox for retrieval. One or more TA3s are generated, reporting the processing and delivery results. These results may either be positive, or negative with reason codes. Action 7 Within mutually agreed upon times, the receiver's SRH transmits the TA3 segments enveloped in an ISA/IEA enveloping structure to the sender's SRH. The sender's SRH will process and reconcile the audit trails with the new information. Action 8 The interchange receiver retrieves the sender's interchange from the receiver's mailbox on the receiver's SRH. Once retrieved, the receiver's SRH generates a TA3, reporting the receipt results. If the receiver is unable to retrieve the sender's interchange, the receiver's SRH will generate a negative TA3 with reason codes. Action 9 Within mutually agreed upon times frames, the receiver's SRH transmits the TA3 segment enveloped in an ISA/IEA enveloping structure to the sender's SRH. The sender's SRH will process and reconcile the audit trails with the new information.

OCTOBER 2010

49

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

RELEASE • 006020

Action 10 With the TA3 acknowledging receipt or failure of receipt of the interchange by the receiver, no additional tracking information is expected to be exchanged between the service request handlers. Therefore, the final DST can be prepared by the sender's SRH and provided to the interchange sender. The sender processes and reconciles the DST with their internal auditing systems. Action 11 The interchange receiver may also receive a DST from the receiver's SRH, providing tracking information from the receiver's SRH's initial receipt of the interchange through the retrieval by the receiver. The receiver processes and reconciles the DST with the receiver's internal auditing systems. Action 12 The interchange receiver reports the receipt and syntactical validity of the sender's interchange envelope by generating a TA1 segment enveloped in an ISA/IEA enveloping structure addressed to the sender. This interchange is then transmitted through the receiver's SRH to the sender's SRH and finally to the interchange sender. The TA1 is the first end-to-end acknowledgment of receipt of the sender's interchange. The interchange sender processes and reconciles the TA1 with the sender's internal auditing systems. Action 13 The interchange receiver reports the syntactical validity and translatability of the sender's interchange by generating one or more functional acknowledgments enveloped in an ISA/GS/GE/IEA enveloping structure addressed to the sender. This interchange is then transmitted through the receiver's SRH to the sender's SRH and finally to the interchange sender. The interchange sender processes and reconciles the functional acknowledgment with the sender's internal auditing systems. Through the processing of the functional acknowledgments, the interchange sender ascertains the status of the data within the receiver's EDI system. Note Only one acknowledgement can be sent for each functional group.The acknowledgment can be either a single Transaction Set 997 or a single Transaction Set 999 as mutually agreed upon by the trading partners.

50

OCTOBER 2010

RELEASE • 006020

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

Action 14 The receiver delivers the translated business data to the appropriate processing application. Depending on applications and available standards, the receiver returns a cross-functional transaction set (such as the Application Advice), or an application specific acknowledgment transaction set (such as the Purchase Order Acknowledgment). This transaction set is then enveloped in an interchange and transmitted through the receiver's SRH to the sender's SRH and finally to the interchange sender. The interchange sender processes and reconciles the Application Advice or application specific acknowledgment with the sender's internal auditing systems. Through the processing of these transaction sets, the interchange sender ascertains the status of the business data in the receiver's application system. Note Only one acknowledgement can be sent for each functional group.The acknowledgment can be either a single Transaction Set 997 or a single Transaction Set 999 as mutually agreed upon by the trading partners.

8.5 Entity/Process Interfaces In order to accurately report the transition of data through multiple parties, a control and auditing system should include a control point at each entity or processing interface. This approach applies equally well for EDI data as it moves through its transmission life cycle. The following table (figure 6) provides a summary of the various entities and processes involved in the interchange's transmission life cycle, and the corresponding ANSI X12 control structures. The first column in figure 6 represents the different functions that occur during an Interchange's transmission life cycle. For clarification, the action number associated with the Multi-VAN model (figure 3) has also been provided. Each function may have one or more associated control structures. If a control structure exists for a given function, the corresponding action number associated with the Multi-VAN model (figure 3) is provided. For example, in the "Receipt and safe store of interchange from sender to sender's SRH" is depicted as action 1 in the Multi-VAN model. The DST reports this activity and

OCTOBER 2010

51

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

RELEASE • 006020

is depicted as action 2 in the Multi-VAN model. The remaining control structures are not generated as a result of this function. Control Structures Function

DST

Receipt and safe store of interchange from sender to sender's SRH (Model action #1)

Model action #2

Mailbag Ack

TA3

TA1

997

999

824 or Appl Ack

Processing of interchange and Model delivery to receiver’s SRH mailbox action #2 at the sender SRH (Model Action #3) Receipt and safe storage of data by receiver’s SRH (Model Action #4)

Model Model action#10 action #5

Processing of interchange and Model delivery to receiver’s mailbox by action #10 receiver’s SRH. (model action # 7) Receipt of interchange from receiver’s mailbox by the receiver (Model action #8) Receiver acknowledges syntactical validity of interchange, functional groups addresses for delivery to sender (No corresponding action in model) Receiver acknowledges syntactical validity of interchange, functional group and the implementation. Receiver identifies action taken on Business data with interchange, address for deliver to sender (No corresponding action in model)

Model action #7

Model action #12

Model action #13

Model action #14

Model action #15

Figure 12 In some implementations, EDI Control Structures are replaced with Non-EDI control processes that are outside of the scope of this document (e.g., personal contact, E-Mail, letters). These additional control processes may be adequate for specific EDI Implementations.

52

OCTOBER 2010

RELEASE • 006020

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

However, there are also significant advantages to be realized by the implementation of the ANSI ASC X12 control structures. With the ability to identify faulty systems, the reliability of data transmissions can be improved. With the new information, interchange senders, receivers, and VANs will be capable of better managing the EDI data, and therefore their business.

8.5.1 A Necessary Implementation (Example) A necessary implementation of these control and auditing standards using only EDI control structures would include the sender's interchange (containing the business data) and the receiver's application response (TS824 or application specific acknowledgment transaction set). By implementing these two structures, the sender can then ascertain if the EDI transaction cycle is complete. When the sender has received the application response, the sender can interrogate the response to determine precisely the status of the data. The receiver may have processed and accepted the data, rejected part or all of the data, or modified the data. Under all of these conditions, the transaction cycle is complete. If the sender has not received the application response, the EDI transaction cycle has not been completed. The receiver has not received, processed, and provided a response to the business data. There may be many reasons for this situation, and is indicative of a failure or a delayed response.

8.5.2 A Sufficient Implementation (Example) As shown in the example above, if there are no failures or delays in the transmission of and response for a sender's interchange, the necessary implementation is sufficient. However, if problems are encountered during the processing cycle, there is insufficient information to identify and rectify the failing system. Therefore, the necessary implementation outlined above does not provide for a sufficient implementation. As demonstrated in the Data Flow model, each of the control elements provide a unique and necessary function in the auditing of the data life cycle. The DST, Mailbag standard, TA3 standard, TA1 standard, TS997/TS999 standards, and the TS824 or application specific standards have unique properties and structures that provide for the transmission, security, and audibility of an EDI interchange as it travels through the various communication entities. Failure to implement any one of the available standards will result in an insufficiency

OCTOBER 2010

53

ASC X12 • ACKNOWLEDGEMENT REFERENCE MODEL

RELEASE • 006020

in the control and audibility of an EDI document's transmission cycle, especially in a multi-VAN environment.

8.5.3 Implementation in the Marketplace The EDI Marketplace will ultimately define the implementation balance for these control and auditing mechanisms. A full implementation may be the only adequate solution, or a hybrid of solutions providing contained cost and improved reliability may be sufficient. Over time, only the EDI marketplace will be able to define the appropriate utilization of the elements in the Data Flow models.

54

OCTOBER 2010