Skip to content
Search

Operating Rules

Operating rules support a range of standards to make electronic data transactions more predictable and consistent, regardless of the technology. CAQH CORE is designated by the Secretary of the Department of Health and Human Services (HHS) as the National Operating Rule Authoring Entity for the administrative transactions covered by HIPAA.

Three sets of CAQH CORE Operating Rules are federally mandated under HIPAA. Click the Operating Rules Mandate tab below to access the federally mandated versions of the Eligibility & Benefits, Claim Status and Payment & Remittance Operating Rules. More information is available on the CMS website. CAQH CORE Operating Rule requirements are a floor, not a ceiling, with updated versions of the rules building on the existing requirements. Therefore all federally mandated operating rule requirements are included in the current versions of the CAQH CORE Operating Rules.


Operating Rules

All CAQH CORE Operating Rules are developed through a collaborative, transparent process that ensures balanced representation among participants.


Connectivity

Establishes key connectivity, security and authentication requirements including acknowledgements, error handling, and the CAQH CORE Connectivity “Safe Harbor” creating a national connectivity mechanism that trading partners can be assured will be supported when healthcare information is exchanged. For links to the CORE Connectivity Rules and more detail, please click here.


Eligibility & Benefits

Establishes consistent infrastructure and data content requirements when health plans and providers exchange information regarding a patient’s insurance coverage and benefits. A set of these rules are federally mandated—more information on all CAQH CORE federally mandated rules can be found in the "Operating Rules Mandate" tab on this page.


Claim Status

Streamlines the electronic process by which a provider requests the status of a claim and how the health plan responds. A version of this rule is federally mandated.

Current version of the CAQH CORE Claim Status Operating Rule:

CORE Claim Status (276/277) Infrastructure Rule vCS2.0


Payment and Remittance

Addresses requirements associated with electronic funds transfers (EFT) and electronic remittance advice (ERA), and establishes consistent use of claim adjustment and denial codes. A set of these rules is federally mandated.


Prior Authorization & Referrals


Health Care Claims


Attributed Patient Roster

Attributed patient rosters are used by health plans, providers and employers to share lists of patients attributed to a provider under a value-based contract.


Benefit Enrollment

Creates consistent processes and infrastructure requirements for employers, unions, government agencies and other organizations to enroll members in a healthcare benefit plan.


Premium Payment

Establishes consistent infrastructure and processes for transmitting information relating to payments.

Current versions of the CAQH CORE Premium Payment Operating Rules:

CORE Premium Payment (820) Infrastructure Rule vPP2.0

Rule Development and Voting

All CAQH CORE Operating Rules are developed through a collaborative, transparent process that ensures balanced representation among participants.

CAQH CORE BODY* CAQH CORE REQUIREMENTS FOR RULES APPROVAL
Level 1:
CAQH CORE Subgroups
Subgroups ensure consensus on initial draft requirements; not addresses in governing procedures.
Level 2:
CAQH CORE Work Groups
Work Groups require that a quorum that 60% of participants vote. Simple majority vote (greater than 50%) by this quorum is needed to approve a rule.
Level 3:
Full CAQH CORE Voting Membership
Full CORE Voting Membership vote requires that a quorum that 60% of Full CORE Voting Member organizations (i.e., CORE participants that create, transmit, or use transactions) vote on the proposed rule at this stage. With a quorum, a 66.67% approval vote is needed to approve a rule.
Level 4:
CAQH CORE Board
The CAQH CORE Board's normal voting procedures apply. If the Board does not approve a proposed operating rule, the Board will issue a memorandum setting forth the reasons it did not approve the proposed operating rule and will ask the work groups to revisit the proposed operating rule.

*CAQH Board/CAQH does not have veto or voting power over the CAQH CORE Operating Rules.


Updating and Maintaining the CAQH CORE Operating Rules

CAQH CORE Operating Rules set national responsibilities and requirements for timely and accurate use of electronic transactions within the healthcare revenue cycle. To keep up with evolving business needs and new technologies, all operating rules are subject to a cycle of maintenance based on applicability, need and lessons learned.

The CAQH CORE Operating Rule Maintenance Process addresses three types of updates: Substantive, Non-substantive, and Typographical, as well as routine, periodic maintenance.

Maintenance and updates to the CAQH CORE Operating Rules are triggered by a variety of reasons:

  • New or emerging industry needs.
  • Updated versions of the X12 Technical Report Type 3 (TR3) Implementation Specifications or other standards supported by an operating rule.

Routine maintenance is included in the rule. Some CAQH CORE Operating Rules include specific maintenance processes that may result in modifications of the rule. Routine maintenance requirements are outlined in the applicable rules, including the CAQH CORE Payment & Remittance Operating Rules and the CAQH CORE Connectivity Rules.

CAQH CORE Operating Rule Change Process

