1.0
Background
And Provisions
The
Department of Health and Human Services (DHHS)
published the first administrative simplification related final
rule on August 17, 2000, which added subchapter C, “Administrative
Data Standards and Related Requirements,” to 45 CFR subtitle A.
Subchapter C includes Parts 160 and 162, which will be referred
to here as the Transaction and Code Sets Rule. On January 16, 2009,
HHS published a Final Rule known as “Health Insurance Reform: Modifications
to Health Insurance Portability and Accountability Act (HIPAA) Electronic
Transaction Standards.” This Final Rule (referred to here as the
“Modifications to HIPAA Electronic Standards Final Rule”) adopted
updated versions of the standards for electronic transactions that
were originally adopted under the Administrative Simplification
subtitle of HIPAA. Since 2009, HHS has published additional Final
Rules for HIPAA initiatives which affect HIPAA transactions. As
a HIPAA covered entity; TRICARE will comply
with applicable adopted HIPAA rules.
1.1 Compliance
Dates
1.1.1 The
contractor shall comply with the most current Final
Rules on HIPAA adopted Electronic Transaction Standards, including
compliance dates.
1.1.2 The
contractor shall comply with the most current Final
Rules on HIPAA adopted Transaction Operating Rules, including compliance
dates.
1.1.3 The
contractor shall comply with Final Rules on HIPAA
adopted code sets (e.g., the use of International Classification
of Diseases, Tenth Revision (ICD-10)), including compliance dates.
1.1.4 The contractor
shall comply with Final Rules on HIPAA adopted identifiers (e.g.,
the use of Health Plan Identifiers (HPID)), including compliance
dates.
1.2 Applicability
The
contractor shall comply with HIPAA Electronic Standards Final Rules
as the rules apply to health plans, health care clearinghouses,
and health care providers who transmit any health information in
electronic form in connection with a transaction covered by the
rule. These Rules refer to health plans, health care clearinghouses,
and health care providers as “covered entities.” The initial Transaction
and Code Sets Rule specifically names the health care program for
active duty military personnel under Title 10 of the United States
Code (USC) and the Civilian Health and Medical Program of the Uniformed
Services (CHAMPUS) as defined in 10 USC 1072(4), as health plans
and this designation has not changed in the Modifications to HIPAA
Electronic Standards Final Rule.
1.3
Transaction
Implementation Specification Standards
1.3.1 The
contractor shall comply with the most current HIPAA Electronic Standards
Final Rules, which adopt specifically stated HIPAA implementations
of Accredited Standards Committee (ASC) X12 standards,
accompanying Errata, Addenda, and Operating
Rules. In the event that additional HIPAA adopted transactions,
accompanying Errata, Addenda, or Operating Rules are mandated for
use in the future; the contractor shall
comply with those HIPAA adopted transaction initiatives by the compliance dates
specified by HHS in Final Rules.
1.3.2 For
retail pharmacy electronic transactions covered under HIPAA, the
contractor shall comply with HIPAA adopted National Council for
Prescription Drug Programs, (NCPDP) Telecommunication and Batch
Standard Implementation Guides named and adopted by Final Rule.
1.3.2.1 The contractor shall accommodate
use of both NCPDP and HIPAA ASC X12 837 Health Care Claim: Professional
for billing of retail pharmacy supplies and professional services.
1.3.2.2 The contractor shall accommodate
use of the HIPAA adopted standard for the subrogation of pharmacy
claims paid by Medicaid which is named and adopted in Final Rule
as the NCPDP Batch Standard Medicaid Subrogation Implementation
Guide. This standard is applicable to Medicaid agencies in their
role as health plans, as well as to other health plans such as TRICARE
that are covered entities under HIPAA.
1.3.3 The contractor shall comply
with HIPAA related Final Rules associated with Section 1104 of the
Administrative Simplification provisions of the Patient Protection
and Affordable Care Act (PPACA) (hereafter referred to as the Affordable
Care Act or ACA). The ACA establishes new requirements for administrative
transactions to improve the utility of the existing HIPAA transactions
and reduce administrative costs (e.g., standard Operating Rules).
1.3.4 HIPAA Adopted Code Set Standards
The
contractor shall comply with HIPAA adopted code sets in accordance
with Final Rules (e.g., International Classification of Diseases,
10th Revision (ICD-10)).
2.0 TRICARE Objectives
2.1 The TRICARE program shall be
in full compliance with the HIPAA Transactions, Code Sets, and Identifiers
Final Rules.
2.2 Private Care
Systems shall be able to receive, process, and send HIPAA compliant
standard transactions where required.
3.0 Contractor Relationships To
The TRICARE Health Plan
3.1 The
Transaction and Code Sets Rule specifically names the health care
program for active duty military personnel under 10 USC
and CHAMPUS as defined in 10 USC 1072(4),
as health plans. For the purposes of implementing the Transaction
and Code Sets Rule, the term “TRICARE” will be used in this chapter
to mean a combination of both the Direct Care (DC) and Private Care
Systems. TRICARE is therefore a health plan.
3.2 The
relationships of the entities that comprise TRICARE determine, in
part, where standard transactions shall be used. Determinations
as to when and where the transaction standards apply are not based
on whether a transaction occurs within or outside of a “corporate
entity” but rather are based
upon the
answers to the two following questions:
• Is the
transaction initiated by a covered entity or its business associate?
If the answer is “no,” then the standard does not apply and is not used.
If “yes,” then the standard applies and the next question needs
to be answered.
• Is the transaction one the
Secretary of HHS adopted as an adopted standard? If “no,” then the
standard is not required by HIPAA to be used. If “yes,” then the
standard shall be used.
To decide if a standard has
been adopted for transaction,
use the
definition of the transaction
as it
is provided in the Final Rule. Knowing who is and is not a business
associate of the TRICARE Health Plan is important in determining
where standard transactions shall be used within TRICARE. See
Appendix A for the definition of “business
associate.”
3.3 The following
table identifies TRICARE entities and their relationships to the
TRICARE health plan.
|
Entity
|
Covered
Entities
|
Non-Covered Entity
|
Business Associate
Of The TRICARE Health Plan?
|
|
Health Plan?
|
Provider?
|
Clearing-house?
|
Employer?
|
|
Department of Defense
(DoD) (Army, Navy, Air Force, Marines, Space
Force, and Coast Guard*)
*In time of war
|
N
|
N
|
N
|
Y
|
N
|
|
TRICARE Health Plan (Represents
both the Health Care Program for Active Duty Military Personnel
under 10 USC
and the CHAMPUS as defined in 10 USC 1072(4).)
|
Y
|
N
|
N
|
N
|
N
|
|
Markets/Military
Treatment Facilities (MTFs) (Supporting
Systems: Composite Health Care System (CHCS), Referral Management
Suite (RMS), Armed Forces Health Longitudinal Technology Application (AHLTA),
Third Party Outpatient Collections System (TPOCS)*, and others)
*Armed Forces Billing and Collection
Utilization Solution (ABACUS) expected to replace TPOCS in 2015.
|
N
|
Y
|
N
|
N
|
N
|
|
Defense Manpower Data
Center (DMDC) Defense Enrollment Eligibility Reporting System
(DEERS)
|
N
|
N
|
N
|
N
|
Y
|
|
Managed Care Support
Contractor (MCSC)
|
N
|
N
|
N
|
N
|
Y
|
|
TRICARE Dual Eligible Fiscal
Intermediary Contract (TDEFIC)
|
N
|
N
|
N
|
N
|
Y
|
|
Defense Finance and Accounting
Service (DFAS)
|
N
|
N
|
N
|
Y
|
N
|
|
TRICARE Dental Program (TDP)
Contractor
|
Y
|
N
|
N
|
N
|
Y
(for foreign claims processing
only)
|
|
Active Duty Dental Program
(ADDP) Contractor
|
Y
|
N
|
N
|
N
|
N
|
|
Pharmacy Data Transaction Service
(PDTS) Contractor
|
N
|
N
|
N
|
N
|
Y
|
|
Designated Provider (DP) Contractors
|
Y
|
Y
|
N
|
N
|
N
|
|
Defense Health Agency-Great
Lakes (DHA-GL)
|
N
|
N
|
N
|
N
|
Y
|
|
Continued Health Care Benefit
Program (CHCBP) Contractor
|
N
|
N
|
N
|
N
|
Y
|
|
TRICARE Quality Management
Contract (TQMC)
|
N
|
N
|
N
|
N
|
Y
|
|
Contractor for Data Analysis
for the DP Contracts
|
N
|
N
|
N
|
N
|
Y
|
|
TRICARE Overseas Program (TOP)
Contractor
|
N
|
N
|
N
|
N
|
Y
|
|
Defense Health Agency
(DHA) (Supporting Systems: DEERS Catastrophic Cap and Deductible
(CCDD), payment record databases (TRICARE Encounter Data (TED) records,
TED Provider (TEPRV) records, and TED Pricing (TEPRC) records),
management databases (Military Health System (MHS)) Data Repository
and its associated data marts)
|
N
|
N
|
N
|
N
|
Y
|
|
TRICARE Pharmacy (TPharm) Contractor
|
N
|
Y
|
N
|
N
|
Y
|
|
TRICARE Area Offices (TAOs)
|
N
|
N
|
N
|
N
|
Y
|
4.0
HIPAA
Transaction Requirements For TRICARE Contractors
4.1 General
4.1.1 The contractor
shall implement transactions in
accordance with the transaction implementation specifications and
any Addenda, Errata,
or Operating Rules named and adopted by the Secretary of HHS, as
standards.
4.1.2 The
contractor shall accept standard transactions from
trading partners that are correct at the interchange control structure
level (envelope) and that are syntactically correct at the standard level
and at the implementation guide level and are semantically correct
at the implementation guide level. The
contractor shall not reject otherwise syntatically correct transactions
for front-end business or application level edits
for transaction content, such as an edit for a recognized provider
number. The contractor
shall apply front-end business or application level
edits after accepting the
transaction. The contractor
shall reject, develop or deny claims failing front-end
business or application edits, after passing syntax and semantic
edits, in accordance with established
procedures for such actions.
4.2 Transactions
Exchanged Between Contractors And Providers (Network And Non-Network Providers,
Markets/MTFs
(CHCS
and RMS))
4.2.1 The
contractor shall ensure HIPAA adopted transactions
exchanged between contractors and providers are in
accordance with HIPAA standards.
4.2.2 The
contractors shall be HIPAA compliant with the following HIPAA adopted
transactions, when HIPAA compliant usage applies:
4.2.2.1 Claims
Transactions
[Receive
Claims Transactions]
• The ASC
X12N 837P - Health Care Claim: Professional, most currently adopted
version.
• The ASC X12N 837I - Health
Care Claim: Institutional, most currently adopted version.
• The ASC
X12N 837D - Health Care Claim: Dental, most currently adopted version.
• The
most currently adopted version of NCPDP Telecommunication Standard
and equivalent NCPDP Batch Standard including claims for
retail pharmacy supplies and professional services.
4.2.2.2 Coordination Of Benefits
(COB) Transactions
[Receive 837 Coordination of
Benefits Transactions]
• The ASC
X12N 837 - Health Care Claim: Professional, most
currently adopted version.
• The ASC X12N 837 - Health Care
Claim: Institutional, most currently
adopted version.
• The ASC X12N 837 - Health Care
Claim: Dental, most currently adopted
version.
4.2.2.3 Eligibility
Inquiry And Response Transactions
[Receive 270 Transactions and
Send 271 Transactions]
• The ASC
X12N 270/271 - Health Care Eligibility Benefit Inquiry and Response,
most currently adopted version
4.2.2.4 Referral Certification And
Authorization Transactions
[Receive 278 Requests and Send
278 Responses]
• The ASC
X12N 278 - Health Care Services Review - Request for Review and
Response, most currently adopted version.
4.2.2.5 Claim Status Request And Response
Transactions
[Receive
276 Transactions and Send 277 Transactions]
• The ASC
X12N 276/277 - Health Care Claim Status Request and Response, most currently
adopted version.
4.2.2.6 Payment
And Remittance Advice (RA) Transactions
[Send 835 Transactions]
• The ASC
X12N 835 - Health Care Claim Payment/Advice, most currently adopted version.
4.2.2.7 Electronic Funds Transfer (EFT)
And Remittance Advice (RA)
The contractors shall be able
to send the following transmissions:
4.2.2.7.1 [Stage 1 Payment Initiation,
transmission of health care payment/processing information]
The National Automated Clearing
House Association (NACHA) Corporate Credit or Deposit Entry with
Addenda Record (CCD+) implementation specifications as contained
in the 2011 NACHA Operating Rules & Guidelines, A Complete Guide
to the Rules Governing the Automated Clearing House (ACH) Network
as follows (incorporated by reference in § 162.920):
• 2011 NACHA
Operating Rules & Guidelines, A Complete Guide to the Rules Governing
the ACH Network, NACHA Operating Rules, Appendix One: ACH File Exchange
Specifications.
• 2011 NACHA Operating Rules
& Guidelines, A Complete Guide to the Rules Governing the ACH
Network, NACHA Operating Rules Appendix Three: ACH Record Format
Specifications, Part 3.1, Subpart 3.1.8 Sequence of Records for
CCD Entries.
• For the CCD Addenda Record
(“7”), field 3, the ASC X12 Standards for EDI Technical Report Type
3, “Health Care Claim Payment/Advice (835),” April 2006: Section
2.4: 835 Segment Detail: “TRN Reassociation Trace Number,” Washington
Publishing Company, 005010X221.
4.2.2.7.2 [Stage 1 Payment Initiation,
transmission of health care RA]
• The ASC
X12N 835 - Health Care Claim Payment/Advice, most currently adopted version.
4.3 Transactions Exchanged Between
The Contractors
And Other Health Plans (And Employers, Where Applicable)
4.3.1 The contractor
shall ensure HIPAA adopted transactions exchanged
between the contractor and
other health plans (including TRICARE supplemental plans) are in
accordance with HIPAA standard.
4.3.2 The
contractors shall be able to electronically transact
with other health plans, in accordance with HIPAA adopted Final
Rules
.4.3.2.1
COB Transactions
[Send and Receive all HIPAA
adopted 837 Transactions]
• The ASC
X12N 837 - Health Care Claim: Professional, most currently adopted
version.
• The ASC X12N 837 - Health Care
Claim: Institutional, most currently adopted version.
• The ASC X12N 837 - Health Care
Claim: Dental, most currently adopted version.
4.3.2.2 Eligibility Inquiry And Response
Transactions
[Send
and Receive 270 Transactions; Send and Receive 271 Transactions]
• The ASC
X12N 270/271 - Health Care Eligibility Benefit Inquiry and Response,
most currently adopted version.
4.3.2.3 Referral Certification And
Authorization Transactions
[Send and Receive 278 Requests;
Send and Receive 278 Responses]
• The ASC
X12N 278 - Health Care Services Review - Request for Review and
Response, most currently adopted version.
4.3.2.4 Payment And Remittance Advice
(RA) Transactions
[Send
835 Transactions]
• The ASC
X12N 835 - Health Care Claim Payment/Advice, most currently adopted version.
4.3.2.5 Claim Status Request And Response
Transactions
[Receive
276 Transactions and Send 277 Transactions]
• The ASC
X12N 276/277 - Health Care Claim Status Request and Response, most currently
adopted version.
4.3.2.6 Health
Plan Premium Payment Transactions
[Receive 820 Transactions]
• The ASC
X12N 820 - Payroll Deducted and Other Group Premium Payment for Insurance
Products, most currently adopted version.
4.3.2.7 Request
To
Primary Payer
For Payment Already Made
By
Subordinate Payer (Medicaid)
[Receive Medicaid Pharmacy
Subrogation Transactions]
• NCPDP
Batch Standard Medicaid Subrogation, most currently adopted version.
The Modifications to HIPAA Electronic Standards Final Rule adopted
a standard for the subrogation of pharmacy claims paid by Medicaid.
This transaction is the Medicaid Pharmacy Subrogation Transaction.
The standard for that transaction is the NCPDP Batch Standard Medicaid
Subrogation Implementation guide. A Medicaid Pharmacy subrogation
transaction is defined as the transmission of a claim from a Medicaid agency
to a payer for the purpose of seeking reimbursement from the responsible health
plan for a pharmacy claim the State has paid on behalf of a Medicaid
recipient. This standard is applicable to Medicaid agencies in their
role as health plans, but not to providers or health care clearinghouses
because this transaction is not used by
them. To the extent that Pharmacy Benefit Managers (PBMs) and
claims processors are required by contract or otherwise to process
claims on behalf of TRICARE, both shall receive
the Medicaid Pharmacy Subrogation Transaction in the standard format.
4.4 Transactions Exchanged Between
Contractors And DMDC (DEERS)
4.4.1 Eligibility
Inquiries And Response Transactions
Based
upon
the “two-question rule” for determining when a transaction shall
be in standard format (see
paragraph 3.2), and the definition of the
Eligibility for a Health Plan Transaction in the Final Rule, eligibility
inquiry and response transactions occurring between business associates
of the same health plan need not be in standard format.
The
contractor shall use transactions in the standard format when
the inquiries and responses are between providers and health plans
or between health plans and health plans
. Because
the contractors and DEERS are business associates of the same health
plan, eligibility inquiry and response transactions between them
may be performed in non-standard format.
4.4.1.1 The contractor
shall perform real-time eligibility inquiries and
responses, associated with enrollment processing, between the contractor and
DEERS via the Government furnished
web-based system/application.
4.4.1.2 Real-time and batch eligibility
inquiries and responses between the contractors and DEERS for claims
processing and other administrative purposes will be in DEERS specified
format.
4.4.2 Enrollment
And Disenrollment Transactions
TRICARE enrollment and disenrollment
transactions between the contractors and DEERS may be performed
using the Government furnished web-based system/application. The
Government will provide a HIPAA standard data and condition compliant
version of Government furnished web-based system/application for
contractor use. Note: Transactions generated by DEERS that validate
that enrollments have been established and that are used by the contractor to
update its system files, are not considered
covered transactions and may be sent in proprietary format.
4.5 Transactions Exchanged Between
The Contractor
And
Providers (Network And Non-Network Providers,
Markets/MTFs
(CHCS
and RMS)) Through Direct Data Entry Systems
4.5.1 Direct
Data Entry Systems
4.5.1.1 The
contractor shall use standard format for all transactions
covered under the Transaction and Code Sets Rule occurring between the contractor and
network/non-network providers and Markets/MTFs, unless
subject to the direct data entry exception. The contractor may
offer a direct data entry system for use by providers. A direct
data entry system however, does not replace the requirement to support
the standard transactions. The contractor shall ensure
direct data entry systems are compliant
with standard transaction data content and conditions.
4.5.1.2 The contractor
shall ensure its direct data entry system does not
add to or delete from the standard data elements and code values.
Direct data entry systems may take the form of web applications.
Non-standard data elements and code values may be included in the
direct data entry system if the non-standard data is obtained or
sent through a separate mechanism such as a web page that is separate
from the web page containing the standard data content, and the
resolution of the standard transaction does not depend on the additional
information.
4.6 Transactions
Involving Foreign Entities
4.6.1 Electronic
transactions from overseas Markets/MTFs and
from United States (U.S.) territories
will be sent directly to the contractor in standard format or routed
through a U.S. based clearinghouse for translation into standard
format prior to being sent to the contractor.
4.6.2 The contractor
shall accept electronic transactions submitted by
foreign entities, such as claims transactions from foreign providers,
directly
or
through
a clearinghouse
for processing.
The contractor
shall accept transactions submitted by foreign entities,
except for those originating from U.S. territories or overseas
Markets/MTFs
in
non-standard format
as they are not covered transactions.
4.6.2.1 Except for transactions originating
from U.S. territories or overseas Markets/MTFs (which will
be in standard format), the contractor may define the format or
formats acceptable from foreign entities, either directly or through
a clearinghouse.
4.6.2.2 Where the TRICARE Overseas
Program (TOP) contractor pays foreign claims and subsequently
bills another contractor for reimbursement, the claim
data submitted to the other contractor
in support of the invoice shall be sent in standard format.
4.7 Transactions Exchanged Between
The Contractor
And
DHA
Payment
Record Submissions, TED records, TEPRV records, and TEPRC records -
Payment records are considered reports and are not covered transactions. The
contractor shall submit payment records in
accordance with contract requirements.
4.8 Clearinghouse
Use By
The Contractor
4.8.1 The contractor may
use contracted clearinghouses for the purposes of receiving, translating,
and routing electronic transactions on its behalf.
Contractor-contracted clearinghouses may receive standard transactions,
convert them into the contractors’ system formats and route them to
the contractors’ systems for processing. The contractor may
send non-standard formatted transactions to its contracted
clearinghouses for the purposes of translating them into standard
format and routing them to the intended recipients.
4.8.2 Transactions between health
care clearinghouses shall be conducted in standard format.
4.8.3 Where a contractor has contracted
with the same clearinghouse as the entity that is submitting or
receiving the transaction, the clearinghouse shall convert the nonstandard
transaction into the standard prior to converting it again to the
intended recipient’s format and sending.
5.0 Trading Partner Agreements
5.1 The contractor
shall
have trading partner agreements with all entities with which electronic transactions
are exchanged. Where a provider uses a billing service or clearinghouse
to exchange transactions, the contractor shall have a trading partner
agreement with both the provider and billing service/clearinghouse.
The
contractor shall ensure trading partner agreements
with providers
contain a “provider
signature on file” provision that allows the contractor to process
the electronic transaction if the provider signature on file requirement
is not being met through another vehicle (e.g., provider certification).
The
contractor
shall develop
and execute trading partner agreements that comply with all DoD
and DHA privacy and security requirements. See
Appendix A for
the definition of “trading partner agreement.”
The
contractor shall ensure all trading partner agreements,
including all existing and active trading partner agreements previously
executed,
are updated, and kept updated,
to reflect current requirements.
5.2 Implementation
Guide Requirements
5.2.1 The
contractor shall ensure trading
partner agreements include, as recommended
in the American National Standard Institute (ANSI) ASC X12N transaction
implementation guides, any information regarding the processing,
or adjudication of the transactions that are helpful to the trading partners
and simplify implementation.
5.2.2 The
contractor shall ensure trading partner agreements
do NOT:
• Modify
the definition, condition, or use of a data element or segment in
a standard Implementation Guide.
• Add any
additional data elements or segments to a standard Implementation
Guide.
• Use any
code or data values, which are not valid to a standard Implementation
Guide.
• Change the meaning or intent
of a standard Implementation Guide.
6.0 Additional Non-HIPAA Transactions
Required
The
contractor 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. The contractor 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. The contractor 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
6.1.3.1 The contractor 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.
6.1.3.2 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.
The
contractor
shall develop
and implement the capability to generate and send the following
transaction(s).
6.1.3.2.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.2 For 837 claim transactions, the contractor 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
the contractor
to
arrange
COB 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
state
funds
erroneously
disbursed on behalf of the TRICARE-eligible beneficiary. TRICARE
Policy requires
the contractor
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, the contractor shall
coordinate with the Medicaid State Agencies submitting non-pharmacy
claims and define the acceptable forms and formats of the claims the
Medicaid State Agencies shall use 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.
7.0 Miscellaneous Requirements
7.1 Paper Transactions
7.1.1 The contractor shall
continue to accept and process paper-based transactions.
7.1.2 The contractor may
pay claims via electronic funds transfer or by paper check. The
ASC X12N 835 Health Care Claim Payment/Advice transaction contains
two parts, a mechanism for the transfer of dollars and one for the
transfer of information about the claim payment. These two parts may
be sent separately. The 835 Implementation Guide allows payment
to be sent in a number of different ways, including by check and
electronic funds transfer. The contractor shall
be able to send the RA portion electronically but may continue to
send payment via check.
7.1.3 Current
applicable requirements for the processing of paper-based and electronic
media transactions, such as claims splitting, forwarding out-of-jurisdiction
claims, generating and sending EOBs to beneficiaries and providers,
etc., apply to the processing of electronic transactions.
7.2 Attendance At Designated Standards
Maintenance Organization (DSMO) Meetings
7.2.1 The
contractor shall regularly
send representatives to the following separate DSMO Trimester meetings:
ANSI Accredited Standards Committee X12 (ASC X12) Standing Meetings,
and the Health Level Seven (HL7) Working Group Meetings. The contractor
shall send one representative to each DSMO Trimester meeting. The
contractor may elect
to send representatives from its claims processing
subcontractor(s) in place of a contractor representative. The
contractor shall make every effort to
have the same representatives attend each meeting for continuity
purposes. The team lead will be the DHA representative in attendance.
7.2.2 The contractor
shall ensure its representatives are knowledgeable regarding TRICARE program
requirements, and of its own administrative
and claims processing systems. Prior to attending a DSMO meeting,
the contractor shall identify from
within their own organizations any issues that need to be addressed
at the DSMO meeting. The contractor shall
inform the DHA representative (team lead) of the issues at least
one week prior to the meetings.
7.2.3 The
contractor shall
ensure its representatives attend
the DSMO meetings as exclusive advocates for TRICARE business needs
and shall not divide their participation
and attention with any commercial business needs and concerns. The
contractor shall ensure its representatives attend
and participate in workgroup and full committee meetings. The contractor shall ensure
its representatives work within the DSMOs to incorporate
into the standards and implementation guides any data elements,
code values, etc., that are required
to conduct current and future TRICARE business. The contractor
shall ensure its representatives also
work to prevent removal of any existing data elements, code values,
etc., from the standards and implementation guides that are necessary
to conduct current and future TRICARE business.
7.2.4 When attending the DSMO meetings, the contractor shall
ensure its representatives shall work as a team and
collaborate with other Government and DoD/TRICARE representatives. The contractor shall
ensure its representatives register
under the DoD/Health Affairs (HA) DSMO memberships. The
contractor shall ensure its representatives take proposed
changes through the processes necessary for adoption within the
DSMOs. The contractor shall ensure its representatives track and
reporting on the status of each proposed change as it progresses
through the process.
7.2.5 Contractor
representatives shall keep DHA apprised of any additions to the
standards that shall be made to accommodate TRICARE business needs
and of any proposed changes to existing standards and implementation
guides. Following a DSMO meeting, each representative attendee shall prepare
a summary report that includes, at a minimum; the work group and
full committee meetings attended, a brief description of the content
of the meetings, the status of any changes in progress, and any
problems or information of which the Government/DHA should be aware.
Each representative shall submit their reports to the DHA team lead
within 10 business days following the
DSMO meetings.
7.3 Provider
Marketing
7.3.1 The
contractor shall encourage
providers to use electronic transactions
only through marketing and provider education vehicles permitted
within existing contract limitations and requirements. No additional
or special marketing or provider education campaigns are required. The contractor shall
educate providers on the cost and efficiency benefits that may be
realized through adoption and use of
electronic transactions.
7.3.2 The
contractor shall assist
and work with providers, who wish to exchange electronic transactions,
to establish trading partner agreements and connectivity with its systems
and to implement the transactions in a timely manner. The
contractor is not
required to perfect transactions on
behalf of trading partners.
7.4 Data
And Audit Requirements
7.4.1 The
contractor shall store all HIPAA-covered electronic
transaction data, including eligibility and claims status transaction
data,
as outlined in
Chapter 9.
The
contractor
shall
refer to Chapter 9 if directed by DHA
to freeze records
, to include
, electronic
transaction data
.
7.4.2 The contractor
shall generate transaction histories covering a period of up to
seven years upon request by DHA in a text format (delimited text
format for table reports) that is able to be imported, read, edited,
and printed by Microsoft® Word (Microsoft® Excel for table reports). The contractor
shall have the ability to generate transaction histories on paper. The
contractor shall ensure transaction histories include
at a minimum, the transaction name or type, the dates the transaction
was sent or received and the identity of the sender and receiver. The
contractor shall ensure transaction histories are
readable and understandable by a person.
7.4.3 Transaction data is subject
to audit by DHA, DoD, HHS, and other authorized Government personnel.
The
contractor
shall have
the ability to retrieve and produce all electronic transaction data upon
request from DHA (for up to seven years, or longer if the data is
being retained pursuant to a records freeze), to include reasons
for transaction rejections as outlined in
Chapter 9.