J-17_WEDIAcknowledgementRecommendation(2).pdf

WEDI Acknowledgement

Recommendations For ASC X12N Implementation Guides

Version 1.0 September 20, 2005

Workgroup for Electronic Data Interchange 12020 Sunrise Valley DR., Suite 100, Reston, VA. 20191

(t) 703-391-2716 / (f) 703-391-2759

Disclaimer This document is Copyright © 2005 by the Workgroup for Electronic Data Interchange (WEDI).

It may be freely redistributed in its entirety provided that this copyright notice is not removed. It may not be sold for profit or used in commercial documents without the written permission of the copyright holder. This document is provided “as is” without any express or implied warranty.

While all information in this document is believed to be correct at the time of writing, this document does not purport to provide legal advice. If you require legal advice, you should consult with an attorney. The information provided here is for reference use only and does not constitute the rendering of legal or financial advice by WEDI. The listing of an organization does not imply any sort of endorsement and WEDI takes no responsibility for the products, tools and Internet sites listed.

The existence of a link or organizational reference in any of the following materials should not be assumed as an endorsement by WEDI.

RFP-CMS-2007-0013

Attachment J-17

WEDI Acknowledgement Recommendations September 20, 2005

Copyright© 2005 WEDI

WEDI would like to thank X12 for assisting in this collaborative effort.

Background This paper presents recommendations for standardizing acknowledgement reporting for the ASC X12N Implementation Guides.

In business today, there are hundreds of different systems that process data differently.

Because of this, differing requirements are imposed on the electronic submissions from trading partners. There also are variances in the reporting mechanisms, which are intended to help submitters verify the compliance of their submissions with the electronic/business requirements of the receiving entity, and the acceptance/rejection of their submissions by the receiving entity.

Response reports frequently are sent to submitters on paper and lack the information needed by the submitter to resolve issues with rejected electronic submissions. With the advent of HIPAA and standard transaction sets, the ability exists to standardize the acceptance or rejection reports. HIPAA makes this possible given that, at a minimum, healthcare trading partners will need to supply standard data content in HIPAA-mandated transaction sets. Standardizing the process for submitters and receivers will significantly reduce the costs associated with understanding and processing errors.

Once the healthcare industry standardizes the acknowledgement reports, correction and resubmission of returned/errored transaction sets will be expedited. This should result in quicker error correction and easier implementation of claim, remittance, eligibility, referral and claim status transaction sets. Finally, standardized reporting will reduce the number of inquiries from trading partners regarding edits and reported information.

Terminology The following definitions allow for a level and consistent interpretation of the terms.

Accepted – The interchange, functional group, transaction set or business unit conforms to the syntax and business rules of X12, X12N and the receiver.

Accepted with errors – The interchange, functional group, transaction set or business unit contained errors, but will be processed by the receiver.

Authoritative source – The authoritative source of the data is the entity submitting a unit of work, receiving a request or submitting a response to a request.

Code - A code is a value from a predefined list of values that is maintained by ASC X12 or by other bodies that are recognized by ASC X12 and identified by reference in the code source appendix at the end of the Data Element Dictionary.

Error – Nonconformance with X12 or X12N syntax or Implementation Guide rules or nonconformance with the business rules of the receiver. (NOTE: Errors do not necessarily equal rejection.)

Final disposition – The final disposition is the last acknowledgment or paired response from the authoritative source of the data. No further communication is required.

Functional group – A collection of similar transaction sets enclosed by a functional group header and a functional group trailer.

Interchange – A group or groups of transaction sets combined into one logical transmission (ISA/IEA). (Note: This may include more than one functional group of transaction sets.)

Receiver – The entity that is the recipient of the communication. The term receiver may apply to providers, payers, clearinghouses or their business associates.

Rejected – The interchange, functional group, transaction set or business unit cannot be processed as sent.

Stage – Logical category of acknowledgment reporting.

Submitter – The entity that is the initiator of the communication. The term submitter may apply to providers, payers, clearinghouses or their business associates.

Transaction set – A group of logically related data business units contained within an ST/SE pair.

Transition period – A period of time which will allow submitters and receivers to progress to a new or subsequent version of a standard. During the transition period, dual use of the current method with the new or subsequent version of the standard may be needed.

Unit of work – A single unit within a transaction set (e.g., one claim within a 837 transaction set, one remittance advice within a 835 transaction set, et cetera). (Note: A transaction set may include more than one unit of work in a transaction set.)