The CAQH CORE processes to update and publish changes to operating rules depends on the nature of the changes: substantive, non-substantive, typographical or routine, periodic maintenance.

  • Substantive changes modify operating rule requirements and require implementers to update their systems. Substantive changes require the formal CORE voting process (see "Rule Development" tab above) be followed, which is an open and balanced process to assure a business need exists, work flow changes are suitable and rule requirements are technically feasible. 

Requests for substantive changes can be sent to CORE@caqh.organd will be considered by CAQH CORE Participants. If a request identifies an issue that may impede or prevent industry implementation of an operating rule, it will be prioritized and addressed by the appropriate CAQH CORE work group.

  • Non-substantive changes do not materially impact implementers that need to comply with the operating rules. Examples of non-substantive changes include adding explanatory text or removing content from operating rules that has been incorporated into a new mandated version of the underlying standard. Non-substantive changes do not require the formal CAQH CORE voting process. 

Note: Since CAQH CORE Operating Rules do not repeat the HIPAA-mandated “minimum” requirements in the HIPAA-mandated X12 TR3 Implementation Specifications, in the event that new versions of X12 TR3 Implementation Specifications or other standards are mandated under HIPAA, appropriate revisions to the CAQH CORE Operating Rules are made and a draft available for public input. For example, the CAQH CORE Operating Rules were updated when HIPAA mandates moved from v4010 to v5010 of the X12 standards.

  • Typographical revisions have no impact on implementers as they do not change operating rule requirements and involve corrections to grammatical and technical errors found in operating rules. Examples of typographical errors include misspelling of words, a misprint, technical formatting adjustments or adjustment in punctuation. Typographic revisions do not require the formal CAQH CORE voting process.
  • Periodic, routine maintenance does not change underlying operating rule requirements, but upgrades content requirements based on industry needs and lessons learned. This type of maintenance – which focuses on a specific rule requirement - requires a formal and transparent process to collect multi-stakeholder input. This process is used for the CAQH CORE Code Combinations Maintenance Process and the EFT & ERA Enrollment Data Sets Maintenance Process. 

The CAQH CORE Operating Rule Change Process is depicted below. 

Rule Change Process
CAQH CORE Operating Rules Versions

When substantial updates that modify rule requirements are made to an operating rule, its major version number is updated. If non-substantive updates are made to an operating rule, such a wording changes or providing additional clarification, the minor version is updated. Typographical revisions will not result in a version number update.

As changes are made to an operating rule, CAQH CORE will issue an erratum within the Revision History section to describe the updates and versioning impact.

Routine, periodic maintenance to operating rules may result in a substantive, non-substantive or typographical revisions

CAQH CORE Version Identification Scheme

Key to effectively managing and maintaining these various potential CAQH CORE Operating Rule updates is the careful and precise assignment of version identifiers to the rules and any of their companion documents. This version identification scheme is shown below.

OR.1.0 No impact to versioning
Primary rule version designating CAQH CORE rule set (requires all CAQH CORE Vote) Substantive revision to the rule (modifies a rule requirement and requires CAQH CORE Participant Approval) Non-substantive revision to the rule (wording changes for meaning clarification, remove ambiguity – no change to a rule requirement) Typographical revision to the rule that corrects grammatical and/or technical formatting - no change to a rule requirement; no impact no implementation; no versioning change.
Contributing Ideas and Suggestions for New
Operating Rules or Enhancement to Existing
Operating Rules

CAQH CORE welcomes industry ideas and input on potential new and updated operating rules. New operating rules could address data content suggestions for HIPAA-mandated transactions, as well as transactions not mandated under HIPAA. The CAQH CORE Board relies on key feedback mechanisms including CAQH CORE surveys, work group feedback, the maintenance processes and industry feedback received at core@caqh.org to prioritize rule development and maintenance efforts.

CAQH CORE is committed to conducting substantive, non-substantive, typographical, and routine maintenance on existing rules and developing new rules as appropriate. All rule development and maintenance is conducted by CAQH CORE Participating Organizations and is performed in accordance with the CAQH CORE Operating Rules Development Process in alignment with the CAQH CORE mission and vision. 

 

HIPAA-mandated Healthcare Operating Rules

Section 1104 of the Patient Protection and Affordable Care Act (ACA) requires the Secretary of the Department of Health and Human Services (HHS) to adopt and regularly update standards, implementation specifications and operating rules for the electronic exchange and use of health information for the purposes of financial and administrative transactions under HIPAA. This section applies to HIPAA covered entities and business associates engaging in HIPAA standard transactions on behalf of covered entities.

The ACA defines operating rules as “the necessary business rules and guidelines for the electronic exchange of information that are not defined by a standard or its implementation specifications."

CAQH CORE is designated by the Secretary of HHS as the Operating Rule Authoring Entity for the HIPAA-mandated administrative transactions. CAQH CORE Operating Rules addressing eligibility & benefits, claim status and payment & remittance are federally mandated.

View the CMS website for more detail on the Administrative Simplification provisions of the ACA.

