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.
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. Tallan’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?
- Overview of certifications steps for all phases
- Step-by-step breakdown of the certification process
- CORE application portal
- Testing site
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 information
- Demographic Information
- Health Plan
- Plan information
- Plan Name
- Service Coverage
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:
- 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:
- Ensure you are properly setting the Content-Type header:
- 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:
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:
- 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.
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!
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.
At Tallan, we’re always interested in discussing EDI management challenges. Reach out to us for a consultation to discuss how we can address these challenges within your current infrastructure. Looking to improve other areas of your business? We also discuss a wide variety of topics at our in-person events and webinars!