Contractors
shall implement the following non-HIPAA mandated transactions as
appropriate.
6.1 Acknowledgments
The
following are required for determining an incoming transaction to
be HIPAA-compliant:
• The interchange or “envelope” shall
be correct;
• The transaction
shall be syntactically correct at the standard level;
• The transaction
shall be syntactically correct at the implementation guide level;
and
• The transaction
shall be semantically correct at the implementation guide level.
Syntax relates to the structure
of the data. Semantics relates to the meaning of the data. Any transaction
that meets these four requirements is HIPAA-compliant and shall
be accepted.
Note: In the
case of a claim transaction, “accepted” does not mean that it shall
be paid. A transaction that is accepted may then be subjected to
business or application level edits. “Accepted” transactions, i.e.,
those that are HIPAA-compliant, that subsequently fail business
or application level edits shall be rejected, developed, or denied
in accordance with established procedures for such actions.
6.1.1 Interchange
Acknowledgment
The Interchange or TA1 Acknowledgment
is a means of replying to an interchange or transmission that has
been sent. The TA1 verifies the envelopes only. Contractors shall
develop and implement the capability to generate and send the following
transaction. Reference the most currently adopted HIPAA version
of ASC X12C/231 Implementation Acknowledgment for Health Care Insurance (999)
TR3, Appendix C.1, to address implementation use of this transaction.
• The ANSI ASC X12N TA1 - Interchange Acknowledgment
Segment.
6.1.2 Implementation Acknowledgment
The Implementation Acknowledgment
Transaction is used to report the results of the syntactical analysis
of the functional groups of transaction sets. It is generally the
first response to a transaction. (Exception: The TA1 will be the
first response if there are errors at the interchange or “envelope”
level.) Implementation acknowledgment transactions report the extent
to which the syntax complies with the standards for transaction
sets and functional groups. They report on syntax errors that prevented
the transaction from being accepted. Version 5010 of the implementation acknowledgment
transaction does not cover the semantic meaning of the information
encoded in the transaction sets. The implementation acknowledgment
transaction may be used to convey both positive and negative acknowledgments.
Positive acknowledgments indicate that the transaction was received
and is compliant with standard syntax. Negative acknowledgments
indicate that the transaction did not comply with standard syntax.
Contractors shall develop and implement the capability to generate,
send, and receive the following transaction (both positive and negative).
• The ASC X12N 999 - Implementation Acknowledgment,
most currently adopted version.
6.1.3 Implementation
Guide Syntax And Semantic And Business Edit Acknowledgments
Contractors
may use a proprietary acknowledgment to convey implementation guide syntax
errors, implementation guide semantic errors, and business edit
errors. Alternatively, for claim transactions (ANSI ASC X12N 837
Professional, Institutional, or Dental), the Health Care Claim Acknowledgment
Transaction (ANSI ASC X12N 277CA) may be used to indicate which
claims in an 837 batch were accepted into the adjudication system
(i.e., which claims passed the front-end edits) and which claims
were rejected before entering the adjudication system.
Note: In
the future, the standards may mandate transactions for acknowledgments
to convey standard syntax, implementation guide syntax, implementation
guide semantic, and business/application level edit errors. Contractors
shall develop and implement the capability to generate and send
the following transaction(s).
6.1.3.1 A proprietary
acknowledgment containing syntax and semantic errors at the implementation
guide level, as well as business/application level edit errors.
6.1.3.2 For 837 claim
transactions, contractors may use the Health Care Claim Acknowledgment Transaction
Set (ANSI ASC X12N 277CA, most currently adopted version) in place
of a proprietary acknowledgment.
6.2 Medicaid
Non-Pharmacy Subrogation Claims
6.2.1 When a beneficiary is eligible for
both TRICARE and Medicaid,
32 CFR 199.8 establishes TRICARE
as the primary payer. Existing TRICARE policy requires contractors
to arrange coordination of benefits procedures with the various
states to facilitate the flow of claims and to try to achieve a reduction
in the amount of effort required to reimburse the states for the
funds they erroneously disbursed on behalf of the TRICARE-eligible
beneficiary. TRICARE Policy requires that the contractors shall
make disbursements directly to the billing state agency.
6.2.2 Currently,
a subrogation non-pharmacy claim from a Medicaid State Agency is
not a HIPAA covered transaction since the Transaction and Code Sets
Rule defines a health care claim or equivalent encounter information
transaction as occurring between a provider and a health plan. Since
Medicaid State Agencies are not providers, their claims to TRICARE
are not covered transactions and need not be in standard format;
however, currently adopted HIPAA ASC X12 837 claim standards used
for processing Institutional, Professional and Dental claims include
the ability to perform Medicaid subrogation. While they are not
currently mandated for use under HIPAA, covered entities are not prohibited
from using currently adopted HIPAA transactions for non-pharmacy
Medicaid subrogation transactions between willing trading partners.
• In accordance with existing TRICARE
policy, contractors shall coordinate with the Medicaid State Agencies
submitting non-pharmacy claims and define the acceptable forms and
formats of the claims that are to be used by the Medicaid State
Agencies when billing TRICARE. State Agency Billing Agreements shall
be modified to reflect the acceptable forms and formats.
Note: It
is expected that the Secretary, HHS will modify the standard to
incorporate Medicaid subrogation claims as HIPAA covered transactions
sometime in the future. If this occurs, this section will be modified
to reflect the change.