Learn how CMS enforces Administrative Simplification requirements by watching this video.

Accessing the HIPAA-mandated Versions of the CAQH CORE Operating Rules

In 2020, CAQH CORE updated its phase-based operating rule structure to align with current stakeholder operations. The CAQH CORE Operating Rules are now organized by the business processes they support which enhances flexibility to update requirements, enables more rapid and targeted rule development and eliminates the potential for an infinite number of future operating rule phases.

While the CAQH CORE Eligibility & Benefits, Claim Status and Payment & Remittance Operating Rule versions have been updated to meet current and emerging business needs, all of the requirements included in the HIPAA-mandated rule versions remain in the current versions.

Below, are links to the federally mandated versions of the operating rules and the most recent version.

Former Operating Rule Name Former Version Current Operating Rule Name Current Version
CAQH CORE ELIGIBILITY & BENEFITS (EB) OPERATING RULE SET
Phase I CORE 152: Eligibility and Benefit Real Time Companion Guide Rule v1.1.0 CAQH CORE Eligibility & Benefits (270/271) Infrastructure Rule
All eligibility infrastructure requirements combined into a single infrastructure rule.
vEB.2.0
Phase I CORE 155: Eligibility and Benefits Batch Response Time Rule V.1.1.0
Phase I CORE 156: Eligibility and Benefits Real Time Response Time Rule V.1.1.0
Phase I CORE 157: Eligibility and Benefits System Availability Rule V.1.1.0
Phase I CORE 154: Eligibility and Benefits 270/271 Data Content Rule v1.1.0 CAQH CORE Eligibility & Benefits (270/271) Data Content Rule
All eligibility data content requirements combined into a single data content rule.
vEB.1.0
Phase II CAQH CORE 260: Eligibility & Benefits Data Content (270/271) Rule V.2.1.0
Phase II CAQH CORE 258: Eligibility and Benefits 270/271 Normalizing Patient Last Name Rule V.2.1.0
Phase II CAQH CORE 259: Eligibility and Benefits 270/271 AAA Error Code Reporting Rule V.2.1.0
Phase I CORE 153: Eligibility and Benefits Connectivity Rule V.1.1.0 CAQH CORE Connectivity Rule vC1.1.0
Phase II CAQH CORE 270: Connectivity Rule V.2.2.0 CAQH CORE Connectivity Rule vC2.2.0
CAQH CORE CLAIM STATUS (CS) OPERATING RULE SET
Phase II CAQH CORE 250: Claim Status Rule V.2.1.0 CAQH CORE Claim Status (276/277) Infrastructure Rule vCS.1.0
Phase II CAQH CORE 270: Connectivity Rule V.2.2.0 CAQH CORE Claim Status (276/277) Infrastructure Rule vC2.2.0
CAQH CORE PAYMENT & REMITTANCE (PR) OPERATING RULE SET
Phase III CORE 350 Health Care Claim Payment/Advice (835) Infrastructure Rule V.3.0.0 CAQH CORE Payment & Remittance (835) Infrastructure Rule vPR.1.0
Phase III CORE 360 Uniform Use of Claim Adjustment Reason Codes and Remittance Advice Remark Codes (835) Rule V.3.0.0 CAQH CORE Payment & Remittance (835) Uniform Use of CARCs and RARCs Rule vPR.1.0
Phase III CORE 370 EFT & ERA Reassociation (CCD+/835) Rule V.3.0.0 CAQH CORE Payment & Remittance (CCD+/835) Reassociation Rule vPR.1.0
Phase III CORE 380 EFT Enrollment Data Rule V.3.0.0 CAQH CORE Payment & Remittance EFT Enrollment Data Rule vPR.1.0
Phase III CORE 382 ERA Enrollment Data Rule V.3.0.0 CAQH CORE Payment & Remittance ERA Enrollment Data Rule vPR.1.0
Phase II CAQH CORE 270: Connectivity Rule V.3.0.0 CAQH CORE Connectivity Rule vC2.2.0
CAQH CORE MASTER COMPANION GUIDE
CAQH CORE Master Companion Guide Template V5010 CAQH CORE Master Companion Guide Template version agnostic

Keeping Up with the CORE Code Combinations

Current Version of the CORE Code Combinations: October 2024 v3.8.3

If you have been tasked with implementing the CAQH CORE Payment & Remittance Uniform Use of CARCs and RARCs (835) Rule, part of the Affordable Care Act (ACA)-mandated Payment & Remittance Operating Rules, you will find all the necessary tools and information here to comply with this operating rule.

These resources are provided free of charge by CAQH CORE, author of the operating rules, and are intended to help organizations comply with the law.

Background

