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.