TRICARE Operations Manual 6010.62-M, April 2021
Health Insurance Portability and Accountability Act (HIPAA) of 1996
Chapter 19
Section 2
HealthInsurance Portability And Accountability Act (HIPAA) Standards ForElectronic Transactions
Revision:
1.0BACKGROUND AND PROVISIONS
The Department of Health andHuman Services (HHS) published the first administrative simplificationrelated final rule on August 17, 2000, which added subchapter C,“Administrative Data Standards and Related Requirements,” to 45Code of Federal Regulations (CFR) subtitle A. Subchapter C includesParts 160 and 162, which will be referred to here as the Transactionand Code Sets Rule. On January 16, 2009, HHS published a Final Ruleknown as “Health Insurance Reform: Modifications to Health InsurancePortability and Accountability Act (HIPAA) Electronic TransactionStandards.” This Final Rule (referred to here as the “Modificationsto HIPAA Electronic Standards Final Rule”) adopted updated versionsof the standards for electronic transactions that were originallyadopted under the Administrative Simplification subtitle of HIPAA.Since 2009, HHS has published additional Final Rules for HIPAA initiativeswhich affect HIPAA transactions. As a HIPAA covered entity; TRICAREmust comply with applicable adopted HIPAA rules.
1.1Compliance Dates
1.1.1The contractor shall complywith the most current Final Rules on HIPAA adopted Electronic Transaction Standards,including compliance dates.
1.1.2The contractorshall comply with the most current Final Rules on HIPAA adoptedTransaction Operating Rules, including compliance dates.
1.1.3The contractorshall 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.4The contractorshall comply with Final Rules on HIPAA adopted identifiers (e.g.,the use of Health Plan Identifiers (HPID)), including compliancedates.
1.2Applicability
1.2.1The contractorshall comply with HIPAA Electronic Standards Final Rules as therules apply to health plans, health care clearinghouses, and healthcare providers who transmit any health information in electronicform in connection with a transaction covered by the rule.
1.2.2TheseRules refer to health plans, health care clearinghouses, and healthcare providers as “covered entities.” The initial Transaction andCode Sets Rule specifically names the health care program for activeduty military personnel under Title 10 of the United States Code(USC) and the Civilian Health and Medical Program of the UniformedServices (CHAMPUS) as defined in 10 USC 1072(4), as health plansand this designation has not changed in the Modifications to HIPAAElectronic Standards Final Rule.
1.3TransactionImplementation Specification Standards
1.3.1The contractorshall comply with the most current HIPAA Electronic Standards FinalRules, which adopt specifically stated HIPAA implementations ofASC X12 standards, accompanying Errata, addenda, and Operating Rules.
1.3.2The contractorshall comply with the HIPAA-adopted transaction initiatives by thecompliance dates specified by HHS in Final Rules in the event thatadditional HIPAA-adopted transactions, accompanying Errata, Addenda,or Operating Rules are mandated for use in the future.
1.3.3The contractorshall comply with HIPAA-adopted National Council for PrescriptionDrug Programs, (NCPDP) Telecommunication and Batch Standard ImplementationGuides named and adopted by Final Rule for retail pharmacy electronictransactions covered under HIPAA.
1.3.3.1The contractor shall accommodateuse of both NCPDP and HIPAA ASC X12 837 Health Care Claim: Professionalfor billing of retail pharmacy supplies and professional services.
1.3.3.2The contractor shall accommodateuse of the HIPAA-adopted standard for the subrogation of pharmacyclaims paid by Medicaid which is named and adopted in Final Ruleas the NCPDP Batch Standard Medicaid Subrogation ImplementationGuide. This standard is applicable to Medicaid agencies in theirrole as health plans, as well as to other health plans such as TRICAREthat are covered entities under HIPAA.
1.3.4The contractorshall comply with HIPAA-related Final Rules associated with Section1104 of the Administrative Simplification provisions of the PatientProtection and Affordable Care Act (PPACA) (hereafter referred toas the Affordable Care Act or ACA). The ACA establishes new requirementsfor administrative transactions to improve the utility of the existingHIPAA transactions and reduce administrative costs (e.g., standard OperatingRules).
1.3.5HIPAA-Adopted Code Set Standards
The contractor shall complywith HIPAA-adopted code sets in accordance with Final Rules (i.e.,International Classification of Diseases, 10th Revision (ICD-10)).
2.0CONTRACTOR RELATIONSHIPS TOTHE TRICARE HEALTH PLAN (THP)
2.1The Transactionand Code Sets Rule specifically names the health care program foractive duty military personnel under Title 10 of the USC and theCHAMPUS as defined in 10 USC 1072(4), as health plans. For the purposesof implementing the Transaction and Code Sets Rule, the term “TRICARE”will be used in this chapter to mean a combination of both the DirectCare (DC) and Purchased Care Systems. TRICARE is therefore a healthplan.
2.2The relationships of the entitiesthat comprise TRICARE determine, in part, where standard transactions shallbe used. Determinations as to when and where the transaction standardsapply are not based on whether a transaction occurs within or outsideof a “corporate entity” but rather are based on the answers to thetwo following questions:
•Is the transaction initiatedby a covered entity or its business associate? If the answer is“no,” then the standard does not apply and does not need to be used.If “yes,” then the standard applies and the next question needsto be answered.
•Is the transaction one theSecretary of HHS adopted as an adopted standard? If “no,” then thestandard is not required by HIPAA to be used. If “yes,” then thestandard shall be used.
2.3To decideif a standard has been adopted for transaction, the definition ofthe transaction needs to be used as it is provided in the FinalRule. Knowing who is and is not a business associate of the THPis important in determining where standard transactions shall beused within TRICARE. See https://manuals.health.mil/pages/DownloadManualFile.ashx?Filename=Definitions.pdf forthe definition of “business associate.”
2.4The followingtable identifies TRICARE entities and their relationships to theTRICARE health plan.
| Entity | CoveredEntities | Non-Covered Entity | Business AssociateOf The TRICARE Health Plan? | ||
|---|---|---|---|---|---|
| Health Plan? | Provider? | Clearing-house? | Employer? | ||
| Department of Defense(DoD) (Army, Navy, Air Force, Marines, Coast Guard*) *In time of war | N | N | N | Y | N |
| TRICARE Health Plan (Representsboth the Health Care Program for Active Duty Military Personnelunder Title 10 of the USC and the CHAMPUS as defined in 10 USC 1072(4).) | Y | N | N | N | N |
| Military Treatment Facilities(MTFs)/Enhanced Multi-Service Market (eMSM) (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 CollectionUtilization Solution (ABACUS) expected to replace TPOCS in 2015. | N | Y | N | N | N |
| DMDC Defense EnrollmentEligibility Reporting System (DEERS) | N | N | N | N | Y |
| Managed Care SupportContractor (MCSC) | N | N | N | N | Y |
| TRICARE Dual Eligible FiscalIntermediary Contract (TDEFIC) | N | N | N | N | Y |
| Defense Finance and AccountingService (DFAS) | N | N | N | Y | N |
| TRICARE Dental Program (TDP)Contractor | Y | N | N | N | Y (for foreign claims processingonly) |
| 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-GreatLakes (DHA-GL) | N | N | N | N | Y |
| Continued Health Care BenefitProgram (CHCBP) Contractor | N | N | N | N | Y |
| TRICARE Quality ManagementContract (TQMC) | N | N | N | N | Y |
| Contractor for Data Analysisfor 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 Repositoryand its associated data marts) | N | N | N | N | Y |
| TRICARE Pharmacy (TPharm) Contractor | N | Y | N | N | Y |
| TRICARE Regional Offices (TROs) | N | N | N | N | Y |
| TRICARE Area Offices (TAOs) | N | N | N | N | Y |
3.0HIPAATRANSACTION REQUIREMENTS FOR TRICARE CONTRACTORS
3.1General
3.1.1Transactionsshall be implemented in accordance with the transaction implementationspecifications and any addenda, errata, or Operating Rules namedand adopted by the Secretary of HHS, as standards.
3.1.2Standardtransactions received by the contractor from trading partners thatare correct at the interchange control structure level (envelope)and that are syntactically correct at the standard level and atthe implementation guide level and are semantically correct at theimplementation guide level shall be accepted.
3.1.3Front-endbusiness or application level edits for transaction content, suchas an edit for a recognized provider number, shall not be the causeof rejecting an otherwise syntactically correct transaction. Front-end businessor application level edits shall be applied after the transactionhas been accepted. Claims failing front-end business or applicationedits, after passing syntax and semantic edits, shall be rejected,developed or denied in accordance with established procedures forsuch actions.
3.2TransactionsExchanged Between The contractor And Providers (Network And Non-Network Providers,Markets/MTFs (CHCS and RMS))
3.2.1HIPAA adopted transactionsexchanged between contractors and providers shall be in accordancewith HIPAA standards.
3.2.2The contractor shall be HIPAAcompliant with the following HIPAA adopted transactions, when HIPAA compliantusage applies:
3.2.3Claims Transactions
[Receive Claims Transactions]
•The ASC X12N 837P - HealthCare Claim: Professional, most currently adopted version.
•The ASC X12N 837I - HealthCare Claim: Institutional, most currently adopted version.
•The ASC X12N 837D - HealthCare Claim: Dental, most currently adopted version.
•The most currently adoptedversion of NCPDP Telecommunication Standard and equivalentNCPDP Batch Standard including claims for retail pharmacy suppliesand professional services.
3.2.4CoordinationOf Benefits Transactions
[Receive837 Coordination of Benefits Transactions]
•The ASC X12N 837 - Health CareClaim: most currently adopted version.
•The ASC X12N 837 - Health CareClaim: most currently adopted version
•The ASC X12N 837 - Health CareClaim: most currently adopted version.
3.2.5EligibilityInquiry And Response Transactions
[Receive 270 Transactions andSend 271 Transactions]
•The ASC X12N 270/271 - HealthCare Eligibility Benefit Inquiry and Response, most currently adoptedversion
3.2.6ReferralCertification And Authorization Transactions
[Receive 278 Requests and Send278 Responses]
•The ASC X12N 278 - Health CareServices Review - Request for Review and Response, most currentlyadopted version.
3.2.7ClaimStatus Request And Response Transactions
[Receive 276 Transactions andSend 277 Transactions]
•The ASC X12N 276/277 - HealthCare Claim Status Request and Response, most currently adopted version.
3.2.8PaymentAnd Remittance Advice (RA) Transactions
[Send 835 Transactions]
•The ASC X12N 835 - Health CareClaim Payment/Advice, most currently adopted version.
3.2.9ElectronicFunds Transfer (EFT) And Remittance Advice (RA)
The contractor shall be capableto send the following transmissions:
3.2.9.1[Stage 1 Payment Initiation,transmission of health care payment and processing information]
The National Automated ClearingHouse Association (NACHA) Corporate Credit or Deposit Entry withAddenda Record (CCD+) implementation specifications as containedin the 2011 NACHA Operating Rules & Guidelines, A Complete Guideto the Rules Governing the Automated Clearing House (ACH) Networkas follows (incorporated by reference in § 162.920):
•2011 NACHA Operating Rules& Guidelines, A Complete Guide to the Rules Governing the ACHNetwork, NACHA Operating Rules, Appendix One: ACH File ExchangeSpecifications.
•2011 NACHA Operating Rules& Guidelines, A Complete Guide to the Rules Governing the ACHNetwork, NACHA Operating Rules Appendix Three: ACH Record FormatSpecifications, Part 3.1, Subpart 3.1.8 Sequence of Records forCCD Entries.
•For the CCD Addenda Record(“7”), field 3, the ASC X12 Standards for EDI Technical Report Type3, “Health Care Claim Payment/Advice (835),” April 2006: Section2.4: 835 Segment Detail: “TRN Re-association Trace Number,” WashingtonPublishing Company, 005010X221.
3.2.9.2[Stage 1 Payment Initiation,transmission of health care RA]
•The ASC X12N 835 - Health CareClaim Payment/Advice, most currently adopted version.
3.3TransactionsExchanged Between The Contractor And Other Health Plans (And Employers,Where Applicable)
3.3.1HIPAA adopted transactionsexchanged between the contractor and other health plans (including TRICAREsupplemental plans) shall be in accordance with HIPAA standard.
3.3.2The contractorshall be able to electronically transact with other health plans,in accordance with HIPAA adopted Final Rules.
3.3.3CoordinationOf Benefits Transactions
[Sendand Receive all HIPAA adopted 837 Transactions]
•The ASC X12N 837 - Health CareClaim: Professional, most currently adopted version.
•The ASC X12N 837 - Health CareClaim: Institutional, most currently adopted version.
•The ASC X12N 837 - Health CareClaim: Dental, most currently adopted version.
3.3.4EligibilityInquiry And Response Transactions
[Send and Receive 270 Transactions;Send and Receive 271 Transactions]
•The ASC X12N 270/271 - HealthCare Eligibility Benefit Inquiry and Response, most currently adoptedversion.
3.3.5ReferralCertification And Authorization Transactions
[Send and Receive 278 Requests;Send and Receive 278 Responses]
•The ASC X12N 278 - Health CareServices Review - Request for Review and Response, most currentlyadopted version.
3.3.6PaymentAnd Remittance Advice (RA) Transactions
[Send 835 Transactions]
•The ASC X12N 835 - Health CareClaim Payment/Advice, most currently adopted version.
3.3.7ClaimStatus Request And Response Transactions
[Receive 276 Transactions andSend 277 Transactions]
•The ASC X12N 276/277 - HealthCare Claim Status Request and Response, most currently adopted version.
3.3.8HealthPlan Premium Payment Transactions
[Receive 820 Transactions]
•The ASC X12N 820 - PayrollDeducted and Other Group Premium Payment for Insurance Products,most currently adopted version.
3.3.9Requestto More Primary Payer for Payment Already Made by Subordinate Payer(Medicaid)
[ReceiveMedicaid Pharmacy Subrogation Transactions]
•NCPDP Batch Standard MedicaidSubrogation, most currently adopted version. The Modifications toHIPAA Electronic Standards Final Rule adopted a standard for thesubrogation of pharmacy claims paid by Medicaid. This transactionis the Medicaid Pharmacy Subrogation Transaction. The standard forthat transaction is the NCPDP Batch Standard Medicaid SubrogationImplementation guide. A Medicaid Pharmacy subrogation transactionis defined as the transmission of a claim from a Medicaid agencyto a payer for the purpose of seeking reimbursem*nt from the responsiblehealth plan for a pharmacy claim the State has paid on behalf ofa Medicaid recipient. This standard is applicable to Medicaid agenciesin their role as health plans, but not to providers or health careclearinghouses because this transaction is not utilized by them.To the extent that Pharmacy Benefit Managers and claims processorsare required by contract or otherwise to process claims on behalfof TRICARE, they shall be able to receive the Medicaid PharmacySubrogation Transaction in the standard format.
3.4TransactionsExchanged Between The Contractor And DMDC (DEERS)
3.4.1EligibilityInquiries And Response Transactions
Based on the “two-questionrule” for determining when a transaction shall be in standard format(see paragraph 3.2), and the definition of theEligibility for a Health Plan Transaction in the Final Rule, eligibilityinquiry and response transactions occurring between business associatesof the same health plan need not be in standard format. Only whenthe inquiries and responses are between providers and health plansor between health plans and health plans shall these transactionsbe in standard format. Because the contractor and DEERS are business associatesof the same health plan, eligibility inquiry and response transactionsbetween them may be performed in non-standard format.
3.4.1.1Real-time eligibility inquiriesand responses, associated with enrollment processing, between the contractorand DEERS shall be performed using the Government furnished web-basedsystem/application.
3.4.1.2Real-time and batch eligibilityinquiries and responses between the contractor and DEERS for claims processingand other administrative purposes will be in DEERS specified format.
3.4.2EnrollmentAnd Disenrollment Transactions
The contractor may performTRICARE enrollment and disenrollment transactions between the contractorand DEERS using the Government furnished web-based system/application.The Government will provide a HIPAA standard data and conditioncompliant version of Government furnished web-based system/applicationfor contractor use.
Note:Transactions generated by DEERSthat validate that enrollments have been established and that areused by the contractor to update their system files, are not consideredcovered transactions and may be sent in proprietary format.
3.5TransactionsExchanged Between The Contractor And Providers (Network And Non-Network Providers,Markets/MTFs (CHCS and RMS)) Through Direct Data Entry Systems
3.5.1DirectData Entry Systems
All transactionscovered under the Transaction and Code Sets Rule occurring betweenthe contractor and network or non-network providers and Market/MTFswill be in standard format, unless subject to the direct data entry exception.
3.5.2The contractormay offer a direct data entry system for use by providers. A directdata entry system however, does not replace the requirement to supportthe standard transactions. Direct data entry systems shall be compliantwith standard transaction data content and conditions.
3.5.3A directdata entry system shall not add to or delete from the standard dataelements and code values. Direct data entry systems may take theform of web applications. Non-standard data elements and code values maybe included in the direct data entry system if the non-standarddata is obtained or sent through a separate mechanism such as aweb page that is separate from the web page containing the standarddata content, and the resolution of the standard transaction doesnot depend on the additional information.
3.6TransactionsInvolving Foreign Entities
3.6.1Electronic transactions fromoverseas Market/MTFs and from US territories will be sent directlyto the contractor in standard format or routed through a US basedclearinghouse for translation into standard format prior to beingsent to the contractor.
3.6.2Electronic transactions submittedby foreign entities, such as claims transactions from foreign providers,may be accepted directly by the contractor or they may be routedthrough a clearinghouse to the contractor for processing. Transactionssubmitted by foreign entities, except for those originating fromUS territories or overseas Market/MTFs, are not covered transactionsand may be accepted by the contractor in non-standard format.
3.6.2.1Except for transactions originatingfrom US territories or overseas Markets/MTFs (which will be in standardformat), the contractor may define the format or formats acceptablefrom foreign entities, either directly or through a clearinghouse.
3.6.2.2Where the TRICARE OverseasProgram (TOP) health care contractor pays foreign claims and subsequentlybills the contractor for reimbursem*nt, claim data submitted tothe contractor in support of the invoice shall be sent in standardformat.
3.7Transactions Exchanged Betweenthe Contractor and DHA
3.7.1Payment Record Submissions,TED records, TEPRV records, and TEPRC records - Payment records areconsidered reports and are not covered transactions.
3.7.2The contractorshall submit payment records in accordance with contract requirements.
3.8ClearinghouseUse By The Contractor
3.8.1The contractor may use contractedclearinghouses for the purposes of receiving, translating, and routingelectronic transactions on their behalf. Contracted clearinghousesmay receive standard transactions, convert them into the contractors’system formats and route them to the contractors’ systems for processing.
3.8.2The contractormay send non-standard formatted transactions to their contractedclearinghouses for the purposes of translating them into standardformat and routing them to the intended recipients.
3.8.3Transactionsbetween health care clearinghouses shall be conducted in standardformat.
3.8.4Where a contractor has contractedwith the same clearinghouse as the entity that is submitting or receivingthe transaction, the clearinghouse shall convert the nonstandardtransaction into the standard prior to converting it again to theintended recipient’s format and sending.
4.0TRADINGPARTNER AGREEMENTS
The contractorshall have trading partner agreements with all entities with whichelectronic transactions are exchanged.
4.1The contractorshall have a trading partner agreement with both the provider andbilling service or clearinghouse where a provider uses a billingservice or clearinghouse to exchange transactions.
4.2Tradingpartner agreements with providers shall contain a “provider signatureon file” provision that allows the contractor to process the electronictransaction if the provider signature on file requirement is notbeing met through another vehicle (e.g., provider certification).
4.3The contractorshall develop and execute trading partner agreements that complywith all DoD and DHA privacy and security requirements. See https://manuals.health.mil/pages/DownloadManualFile.ashx?Filename=Definitions.pdf forthe definition of “trading partner agreement.”
4.4All tradingpartner agreements, including all existing and active trading partneragreements previously executed, shall be updated, and kept updated,to reflect current requirements.
5.0ImplementationGuide Requirements
5.1Contractor trading partneragreements shall include, as recommended in the American National StandardInstitute (ANSI) ASC X12N transaction implementation guides, anyinformation regarding the processing, or adjudication of the transactionsthat are helpful to the trading partners and simplify implementation.
5.2Tradingpartner agreements shall not:
•Modify the definition, condition,or use of a data element or segment in a standard ImplementationGuide.
•Add any additional data elementsor segments to a standard Implementation Guide.
•Utilize any code or data values,which are not valid to a standard Implementation Guide.
•Change the meaning or intentof a standard Implementation Guide.
6.0ADDITIONALNON-HIPAA TRANSACTIONS REQUIRED
The contractor shall implementthe following non-HIPAA mandated transactions as appropriate.
6.1Acknowledgments
The following are requiredfor determining an incoming transaction to be HIPAA-compliant:
•The interchange or ‘envelope’shall be correct
•The transaction shall be syntacticallycorrect at the standard level
•The transaction shall be syntacticallycorrect at the implementation guide level
•The transaction shall be semanticallycorrect at the implementation guide level
Syntax relates to the structureof the data. Semantics relates to the meaning of the data. Any transactionthat meets these four requirements is HIPAA-compliant and shallbe accepted.
Note:In the case of a claim transaction,‘accepted’ does not mean that it shall be paid. A transaction thatis accepted may then be subjected to business or application leveledits. Accepted transactions, i.e., those that are HIPAA-compliant,that subsequently fail business or application level edits shallbe rejected, developed, or denied in accordance with establishedprocedures for such actions.
6.1.1InterchangeAcknowledgment
6.1.1.1The Interchange or TA1 Acknowledgmentis a means of replying to an interchange or transmission that hasbeen sent. The TA1 verifies the envelopes only.
6.1.1.2The contractor shall developand implement the capability to generate and send the following transaction.Reference the most currently adopted HIPAA version of ASC X12C/231Implementation Acknowledgment for Health Care Insurance (999) TR3,Appendix C.1, to address implementation use of this transaction.
•The ANSI ASC X12N TA1 - InterchangeAcknowledgment Segment.
6.1.2ImplementationAcknowledgment
6.1.2.1The Implementation AcknowledgmentTransaction is used to report the results of the syntactical analysisof the functional groups of transaction sets. It is generally thefirst response to a transaction. (Exception: The TA1 will be thefirst response if there are errors at the interchange or “envelope”level.) Implementation acknowledgment transactions report the extentto which the syntax complies with the standards for transaction setsand functional groups. They report on syntax errors that preventedthe transaction from being accepted. Version 5010 of the implementationacknowledgment transaction does not cover the semantic meaning ofthe information encoded in the transaction sets.
6.1.2.2The implementation acknowledgmenttransaction may be used to convey both positive and negative acknowledgments.Positive acknowledgments indicate that the transaction was receivedand is compliant with standard syntax. Negative acknowledgmentsindicate that the transaction did not comply with standard syntax.
6.1.2.3The contractor shall developand implement the capability to generate, send, and receive the followingtransaction (both positive and negative).
•The ASC X12N 999 - ImplementationAcknowledgment, most currently adopted version.
6.1.3ImplementationGuide Syntax And Semantic And Business Edit Acknowledgments
6.1.3.1The contractor may use a proprietaryacknowledgment to convey implementation guide syntax errors, implementationguide semantic errors, and business edit errors. Alternatively,for claim transactions (ANSI ASC X12N 837 Professional, Institutional,or Dental), the Health Care Claim Acknowledgment Transaction (ANSIASC X12N 277CA) may be used to indicate which claims in an 837 batchwere accepted into the adjudication system (i.e., which claims passedthe front-end edits) and which claims were rejected before enteringthe adjudication system.
6.1.3.1.1In the future, the standardsmay mandate transactions for acknowledgments to convey standard syntax,implementation guide syntax, implementation guide semantic, andbusiness or application level edit errors.
6.1.3.1.2The contractor shall developand implement the capability to generate and send the following transaction(s).
6.1.3.2A proprietary acknowledgmentcontaining syntax and semantic errors at the implementation guide level,as well as business/application level edit errors.
6.1.3.3The contractor may use theHealth Care Claim Acknowledgment Transaction Set (ANSI ASC X12N 277CA,most currently adopted version) in place of a proprietary acknowledgmentfor 837 claim transactions.
6.2MedicaidNon-Pharmacy Subrogation Claims
6.2.1When a beneficiary is eligiblefor both TRICARE and Medicaid, 32CFR 199.8 establishes TRICARE as the primary payer.
6.2.1.1Existing TRICARE policy requiresthe contractor to arrange coordination of benefits procedures with thevarious states to facilitate the flow of claims and to try to achievea reduction in the amount of effort required to reimburse the statesfor the funds they erroneously disbursed on behalf of the TRICARE-eligiblebeneficiary.
6.2.1.2TRICARE Policy requires thatthe contractor make disbursem*nts directly to the billing stateagency.
6.2.2Currently, a subrogation non-pharmacyclaim from a Medicaid State Agency is not a HIPAA covered transactionsince the Transaction and Code Sets Rule defines a health care claimor equivalent encounter information transaction as occurring betweena provider and a health plan.
6.2.2.1Since Medicaid State Agenciesare not providers, their claims to TRICARE are not covered transactions andneed not be in standard format; however, currently adopted HIPAAASC X12 837 claim standards used for processing Institutional, Professionaland Dental claims include the ability to perform Medicaid subrogation.While they are not currently mandated for use under HIPAA, coveredentities are not prohibited from using currently adopted HIPAA transactionsfor non-pharmacy Medicaid subrogation transactions between willingtrading partners.
6.2.2.2The contractor shall coordinatewith the Medicaid State Agencies submitting non-pharmacy claims anddefine the acceptable forms and formats of the claims that are tobe used by the Medicaid State Agencies when billing TRICARE in accordancewith existing TRICARE policy. State Agency Billing Agreements shallbe modified to reflect the acceptable forms and formats.
Note:It is expected that the Secretary,HHS will modify the standard to incorporate Medicaid subrogation claimsas HIPAA covered transactions sometime in the future. If this occurs,this section will be modified to reflect the change.
7.0MISCELLANEOUSREQUIREMENTS
7.1Paper Transactions
7.1.1The contractorshall continue to accept and process paper-based transactions.
7.1.2The contractormay pay claims via electronic funds transfer or by paper check.The ASC X12N 835 Health Care Claim Payment/Advice transaction containstwo parts, a mechanism for the transfer of dollars and one for thetransfer of information about the claim payment. These two partsmay be sent separately. The 835 Implementation Guide allows paymentto be sent in a number of different ways, including by check andelectronic funds transfer.
7.1.3The contractorshall be able to send the RA portion electronically but may continueto send payment via check.
7.1.4Currentapplicable requirements for the processing of paper-based and electronicmedia transactions (e.g., claims splitting, forwarding out-of-jurisdictionclaims, generating and sending Explanation of Benefits (EOBs) tobeneficiaries and providers) apply to the processing of electronictransactions.
7.2Attendance At Designated StandardsMaintenance Organization (DSMO) Meetings
7.2.1The contractorshall send representatives to the following separate DSMO Trimestermeetings: ANSI Accredited Standards Committee X12 (ASC X12) StandingMeetings, and the Health Level Seven (HL7) Working Group Meetings.
7.2.1.1The contractor shall send onerepresentative to each DSMO Trimester meeting.
7.2.1.1.1The contractor may elect tosend representatives from their claims processing subcontractor(s)in place of a contractor representative.
7.2.1.1.2Every effort shall be madeto have the same representatives attend each meeting for continuity purposes.The team lead will be the DHA representative in attendance.
7.2.1.2The contractor’s representative(s)shall be knowledgeable of TRICARE program requirements, and of theirown administrative and claims processing systems.
7.2.1.2.1Prior to attending a DSMO meeting,the representatives shall identify from within their own organizationsany issues that need to be addressed at the DSMO meeting.
7.2.1.2.2The representatives shall informthe DHA representative (team lead) of the issues at least one week priorto the meetings.
7.2.2The contractor’srepresentative(s) shall attend the DSMO meetings as exclusive advocatesfor TRICARE business needs and should not divide their participationand attention with any commercial business needs and concerns.
7.2.2.1The contractor’s representativesshall attend and participate in work-group and full committee meetingsand shall work within the DSMOs to incorporate into the standardsand implementation guides any data elements, code values, etc.,that may be required to conduct current and future TRICARE business.
7.2.2.2The contractor’s representative(s)shall also work to prevent removal of any existing data elements, andcode values from the standards and implementation guides that arenecessary to conduct current and future TRICARE business.
7.2.3The contractor’srepresentative(s) shall work as a team and collaborate with otherGovernment and DoD representatives when attending the DSMO meetings.
7.2.3.1The contractor representative(s)shall register under the DoD/Health Affairs (HA) DSMO memberships.
7.2.3.2The contractor representative(s)are responsible for taking proposed changes through the processes necessaryfor adoption within the DSMOs.
7.2.3.3The contractor’s representative(s)shall track and report on the status of each proposed change asit progresses through the process. For reporting requirements, seeDD Form 1423, Contract Data Requirements List (CDRL), located inSection J of the applicable contract.
7.2.4The contractor’srepresentative(s) shall keep DHA apprised of any additions to thestandards that shall be made to accommodate TRICARE business needsand of any proposed changes to existing standards and implementationguides.
7.2.4.1Following a DSMO meeting, eachrepresentative 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 ofany changes in progress, and any problems or information of whichthe Government and DHA should be aware.
7.2.4.2The contractor representative(s)shall submit their reports to the DHA team lead within 10 business daysfollowing the DSMO meetings. For reporting requirements, see DDForm 1423, CDRL, located in Section J of the applicable contract.
7.3ProviderMarketing
7.3.1The contractor shall encourageproviders to utilize electronic transactions only through marketingand provider education vehicles permitted within existing contractlimitations and requirements. No additional or special marketingor provider education campaigns are required.
7.3.1.1The contractor shall educateproviders on the cost and efficiency benefits that can be realized throughadoption and utilization of electronic transactions in its marketingefforts.
7.3.1.2The contractor may use providerincentives/disincentives, at no additional cost to the Government,to encourage use of electronic transactions.
7.3.2The contractorshall assist and work with providers, who wish to exchange electronictransactions, to establish trading partner agreements and connectivitywith their systems and to implement the transactions in a timelymanner.
7.3.3The contractor is not requiredto perfect transactions on behalf of trading partners.
7.4DataAnd Audit Requirements
7.4.1The contractor shall storeall HIPAA-covered electronic transaction data, including eligibilityand claims status transaction data as outlined in Chapter9.
7.4.2The contractor, upon directionfrom DHA to freeze records, shall follow Chapter9.
7.4.3The contractor shall generatetransaction histories covering a period of up to six years uponrequest by DHA in a text format (delimited text format for tablereports) that is able to be imported, read, edited, and printed byMicrosoft® Word (Microsoft® Excel for table reports).
7.4.3.1The contractor shall have theability to generate transaction histories on paper. Transactionhistories shall include at a minimum, the transaction name or type,the dates the transaction was sent or received and the identityof the sender and receiver.
7.4.3.2The contractor’s transactionhistories shall be able to be read in plain writing.
7.4.4The contractor’stransaction data is subject to audit by DHA, DoD, HHS, and otherauthorized Government personnel.
7.4.4.1The contractor shall have theability to retrieve and produce all electronic transaction dataupon request from DHA (for up to six years, or longer if the datais being retained pursuant to a records freeze), to include reasonsfor transaction rejections as outlined in Chapter9.
7.4.4.2Electronic transaction dataremains property of the Government, and shall be turned over inits entirety upon termination of the contract, or upon request bythe Government before that time.
- END -