The CAQH CORE Payment & Remittance Operating Rules, among other things, simplify the language used to communicate about claim payment and remittance information. The CAQH CORE Payment & Remittance Uniform Use of CARCs and RARCs (835) Rule brings uniformity to the use of Claim Adjustment Reason Codes (CARCs), Remittance Advice Remark Codes (RARCs), and Claim Adjustment Group Codes (CAGCs) by identifying a limited set of CARC/RARC/CAGC combinations to be used in defined universal business scenarios. These codes are used in combination to convey details about a claim adjustment or denial in the X12 v5010 835.

Together, the business scenarios and code combinations make up the CORE-required Code Combinations for CORE-defined Business Scenarios (CORE Code Combinations), a companion document to the CAQH CORE Payment & Remittance Uniform Use of CARCs and RARCs (835) Rule.

The published CARC and RARC lists and, in turn, the CORE Code Combinations are updated three times per year.

Current and Past Versions of the CORE Code Combinations

The current version of CORE Code Combinations for use with the CAQH CORE Payment & Remittance Uniform Use of CARCs and RARCs (835) Rule is the CORE Code Combinations October 2024 v3.8.3

As the table illustrates, this version aligns with CARC and RARC list updates published June 1, 2024.

Date of Published CARC and RARC List Updates (Updates Trigger Compliance-based Reviews of the CORE Code Combinations) Resulting Version of the CORE Code Combinations Does Version Include Market-based Adjustments from Industry? Compliance Date (Applies as of January 1, 2014 to all HIPAA-covered Entities) Adjustments Between Versions of the CORE Code Combinations
June 1, 2024 October 2024 v3.8.3 (current) No January 1, 2025 Adjustments from June 2024 v3.8.2 to October 2024 v3.8.3
March 1, 2024 June 2024 v3.8.2 (now deprecated) No September 1, 2024 Adjustments from February 2023 v3.8.1 to June 2024 v3.8.2
November 1, 2023 February 2024 v3.8.1 (now deprecated) No May 1, 2024 Adjustments from October 2023 v3.8.0 to February 2024 v3.8.1
July 1, 2023 October 2023 v3.8.0(now deprecated) Yes January 1, 2024 Adjustments from June 2023 v3.7.4 to October 2023 v3.8.0
March 1, 2023 June 2023 v3.7.4(now deprecated)  No September 1, 2023 Adjustments from February 2023 v3.7.3 to June 2023 v3.74
November 1, 2022 February 2023, v3.7.3  (now deprecated) No May 1, 2023 Adjustments from October 2022 v3.7.2 to February 2023 v3.7.3 
July 1, 2022 October 2022, v3.7.2 (now deprecated) No January 1, 2023 Adjustments from June 2022 v3.7.1 to October 2022 v3.7.2
March 1, 2022 June 2022 v3.7.1 (now deprecated) No September 1, 2022 Adjustments from February 2022 v3.7.0 to June 2022 v3.7.1
November 1, 2021 February 2022 v3.7.0 (now deprecated) Yes May 1, 2022 Adjustments from October 2021 v3.6.5 to February 2022 v3.7.0
July 1, 2021 October 2021 v3.6.5 (now deprecated) No January 1, 2022 Adjustments from June 2021 v3.6.4 to October 2021 v3.6.5
March 1, 2021 June 2021 v3.6.4 (now deprecated) No September 1 , 2021 Adjustments from February 2021 v3.6.3 to June 2021 v3.6.4
November 1, 2020 February 2021 v3.6.3 (now deprecated) No May 1, 2021 Adjustments from October 2020 v3.6.2 to February 2021 v3.6.3
July 1, 2020 October 2020 v3.6.2 (now deprecated) No January 1, 2021 Adjustments from June 2020 v3.6.1 to October 2020 v3.6.2
March 1, 2020 June 2020 v3.6.1(now deprecated) No September 1, 2020 Adjustments from February 2020 v3.6.0 to June 2020 v3.6.1
November 1, 2019 February 2020 v3.6.0 (now deprecated) Yes May 1, 2020 Adjustments from October 2019 v3.5.4 to February 2020 v3.5.0
July 1, 2019 October 2019 v3.5.4
(now deprecated)
No January 2, 2020 Adjustments from June 2019 v3.5.3 to October 2019 v3.5.4
March 1, 2019 June 2019 v3.5.3
(now deprecated)
No September 1, 2019 Adjustments from February 2019 v3.5.2 to June 2019 3.5.3
November 1, 2018 February 2019 v3.5.2
(now deprecated)
No May 1, 2019 Adjustments from October 2018 v3.5.1 to February 2019 v3.5.2
July 1, 2018 October 2018 v3.5.1
(now deprecated)
No January 2, 2019 Adjustments from June 2018 v3.5.0 to October 2018 v3.5.1
March 1, 2018 June 2018 v3.5.0   
(now deprecated)
Yes September 1, 2018 Adjustments from February 2018 v3.4.2 to June 2018 v3.5.0
July 3, 2017 October 2017 v3.4.1   
(now deprecated)
No January 5, 2018 Adjustments from June 2017 v3.4.0 to October 2017 v3.4.1
March 1, 2017 June 2017 v3.4.0
(now deprecated)
Yes September 1, 2017 Adjustments from February 2017 v3.3.2 to June 2017 v3.4.0
November 1, 2016 February 2017 v3.3.2
(now deprecated)
No May 2, 2017 Adjustments from October 2016 v3.3.1 to February 2017 v3.3.2
July 1, 2016 October 2016 v3.3.1
(now deprecated)
Yes January 4, 2017 Adjustments from June 2016 v3.3.0 to October 2016 v3.3.1
March 1, 2016 June 2016 v3.3.0
(now deprecated)
Yes September 10, 2016 Adjustments from February 2016 v3.2.2 to June 2016 v3.3.0
November 1, 2015 February 2016 v3.2.2   
(now deprecated)
No May 1, 2016 Adjustments from October 2015 v3.2.1 to February 2016 v3.2.2
July 1, 2015 October 2015 v3.2.1   
(now deprecated)
No January 1, 2016 Adjustments from June 2015 v3.2.0 to October 2015 v3.2.1
March 1, 2015 June 2015 v3.2.0
(now deprecated)
Yes September 5, 2015 Adjustments from February 2015 v3.1.3 to June 2015 v3.2.0
November 1, 2014 February 2015 v3.1.3   
(now deprecated)
No May 2, 2015 Adjustments from October 2014 v3.1.2 to February 2015 v3.1.3
July 1, 2014 October 2014 v3.1.2
(now deprecated)
No January 1, 2015 Adjustments from July 2014 v3.1.1 to October 2014 v3.1.2
N/A Minor adjustments to address oversight from Market-based Review July 2014 v3.1.1   
(now deprecated)
Yes October 2, 2014 Adjustments from February 2014 v3.0.4 to July 2014 v3.1.1
March 1, 2014 and March 14, 2014 June 2014 v3.1.0
(now deprecated)
Yes September 4, 2014 Adjustments from February 2014 v3.0.4 to June 2014 v3.1.0
November 1, 2013 February 2014 v3.0.4   
(now deprecated)
No May 1, 2014 Adjustments from October 2013 v3.0.3 to February 2014 v3.0.4
July 1, 2013 & July 15, 2013 October 2013 v3.0.3
(now deprecated)
No January 1, 2014 Adjustments from May 2013 v3.0.2 to October 2013 v3.0.3
March 1, 2013 May 2013 v3.0.2 (now deprecated) No N/A Adjustments from January 2013 v3.0.1 to May 2013 v3.0.2
November 1, 2012 January 2013 v3.0.1 (now deprecated) No N/A N/A
March 8, 2011 June 2012 v3.0.0 (now deprecated) No N/A N/A