Section 1: Submitters and Receivers In the industry today, the flow of transaction set acknowledgements typically is in one direction. For instance, while some provider systems and clearinghouses are built to pick up and act upon the acknowledgement reports from the payers, the reverse is not always true. Providers and clearinghouses cannot always issue an acknowledgement or error report to the payer because the infrastructure to handle that type of acknowledgement sometimes is not available.

Table 1 Roles and Obligations, below, shows how industry constituents’ responsibilities change as submitters and receivers, based on the transaction sets. For simplicity’s sake, the table shows only the initial submitter and the ultimate receiver. For a visual representation of the transaction set flow, including clearinghouses, see the business transaction flows on pages 18-22.

It should be noted that one or more intermediaries or clearinghouses may be in between the initial submitter and ultimate receiver. Those intermediaries or clearinghouses may act as the submitter and receiver for the same transaction set. Table 1 Roles and Obligations, below, identifies the basic submitters and receivers by transaction set and provide guidelines for submitter and receiver responsibilities relative to the transaction set flow. It is assumed that all appropriate levels of acknowledgements will be used, depending on the stage of the rejection/error as described in Tables 2 and 3. For purposes of Table 1 Roles and Obligations, the initial submitter and ultimate receiver are identified as providers and payers with the understanding that intermediaries such as clearinghouses also may be in the workflow.

Table 1 Roles and Obligations

Transaction Set Submitter Receiver

270 Provider or Payer.

If the receiver reports a rejected transaction set or unit of work, the submitter has the option of fixing and resending as needed. However, if resent, it should be formatted correctly.

Payer.

The receiver must respond if unable to process the transaction set or unit of work.

271 Payer.

If the submitter receives a response that a 271 transaction set is formatted incorrectly, it must correct and resend the transaction set.

Provider or Payer.

If the receiver receives an incorrect 271 transaction set, it has the option of requesting a corrected 271 transaction set.

Transaction Set Submitter Receiver

275 Provider.

If the receiver is not able to interpret the X12 transaction set or embedded HL7 message, the submitter must correct and resend.

Payer.

The receiver must respond if unable to process an X12 transaction set or embedded HL7 message.

276 Provider.

The submitter has the option of fixing and resending a 276 transaction set or unit of work if the submitter receives a response that the 276 transaction set or unit of work is unacceptable. If the submitter chooses to resend, the transaction set or unit of work should be formatted correctly.

Payer.

The receiver must respond if unable to process a claim status transaction set or unit of work request from a submitter.

Solicited

Response

Payer.

If a submitter receives a notice that its solicited 277 transaction set or unit of work was formatted incorrectly, it must correct and resend.

Provider.

If the receiver receives an incorrect solicited 277 transaction set or unit of work, it has the option of requesting a corrected transaction set or unit of work.

Request for Additional

Information

Payer.

If a submitter receives a notice that its 277 request for additional information transaction set or unit of work was formatted incorrectly, it must correct and resend if the submitter still needs the additional information.

Provider.

If the receiver receives an incorrect 277 request for additional information transaction set or unit of work, it must request a corrected 277 request for additional information.

Acknowledge-ment

Payer.

If a submitter receives a notice that its 277 acknowledgement transaction set or unit of work was formatted incorrectly, it must correct and resend.

Provider.

If the receiver receives an incorrect 277 acknowledgement transaction set or unit of work, it has the option of requesting a corrected 277 acknowledgement.

Request

Provider.

The submitter has the option of

Payer.

The receiver must respond to the

Set Submitter Receiver fixing and resending a 278 transaction set or unit of work if the submitter receives a response that the 278 transaction set or unit of work was rejected.

provider if unable to process a 278 authorization or referral transaction set or unit of work request.

Response

Payer.

If a submitter receives a notice that its 278 transaction set or unit of work was formatted incorrectly, it must correct and resend the transaction.

Provider.

If the receiver receives an incorrect 278 transaction set or unit of work, it has the option of requesting a corrected 278 transaction set or unit of work.

820 Sponsoring Entity/Employer.

The submitter should resubmit if unacceptable.

Payer.

The receiver must respond if unable to process a transaction set or unit of work.

834 Sponsoring Entity/Employer.

The submitter should resubmit if unacceptable.

Payer.

The receiver must respond if unable to process a transaction set or unit of work.

835 Payer.

