999 Implementation Acknowledgment for Health Care Insurance (008020X335)

JANUARY 2022

Copyright © 2008-22, X12 Incorporated, Format © 2008-22 Washington Publishing Company. Exclusively published by the Washington Publishing Company. No part of this publication may be distributed, posted, reproduced, stored in a retrieval system, or transmitted in any form or by any means without the prior written permission of the copyright owner.

All rights reserved.

Abstract

The purpose of this implementation guide is to provide standardized data content and structure to users of the X12 999 transaction set.

Preface

X12 standards are developed to identify the broadest data requirements for a transaction set. Type 3 Technical Reports (TR3), also known as implementation guides, define the explicit data requirements for a specific business purpose. Trading partners who implement according to the instructions in this TR3 can exchange data consistently with multiple trading partners.

As X12 does not define transport requirements, trading partners define their specific transport requirements separately.

1.1 Implementation Purpose and Scope

For the health care industry to achieve the potential administrative cost savings with Electronic Data Interchange (EDI), standards have been developed to facilitate consistent implementation by all organizations. To facilitate a smooth transition into the EDI environment, uniform implementation is critical.

The purpose of this implementation guide is to provide standardized data content and structure to users of the X12 999 transaction set for Health Care Insurance. This implementation guide is intended to enable a receiver of a functional group based on an X12 Implementation Guideline (TR3) related to Health Care Insurance business processes, to report errors as specified by that transaction's implementation guideline (TR3), or to acknowledge receipt of an error-free transaction set.

1.2 Version Information

This implementation guide is based on the October 2020 X12 standards, referred to as Version 8, Release 2 (008020).

The unique Version/Release/Industry Identifier Code for transaction sets that are defined by this implementation guide is 008020X335.

The two-character Functional Identifier Code for the transaction set included in this implementation guide:

• FA   Functional or Implementation Acknowledgment Transaction Sets (997, 999)

The Version/Release/Industry Identifier Code and the applicable Functional Identifier Code must be transmitted in the Functional Group Header (GS segment) that begins a functional group of these transaction sets. For more information, see the descriptions of GS01 and GS08 in Appendix C EDI Control Directory.

1.3.1 Batch and Real-Time Usage

There are multiple methods available for sending and receiving business transactions electronically. Two common modes for EDI transactions are batch and real-time.

Batch - In a batch mode the sender does not remain connected while the receiver processes the transactions. Processing is usually completed according to a set schedule. If there is an associated business response transaction (such as a 271 Response to a 270 Request for Eligibility), the receiver creates the response transaction and stores it for future delivery or transmits the response transaction back to the sender of the original transaction. The sender of the original transmission reconnects at a later time and picks up the response transaction. Note: The sender of the original transmission may not always be the entity that picks up the response transaction at a later time (e.g. Provider submitting through a clearinghouse.)

Real-Time - In real-time mode the sender remains connected while the receiver processes the transactions and returns a response transaction to the sender. This implementation guide does not set specific response time parameters for implementers.

This implementation guide was based on requirements for batch mode. Willing trading partners may use batch or real-time mode.

1.3.2 Other Usage Limitations

The X12 999 transaction set is designed to report on conformance against an implementation guideline (TR3), but can also report on conformance with the standard syntax requirements.

The 999 is not limited to only IG errors. It can report standard syntax errors, as well as IG errors.

This 999 implementation guide can NOT be used for any application level validations.

The X12 999 transaction set is designed to respond to one and only one functional group (i.e. GS/GE), but will respond to all transaction sets (i.e. ST/SE) within that functional group.

When acknowledging a healthcare implementation guide (TR3) based transaction, only a single transaction set 999 can be used. When acknowledging a healthcare implementation guide (TR3) based transaction, the transaction set 997 must not be used.

This X12 999 Implementation Guideline must NOT be used to respond to any management transaction sets intended for acknowledgments, i.e. TS 997 and 999, or interchange control segments related to acknowledgments, i.e. TA1 and TA3.

1.4 Business Usage

This X12 999 implementation guide (TR3) is intended to meet the needs of the Health Care industry as a whole;

1. for a standard implementation guideline designed for reporting of syntactical errors against a functional group based on an X12 Implementation Guideline,
2. to report receipt of a functional group that fully complies with an implementation guideline.

For more information on the relationship between the 999 transaction set and other response transaction sets, refer to the X12 document "X12 Acknowledgement Reference Model".

1.4.1 Health Care Transaction Flow

Each X12 implementation guide explains how to use X12 transaction sets to meet a single defined business purpose. The diagrams found at https://www.x12.org/flow depict the business functions supported by the X12 health care implementation guides.

1.5 Business Terminology

To ensure consistent use of terms, definitions, and acronyms across X12 products, X12 maintains the Wordbook, a comprehensive corporate glossary. The included terms are either proprietary to X12, cite definitions published by another authority, or represent common terms and definitions that are relevant to X12's work. The terms and definitions defined in the Wordbook are used in X12 work products when applicable, without modification or revision. The Wordbook can be referenced online at wordbook.x12.org.