High-level Summary of Adjustments in Version 3.8.3 of the CORE Code Combinations

Version 3.8.3 of the CORE Code Combinations includes updates based on Compliance-based as part of the CAQH CORE Code Combinations Maintenance Process based on published CARC and RARC lists as of June 1, 2024.

The table below summarizes the Compliance-based Adjustments approved by the CAQH CORE Code Combinations Task Group for inclusion in the current version of the CORE Code Combinations by CORE-defined Business Scenario.

Type of Adjustment CORE-defined Business Scenario #1 CORE-defined Business Scenario #2 CORE-defined Business Scenario #3 CORE-defined Business Scenario #4

July 2024
Compliance-based Review

Addition of new RARC N896 to existing CARCs 163, 250, 251, and 252, Addition of new RARC N897 to exisiting CARC’s 163, 250, 251 and 252, Addition of new RARC N899 to exisiting CARC’s 163, 250, and 252, Addition of new RARC N900 to existing CARCs 163, 250, and 252, Addition of new RARC N901 to exisiting CARCs 250 and 251, Addition of new RARC N902 to exisiting CARCs 163, 250, and 252, Addition of new RARC N903 with exisiting CARCs 250 and 251.

Addition of new RARC N898 with exisiting CARC 16.

Addition of new RARC N897 with existing CARC 201, Addition of new RARC N904 with existing CARCs 109 and B11.

N/A


Summary of Compliance-based Adjustments in Version 3.8.3 of the CORE Code Combinations

June 2024 Adjustments to Published Code Lists CORE Code Combinations v3.8.3 October 2024 Compliance-based Adjustments

Deactivations
(0 CARCs and 0 RARCs deactivated by Code Committees)

N/A

Modifications
(0 CARC descriptions and 0 RARC descriptions modified by Code Committees)

N/A