If the submitter receives a notice of a noncompliant transaction set or unit of work, the submitter must correct and resend if requested.

Provider.

The receiver has the option of requesting that the payer correct the transaction set or unit of work if unacceptable.

837 Provider or Payer.

If a receiver reports a rejected transaction set or unit of work, the submitter should correct the rejection and resend.

Payer.

The receiver must respond if unable to process the transaction set or unit of work.

Recommendation 1.1 – Receiving partners should return appropriate acknowledgements as defined below in Tables 2 and 3. Responses should meet the timeliness requirements specified in the service level or trading partner agreement.

Recommendation 1.2 – If the receiving partner sends a rejection message in an acknowledgement or response, the submitter may act on the rejection by correcting the error and resending a corrected transaction set. (Note: In some instances, a clearinghouse or intermediary may not be able to immediately correct the data content in error. In those instances, the acknowledgement or response should be returned to the initial submitter.)

Recommendation 1.3 – The submitter should receive acknowledgements as shown in Tables 2 and 3 and should not reject an acknowledgement as a non-supported transaction.

Section 2: Acknowledgment and Rejection Reporting Mechanisms WEDI believes that acknowledgment of receipt and reporting of rejections between trading partners currently is inconsistent and incomplete. Although no reporting mechanisms are mandated by the HIPAA Transactions and Code Sets Final Rule, it is important that an accurate audit trail be maintained to provide relevant feedback between trading partners. To solidify the audit process and add value to the transaction set processing cycle, it is critical to include complete, accurate and consistent reporting mechanisms between trading partners. Standard acknowledgements will significantly improve accountability, quick resolution of issues, resubmission of rejected transaction sets and/or units of work, and correction of submitter systems based on errors accepted but advised.

This document uses the term ‘stage’ to indicate a logical category of acknowledgement reporting. The stages may be thought of as though they take place in sequence.

However, computer systems usually are programmed to perform error checking for the several stages in parallel, and this document is not intended to imply that the processes should be serial. Rather, the stages are meant to assist in understanding categories and to separate functions that should be the same across the industry from functions that are specific to individual entities.

Following are the multiple stages of acknowledgement reporting:

1. Transaction set interchange validation