1.6 Transaction Acknowledgments

The purpose of transaction acknowledgments is to report to the sender whether the transaction being acknowledged was accepted or rejected.

The X12 Technical Report Type 2, Acknowledgment Reference Model provides guidance on several control structures and transaction set standards intended to augment EDI auditing and control systems.

1.7 Related Transactions

This X12 999 Implementation Guide (TR3) is designed for responding to Health Care transactions based upon an Implementation Guide.

1.8 Trading Partner Agreements

Trading partner agreements are used to establish and document the relationship between trading partners. A trading partner agreement must not override the specifications in this implementation guide if a transmission is reported in GS08 to be a product of this implementation guide.

1.9 Transaction Compliance

There are three types of compliance that may be relevant to a transmitted transaction.

Compliance with implementation guide requirements

Compliance with state and federal regulation

Compliance with trading partner contractual agreements

1.9.1 Transaction Compliance with Implementation Guide Requirements

A transaction complies with X12 implementation guide requirements if the transaction satisfies all format and content rules and constraints specified in the applicable X12 standards and the implementation guide (also known as a TR3) itself.

Should additional clarification of an X12 implementation guide requirement be desired, two options are available.

• The following X12 work products can be viewed online at https://products.x12.org:
  Interchange Control Structure (X12.5)
  Application Control Structure (X12.6)
  Interconnect Mailbag Control Structures (X12.56)
  Security Structures (X12.58)
  Implementation of EDI Structures - Semantic Impact (X12.59)
  Design Rules and Guidelines (X12.61)
  Acknowledgment Reference Model
  Reference Model for Inclusion of Sender and Receiver Identification in XML
  Compliance in X12.
• The X12 Request for Interpretation (RFI) viewer may be searched: https://rfi.x12.org. If existing RFI responses do not clarify the outstanding issue, a new RFI may be submitted.

X12 does not specify the business rules that the receiving entity must use to decide when to accept or reject a transaction. The receiver will handle transactions that are not TR3-compliant based on its own business process.

A receiver may specify its business rules in a trading partner agreement or companion document. As stated in §1.8, these documents do not override TR3 requirements, nor change how transaction compliance with this TR3 is determined.

1.9.2 Transaction Compliance with State and Federal Regulations

This implementation guide has been developed for use as an insurance industry implementation guide. At the time of publication it has not been adopted as a state or federal standard. Should this implementation guide be adopted as a standard, the adopting authority will establish compliance dates for its use by impacted entities.

X12 is not the authority for determining compliance with regulatory requirements that might further constrain implementation guide requirements. Questions of compliance for regulatory requirements should be directed to the governing authority.

X12 does not specify the business rules that the receiving entity must use to decide when to accept or reject a transaction. The receiver will handle transactions that do not comply with applicable regulatory requirements as specified by the applicable regulation(s) or governing authority.

1.9.3 Transaction Compliance with Contractual Requirements

X12 is not the authority for determining compliance with contractual requirements that might further constrain implementation guide requirements. Questions of compliance for contractual requirements should be directed to the contracting entity.

X12 does not specify the business rules that the receiving entity must use to decide when to accept or reject a transaction. The receiver will handle transactions that do not comply with contractual requirements as specified by the applicable contract or contracting entity.

1.10.1 Overall Data Architecture

NOTE
See X12.6 to review the transaction set structure, including descriptions of segments, data elements, levels and loops.

1.10.1.1 Response Process

For more information on the relationship between the 999 transaction set and other response transaction sets, refer to X12 document Acknowledgment Reference Manual, Chapter 6. Use the following link to access the X12 Acknowledgment Reference Manual.

2. Transaction Set

NOTE
See X12 documents X12.5, X12.6, and X12.59 to review transaction set structure, including descriptions of segments, levels, and loops.

2.1 Presentation Examples

The X12 standards are generic. For example, multiple trading communities use the same PER segment to specify administrative communication contacts. Each community decides which elements to use and which code values in those elements are applicable.

This implementation guide uses a format that depicts both the generalized standard and the insurance industry-specific implementation. In this implementation guide, IMPLEMENTATION specifies the requirements for this implementation. X12 STANDARD is included as a reference only.

The transaction set presentation is comprised of two main sections with subsections within the main sections:

Transaction Set Listing

There are two sub-sections under this general title. The first sub-section concerns this implementation of a generic X12 transaction set. The second sub-section concerns the generic X12 standard itself.

This section lists the levels, loops, and segments contained in this implementation. It also serves as an index to the segment detail.

This section is included as a reference.

Segment Detail

There are three sub-sections under this general title. This section repeats once for each segment used in this implementation providing segment specific detail and X12 standard detail.

This section is included as a reference.

This section is included as a reference. It provides a pictorial view of the standard and shows which elements are used in this implementation.

This section specifies the implementation details of each data element.

These illustrations (Figures 2.1 through 2.5) are examples and are not extracted from the Section 2 detail in this implementation guide. Annotated illustrations, presented below in the same order they appear in this implementation guide, describe the format of the transaction set that follows.