Additions
0 CARCs and 9 RARCs added by Code Committees

 

  • Addition of new RARCs
    • RARC N896 to CARC 163
    • RARC N896 to CARC 250
    • RARC N896 to CARC 251
    • RARC N896 to CARC 252
    • RARC N897 to CARC 163
    • RARC N897 to CARC 250
    • RARC N897 to CARC 251
    • RARC N897 to CARC 252
    • RARC N897 to CARC 201
    • RARC N898 to CARC 16
    • RARC N899 to CARC 163
    • RARC N899 to CARC 250
    • RARC N899 to CARC 282
    • RARC N900 to CARC 163
    • RARC N900 to CARC 250
    • RARC N900 to CARC 252
    • RARC N901 to CARC 250
    • RARC N901 to CARC 251
    • RARC N902 to CARC 163
    • RARC N902 to CARC 250
    • RARC N902 to CARC 252
    • RARC N903 to CARC 250
    • RARC N903 to CARC 251
    • RARC N904 to CARC 109
    • RARC N904 to CARC B11

Overview of Market-based Review Process and Scope

CAQH CORE facilitates a public 60-day period during which industry entities can submit potential Market-based Adjustments to code combinations in the existing CORE-defined business scenarios. Industry entities can submit three categories of potential code combination adjustments:

  • Addition of new CORE Code Combinations.
  • Removal of existing CORE Code Combinations.
  • Relocation of an existing CORE Code Combination from an existing CORE-defined Business Scenario to another existing CORE-defined Business Scenario.

Summary of Market-based Adjustments in the October 2024 Version of the CORE Code Combinations

Type of Adjustment CORE-defined Business Scenario #1 CORE-defined Business Scenario #2 CORE-defined Business Scenario #3 CORE-defined Business Scenario #4
Additions

N/A

N/A

N/A

N/A

Removals

N/A

N/A

N/A

N/A


Timeline for Updates and Compliance with Updated CORE Code Combinations

The CORE Code Combinations are updated at scheduled intervals to align with updates to the published CARC and RARC lists, which are maintained by CARC/RARC Code Committees external to CAQH CORE. The following table illustrates the timeline.

Projected Dates of CARC & RARC List Updates Scheduled Publication Date of CORE Code Combinations   
(approximately 3 months after list updates)
Mandated Compliance Date for CORE Code Combinations (90 days after date of publication)
~November 1 February 1 May 1
~March 1 June 1 September 1
~July 1 October 1 January 1

Beginning January 1, 2014, HIPAA-covered entities have 90 days to comply with published updates to the CORE Code Combinations.

Exception: In some instances, the effective date for code modifications and deactivations approved by the code maintenance committees is more than six months after publication of the updated code list. To accommodate code modifications or deactivations that go into effect after the compliance date for the new version of the CORE-required Code Combinations for CORE-defined Business Scenarios (e.g. adjustments with effective dates greater than six months from the code list publication date), CAQH CORE has incorporated the following exceptions to the 90 day compliance timeframe:

  1. Any deactivated CORE-required CARCs and RARCs may continue to be used until the effective deactivation/stop date as published by the respective code maintenance committee.
  2. Any modified CORE-required CARCs and RARCs may continue to be used with their previous description until the effective date of the code description modification as published by the respective code maintenance committee.

After the effective date, the unmodified or deactivated code can only continue to be used in “derivative business transactions”. Derivative business transactions are business messages where the CARC or RARC is being reported from an original business message that was initiated prior to the code adjustment effective date.

NOTE: The 04/19/13 CMS Notice to the Industry states that because the Maintenance Process was adopted in the IFC, covered entities should understand that revised and updated versions of the CORE Code Combinations are part of the regulation (applies to both Compliance and Market-based Adjustments to current CORE-defined Business Scenarios); covered entities are responsible for complying with the latest version.

Impact by Stakeholder Type

The CAQH CORE Payment & Remittance Uniform Use of CARCs and RARCs (835) Rule requirements and the impact of updated versions of the CORE Code Combinations vary depending on an entity’s stakeholder type.

NOTE: ACA Section 1104 mandates that all HIPAA covered entities comply with the Payment & Remittance Operating Rules; however non-HIPAA covered entities play a crucial role in enabling their provider and health plan clients to realize the benefits of industry adoption and often act as Business Associates on behalf of a HIPAA covered entity.

  Creators of the X12 v5010 835 Receivers of the X12 v5010 835
Applicable Stakeholder Types Creators of the X12 v5010 835

Any organization with systems that creates the X12 v5010 835, which may include:

  • Health plans and/or PBM agents.
  • Health plan-facing clearinghouses.
  • Health plan-facing vendors.
  • Health plan business associates.
Receivers of the X12 v5010 835

Any organization with systems that receive the X12 v5010 835 and extracts data for manual processing, which may include:

  • Providers.
  • Provider-facing clearinghouses.
  • Provider-facing vendors.
  • Provider business associates.
 

What requirements apply to my organization?

 

(Please refer to CAQH CORE Payment & Remittance Uniform Use of CARCs and RARCs (835) Rule for a full list of applicable rule requirements)

Creators of the X12 v5010 835