2. Format (X12 or NCPDP) syntax checking (described in the columns for functional group and transaction set syntax in Tables 2 and 3.

3. HIPAA implementation guide conformance checking.

4. Entity-specific pre-application validation, such as for companion guide requirements.

5. Entity-specific application rejection, such as adjudication results or response to a request transaction.

Recommendation 2.1 – Error checking, acknowledgment and reporting for the first three stages above (interchange validation, syntax checking and Implementation Guide conformance checking) should be implemented by all participants as outlined in Tables 2 and 3. In contrast, pre-application validation and application processing are specific to each participant. However, if implemented, they must be reported with the acknowledgement reporting standards shown in Tables 2 and 3.

Recommendation 2.2 – The transition period should be a minimum of two years in length. During that period, receivers must be able to send the standard acknowledgements, error reports and legacy reports as currently sent (hard copy and/or electronic), as requested by the submitter of the original transaction.

Recommendation 2.3 – Code values as defined in each Implementation Guide and is applicable to each specific acknowledgement and/or response should be adopted.

Section 3: Recommended Stages of Acknowledgement Reporting or Response (NOTE: To see the enveloping and looping structures within X12 transaction sets, see Appendix A, attached.)

Interchange Stage An interchange stage is the stage that validates a transaction set at the interchange level. This validation reviews the ISA and IEA segments and their consistency with the data they contain. Most X12 interchange errors will cause the receiver to reject the entire interchange with no further processing, but the receiver could accept or correct certain errors if they do not affect translation of the transaction set units of work. Errors will be reported in the TA1 segment.

Functional Group Stage The functional group validation is enforced for functional group level problems. This validation reviews the GS and GE segments and their consistency with the data they contain. Most X12 functional group errors will cause the receiver to reject the entire functional group with no further processing, but the receiver may accept or correct certain errors if they do not affect the translation of the transaction set units of work.

The receiver will report all detected errors, whether resulting in rejection or acceptance-with-error, with the 999 transaction set.

Transaction Set X12 Syntax Stage A transaction set may contain one or more standard transaction units of work. A transaction set syntax validation analyzes the transaction set and reports X12 syntax problems. This validation reviews the ST and SE segments, as well as information source segments and their consistency with the data they contain.

An error affecting one or several units of work within a transaction set must not cause adverse action against other valid units of work within the transaction set. This may require an accept-with-errors of the transaction set at this stage so as to accept the valid units of work at a subsequent stage. This is possible only if the syntax errors are not of a critical nature and does not force the rejection of the entire transaction set. An error in one transaction set must not affect the processing of other transaction sets contained in the functional group or interchange envelopes.

The receiver will report all detected errors (whether resulting in rejection or acceptance-with-error) with the 999.

Implementation Guide Conformance Stage An Implementation Guide (IG) conformance validation analyzes the transaction set for IG conformance problems. This validation varies depending on the implementation guide being used, as the code sets, looping structures and other implementation guide specific conformance requirements vary somewhat.

At this stage, the validation should be limited to what is described in the IGs and not include the application validation described below. For example, Companion Guide requirements should not be included at the IG conformance validation stage. All errors must be reported to the submitter, including when the transaction is accepted-with-errors. IG errors apply to data contained within the industry-defined looping structure (for example, to a single claim or all the claims for a specific billing provider).

Subsequent units of work within the same lG structure in the transaction set must be accepted provided no problems were found within their segments or loops. The scope of error action is limited to the IG restriction and is applied to a transaction set. See Tables 2 and 3 below for the acknowledgement reporting mechanisms for each transaction set.

Pre-application Validation Stage Pre-application validation may be performed in the front-end system, but is application-specific and not related to the X12 or implementation guide conformance of a transaction set. Typically, Companion Guide validation will be implemented at the application validation stage.

Although error messages generated from application validation are specific to a trading partner, business situation or application, they are generated before the transaction set is processed through an application. They typically are created to detect common and/or obvious errors so as to expedite advising the submitter and eliminate delays caused by flawed transaction sets or units of work moving forward through an application or adjudication system. They may report acceptance-with-error, correction or rejection.

As stated above, it is important to differentiate application messages from EDI messages for ease and consistency in implementation across trading partners. An example of an application validation could be checking the structure of a subscriber ID or checking for the presence of certain required provider identifiers, such as UPIN or Medicaid ID. The 824 acknowledgement transaction set is the appropriate transaction set for this stage of validation for transaction sets other than the X12N 837 transaction set. The 277 acknowledgement transaction set is the appropriate acknowledgement transaction set for the X12N 837 transaction set.

Application Processing Results Stage Application processing results are messages generated out of the application system to which a transaction set is directed. They provide a response to the unit of work sent into the application as a result of application processing. For a claim, the application result is a claim payment transaction, which may include payment and/or rejection information. For an eligibility request, the application result would be a response providing the inquiry results.

See Tables 2 and 3 below for the application reporting mechanisms for each transaction set at each stage.

Recommendation 3.1 – The stages described above should be applied throughout the health care industry and on all X12N HIPAA transaction sets. The stages indicate the appropriate acknowledgment and/or error report to be returned for each transaction set as specified in Tables 2 and 3.

Recommendation 3.2 – The industry should begin voluntary adoption of the 999 transaction set for the functional group, X12 syntax, and IG conformance stages transitioning from the 997 transaction set to the 999 transaction set in accordance with the timeline shown in Appendix B, attached.

Recommendation 3.3 – Acknowledgements should be implemented as recommended in the Legend for Tables 2 and 3.

Legend for Tables 2 and 3

Transaction Set Description Recommendation

TA1 Interchange Acknowledgement. This segment acknowledges the receipt of an X12 interchange header (ISA) and trailer (IEA) from a previous interchange. If the header/trailer pair is received correctly, the TA1 reflects a valid interchange, regardless of the validity of the data contents in the header/trailer envelope.

Use of the TA1 is subject to trading partner agreement and is not required.

For real-time transaction sets when the communication is held open, if the communication is successful, a TA1 is not needed.

The TA1 report should be used at the interchange stage. The TA1 acknowledges receipt and reports that the interchange has been accepted, accepted-with-errors or rejected. If the entire interchange is rejected, the only acknowledgement required is the TA1.

270 Eligibility Inquiry. The 270 is adopted by HIPAA as the standard transaction set to carry one or more eligibility inquiry units of work.

271 Eligibility Response. The 271 is adopted by HIPAA as the standard transaction set to carry one or more eligibility response units of work, which are the business responses to eligibility inquiry units of work.

275 Claim Attachment. Proposed rule to be released soon.

276 Claims Status Inquiry. The 276 is adopted by HIPAA as the standard transaction set to carry one or more claims status inquiry units of work.

Solicited

Claim Status Response

Claims Status Response. The 277 is adopted by HIPAA as the standard transaction set to carry one or more claims status response units of work, which are the business responses to the 276 claims status inquiry units of work.

Set Description Recommendation

Acknowledge ment (acknow)

The Health Care Claim Acknowledgment 277 commonly referred to as the unsolicited 277. When used as an acknowledgement, the 277 should be used to communicate the total number of claims accepted, pended or rejected, and the reasons for pending or rejecting the claims.

The 277 health care claim acknowledgment should be created by the receiver of the 837 claim transaction set to acknowledge to the submitter each unit of work, regardless of whether the unit of work was accepted into the adjudication system or rejected. Having an automated acknowledge-ment would allow clearinghouses and/or providers to retain the audit trail of information without handling or storing paper and allow for automated tracking of claims to focus on those rejected or that contain errors.

Request for Additional

Information

Request for Additional Information. The 277 will serve as the claim attachment request for additional information.

278 Referral Certification and Authorization.

The 278 is adopted by HIPAA as the standard transaction set to carry one or more requests for authorization for health care, requests for referral or the business responses to these requests.

820 Premium Payment. The 820 was transaction set for the premium payment transaction.

Set Description Recommendation

824 Application Acknowledgement. This transaction set is an acknowledgment of X12 transactions sets received by receivers’ application systems. The transaction set must be syntactically correct, as reported by the 999, before moving forward for application validation.

The 824 is not a replacement for the 999 transaction and must be used in conjunction with the 999 as noted in Tables 2 and 3.

The 824 application acknowledgement should be created by the receiver of non-claim transaction sets to acknowledge each unit of work to the submitter, regardless of whether the unit of work was accepted, accepted-with-errors or rejected.

834 Health Plan Enrollment and Disenrollment. The 834 was adopted by HIPAA as the standard transaction set to carry one or more enrollment or disenrollment units of work.

835 Remittance Advice. The 835 was transaction set to carry one or more electronic remittance advices describing denial, payment or partial payment of a health care or NCPDP claim. The 835 also was adopted as the standard transaction set to carry one or more payment orders.

837 Claim. The 837 was adopted by HIPAA in three different Implementation Guides as the standard transaction set to carry one or more health care claims.

997 Functional Acknowledgment. The 997 is a transaction set that carries acknowledgments to indicate the results of the syntactical analysis of the X12 transaction sets contained within a transaction set interchange (found between the ISA and IEA).

X12 has approved the 999, so the 997 report should be used only for acknowledge-ment or X12 syntax error reporting during the transition period noted in the timeline in Appendix B.

Set Description Recommendation

999 Implementation Acknowledgment. The 999 is a transaction set that indicates the results of the conformance analysis of the X12 transaction sets contained within a transaction set interchange against the requirements of both X12 syntax and Implementation Guide constraints. This transaction set is available only in X12 version 5010 and later, but still may be used for acknowledging prior versions of the standard.

The 999 implementation guide should emphasize use of the accept-with-errors functionality so it is possible to accept individual transaction sets at a later stage without forcing the rejection of the entire transaction set with a 999 when the errors affect only one unit of work within the transaction set. The same implementation guide should be used for all the HIPAA standard transaction sets.

Tables 2 and 3 reflect the business process models and final disposition of the exchange. The determination of final disposition is related to the authoritative source of the data. Therefore, the authoritative source of the data will always communicate the final disposition. Any further communication after final disposition will need to be pursued through other means of communication, whether that be sending an additional electronic communication or fax, or via telephone. This approach was used when creating Tables 2 and 3.

Table 2 Real-time Acknowledgements

Transaction Set Interchange

Functional Group/ Transaction Set Syntax/

IG Conformance

Pre-application Validation

(companion documents)

Application Results

270 TA1(1) 999(2) 271* 271

271 TA1(1) 999(2) N/A N/A

276 TA1(1) 999(2) 277* 277

Response to 276

TA1(1) 999(2) N/A N/A

278 TA1(1) 999(2) 278* 278

(1) Do not use with real-time transaction sets (that is, when the communication is held open) to report valid interchanges. Use only with real-time transaction sets when the transaction set contains errors.

(2) Do not use with real-time transaction sets to report valid transaction set syntax within a GS/GE functional group or ST/SE transaction set. Use only with real-time transaction sets when the transaction set contains errors.

* The application results transaction set also may be used in the pre-application stage.

Table 3 Batch Acknowledgements

Transaction Set Interchange

Functional Group/ Transaction Set

Syntax/ IG Conformance

Pre-application Validation

(companion documents)

Application Results

270 TA1 999 271* 271

271 TA1 999 N/A N/A

275 TA1 999 824 835

276 TA1 999 277* 277

Response to 276

TA1 999 N/A N/A

Request for

Addl Info

TA1 999 824 275

Acknow

TA1 999 824 N/A

278 TA1 999 278* 278

820 TA1 999 824 N/A

834 TA1 999 824 N/A

835 TA1 999 824 N/A

837 TA1 999 277 Acknow 835

*The application results transaction set also may be used in the pre-application stage.

Business Transaction Set Flows The following business transaction set flows illustrate the recommendations made above. Clearinghouses (possibly multiple clearinghouses) may be employed by either the providers or payers to send and receive the transaction sets being exchanged.

However, the most complex situation in this illustration assumes that only one provider clearinghouse and one payer clearinghouse is involved. Five distinct examples are displayed below, but by no means should these examples lead the reader to believe that these are the only situations occurring. A payer frequently will receive transaction sets from individual providers, as well as from many clearinghouses. The acknowledgement transaction sets should remain the same, regardless of whether the receiver is responding to an individual or a clearinghouse. For purposes of this paper, the examples are simplified for reasons of clarity. The 277 transaction set noted in the examples below all refer to the 277 acknowledgement transaction set:

1. Example 1 illustrates a situation in which the provider is sending directly to a payer and no clearinghouse is involved.

2. Example 2 illustrates a situation in which the provider has employed the services of a clearinghouse and the clearinghouse sends directly to the payer.

3. Example 3 illustrates a situation in which the payer has employed the services of a clearinghouse and the provider sends directly to the payer’s clearinghouse.

4. Example 4 illustrates a situation in which the provider and payer both have employed the services of clearinghouses.

All examples below illustrate the transaction set flow of a batch X12N transaction set containing claims as the unit of work. Please note that, if the transaction set is an NCPDP transaction set, the TA1, 999 and 277 acknowledgements would not be needed; however, an 835 response still would be required.

Example 1

In this example, the 837 transaction set is sent directly from the provider to the payer:

1. The provider sends the payer an 837 transaction set.

2. The payer checks the interchange during the communication session. The resulting acknowledgement is the TA1 transaction set.

3. The payer checks the functional group, Transaction Set X12 syntax and X12N

Implementation Guide conformance. The resulting acknowledgement is the 999 transaction set. This acknowledgement may be given during the communication session; however, in some cases, the acknowledgement will be ready for retrieval during the next communication session.

4. The payer validates the transaction set against the payer’s own companion guide and generates a 277 acknowledgement transaction set to identify conforming and rejected units of work before processing the transaction set through the application stage. This acknowledgement may be produced before the next communication session.

5. The payer creates the 835 transaction set. This transaction set may be produced before the next communication session.

6. The provider validates the 835 transaction set and creates the TA1, 999 and 824 transaction sets. Nonconformities, such as transaction set syntax or out-of-balance errors, must be corrected by the payer and the transaction set then must be resent.

Provider

Payer

Example 2

1. The provider sends an 837 transaction set to its clearinghouse.

2. The clearinghouse responds with TA1, 999 and 277 acknowledgement transaction sets. (Note: The 999 and 277 may or may not occur within the same communication session. The 999 and 277 may be made available during the next communication session.)

3. The clearinghouse sends an 837 transaction set to the payer.

4. The payer responds with TA1, 999 and 277 acknowledgement transaction sets.

(Note: The 999 and 277 may or may not occur within the same communication session. The 999 and 277 may be made available during the next communication session.)

5. The clearinghouse passes the payer’s 277 acknowledgement transaction set back to the provider. (Note: Rejects identified in the TA1, 999 received by the clearinghouse from the payer would be rejects that the clearinghouse would need to address. The 277 acknowledgement rejections would be addressed by the provider. The 999 and 277 may or may not occur within the same communication session. The 999 and 277 may be made available during the next communication session.)

6. The clearinghouse picks up the 835 remittance transaction set from the payer.

7. The clearinghouse responds with TA1, 999 and 824 transaction sets. (Note:

Rejections at this stage need to be addressed by the payer.)

8. The provider picks up the 835 remittance transaction set from the clearinghouse.

9. The provider responds with TA1, 999 and 824 transaction sets. (Note: Rejections at this stage need to be addressed by the clearinghouse.)

Clearinghouse

Example 3

1. The provider sends an 837 transaction set to the payer’s clearinghouse.

2. The clearinghouse responds with TA1, 999 and 277 transaction sets. (Note: The 999 and 277 may or may not occur within the same communication session. The 999 and 277 may be made available during the next communication session.)

3. The clearinghouse passes the 837 transaction set to the payer.

4. The clearinghouse picks up the 277 and 835 remittance transaction sets from the payer.

5. The provider picks up the payer’s 277 and 835 remittance transaction sets from the clearinghouse.

6. The provider responds with TA1, 999 and 824 transaction sets. (Note: Rejections from the TA1 or 999 transaction sets need to be addressed by the clearinghouse. Other rejections identified in the 824 transaction set may need to be returned to the payer.)

7. The clearinghouse returns the 824 transaction set to the payer. Rejections for reasons such as transaction set out-of-balance must be corrected by the payer and resent.

Clearinghouse

Example 4

1. The provider sends the 837 transaction set to the provider’s clearinghouse.

2. The provider’s clearinghouse responds to the provider with TA1, 999 and 277 acknowledgement transaction sets. (Note: The 999 and 277 may or may not occur within the same communication session. The 999 and 277 may be made available during the next communication session.)

3. The provider’s clearinghouse sends the 837 transaction set to the payer’s clearinghouse.

4. The payer’s clearinghouse responds to the provider’s clearinghouse with TA1 and 999 transaction sets, and possibly the 277 acknowledgement transaction set if that functionality exists at the payer’s clearinghouse. (Note: The 999 transaction set may not be returned within the same communication session, but may be available during the next communication session.)

5. The payer’s clearinghouse passes the 837 transaction set to the payer.

6. The payer’s clearinghouse picks up the 277 acknowledgement (if not created by the payer’s clearinghouse) and 835 remittance transaction sets from the payer.

7. The provider’s clearinghouse picks up the payer’s clearinghouse’s 277 acknowledgement and 835 remittance transaction sets from the payer’s clearinghouse.

8. The provider’s clearinghouse responds with TA1, 999 and 824 transaction sets.

(Note: Some rejections at this stage need to be addressed by the payer’s clearinghouse;

others may need to be returned to the payer.)

Clearing house

Provider Clearing house

9. The payer’s clearinghouse returns rejections to the payer. Rejections such as out-of-balance transaction sets must be corrected by the payer and resent.

10. The provider picks up the 835 and 277 acknowledgement transaction sets from the provider’s clearinghouse. The 277 acknowledgement transaction set would be errors the provider would need to address.

11. The provider responds with TA1, 999 and 824 transaction sets. (Note: Rejections at this stage need to be addressed by the provider’s clearinghouse.)

Appendix A

Reference Diagram: Enveloping and Looping Structures within X12 Transaction Sets

Washington Publishing Company © 2005.

Reprinted with permission.

Appendix B

WEDI Recommended Acknowledgement Implementation Time Line (as of September 20, 2005)

Proposed Task Implementation

Start Date

Proposed Task Completion

Date Proposed Implementation Task

11/01/2005 01/01/2006 Review and report on the success of the pilots in UT and NJ and conduct a WEDI pilot for the 277 Acknowledgement Version 5010 transaction set.

01/01/2006 07/01/2006 Establish pilot tests for the TA1 Version 5010 transaction set.

01/01/2006 07/01/2006 Establish pilot tests for the 999 Version 5010 transaction set.

07/01/2006 N/A Full implementation of the TA1 on all relevant transaction sets.

07/01/2006 10/01/2006 Begin the transition from the 997 to the 999.

07/01/2006 N/A All payers and clearinghouses make available a 277 acknowledgement that identifies all accepted and rejected claim units of work.

10/01/2006 N/A Full implementation of the 999 on all relevant transaction sets.

01/01/2007 07/01/2007 Establish pilot tests for the 824 transaction sets.

07/01/2007 N/A Full implementation of the 824 on all relevant transaction sets.