Figure 2.1 - Transaction Set Key - Implementation

Figure 2.2 - Transaction Set Key - Standard

Figure 2.3 - Segment Key - Implementation

Figure 2.4 - Segment Key - Diagram

Figure 2.5 - Segment Key - Element Summary

2.2.1 Industry Usage

Industry Usage describes when loops, segments, and elements are to be sent when complying with this implementation guide. The three choices for Usage are required, not used, and situational. To avoid confusion, these are named differently than the X12 standard Condition Designators (mandatory, optional, and relational).

2.2.1.1 Determining Transaction Compliance with Industry Usage Requirements

A transmitted transaction complies with the governing implementation guide when it satisfies the requirements as defined within the implementation guide. Specifically, the presence or absence of an item (loop, segment, or element) complies with the industry usage specified by this implementation guide according to the following table.

2.2.2 Loops

Loop requirements depend on the context or location of the loop within the transaction. See Appendix B for more information on loops.

• A nested loop can be used only when the associated higher level loop is used.
• The usage of a loop is the same as the usage of its beginning segment.
  • If a loop's beginning segment is Required, the loop is Required and must occur at least once unless it is nested in a loop that is not being used.
  • If a loop's beginning segment is Situational, the loop is Situational.
• Subsequent segments within a loop can be sent only when the beginning segment is used.
• Required segments in Situational loops occur only when the loop is used.

3. Examples

Business scenario examples for use of this transaction can be found on the X12 Examples website at http://examples.x12.org. The X12 Examples website provides convenient access to examples of X12 transaction transmissions, including the data stream and a description of the associated scenario.

Appendix A. External Code Sources

Prior to this publication, X12 TR3s contained a subset of the overall Code Source Directory, formerly known as Appendix A of X12.3. External code lists are not part of the X12 standard and are provided for information purposes only. The full listing is available in Glass, X12's On-Line viewer.

Read more about Glass here: https://glasshelp.x12.org/.

Where an external code source is referenced in this publication, the implementer is required to use only the codes from that list. Codes must be reported as listed in the code source (e.g. with leading zeroes). Implementers must follow the instructions for code use that are supplied by the code set owner.

B.1.1 X12 Referenced and Related Standards

This technical report is based on the X12 EDI standard which comprises a series of interdependent publications. Implementers are advised to consult these publications when using this technical report.

The following standards are required to interpret, understand, and use this technical report:

• X12.5 - Interchange Control Structure
• X12.6 - Application Control Structure

The following guideline is useful to interpret, understand, and use this technical report:

• Compliance in X12

The following reference model is useful to interpret, understand, and use this technical report:

• Acknowledgment Reference Model

All of the documents above are available online using links to X12's Online Viewer.

B.1.1.1 Transmission Control Schematic

Refer to X12.5 - Interchange Control Structures, Section 3.5 - Order of Control Segments, and Chapter 5 Interchange Segment Specifications.

Similar transaction sets, called "functional groups," can be sent together within a transmission. Each functional group is prefaced by a group start segment, and a functional group is terminated by a group end segment. One or more functional groups are prefaced by an interchange header and followed by an interchange trailer. Figure B.1 - Transmission Control Schematic, illustrates this interchange control.

Figure B.1 - Transmission Control Schematic

B.1.1.2 Constraints applicable to the suite of TR3s

Refer to X12.6 - Application Control Structure, Section 3.2.8 - Minimums/Maximums.

Data element minimum and maximum lengths are set by the X12 standard. This implementation guide may further restrict minimum and maximum lengths within the bounds set by the standard. Such restrictions may occur implicitly by virtue of the allowed qualifier for the data element, or they may be stated explicitly in a note attached to the element or in the general limitations below.

B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification

The current X12 standard allows a maximum length greater than 50 characters for data element 127. For implementations governed by this implementation guide, unless another value is specified in an attached note, the maximum length of each occurrence of this data element is constrained to 50 characters.

B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount

For implementations governed by this implementation guide, unless another value is specified for an instance of Data Element 782 within Section 2 (Transaction Set), each occurrence of Data Element 782 (Monetary Amount) will be limited to a maximum length of 10 characters including reported or implied places for cents (implied value of 00 after the decimal point). Note that the decimal point and leading sign, if sent, are not part of the character count.

EXAMPLE

• The following transmitted value represents the largest positive dollar amount that can be sent: 99999999.99
• The following transmitted value is the longest string of characters that can be sent representing whole dollars. 99999999
• The following transmitted value is the longest string of characters that can be sent representing negative dollars and cents. -99999999.99
• The following transmitted value is the longest string of characters that can be sent representing negative whole dollars. -99999999

B.1.1.3 Decimal

While the X12 standard supports usage of exponential notation, this guide prohibits that usage.

Appendix D. Change Summary

This Implementation Guide (008020X335) defines the X12 requirements for the Implementation Acknowledgment for Health Care Insurance. It is based on version/release/subrelease 008020 of the X12 standards.