Systems creating the X12 v5010 835  must have the ability to:

  • Align its internal codes and corresponding business scenarios to the CORE-defined Business Scenarios CARC, RARC, CAGC and NCPDP Reject Code combinations specified in the CORE Code Combinations.
  • Support the maximum CORE-required Code Combinations  in the v5010 X12 835 as specified in CORE Code Combinations.
    • No other code combinations are allowed for use in the CORE-defined Business Scenarios.
    • When specific CORE-required Code Combinations are not applicable to meet the health plan’s or its PBM agent’s business requirements within the CORE-defined Business Scenarios, the health plan and its PBM agent is not required to use them.
    • The only exception to this maximum set of CORE-required Code Combinations is when the respective code committees responsible for maintaining the codes create a new code or adjust an existing code. Then the new or adjusted code can be used with the Business Scenarios and a Compliance-based Review will consider the ongoing use of these codes within the maximum set of codes for the Business Scenarios.
    • A deactivated code must not be used.
  • In the case where a health plan or its PBM agent wants to use an existing code combination that is not included in the maximum code combination set for a given CORE-defined Business Scenario, a new code combination must be requested in accordance with the CORE Code Combinations Maintenance Process.
Receivers of the X12 v5010 835

When receiving a v5010 X12 835, a product extracting the data from the X12 v5010 835 for manual processing must make available to the end user:

  • Text describing the CARC/RARC/CAGC and CARC/NCPDP Reject Codes included in the remittance advice, ensuring that the actual wording of the text displayed accurately represents the corresponding code description specified in the code lists without changing the meaning and intent of the description.
  • Text describing the corresponding CORE-defined Business Scenario.
  • The requirement to make available text describing the corresponding CORE-defined Business Scenario to the end user does not apply to retail pharmacy
  • This requirement does not apply to an entity that is simply forwarding the X12 v5010 835 to another system for further processing.

 

What does my organization need to do when an updated version of the CORE Code Combinations is published? Creators of the X12 v5010 835

Organizations with systems that create the X12 v5010 835 should:

  • Adjust systems to support the maximum set of CORE-required Code Combinations and minimum set of CORE-defined Business Scenarios as specified in the updated version of the CORE Code Combinations for each version update.
  • Implement an ongoing maintenance process given the CORE Code Combinations will be updated three times per year
Receivers of the X12 v5010 835

Organizations with products that receive the X12 v5010 835 and extract data for manual processing should:

  • Adjust systems to ensure appropriate text is displayed as specified in the updated version of the CORE Code Combinations for each version update.
  • Implement an ongoing maintenance process given the CORE Code Combinations will be updated three times per year.

 

Providers should:

  • Ensure vendor /clearinghouse/other business associate (e.g. receiver of the v5010 X12 835) has updated its systems to align with the updated version of the CORE Code Combinations.
  • Monitor code combinations sent via the v5010 X12 835 to ensure alignment with the updated version of the CORE Code Combinations.
  • Report non-compliance to CMS as appropriate.
The CORE Code Combinations Maintenance Process

The CARC and RARC lists are authored and maintained by CARC/RARC Code Committees designated by the Secretary of Health and Human Services.  Addition, modification, or removal of codes must be addressed by the appropriate committee, either the Claim Adjustment Status Code Maintenance Committee or Remittance Advice Remark Code Committee; this is out of scope for CAQH CORE. The CARC/RARC Code Committees meet and publish updates on the Washington Publishing Company’s website three times per year. The CAGCs are part of the X12 835 standard and are thus maintained by ASC X12.

CARCs
(Claim Adjustment Status Code Maintenance Committee)
RARCs
(Remittance Advice Remark Code Committee)
CAGCs
(ASC X12)
  • Total # of CARCs: 358
    • not all in CORE Code Combinations
  • There are approximately 35 CARC Committee members representing a variety of stakeholder including health plans, associations, vendors, and government entities.
  • Entities can complete the CARC Change Request Form.
  • Total # of RARCs: 2,001
    • not all in CORE Code Combinations.
  • The RARC Committee members represent various components of CMS.
  • Entities can complete the RARC Change Request Form.
  • Total # of CAGCs: 4
    • All are in CORE Code Combinations.
  • Part of the ASC X12 standard, therefore, can only be revised when a new HIPAA. mandated version of X12 standards is issued; current version is ASC X12 v5010.
  • Entities can submit a request to ASC X12.

The CORE Code Combinations are maintained by the CAQH CORE Code Combinations Task Group.

The CAQH CORE Code Combinations Task Group conducts two types of reviews and adjustments of the CORE Code Combinations as part of its ongoing CAQH CORE Code Combinations Maintenance Process required by the CAQH CORE Payment & Remittance Uniform Use of CARCs and RARCs (835) Rule:

Compliance-based Reviews: Occur three times per year and consider only additions, deactivations, or modifications to the current published CARC and RARC lists by the code committees since the last update to the CORE Code Combinations

Market-based Reviews: Occur once every two years and address ongoing and evolving industry business needs. A Market-based Review considers industry submissions addressing:

