CAQH CORE Certification Tips

CAQH CORE certification demonstrates that health plans, clearinghouses and software vendors meet federally mandated operating rules when exchanging HIPAA EDI transactions. Internally for organizations, the certification process provides value by exercising a broad variety of test cases. Last but not least, CORE specifies the message envelope details for exchanging EDI over two types of HTTP endpoints, reducing the implementation times that custom message formats can incur.

CORE Seals

The CAQH website is the complete resource for understanding the types and variations of CORE certification. In this article, we’ll take a complementary approach. Rather than attempt to summarize the full spectrum of options, we’ll focus on a single use case in order to highlight key information and technical challenges. Caliber Health’s T-Connect Eligibility Module places us in the software vendor category. Our EDI management solution enables health plans to act as an information source to respond to 270 Eligibility requests with a 271 response.

Information Gathering and Planning

A solid discovery phase is important for understanding any gaps your organization needs to cover from a technology and subject matter perspective. It’s also important to communicate the reasons for certification to partners and internal stakeholders.

Who is CAQH?

CAQH (Council for Affordable Quality Healthcare) is a non-profit organization focused on the improvement of healthcare information exchange. CORE (Committee on Operating Rules for Information Exchange) is the CAQH initiative responsible for defining operating rules for HIPAA transactions. CORE also guides the testing and certification process to support the operating rules.

What is CORE certification?

CORE certification is a set of steps and testing scenarios that validate healthcare organizations manage administrative transactions in accordance with well-defined operating rules. There are currently four tracks. Each phase confers its own certification.

  • Phase I – 270 / 271 requirements. This phase is a baseline for the content of eligibility requests, responses and acknowledgements, as well as system availability and response times.
  • Phase II – Additional operating rules for the 270 / 271 transactions, especially related to error reporting. This phase also addresses the 276 / 277 Claim Status transactions.
  • Phase III – Focused on 835 Claim Payments. While the X12 guide defines the required codesets and balancing rules, Phase III standardizes the CARC and RARC codes for reporting adjudication information.
  • Phase IV – The most expansive phase, covering 837 claims, 278 service reviews, 834 enrollments and 820 premium payments.

Why should my organization get certified?

  • After HIPAA mandated the administrative standards, it became apparent that operating rules were also necessary to optimize information exchange. For example, an information source receiving a 270 eligibility request may fail to locate the specified member. The 271 response contains a range of error codes. Without specific operating rules, different health plans could return structurally valid 271 responses but indicate the error condition in distinct ways. Section 1104 of the Affordable Care Act mandates the establishment of operating rules, and CMS subsequently designated CAQH to develop and maintain these standards.
  • The CORE test cases align with common administrative workflows. Working through these steps is helpful for identifying any shortcomings that may exist in an implementation.
  • Adhering to the HTTP formats in the CORE guidelines removes the responsibility from trading partners to come up with a particular syntax.

What resources should we plan for?

  • EDI Analyst – This role is needed for breaking down the CORE requirements and mapping them to your existing systems.
  • Developer(s) –  EDI mapping, web API programming and database development skills needed here.

Where can I gather more information?


Now that we’ve gained an overview of the certification process, we’re ready to begin laying the technical foundation for end-to-end testing.

Master Test Bed Data

The nature of the 270 request / 271 response pair requires a common data set. Both requests and responses during the testing phase will be based on the CAQH-curated test data set published here.

Beneficiary Data
The first 25 tabs in the spreadsheet represent beneficiaries
  • Beneficiary information
    • Name
    • Address
    • Demographic Information
    • Health Plan
    • Accumulators
Health Plan Data
Tabs 26-35 specify health plan details
  • Plan information
    • Plan Name
    • Service Coverage
    • Deductibles
    • Copays
    • Coinsurance

In order to act as an information source or receiver, you’ll need to extract and load the test data set and connect it within your infrastructure through a data access layer.

Here’s a simple way this information can be modeled:

Eligibility Data Model

Web Endpoints Phase I and II specify two possible formats for exchanging eligibility and claim status messages. Certification requires the implementation of both endpoints. The MIME Multipart option will be straightforward for most developers. The SOAP endpoint has a few nuances that are worth mentioning in more detail.

  • Use a good testing tool to do preliminary testing with your eligibility service. SoapUI has all the features you’ll need to emulate the CORE message format.
  • Make sure your service to specifies SOAP 1.2. Here’s the configuration on our WCF service:
SOAP 1.2 Binding
  • Ensure you are properly setting the Content-Type header:
Set ContentType
  • WS-Security can be a challenge to configure on both the client and the server. The WSDL for the SOAP endpoint describes the message body. You will notice the header node for security is not included. The full request looks like this:
WS-Security Header

The key  here is that the Security node in the request should not be part of your schema – it is managed by your SOAP framework. This overview provides a good description of how to configure SoapUI to enable WS-Security.

Here’s what my outgoing configuration looks like:

WS-Security Configuration
  • It’s important to check the “Must Understand” flag. This will ensure the security header matches the WS-Security CORE specifications. Once you’ve associated this configuration with your test message, SoapUI will handle the generation of the header.


With the information gathering and prep steps out of the way, it’s time for the fun part. To kick things off, you’ll need to register an account with the CAQH testing partner. During setup, you’ll specify similar information to your CAQH Portal registration:

  • Which certification phases you want to start with
  • The category your test cases fall under (plan, provider, etc)

In our example of Phase I and II certification, the majority of testing steps involve receiving a 270 request. The expectation is that our software will receive the request, perform the required validations and lookups against the shared dataset, and return a valid response.

Eligibility Test Submission

After submitting the form, the 270 request is sent immediately to your endpoint. Any failures include a 999 response and a human-readable HTML page describing the error. Once you’ve corrected any compliance issues in your implementation, you can re-run the test. It’s a good feeling when you pass!

Eligibility Test Response

We hope these tips are helpful in getting an overview of the certification process. It’s worth noting that upon registration with the CORE portal, you’ll be assigned a contact from CAQH. We were impressed with their responsiveness and guidance.

Caliber Health is dedicated to helping health plans, TPAs, and providers meet their EDI management challenges. Contact us today for a consultation or EDI solution demo!

Leave a Reply

Your email address will not be published. Required fields are marked *