Adjustments to the existing CORE Code Combinations for existing CORE-defined Business Scenarios (additions, removals, etc.) based on real-world usage data and/or a strong business case

Addition of new CORE-defined Business Scenarios and associated CORE-required Code Combinations based on real-world usage data and a strong business case

CAQH CORE has also established a Code Combinations Emergency Update Process.

The timeline below lays out the general timeframes for the CARC/RARC Code Committees and the CAQH CORE Code Combinations Maintenance Process. 

Timeline of CARC/RARC Code Committees

*Goal is to publish the Market Adjustments with Compliance-based Adjustments to ensure only 3 annual updates to the CORE Code Combinations.    
 

To learn more about the CORE Code Combinations Maintenance Process, see the FAQs for CAQH CORE Use of CARCs & RARCs Rule.

How to Submit Market-based Adjustments

The CAQH Committee on Operating Rules for Information Exchange (CORE) 2024 Market-based Review (MBR) is now open. MBR of the CORE-required Code Combinations for CORE-defined Business Scenarios occur annually to adjust the CORE Code Combinations to address ongoing and evolving business needs.

2024 MBR INDUSTRY-WIDE SUBMISSION PERIOD
The 2024 MBR will consider adjustments to the existing four CORE-defined Business Scenarios. Potential adjustments include additions, removals, or relocations to code combinations in the existing CORE-defined Business Scenarios. Additionally, the 2024 MBR allows for the submission of refinements to the four CORE-defined Business Scenarios and suggestions for new CORE-defined Business Scenarios.

All recommended changes and additions submitted via the 2024 MBR will be evaluated by the CCTG, and approved changes will be reflected in the February 2025 update of the CORE Code Combinations.

DUE DATE: The 2024 MBR will remain open until 5 PM ET, Monday, October 28, 2024. Please contact CORE@caqh.org for more information.

WHO CAN SUBMIT: Any organization or individual that creates, uses, or transmits HIPAA transactions, may submit potential Market-based adjustments via the online CORE 2024 Market-based Adjustments Form.

HOW TO SUBMIT:

  • The 2024 Market-based Review form can be found by clicking HERE.

INTERESTED IN JOINING CORE OR THE CORE CODE COMBINATIONS TASK GROUP? 

  • You can learn more about CORE by clicking here.
  • Please email us at CORE@caqh.org for more information on how to join us for this important work.

If you need additional assistance in navigating the Market-based Adjustments Form or have any questions regarding the 2024 MBR, feel free to respond directly to this email or contact Tanner Fuchs, Senior Associate, CORE at tfuchs@caqh.org

Get Involved in the CAQH CORE Code Combinations Maintenance Process

Entities are encouraged to join CAQH CORE as a Participating Organization to:

  • Contribute to the evolution of CAQH CORE Use of CARCs & RARCs Rule and the CORE Code Combinations via the CAQH CORE Code Combinations Task Group.
  • Have a voice in the development of operating rules.
  • Be part of a solution that is taking cost and complexity out of the healthcare system.

CAQH CORE welcomes Participating Organizations representing a range of stakeholder groups.

Entities can also contribute a number of other ways, for example:

  • Submission of Market-based Adjustments to the CORE Code Combinations.
  • Work directly with CMS, standard setting bodies like ASC X12, and the various industry code committees to advance industry knowledge.
  • Respond to public surveys or submit requests to CORE@caqh.org.

Trading Partner Collaboration: Conformance Testing and Voluntary CORE Certification

  • Conformance testing with your trading partners is a critical aspect to making your  operating rules implementation a success.
    • HIPAA covered entities can quickly communicate their organization’s readiness to testing their conformance with trading partners by adding their company information to the CORE Partner Testing page of the CAQH website.
    • Entities should consider voluntary CORE Certification to publicly communicate their systems meet the CAQH CORE Rayment & Remittance Operating Rule requirements.

Keeping Up with the CORE-required Maximum Enrollment Data Sets

If you are tasked with implementing the EFT & ERA Enrollment Data Rules mandated under HIPAA, you will find the necessary information here to comply with these operating rules.

Background

The CAQH CORE Payment & Remittance Operating Rules support the healthcare industry's transition to electronic payment and remittance advice.

Two of the five CAQH CORE Payment & Remittance Operating Rules address the barriers to greater provider EFT and/or ERA enrollment. The EFT & ERA Enrollment Data Rules outline maximum sets of standard data elements to be collected by a health plan or its agent during provider enrollment in EFT and/or ERA. The rules also outline a flow and format for collection of the data elements, among other requirements.

The EFT & ERA Enrollment Data Rules also recognize the need for ongoing maintenance of the CORE-required Maximum EFT & ERA Enrollment Data Sets and establishes a policy and process to review the Enrollment Data Sets no less than annually. From 2014 - 2022, review of the Enrollment Data Sets was conducted annually, with limited in-scope submissions from the industry and no substantive adjustments to the data sets.