NOTICE
Old UPD URLs no longer redirect to current URLs. Please update your browser bookmarks.

Providers use: https://upd.caqh.org/oas

Practice managers use: https://upd.caqh.org/pmm

Quick Links
Send Me Information
CORE^® Phase I Rules
CORE^® Phase II Rules
CORE^® FAQs
CAQH^® Jobs

SET TEXT SIZE

PRINTER FRIENDLY

Physicians and other health providers are now using this industry standard for provider data collection

CORE Phase II
Committed Organizations:

Are You Ready to Submit
Your Phase II Pledge?

THE PHASE II RULES

CORE Phase II
Scope and Rules

STATE ACTIVITIES

CORE State Information

UPCOMING CORE PRESENTATIONS:

The World Health Care Congress 5th Annual Leadership Summit on Medicare
7/12/09 - 7/14/09

IOM - The Healthcare Imperative: Lowering Costs and Improving Outcomes, Strategies that Work
7/16/09 - 7/17/09

The World Health Care Congress 7th Annual Health Care Quality Congress
8/3/09 - 8/5/09

MMIS Conference
8/16/09 - 8/20/09

National Plan Automation Group Conference
9/13/09 - 9/16/09

HIPAA Summit 17
9/16/09

ASC X12 Trimester Meeting
9/20/09

NAIC Fall National Meeting
9/21/09 - 9/24/09

AICPA National Healthcare Industry Conference
9/24/09 - 9/25/09

View the complete list of 2009 CORE presentations.

CORE FAQ's

I. CORE General FAQs

II. Policy FAQs

101: Pledge
102: Certification Policy
103: Exemption Policy
104: Testing Policy
105: Enforcement Policy

III. Operating Rule FAQs

150: Batch Acknowledgements
151: Real Time Acknowledgements
152: Companion Guide Rule
153: Connectivity Rule
154: 270/271 Data Content Rule
155: Batch Response Time Rule
156: Real Time Response Time Rule
157: System Availability Rule

IV. Test Suite, Supplement, and Master Test Bed Data FAQs

V. Measures of Success FAQs

VI. CORE Resources and Links FAQs

I. General

What is CORE?

The Committee on Operating Rules for Information Exchange (CORE) is a multi-stakeholder initiative created, organized and facilitated by CAQH. CORE’s Phase I goal is to create, disseminate, and maintain operating rules that enable healthcare providers to quickly and securely obtain reliable healthcare eligibility and benefits information. CORE operating rules will decrease the amount of time and resources providers spend verifying patient eligibility, benefits and other administrative information at the point of care. CORE operating rules, envisioned to be introduced in multiple phases, have support from health plans, medical professional societies, providers, vendors, associations, regional entities, standard-setting organizations, government agencies and other healthcare constituencies. See CORE Participating Organizations for a list of participants.

What is CAQH?

CAQH, an unprecedented nonprofit alliance of health plans, networks and trade associations, is a catalyst for industry collaboration on initiatives that simplify healthcare administration. CAQH solutions.

Promote quality interactions between plans, providers and other stakeholders
Reduce costs and frustrations associated with healthcare administration
Facilitate administrative healthcare information exchange
Encourage administrative and clinical data integration

www.caqh.org

What are Operating Rules?

Operating rules build on existing standards to make electronic transactions more predictable and consistent, regardless of the technology. By addressing the rights and responsibilities of all parties, security, transmission standards and formats, response time standards, liabilities, exception processing, error resolution and more, operating rules facilitate interoperability among parties who exchange healthcare data. Beyond reducing cost and administrative hassles, operating rules foster trust among all participants.CORE operating rules are based on principles similar to those that govern ATM networks and direct deposit banking in the banking industry as well as those that maintain and facilitate electricity flow in the power industry.

Why Develop Operating Rules For Healthcare Eligibility and Benefits Information?

HIPAA provides a foundation for the exchange of eligibility and benefits information, but does not go far enough to promote interoperability. The data scope identified by HIPAA is limited and elements needed by providers are not mandated. Further, HIPAA neither standardizes data definitions nor offers business requirements (e.g., timely response).

Operating rules promote interoperability between the numerous stakeholders that create, send and/or transmit healthcare eligibility, benefits and other healthcare administrative information. Interoperability ensures that information can be uniformly requested, provided and understood by all stakeholders.

The CORE Phase I operating rules, therefore, will streamline the way eligibility and benefits, and other healthcare administrative information, is exchanged electronically. Easier, more-reliable access to this information at the point of care will reduce the amount of time providers spend on administration by improving the accuracy of claims submitted and providing enhanced information on patient financial responsibility.

What Do The CORE Phase I Operating Rules Address?

The CORE Phase I rules build upon the HIPAA 270/271 transactions for eligibility and benefits as well as other standards. They address the following information:

System connectivity safe harbor standard (HTTP/S)
Standard inquiry acknowledgements
Maximum response times (batch and real-time)
Minimum hours a system must be available (system availability)
Standard 270/271 companion guide flow and format
Data content: service type codes and patient financial responsibility

Did CORE Build A Database?

No. CORE is solely focused on developing operating rules that will guide the exchange of healthcare administrative data, including eligibility and benefits information, for organizations that become CORE-certified. In practical terms, this exchange will happen through existing infrastructure, such as clearinghouses or direct from provider to health plan. Thus, participating payers will continue to maintain their own eligibility and benefit databases. Providers will use the vendor system of their choice to request and receive information.

How Do The CORE Phase I Rules Work?

Operating rules typically do not specify technology or tools that must be used in communicating information; rather they govern how that information is exchanged. Any entity that agrees to follow the CORE Phase I operating rules will be able to provide the eligibility and benefits data as outlined in the CORE Phase I rules. Thus, healthcare providers will select the technology system of their choice and utilize that system as the connecting point for routing their eligibility and benefits inquiries to payers with whom they have trading partner relationships. Given this, the more payers, vendors, providers, and others who become CORE-certified will enhance the benefits the industry can gain from the adoption of the CORE Phase I Rules.

The use of the CORE operating rules is voluntary. Stakeholder entities that wish to adopt the rules are required to sign a Pledge committing them to ensure that their IT systems can perform according to the CORE rules. A CORE-authorized testing vendor will certify that each entity’s system(s) complies with the CORE rules.

Once an entity obtains its respective CORE Seal, each entity can market itself as CORE-certified or a CORE endorser. Any entity that agrees to follow the CORE operating rules will be able to exchange eligibility and benefits information outlined in the rules.

How Were The CORE Phase I Rules Created?

The CORE Phase I rules-development process took place from January 2005 to March 2006.

CORE's Rules, Technical and Policy Work Groups created and refined draft rules over several months and presented them to the CORE Steering Committee for approval. The CORE Steering Committee reviewed and approved the draft rules, then sent them to the full CORE body for vote in February 2006. The CORE voting membership approved the rules in March 2006 with an official vote.

The CAQH Board of Directors, which is made up of CEO’s from many of the nation’s leading health plans, issued a statement of endorsement for the CORE Phase I rules in April 2006.

Why Are The CORE Phase I Rules Only For The Eligibility Transaction?

CAQH determined that CORE could have the most immediate impact by focusing on improving eligibility and benefits verification in Phase I. The Phase I rules apply only to 270/271 electronic data interchange (EDI) eligibility transactions, as decided upon by the CORE membership. Later phases of CORE will include other types of transactions. Phase II of CORE will include operating rules on the 270/271 eligibility transaction and the 276/277 claims status transaction.

Are the Phase I Rules for EDI, DDE and web-based transactions?

The Phase I rules only apply to EDI. Direct data entry (DDE) and web-based transactions are not part of the Phase I scope.

Do The Rules Apply to Batch and Real-Time Processing?

Yes, the Phase I rules apply to both batch and real-time processing. However, if an entity does not offer batch processing, it can continue to offer only real-time processing and will only have to undergo testing for its real-time systems. But if an entity offers both batch and real-time processing, than both processing types have to be in compliance with the CORE rules and pass CORE certification.

Who Will Adopt And Comply With The Phase I Rules?

The CORE Phase I operating rules are for use by entities that create, use or transmit eligibility data. Adopting and complying with the CORE Phase I operating rules is voluntary. Stakeholder entities that wish to adopt the rules are required to sign the CORE 101: Pledge Version 1.0.0 committing the organization to ensure their IT system(s) can conform to the CORE rules. A CORE-authorized testing vendor will validate that the entity’s systems complies with CORE rules.

What Does It Mean To Be CORE-Certified?

Any entity that creates, transmits, or uses eligibility data is eligible to become CORE-certified. CORE-certification indicates an entity has signed the CORE Pledge and successfully completed certification testing, both of which are designed to demonstrate an entity’s compliance with all the CORE Phase I rules.

Any entity that agrees to follow the CORE operating rules will be expected to exchange eligibility and benefits information per the requirements of the CORE Phase I rules and policies, with all its trading partners. Given the requirements of the CORE Phase I rules, use of these rules by the industry will enhance the usability and content of the eligibility transaction as well as decrease administrative costs and resources. Therefore, the benefit of the CORE Phase I rules increases with each additional entity that becomes certified.

After an entity successfully completes the CORE certification process, it can market itself as CORE-certified. Please refer to CORE Phase I Certification: A Step-By-Step Process for more information about CORE certification.

Notes:

1) CORE-certification does not replace trading partner relationships.

2) We encourage small providers to consider requesting/requiring that their vendor is CORE-certified so that providers can experience the benefits that arise from the adoption of the CORE rules. However, if a provider is capable of seeking CORE-certification, we encourage them to do so.

What Does It Mean To Be A CORE Endorser?

Entities that do not create, transmit, or use eligibility data, or are small providers, are eligible to become CORE Endorsers. Endorsing organizations can demonstrate their support for the CORE mission and the Phase I rules by signing the CORE 101: Pledge Version 1.0.0 and applying for and using the CORE Phase I Endorser Seal.

CORE-endorsing organizations will participate in CORE public relations campaigns, provide feedback and input when requested to do so by CORE, and encourage their members to consider becoming CORE-certified. Please refer to the CORE Phase I CORE Endorser Seal: Application Process for information on how to obtain a CORE Phase I Endorser Seal.

How Is CORE Participation Different Than CORE Certification/Endorsement?

Only organizations that join CORE as participants may contribute to the CORE rule-making process. Entities that become CORE-certified have committed to use the rules and are allowed to market that CORE commitment, and entities that achieve CORE Endorser status support CORE’s mission and operating rules and may market that support. However, simply signing the CORE 101: Pledge Version 1.0.0 and subsequently becoming CORE-certified or a CORE Endorser does not automatically allow an organization to participate in the CORE rule-making process. See the CORE Participation Application for further information.

What Entities Are CORE-Certified Or CORE-Endorsers?

See the CORE Certification/Endorsement list for further information.

For CORE-Certified Vendors, How Can I Find Out What Product Is Certified?

See the CORE Certification/Endorsement list for further information, which specifically lists vendor product certification.

How Do I Become A CORE Participant?

CORE participation is open to any interested healthcare stakeholder, including health plans, providers, technology companies, government entities, trade associations, vendors and standard-setting organizations. See CORE Participating Organizations for a list of current participants. Please refer to the CORE Participation Application for information on how to become a CORE participant.

How Do I Become CORE-Certified?

Please refer to CORE Phase I Certification: A Step-By-Step Process for more information.

How Do I Become A CORE-Endorser?

Please refer to CORE Phase I CORE Endorser Seal: Application Process for more information.

If None Of My Trading Partners Are CORE-Certified, But My Organization Is, Do We Have To Comply With The CORE Rules?

CORE certification is voluntary. No organization is required to adopt the CORE rules. However, if your organization becomes CORE-certified, your organization is expected to comply with the CORE rules in all its eligibility transactions. Specifically, non-CORE-certified providers that work with your organization can lodge a complaint about CORE rules non-compliance with CAQH, while non-certified health plans and vendors cannot. See the CORE 105: Enforcement Policy Version 1.0.0 for more information.

Does My Organization Have To Return Eligibility Information If The Requestor Of The Information Does Not Meet My Organization's Requirements For Patient Identification?

No: Moreover, in Phase I, CORE does not address/include any rules for patient identification requirements.

Do the CORE Phase I Operating Rules apply when an entity is providing eligibility transaction services as an Application Service Provider (ASP) for providers and translates the non-standard eligibility transactions in a proprietary format into the standard transaction or vice versa as provided for in §162.930 Additional rules for healthcare clearinghouses of the HIPAA Transactions final rule?

Yes. Since the CORE Phase I Rules build on the HIPAA 270/271 transactions, the ASP vendor is acting as a health care clearinghouse business associate for a provider would undergo CORE certification testing as a Provider Vendor and/or Clearinghouse. In this case, the ASP vendor would have to comply with all of the CORE Phase I Rules in order to become CORE certified.

What Version Of The CORE Rules, CORE Test Suite, CORE Test Suite Supplement And CORE Master Test Bed Data Should I Be Using?

Your organization should use the version of the CORE Rules and Policies, Test Suite, Test Suite Supplement, and Master Test Bed Data for which it is certified. Currently there is only one version (Phase I) of the CORE rules and test suite (Versions 1.0.0); the most current Test Suite Supplement version is 1.0.1.

How Will The CORE Phase I Rules Be Updated?

CORE rules changes are categorized as major (for example, additional requirements or clarifications to a rule) or minor (for example, changes due to a typo or grammatical error). Minor modifications will not require re-certification. Major changes (e.g., a new phase) will require completing the applicable CORE certification or endorsement process and payment of all applicable fees.

Major changes will only occur after the CORE membership approves, by vote, major modifications, changes, or deletions to CORE rules. Only one major modification will be permitted in the first year of Phase I. Generally, CORE rules will not be amended between CORE rule versions unless government regulations are issued that impact the rules or problems arise upon implementation which need to be addressed. In this scenario, adoption of the modified rule(s) by CORE participants will be within a reasonable timeframe, but will acknowledge/comply with federal mandates.

See the CORE 102: Certification Policy Version 1.0.0 for more information.

Do All CORE Member Participants Contract With One Another (Become Trading Partners) By Participating In CORE?

No. Use of and participation in CORE is non-exclusive. CORE will not be involved in trading partner relationships, will not dictate relationships between trading partners, and CORE will not determine with whom and how health plans conduct their vendor contracting.

II. Policy FAQs - 101: Pledge

Why Sign The Pledge To Become CORE-Certified or a CORE-Endorser?

Signing the CORE 101: Pledge Version 1.0.0 is the first step in the CORE certification and endorsement process. By signing the CORE Pledge, an entity agrees to be publicly recognized as a supporter of CORE’s mission and operating rules. In addition, if seeking certification, the entity commits to adopt, implement and comply with the CORE operating rules and to use reasonable efforts to encourage its trading partners to use the CORE operating rules. An entity must complete CORE certification testing within 180 days of signing the CORE Pledge.

Is The Pledge Binding?

Organizations may sign and withdraw from the CORE 101: Pledge Version 1.0.0 at any time.

What Does It Mean To Have 180 Days To Complete Certification?

After signing the CORE Phase I Pledge, an entity has 180 days to complete CORE-certification testing by working with a CORE-authorized testing vendor of its choice and submit its CORE certification application to CAQH (per the CORE Phase I Certification Policy, CAQH has 30 business days to process the application). It is expected that entities will take all necessary steps into consideration when determining their work plan for becoming CORE certified.

II. Policy FAQs - 102: Certification Policy

What is the Cost of the CORE-Certification Seal and Certification Testing?

Entities successfully completing CORE certification testing will be charged a fee based on their net annual revenues to obtain an appropriate CORE-Certification Seal. CORE-Certification Seal fees are as follows:

Health Plans:

Below $75 million in net annual revenue: $4,000 fee
$75 million and above in net annual revenue: $6,000 fee

Below $75 million in net annual revenue: $4,000 fee
$75 million and above in net annual revenue: $6,000 fee

Up to $1 billion in net annual revenue: $500 fee
$1 billion and above in net annual revenue: $1,500 fee

No fee

There is no charge to Federal or State government entities to receive the CORE- Certification Seal.
There is no charge to CAQH member plans to receive the CORE-Certification Seal.
This fee is a one-time cost for Phase I certification, unless an entity becomes de-certified or if major changes to the rules are approved by a full CORE vote (Reference CORE 102: Eligibility and Benefits Certification Policy).
CORE-authorized certification testing vendors also may charge a fee related to CORE certification testing, as determined by each of the authorized vendors. Please discuss this with your CORE-authorized testing vendor.

What Is The Cost For A Medicare Or Medicaid Plan to Become Certified?

CAQH does not charge government entities to participate in CORE or to become CORE certified. Thus, there is no fee for Medicaid or Medicare plans to apply for the certification Seal; that said, the CORE-authorized testing vendors may charge the Medicaids or Medicare for using their CORE certification testing product.

Will My Organization Have To Complete The CORE Certification/Endorsement Process For Each Phase of CORE Rules?

Yes, if your organization decides to continue to support CORE-certification. CORE certification/endorsement is specific to each phase of CORE rules, e.g., Phase II, Phase III. Major modifications to the CORE Phase I rules (allowable once in the first year through a vote by the entire CORE membership) would result in a new phase of CORE rules. All entities that wish to be certified for that new phase (whether CORE-certified or not) will need to complete the CORE certification process and pay all applicable fees. See the CORE 102: Certification Policy Version 1.0.0 for more information.

Why Would An Entity Have To Re-certify for Phase I?

CORE Phase I re-certification will be required if an entity’s CORE Phase I Seal is revoked. Such a revocation would come about as a result of a validated complaint of non-compliance following CORE’s review of a submission of a Request for Review of Possible Non-Compliance Form. See the CORE 105: Enforcement Policy Version 1.0.0 for more information.

The only exception to CORE’s re-certification policy is vendors. If a vendor issues an upgraded/new version of their CORE-certified product, and this product includes a major change to the eligibility aspect of the product, the vendor will need to undergo re-certification for that product.

What Is The CORE HIPAA Attestation Form, And Who Has To Sign It?

All organizations that operate under the CORE Phase I rules are assumed to be HIPAA-compliant. Organizations intending to operate under the CORE rules will be asked to attest to this fact when applying for a CORE Seal by completing and signing the CORE HIPAA Attestation Form. The form must be signed by an appropriate senior-level executive. Vendors and other non-covered entities will have to sign the form as well, demonstrating that they support a compliant 270/271 transaction. CORE will not test for HIPAA compliance.

My Company Has Many Subsidiaries. Do They All Have To Be Compliant With The Phase I Rules?

A parent corporation seeking certification will not be certified unless all subsidiaries of the corporation are compliant with CORE Phase I rules. Otherwise, each subsidiary of the parent must individually seek certification and thus would receive its own CORE Phase I Seal.

Vendors must complete the CORE certification process and pay the required fee for each product they want to be CORE certified. For vendors, CORE-certification will apply only to vendor products rather than corporate entities.

What Happens If A CORE-Certified Organization Buys An Entity That Is Not CORE-Certified?

If a CORE-certified entity acquires an entity that is not CORE-certified, the acquiring parent company will only be allowed to remain CORE-certified if the acquired company is not involved in eligibility transactions and its business is not applicable to the CORE operating rules. However, if the acquired company has business that is applicable to the CORE operating rules, the acquiring parent company will have to seek a new CORE-certification Seal or apply for a health plan exemption, if appropriate. Previously certified separate subsidiaries may retain their existing certification.

What Happens If A Non-CORE Certified Entity Buys A CORE-Certified Entity?

If a CORE-certified entity is acquired by an entity that is not CORE-certified, that new company willonly be allowed to remain CORE-certified if the acquired company is the only business that is applicable to the CORE operating rules. If this is not the case, then the newly merged company will be required to seek certification. If the acquired company continues to operate as a separate subsidiary, it may retain its CORE-certification.

Can I Put The Seal Up On My Organization’s Website?

Yes. After processing your CORE Endorsement or Certification application, CAQH will send you an electronic copy of your CORE Seal that you can use in your communication tools/materials. Please refer to the CORE Marketing Guidelines for more information.

What Items Do Providers Need To Accomplish To Become CORE-Certified?

CORE expects only large providers to become CORE certified. Providers who wish to become CORE-certified must comply with all of the Phase I CORE rules that apply to providers and complete the CORE certification tests for each rule that applies to providers. (See the CORE Test Suite for a list of the provider certification tests.) Providers can satisfy the certification requirements by either using a provider/vendor's solution or a combination of a provider/vendor's solution in addition to some in-house work.

What Is The Level of Effort, Time Commitment and Length of Time For Becoming CORE-Certified?

The effort level/time commitment/length of time will depend upon how many adjustments an organization needs to make to its IT system(s) in order to become compliant with the CORE Phase I rules and thus be prepared to complete CORE certification testing. If an entity completes a thorough gap analysis and makes the appropriate IT changes before beginning CORE certification testing, the certification testing period could be anywhere from 20-60 days, depending on the resources the entity puts toward the certification testing effort. Please see the CORE PhaseI Certification Step-by-Step for an overview of all steps required to be completed to obtain a Seal. Please contact CAQH if you would like to be put in touch with others who have completed or began certification testing.

What Is The Necessary Paperwork Required to Submit with the Seal Certification Application?

Seal Application Form
Seal fee (if applicable)
Certification testing results (not applicable to Endorsers)
HIPAA Attestation Form (not applicable to Endorsers)
Health Plan IT Exemption Form (if applicable)

Once The Required Paperwork for CORE Certification Has Been Submitted to CAQH, How Long Does It Take To Receive The CORE Seal?

Per the CORE certification policy, CAQH will complete its processing of the paperwork in no more than 30 business days. All entities will be informed of their queue status at the time of submission if CAQH has a larger number of applications to process.

How Will The Certification Process Be Affected For Both A Clearinghouse/Vendor And A Health Plan/Provider If The Clearinghouse/Vendor Acts On Behalf Of the Health Plan/Provider For Some Rules?

Any health plan seeking CORE-certification must undergo certification testing for all functions it offers that is covered by the CORE Phase I rules. When a health plan outsources some functions to a clearinghouse, both the health plan and its clearinghouse will need to undergo testing for the functions each provides in order for the health plan to become CORE-certified.

In this case, a health plan (and/or provider) can chose the "Not Applicable" choice for any certification testing requirement provided they upload a rationale statement explaining why a certain test script is applicable. For example, if a vendor offers connectivity services for a health plan, the rationale statement would include that vendor X will be providing this functionality on their behalf, so they do not need to undergo testing. Vendor X must then undergo certification testing for this function as a health plan clearinghouse. Both the health plan and the vendor may each test independently using different CORE-authorized certification testing vendors.

Based Off Of The Above Question, Will The Two Entities Have To Use The Same CORE-Authorized Certification Testing Vendor? If Not, Can Test Data Or Results Be Exchanged Between The Two Testing Vendors

No. Both the organization seeking CORE-certification, including the entity that has outsourced some functions, may undergo CORE -certification testing with different testing vendors.When an entity outsources some or all of the capabilities required by the CORE Phase I rules, it can choose the "Not Applicable" choice for any certification testing requirement provided they upload a rationale statement explaining why they do not feel a certain test script is applicable. In this case, the entity must indicate which entity is performing that function on their behalf. For example, if a vendor offers connectivity services for a health plan, the rationale statement would include that vendor X will be providing this functionality on their behalf, so they do not need to undergo testing. Vendor X must then undergo certification testing for this function as a health plan clearinghouse. Both the health plan and the vendor may each test independently using different CORE-authorized certification testing vendors.

II. Policy FAQs - 103: Exemption Policy

What Is The CORE Exemption Policy?

The CORE 103: Exemption Policy Version 1.0.0 allows a health plan seeking CORE certification to request that a scheduled migration of an existing IT system(s), that represents up to 30 percent of a payer’s marketshare, be exempt from being CORE compliant – only if the remainder of the health plan’s IT systems are CORE compliant. The policy requires the new IT system to be CORE compliant by the end of the exemption period, which lasts for 12 months.

What Criteria Must Be Met For A Health Plan To Be Eligible For An Exemption?

Any health plan seeking the CORE Phase I Exemption must meet the following criteria:

No more than 30 percent of a health plan’s total membership can be processed by the IT system(s) to be covered by the exemption.
Migration must be scheduled for completion no later than 12 months from the date of when the health plan is granted CORE certification.

CORE 103: Exemption Policy

CORE IT Exemption Request Form

What Is The Deadline To Submit A Health Plan IT Exemption Request?

CORE Phase I certification exemptions will only be granted until December 31, 2007. All CORE-certified health plans, therefore, must be fully CORE Phase I compliant by December 31, 2008. If a CORE-certified health plan acquires another health plan that is not CORE-certified after December 31, 2007, however, it can seek additional/new IT system exemptions for its newly acquired entity. Exemptions that are due to newly acquired entities will only be granted if the same above parameters on time periods and percentage of membership are met.

II. Policy FAQs - 104: Testing Policy

Who Has To Undergo CORE Certification Testing?

All entities that create, transmit or use eligibility data seeking CORE certification will have to undergo certification testing if they want to obtain a CORE Seal. All parties essential to the success of the eligibility transaction are addressed in the CORE-certification testing process: providers, health plans, clearinghouses, and vendors. CORE-certification testing varies by stakeholder type.

Associations, medical societies and entities that do not create, transmit or use eligibility data are not eligible for CORE certification, as well as small providers. (However, we encourage small providers to consider requesting/requiring that their vendor become CORE-certified so that the provider can experience the benefits of the CORE certification.) However, such entities may demonstrate their support for CORE’s mission and operating rules by signing the CORE 101: Pledge Version 1.0.0 and applying for and using the CORE Endorser Seal.

Why Is Testing Required For CORE Certification?

CORE-certification testing is required to confirm that entities comply with all of the CORE Phase I rules. Successful completion of a stakeholder-specific testing, demonstrated through proper documentation from a CORE-authorized testing vendor, is the prerequisite for obtaining a stakeholder-specific CORE Seal.

What And Who Are CORE- Testing Vendors?

The CORE-authorized certification testing vendors are:

Edifices
Claredi, an Ingenix Division

Besides Edifecs And Claredi, Are There Any Additional Vendors Authorized by CORE To Perform CORE Certification Testing?

No.

How Much Will CORE-Certification Testing Cost?

Certification testing costs are determined by each CORE-authorized certification testing vendor and are subject to change. Click here for a list of the CORE-authorized testing vendors and links to their web pages that will list their respective certification testing fees. Separately, CAQH charges a fee for the CORE Seal.

What Do I Do With My Successful CORE Certification Testing Results?

The CORE certification testing results provided to you by the CORE-authorized certification testing vendors are required to apply for a CORE Seal. When your organization has successfully completed certification testing, submit the results to CORE, along with other required documentation, when applying for your desired CORE Seal. Please see the CORE Seal Application Form for more information.

Is Certification-Testing a One "Shot" Test Or Are There Several Iterations?

An organization can perform all or specific parts of the CORE-certification testing as many times as needed. Per the Certification Policy, the number of tests undertaken by any entity is confidential information between the entity and the CORE-authorized testing vendor.

Note, there is a CORE Enforcement Policy. Therefore, if an organization passes the certification testing, but all its systems are not compliant with the Phase I rules, providers and any other CORE-certified organization trading eligibility information with the organization can file a complaint against the organization.

II. Policy FAQs - 105: Enforcement Policy

Who Can File A Complaint?

Two types of entities may file a complaint:

Any healthcare provider that is an end-user of a CORE-certified product/service may lodge a complaint against a CORE-certified entity if the provider believes the CORE-certified entity is not complying with the CORE Phase I rules and/or policies. The complaint needs to be made by submitting a Request for Review of Possible Non-Compliance Form to CORE.
Beyond provider end-users, CORE-certified organizations involved in the alleged non-compliant transactions may file a complaint, e.g. vendors, health plans, etc.

What Happens If A Company Is CORE-Certified And Believes That A CORE-Certified Trading Partner Is Not Compliant With The CORE Rules?

CORE-certified entities are encouraged to privately resolve disputes before submitting a formal complaint of possible non-compliance. CORE enforcement is a complaint-driven process that will require documentation (electronic or paper) demonstrating multiple instances of non-compliance with the CORE Phase I rules. Please see CORE 105: Enforcement Policy Version 1.0.0 for further details.

What Happens If An Organization Becomes De-Certified?

If a CORE-certified entity is found to be in actual violation of a CORE rule(s) and the violation is not remedied per the CORE enforcement timeline, the entity’s certification will be terminated and its name removed from the CORE website. De-certified organizations are entitled to seek re-certification by completing the CORE certification process and paying all required fees again.

Is The Complaint Process Confidential?

The details of specific complaints remain confidential. Names or other identifying information will not be publicly released by CORE. This information will only be used and disclosed by CORE for its non-compliance review by the CORE Enforcement Committee.

What is the CORE Enforcement Committee?

The CORE Enforcement Committee, composed of a diverse group of CORE participants, will review verified complaints and will be responsible for providing any extension to the grace period to remediate an issue. Enforcement Committee members will be appointed by the CORE Steering Committee from nominations made by Steering Committee members and/or CORE members. In Phase I until there is an equal representation of stakeholders, or until a sufficient number of certified entities exist, CORE Subgroup and/or Work Group Chairs will serve on the Enforcement Committee.

III. Operating Rule FAQs - 150. Batch Acknowledgements

Currently My Organization’s EDI System Only Returns A 997 If The Functional Group Is Rejected. Must My System Be Changed To Comply With The CORE Acknowledgement Rule?

Yes. The CORE 150: Rule For Batch Acknowledgements Version 1.0.0 requires that the health plan or information receiver must always return a 997 Functional Acknowledgement for all functional groups, whether or not the group is rejected. This requirement allows the provider to know within a reasonable timeframe if the submitted batch of inquiries was accepted by the health plan and will be processed. Likewise, the rule also requires that the provider must always return a 997 Functional Acknowledgement for all functional groups whether or not the group is rejected, thereby allowing timely resolution of any issues.

My Organization’s EDI System Was Developed In-House And Does Not Currently Support The TA1. However, Our System Does Support The 997 For Rejected Functional Groups. Is This OK Under The CORE Rule?

No. In order to be compliant with the CORE 150: Batch Acknowledgements Rule Version 1.0.0, your organization’s system must be able to return a TA1 for an interchange that is rejected and for all rejected and/or accepted functional groups. If it is unable to do so, your organization will need to remediate the system to be compliant with the CORE rule in order to become CORE-certified.

If My Organization’s System Is Not Changed To Always Return The 997 Acknowledgements, Can My Organization Become CORE-Certified?

No. Your organization must successfully complete all of the required certification test scripts required by the CORE Test Suite to become CORE-certified. The test scripts for the CORE 150: Batch Acknowledgements Rule Version1.0.0 will test for your system’s capabilities to return the 997 acknowledgment.

The TA1 Interchange Acknowledgment is described in the HIPAA implementation guide Appendix B EDI Control Director. The note for the ISA14-I13 Acknowledgment Requested data element indicates that trading partners may mutually agree to whether or not to return the TA1. A "0" in ISA14-I13 indicates that no TA1 should be returned even for an invalid Interchange and a "1" indicates that a TA1 should always be returned, even for a valid Interchange. Does the CORE Acknowledgements Rule required that the ISA14-I13 data element not be used?

Since all of the data elements in the ISA Interchange Control Segment are mandatory in the X12 standards, the language of the CORE Acknowledgments Rules was carefully chosen. Thus the CORE Acknowledgments Rule does not say not to use the ISA14-I13 element, but rather, that CORE-certified entities are to ignore the value in this data element and must always return a TA1 in the case of an invalid ISA/IEA interchange and to not return a TA1 in the case of a valid ISA/IEA interchange regardless of the value of the ISA14-I13 data element.

In case of batch mode does my organization have to acknowledge the receipt of a batch using 997 even if the data was not sent in 270 format?

The 997 Functional Acknowledgment can be used only to acknowledge receipt, acceptance or rejection of X12 transaction sets. It is not designed to be able to report receipt and/or errors, etc. in a proprietary file format. Thus it cannot be used to acknowledge receipt of a non-X12 transaction set.

III. Operating Rule FAQs - 151: Real Time Acknowledgements

Does The Real Time Acknowledgement Rule Mean That My Organization’s System Must Always Return All Of These Types Of Acknowledgements: TA1, 997 And The 271 Response?

No. For real time inquiries, your organization’s system must return a TA1 if the interchange is rejected, a 997 if the functional group is rejected, or the 271 response, to be compliant with this rule. Thus, your organization’s system must return only one of these acknowledgements, depending on the processing results, not all three.

Can a Clearinghouse or Vendor act on behalf of a Health Plan or Provider for Real-Time Acknowledgments?

Yes. Each health plan seeking certification will have to work with its clearinghouse and/or vendor to jointly complete CORE-certification testing in order for the health plan to be awarded the CORE-Certification Seal. A clearinghouse or vendor would not be able to certify "generically" as a health plan and then transfer such certification to any health plan.

The TA1 Interchange Acknowledgment is described in the HIPAA implementation guide Appendix B EDI Control Director. The note for the ISA14-I13 Acknowledgment Requested data element indicates that trading partners may mutually agree to whether or not to return the TA1. A "0" in ISA14-I13 indicates that no TA1 should be returned even for an invalid Interchange and a "1" indicates that a TA1 should always be returned, even for a valid Interchange. Does the CORE Acknowledgements Rule required that the ISA14-I13 data element not be used?

Since all of the data elements in the ISA Interchange Control Segment are mandatory in the X12 standards, the language of the CORE Acknowledgments Rules was carefully chosen. Thus the CORE Acknowledgments Rule does not say not to use the ISA14-I13 element, but rather, that CORE-certified entities are to ignore the value in this data element and must always return a TA1 in the case of an invalid ISA/IEA interchange and to not return a TA1 in the case of a valid ISA/IEA interchange regardless of the value of the ISA14-I13 data element.

Is an acknowledgement necessary if the user sends eligibility data in a proprietary (not a 270) format in a real-time mode?

Good business practices for electronic message exchange encourage all senders and receivers to appropriately acknowledge receipt and either acceptance/rejection and errors found in any message. That said, the CORE Phase I rules are focused on the conduct of the HIPAA-named X12 270/271 transaction sets, and the CORE rules are focused on the X12 as well. Thus, the CORE rule only addresses the use of the X12 standard acknowledgements (TA1, 997) and when to use them when conducting the 270/271 transaction sets. Additionally, in order to become CORE-certified, an entity is required to attest to its compliance with HIPAA, which requires the use of the appropriate X12 implementation guides.

Are all CORE rules with regards to Acknowledgement only applicable to scenarios where my organization receives data in a 270 format.

Please see FAQ #68.

III. Operating Rule FAQs - 152: Companion Guide Rule

Why Was The CORE 152: Companion Guide Rule Version 1.0.0 Created?

Currently health plans have independently created companion guides that vary in format and structure. Since such variance can be confusing to trading partners/providers, CORE developed this 270/271 Companion Guide template in conjunction with WEDI in 2003, with input from multiple health plans, system vendors, provider representatives and healthcare/HIPAA industry experts. The template organizes information into several simple sections and provides for a common information flow and format, while at the same time giving health plans the flexibility to tailor the document to meet their particular needs. The template covers a broad range of HIPAA-adopted transaction sets and is not specific to any one of them.

This Companion Guide template was adapted from the CAQH/WEDI Best Practices Companion Guide Template.

Does This CORE Rule Require A Change To All of My Current Companion Guide Documents For the 837 claims?

No. Similar to the other Phase I rules, the scope of the CORE 152: Companion Guide Rule Version 1.0.0 is limited to the 270/271 eligibility and inquiry response transactions.

Will All Of The Detailed Content Of My Organization’s 270/271 Companion Guide Be Analyzed And Evaluated For CORE Certification Testing?

No. Your organization is only required to submit to the authorized testing vendor 1) the Guide’s table of contents and 2) a page showing your organization’s requirements for the presentation of segments, data elements and codes. Your selected CORE-authorized certification testing vendor will assess these documents to determine that your companion guide conforms to the CORE required flow and format.

III. Operating Rule FAQs - 153: Connectivity Rule

How Did CORE Decide That HTTP/S Is Secure And Reliable Enough To Protect The Delivery Of Healthcare Information Over The Internet?

CORE solicited input on this topic from its Technical Work Group members and experts within healthcare and other industries, such as financial services. Based on this input, including the information that other healthcare industry projects, such as the Markle Foundation’s Connecting for Health project and the CMS Nationwide Health Information Network architecture prototypes, are using HTTP/S over the Internet, CORE determined that HTTP/S is an appropriate choice as the baseline standard for delivery of healthcare information. Email CORE at CORE@caqh.org for more background information.

May payers support other versions of HTTPS as well as v1.1?

Yes. Payers may support other versions, but they must support HTTPS 1.1 in order to achieve CORE certification. The intent of the CORE 153: Connectivity Rule Version 1.0.0 is to provide a safe harbor that application vendors can develop towards without needing to get detailed information from every potential payer with whom they would like to connect.

Is There A Required Format For The Authorization, Date/Time, And Payload ID To Be Sent In The HTTP Message?

No. CORE decided not to require a format for these data elements for Phase I. However, CORE does plan to require a particular format for sending these data elements in later Phases, and will be seeking industry input on the exact format. Please speak with your CORE-authorized certification testing vendor on how they will work with you on CORE certification testing given your organization’s current HTTP format requirements and those used by certification testing vendor.

Is An Implementation Approach That Uses SOAP 1.1 Or 1.2, With Or Without Attachments, Running On Top Of HTTP/S 1.1, Compliant With The CORE Phase I Connectivity Rule?

Yes. SOAP (Simple Object Access Protocol) is an XML messaging specification that describes a message format. When implementing SOAP 1.1. or 1.2, with or without attachments, over HTTP/S 1.1, the sender uses the HTTP POST functionality to send the SOAP message. In this case, because the SOAP message uses the Hypertext Transfer Protocol (HTTP) as the underlying transport, an organization may elect to use SOAP 1.1 or 1.2, with or without attachments, and still be in compliance with the CORE Phase I Connectivity Rule.

The CORE Phase I Connectivity Rule requires in its conformance language that Information Sources publish their detailed message format specifications in their publicly available Companion Guide. Therefore, any entity using SOAP would need to publish their detailed message format specifications in order to be compliant with the CORE Phase I rules.

See the CORE website (www.caqh.org) for copies of detailed Connectivity specifications that have been submitted by CORE participants as examples and information about the various approaches/options currently used for HTTP/S 1.1 message formats.

If Implementing SOAP 1.1 With Attachments Running On Top Of HTTP/S Is Compliant, How Would An Entity Electing This Implementation Approach Satisfy The Certification Testing Requirements Of The Rule?

When testing with a CORE-authorized certification testing vendor check the N/A (not applicable) box for the detailed certification testing script(s) that do not apply when using SOAP (e.g. the 403 error messages tested under the Connectivity Test Script #2 because SOAP requires other types of error messages). As with all the Phase I Test Scripts, if you check N/A for a Test Script you will need to indicate to the testing vendor, in writing, your rationale for why the Test Script does not apply to you. In this case, you would indicate that you are using SOAP over HTTP/S to transport the X12 eligibility transactions.

Will All CORE-Authorized Certification Testing Vendors Use The Same Test Scripts And Same Detailed Connectivity Method To Test The Connectivity Rule?

For every rule, including the Connectivity Rule, each CORE-authorized Certification Testing Vendor will use the same Test Scripts by stakeholder. Additionally, each CORE-certified entity will be responsible for being in compliance with the rules, understanding that not all aspects of rules compliance are tested during CORE certification testing, e.g. maintaining system availability. Because the CORE-authorized certification testing vendors each operate a little differently with regard to how they connect to their clients, they may use different approaches to test for the detailed CORE Connectivity Test Scripts. The CORE certification testing vendor you select to work with to conduct your CORE certification testing will provide your organization with the details necessary to complete the CORE Connectivity Rule certification tests.

My Organization’s Security Procedures Require That Clients Use A Digital Certificate To Identify Themselves. Under CORE Rules, Can We Mandate That They Use The Certificate Method?

Yes. CORE requires that entities use a User ID/Password to authenticate the sender at a minimum. If your organization’s policies require a higher level of security, CORE Phase I certification/participation does not prevent you from implementing additional security mechanisms. Note, these additional mechanisms, like any other additional requirements you have beyond the CORE rules, will not be tested by the CORE-authorized certification testing vendors as part of CORE certification testing.

What Is The Recommended Method For Allowing Entities To Receive Another Entity's Root Public Digital Certificate?

CORE does not make recommendations for this process. Please discuss this with your individual trading partners.

How Will Future Versions Of HTTP/S Impact This Standard?

CORE continually reviews its rules for usability and appropriateness to ensure that they are compatible with current technology. Necessary changes to CORE Rules will be made through the established CORE rule writing processes.

Batch Processing: How Long Must A Responder Maintain Response Files On Their System?

CORE recognizes that every organization has its own record-retention policies and, therefore, does not mandate a strict requirement for retention of response files. However, CORE recommends that a copy of responses be kept available for a minimum of six months after they are ready in order to support the process of discovery in the case of a complaint against a CORE certified entity regarding CORE compliance.

Batch Processing: Why Not FTP Or sFTP For Batch Transactions Instead of HTTP/S?

HTTP/S is robust and has a proven track record with batch transactions. The benefits of a single communication standard were a compelling reason to mandate its availability. Information sources that allow FTP and/or sFTP for batch transactions still can support those transmission methods.

Batch Processing: Can CORE Provide More Specificity For The Actual HTTP Messages To Use In The Batch Request And Response?

CORE does not mandate the batch request/response flow. An example of how it could be implemented is below. Please speak with your CORE-authorized certification testing vendor on how they will work with you on this issue during testing. See below for an example, or click on this link to view more examples.

Information to put behind the link for an example:
1) Client (provider or their intermediary) sends an HTTPS POST message with a data content of: something like:
   <Message>
     <Operation>ListBatchResponses</Operation>
     <FilePattern>*.271</FilePattern>
   </Message>
2) Server (payer or their intermediary) responds with a data content of something like:
<Message>
   <FileList>
     <File>20060208_12345.271</File>
     <File>20060208_543627.271</File>
   </FileList> </Message>
3) Client decides which file to retrieve and sends a request like:
   <Message>
     <Operation>GetFile</Operation>
     <File>20060208_543627.271</File>
   </Message>
4) and the server sends it back in something like:
   <Message>
     <File>20060208_543627.271</File>
     <CDATA>ISA*00*.....................IEA*1*12345~</CDATA>
   </Message>

5) The client could then request other files or decide they are done.

Batch Processing: My Organization’s System Can Provide A 997 Back On Batch Transactions Within 20 Seconds. Why Cannot My Organization Just Send The 997 In The Response To The Submission To Increase Efficiency?

For consistency and ease of development, CORE decided that it was important to have a single standard. Based on that decision, and the fact that many batch processing information sources cannot commit to having the 997 available in 20 seconds, CORE elected to mandate that the 997 not be provided in the HTTP response.

Batch Processing: Will A Receiver Be Able To Re-Pickup a File if Needed?

CORE does not specify this, but recommends that information sources allow for re-pickup for at least one month after the initial pickup of a batch response file. Please refer to your own internal policies.

Batch Processing: Will There Be A Maximum Number Of Response Files That A Receiver Will Be Able To Pickup In One Session Due To Payload Sizes?

CORE does not set a maximum on the number of response files that a receiver will be able to pickup. Information sources should create policies to specify the limit to the number or size of files that can be picked up and document those policies in their companion guide.

Batch Processing: Will A Payload Be Able To Contain Different Types Of Responses?

CORE does not specify the different types of responses a payload can contain. Please refer to your own internal policie

Batch processing: How is a batch reply matched with its request without downloading each file and parsing it? Are reply filenames to somehow encode the payload ID?

CORE does not specify any convention for linking the batch response to the batch request beyond the X12 requirements. Some information sources may provide this information as part of the file name, or as meta-data included in a file listing, and this should be documented in the information source’s Companion Guide.

Batch processing: Is there a one-to-one correspondence between batch input transmissions and batch output files?

CORE does not specify the content of the physical file returned by the batch processing. Information sources should specify in their Companion Guide the expected contents of the batch files.

Batch processing: Must a batch reply file contain replies for every request in a batch request? Is it an error to omit some?

CORE does not specify the detailed data content of the 271 response, which is left to the appropriate implementation guide. According to the X12 guide, there is no requirement for a batch 271 to respond to every request included in a batch 270. For the HIPAA-mandated X12 270/271 transaction, details on linking the batch responses to the batch request are described in sections 1.3.3 Business Uses and 1.3.6 Information Linkage.

Batch processing: Must a batch reply file contain the replies in the same order as they appeared in the request?

CORE does not specify the detailed data content of the 271 response, which is left to the appropriate implementation guide. In the X12 usage, there is no requirement to order responses according to the batch request order. See section 1.3.6 Information Linkage of the HIPAA implementation guide for the 270/271 for more information on linking batch responses to the corresponding request.

For The Purposes Of The Re-Transmission, What Is The Definition Of A Duplicate Transaction?

CORE does not define a duplicate transmission. Please refer to your own internal policies.

What Happens If A Provider's System Continues To Send Duplicate Transactions Within 15 Minutes?

CORE does not define the recourse for information sources in this case.

Why Does This Rule Only Apply To The Information Source? Doesn’t The Information Receiver Need To Comply With Certain Items?

There is nothing in the CORE Connectivity Rule contents that can be tested and certified through use of a testing vendor for information receivers. With regards to testing, all of the capabilities defined in this rule to be tested are related to the information source.

Is There A Time Period For How Long The Source Needs To Maintain This Tracking Information?

CORE recognizes that every organization has its own record-retention policies and does not mandate a strict requirement for retention of tracking information. To support ongoing tracking of response times and performance measurement, CORE recommends that entities keep this information for at least 18 months, if that is in accord with the organization’s existing policies.

Where Can I Get More Information About Exchanging Data In HTTP/S?

Many organizations and regional healthcare trading partners have adopted detailed specifications for exchanging this information in HTTP/S. These include:

Availity (in wide use in Florida) http://www.availity.com
HTP (used by UHIN and other organizations) http://www2.htp-inc.com/
HTS (the format used by NEHEN in New England) www.nehen.org
MN HIPAA Collaborative (Minnesota) http://www.mnhipaacollab.org/
Other examples submitting to CAQH (www.caqh.org) – CAQH has created the Phase I HTTPS Examples document based on these submissions.

Back to Top

Can My Vendor Offer HTTP/S on My Behalf?

The CORE Phase I rules do not require that an entity (provider or health plan) implement the technology directly into their own data center. The rules implicitly acknowledge that both providers and health plans will use technology solutions provided by vendors to accomplish all that must be done. That said, the CORE rules also do not require a "direct" connect - meaning that providers connect directly to the health plan's data center and do not connect to any intermediary, such as a clearinghouse.

Thus, the CORE rules do not require any specific architecture, but rather specifies the capabilities that need to be enabled by any CORE-certified entity.

An entity, working with or without their vendor providing the HTTP/S connectivity capability, will have to demonstrate compliance with the CORE Connectivity Rule through the certification testing.

CAQH encourages payers who are using vendors to review their compliance to make sure that they are fully in compliance with both CORE and HIPAA - and particularly the clause in HIPAA that says payers cannot charge more than the cost of telecommunications for handling the connectivity.

What Is The Payload Identifier (ID)?

Within the context of the CORE Connectivity Rule the Payload ID is an identifier that uniquely identifies the X12 interchange(s) transported by the HTTP message and is used to allow submitters and information receivers to easily reconcile their records of submissions and responses. CORE elected to use an ID outside of the X12 message for this purpose because many information receivers' systems separate the HTTP communication processing from the X12 message processing. The payload ID is generated and sent by the entity that initiates the HTTP communication session. Usually this is the provider or clearinghouse that is sending the request to the health plan or other information source. It is one of the CORE-required HTTP message parameters (along with authorization information and date and time stamps) and it must be unique to each HTTP message and the X12 interchange(s) being transported by the HTTP message instance.

All CORE-certified entities are required to capture, log and be able to report on each HTTP message transporting an X12 interchange and to be able to link the X12 interchange to a specific HTTP message instance. The Payload ID (Message Body identifier) is the mechanism used to associate a given instance of an X12 interchange to the HTTP message instance.

Is The Payload ID Outside The X12 Interchange?

Yes.

Is The Payload ID Generated And Sent By The Submitter?

Yes, it is generated by the system that creates the HTTP request message. Typically this is the provider or clearinghouse working on the provider's behalf.

Does The Responder Need To Return The Payload ID On The Response?

The payload ID does not get carried through to the content of the 271 response. In the real time usage, the submitter can tie the 271 response to the Payload ID because the 271 response in the real time mode is passed within the same communication session used to send the Payload ID and the requesting 270. In the batch usage, the acknowledging response to the submission is sufficient to record that a particular Payload was successfully delivered.

Is The Payload ID Unique For Each Transaction Sent By The Submitter?

No. It is unique to each HTTP message instance and the payload being transported by HTTP.

What Should Be Expected From Trading Partners Regarding The Payload ID’s, And How It Should Be Used?

An entity should expect to receive a long, possibly alphanumeric, ID from your trading partners and you should be able to store that ID and associate it with each X12 real time message you process from your trading partner through the HTTP communication system you support. From a technical perspective, most submitters will use some sort of globally unique ID or universally unique ID (GUID or UUID) as their payload ID so receivers should allocate a data field that can contain at a minimum the 128 bits required to store a GUID/UUID. Phase I does not specify the detailed requirements in this are, but Phase II may.

For Batch Response Pick-Up, Does CORE Intend For This To Be A Programmatic Interface Or A Human Interface?

Under the CORE rules, information sources must provide a programmatic interface to allow an automated task whereby the provider's system requests the batch of 271 responses be transferred to the provider's system without a need for human intervention.

Can A Clearinghouse Or Vendor Act On Behalf Of A Health Plan For The Connectivity Rule?

Yes. Each health plan seeking certification would have to work with its clearinghouse and/or vendor to jointly complete CORE-certification testing in order for the health plan to be awarded the CORE-Certification Seal. A clearinghouse or vendor would not be able to certify "generically" as a health plan and then transfer such certification to any health plan.

Can my organization run a 270/271 transaction on XML?

If the question is asking if an XML-based eligibility inquiry and response equivalent to the X12 270/271 can be used in replace of a ASCII character-based 270/271, the answer is no.

However, if the question is asking if your organization accepts the 270 into its EDI system either directly from a provider or through a clearinghouse, and then once received, converts it into any format they wish for internal processing, e.g., XML or some other proprietary format, the answer is yes.

Also, for the purposes of the Connectivity Rule, organizations can specify an XML "wrapper" around the 270 and 271 transactions.

III. Operating Rule FAQs - 154: 270/271 Data Content Rule

Does The CORE Rule Require A DTP Segment In The 270 Inquiry At Either The Subscriber Or Dependent Levels Or Both?

No. The CORE rule does not require that a DTP segment be used. The CORE rule only specifies that when the DTP is used with Code "307," at either the subscriber or dependent levels, the provider is requesting the health plan to specify the date when the health plan coverage begins.

Does The CORE Rule Require A DTP Segment In The EQ Loop In A 270 Inquiry?

No. The CORE rule does not require that a DTP segment be used in the EQ loop. The CORE rule only specifies that when the DTP is used with Code "307" in the EQ loop, the provider is requesting the health plan to indicate if the effective date of coverage for that specific service type code is different than the begin date of the health plan coverage.

What Does "Health Plan Name" Mean In The Data Content Rule?

The "health plan name" is a specific product name for an insurance plan assigned to the health plan covering the individual who is the subject of the inquiry/response. The name is distinct from a type of health plan code that would be returned in the EB04-1336 Insurance Type Code. The health plan name is simply an alphanumeric description of the plan coverage which is assigned by the insurer.

Does The CORE Rule Allow An Inquiry About Eligibility Dates In The Past Or Future?

Yes. A provider may submit an inquiry asking about eligibility for a health plan for either past or future dates. However, a health plan is not required by the CORE rule to report eligibility dates older than 12 months in the past or beyond the end of the current month. When the health plan does not support such an inquiry, it is required to return the 271 with the appropriate AAA segment indicating the dates of service requested are outside of its reporting period.

How Does CORE Handle Eligibility Dates?

The 270 eligibility inquiry may request a benefit coverage date 12 months in the past or up to the end of the current month. If the inquiry is outside of this date range and the health plan (or information source) does not support eligibility inquiries outside of this date range, the 271 response must include the AAA segment with code "62" Date of Service Not Within Allowable Inquiry Period in the AAA03-901 Reject Reason Code data element.

Note, there are no guarantees under CORE that a response to an eligibility inquiry is final.

Is The Begin Date The Date When Coverage Starts Or When A Patient Was Enrolled?

The use of code 307 in the 271 response required by CORE means the date on which health plan coverage starts – and not the date of enrollment.

Does A 271 Response That Conforms To The CORE 154: 270/271 Data Content Rule Version1.0.0 Guarantee That The Health Plan Will Pay A Claim Submitted Covering The Same Individual?

No. A 271 response from a health plan does not guarantee that the health plan will reimburse the provider for health services if a claim is submitted.

When A Plan Has Global Deductibles, Can A Health Plan Satisfy The CORE 154: 270/271 Data Content Rule Version1.0.0 To Report Deductibles By Returning A Deductible Amount Applicable Globally To The Health Plan Only On The EB Segment With Service Type Code 30?

Yes. Many health plans have a single deductible that applies to all benefits provided under that health plan. When this is the situation, a health plan should return a deductible amount only on the EB segment with Service Type Code 30.

The CORE 154: 270/271 Data Content Rule Version 1.0.0 requires the use of code "C" Deductible in EB01-1390 Eligibility or Benefit Information data element and use of EB07-782 Monetary Amount to indicate the dollar amount of the deductible for the type of service specified in EB03-1365 service type code.

Since Service Type Code 30 is defined to mean health plan benefit coverage, this is the service type code that must be used when returning a global or universal deductible amount that applies to the health plan. The CORE rule also states that when a deductible does not apply to a particular benefit (service type), the EB segment with code "C" in EB01 should not be returned.

Example 1 below shows a portion of the 271 response in which the health plan has only one deductible which is applicable to all benefits provided.

Example 1: Active Health Plan Coverage which includes all CORE-required service types and a $300 global deductible

DTP307D8*20060101	Health Plan Coverage Begin Date
EB1IND*30	Active Health Benefit Plan Coverage
EBCIND30*300***Y	Health Benefit Plan Coverage Deductible of $300 for in-network providers
EB1IND*1	Active Medical Care Coverage
EB1IND*33	Active Chiropractic Coverage
EB1IND*35	Active Dental Coverage
EB1IND*48	Active Inpatient Hospital Coverage
EB1IND*50	Active Outpatient Hospital Coverage
EB1IND*86	Active Emergency Services Coverage
EB1IND*88	Active Pharmacy Coverage
EB1IND*98	Active Professional Office Visit Coverage
EB1IND*AL	Active Vision Coverage
<segments not returned for any deductible variance at a service type code (benefit) level>

Example 2: Many health plans may also have both a global health plan deductible and then separate different deductibles applicable to specific pharmacy benefits.


DTP307D8*20060101	Health Plan Coverage Begin Date
EB1IND*30	Active Health Benefit Plan Coverage
EBCIND30*500***Y	Health Benefit Plan Coverage Deductible of $500 for in-network providers
EB1IND*1	Active Medical Care Coverage
EB1IND*33	Active Chiropractic Coverage
EB1IND*35	Active Dental Coverage
EB1IND*48	Active Inpatient Hospital Coverage
EB1IND*50	Active Outpatient Hospital Coverage
EB1IND*86	Active Emergency Services Coverage
EB1IND*88	Active Pharmacy Coverage
EB1IND*98	Active Professional Office Visit Coverage
EB1IND*AL	Active Vision Coverage
EBCIND88*50***Y	Separate $50 deductible for in-network Pharmacy coverage
<segments not returned for any other deductible variance for remaining CORE-required service type (benefit) levels>

If A Health Plan Chooses Not To Respond With Co-payment To One Of The Optional Codes (e.g., 35-Dental, 88-Pharmacy, Or AL- Vision), Does This Mean It Should Still Respond With Coinsurance And Deductible For These Optional Codes?

No. If your organization chooses to respond with active/inactive only, then your organization should not return any of the patient liability types. As detailed in the rule’s subsections, 2.3.1, 2.3.2 and 2.3.3, the health plan may choose not to provide the patient liability information for certain service types and instead return active/inactive information only. However, if the health plan chooses to return patient liability information, it must do so for all three required patient liability types (co-payment, co-insurance and deductible) as applicable to the product.

How Is Pre-Determination Handled?

CORE Phase I does not address pre-determination.

What Is Under The "1-Medical Care" Service Type Code?

CORE Phase I does not require subsets of codes. CORE describes Medical Care as: Medical care services to diagnose and/or treat a medical condition, illness or injury. Medical services and supplies provided by physicians and other health care professionals.

In The 2100C And 2110C Loops, DTP Segment, Element DTP02, Must An Entity Support Date Range (RD8 qualifier), Or Can An Entity Limit Its Support To Only Single Date (D8 qualifier)?

The CORE Data Content Rule Subsection 2.4 states that "The health plan or information source may alternatively return a range of dates if known using…." Thus, the CORE Rule does **not** require the health plan to return a date range, the health plan can report only a single date.

For Emergency Services, Why Was Code 86 Selected Rather Than 52?

Code 52 is specific to hospital emergency services - Code 86 is general. CORE selected Code 86 so that emergency services provided in outpatient/urgent care/walk-in facilities would be included. Code 86 is what is required to be returned in v5010 draft.

When a health plan has different deductible amounts for hospital emergency medical services they may return an additional EB segment using Service Type Code 52 Hospital-Emergency Medical in addition to the EB segment using Code 86.

Some of our older health plans do not have a separate chiropractic benefit but rather include coverage for this benefit under the physician office visit benefit. In this situation it would be inaccurate to respond to an explicit 270 inquiry about chiropractic benefit with a "not-covered" code in EB01 per the CORE 154 Data Content Rule. How can we respond to an explicit 270 inquiry for chiropractic benefit in this situation and not violate the CORE Data Content Rule?

In this situation the health plan or information source could use multiple EB segments in the 271 response to an explicit 270 code 33 inquiry. The first EB segment would be EB01 = V Cannot Process and EB03 = 33 Chiropractic. The second EB segment would be EB01 = 1 Active Coverage and EB03 = 98 Professional (Physician) Office Visit to indicate that chiropractic services in are included in the office visit benefit. Subsequent EB segments would then also be returned with the appropriate patient financial responsibility information for deductible, co-pay, co-insurance and in/out-of-network amounts if applicable. CORE Phase II will be addressing if there is alternative to this approach.

Does the Dental Service Type apply to the dental coverage supplied by a medical plan? Or the dental benefits supplied on a dental plan? Our organization currently does not receive 270 transactions for dental plans.

Your organization’s health plan offers separate stand-alone dental plans to health plan sponsors. The dental benefits are thus covered separately and are not included in the medical health plans offered by your plan. Individuals that are enrolled in the dental plans are assigned completely different member IDs from those assigned to the individual that may also be enrolled in a medical health plan. Additionally, not all plan sponsors elect to offer both medical and dental plans to their members. Thus, any 270 inquiry submitted by a provider would have to include the correct member ID (MID) and DOB.

If the MID submitted was identifying an individual enrolled in a dental plan, your plan would then return the CORE-required 271 showing that of the 9 required service types, only Code 35 Dental benefits are covered and the other service types would be returned with a "not-covered" code. Likewise, if the 270 submitted was for a MID identifying an individual enrolled in your organization’s medical health plan, the 271 response would then provide the CORE-required information for all of the service types except for Code 35 which would be returned with a "not-covered" code.

The CORE Phase I Data Content Rule Subsection 1.2 states that when a generic 270 inquiry is submitted that includes a date, CORE-certified participants are required to submit only code "307" Eligibility, and that this code is defined to mean that the submitter is requesting the date on which the health plan coverage begins. Does the CORE rule then prohibit the use of the other HIPAA-allowed codes ("435"/Admission and "472"/Services)?

The intent of the CORE Phase I Data Content rule is to provide a consistent definition for Code "307" Eligibility such that all CORE-certified entities will use and interpret this code in the same way. The CORE rule does not prohibit any entity from also using any of the other HIPAA-allowed date codes as specified in the 270/271 implementation guides. Thus, when a CORE-certified health plan or information source receives a generic 270 inquiry that uses the date code "437"/Admission, for example, it should respond with the health plan benefits information in effect for the admission date specified in the corresponding 270 inquiry as required in the CORE Phase I Data Content Rule for the.

Is the Test Script for the Data Content Rule: "Extract from a valid 271 response transaction as defined in the CORE rule the data indicating the name of the health plan covering the individual specified in the 270 eligibility inquiry," Explicitly Stated in the Data Content Rule As A Provider Requirement?

No. The requirement for receivers of the 271 to have the systems capability to display the content of the 271 is stated in the CORE Certification testing script - scripts #3, 5, 7, 9 and 11, therefore the Data Content Rule does not explicitly require this item of providers and provider vendors. However, the issue of having providers have the display capability was discussed and agreed to by the CORE membership; that this was a requirement for certification for providers and vendors of provider systems. The CORE membership felt that without requiring provider systems to display the required content, requiring the content to be provided by the health plans would not address the business need to make the information usefully available to the providers, which is why this requirement was agreed to be included in the Test Suite. In Phase II, the CORE membership will review each Phase I rule to determine if wording changes should be made. This issue will be addressed at that time.

Can A Clearinghouse Or Vendor Act On Behalf Of a Health Plan For The Data Content Rule?

Rule 154 Subsection 2.6 – are all entities required to support explicit request for each of the CORE service types? What does support mean? What if most do not apply to my organization?

The CORE Data Content rule requires all CORE-certified entities to be able to support an explicit inquiry about each of the nine required CORE service types. Support means that an entity must be able to receive and response to a 270 inquiry about only one of the CORE required service types, such as 33-Chiropractic. If the health plan does not include coverage for that specific service type (benefit), the health plan must respond with a 271 indicating that the specific service type is not covered and return all of the other information required by the CORE rule.

In the Data Content rule, can multiple service codes be displayed?

CORE rules are specific to “what” data is to be exchanged and what that data represents. Neither the CORE Rules nor the X12 270/271 Implementation Guide address the displaying of information. Therefore, how the HIS/PMS vendor chooses to “display” this information, is solely under the purview and control of these IT system vendors.

Have any other insurance companies expressed concern over the "patient responsibility" representation for coinsurance? My organization is concerned with the 90/70 type of coinsurance percentages used today (representing the % paid by the insurer) will be confusing when displayed as a 10/30 (switching to "patient responsibility representation"). Believe it is an industry standard for the coinsurance to be displayed as the % paid by the insurer. If my organization must send coinsurance as member responsibility, can we also display/send an additional coinsurance for the payer responsibility %?

The CORE Phase I Data Content Rule does not address how patient financial responsibility information is displayed by the provider's system once the 271 is received and the data extracted. Therefore, how the HIS/PMS vendor chooses to “display” this information, is solely under the purview and control of these IT system vendors. The rule only specifies that the co-insurance is returned as the percent that is the patient's responsibility, which is consistent with the proper use of the EB segment.

Actually, the rule addresses the "patient's" financial responsibility for co-pay, deductible and co-insurance, since this is the information the provider is actually seeking, not the health plan's financial responsibility.

My organization’s co-pay can be a dollar amount, a percentage, the greater of amount and percent, or the lesser the two. How would my organization designate a co-pay if it is one of the last two options stated above?

Subsection 2.3.2 of the CORE 154 Phase I Data Content Rule states that a health plan is to use Code "B" Co-payment in EB01 and to use EB07-782 Monetary Amount to express the dollar amount of co-payment that is the patient's responsibility. An example, then, of returning a $15.00 co-pay dollar amount for an office visit to an in-network provider would be:

EB*B*IND*98**TENNESSEE PCN**15*****Y

The CORE data content rule does not specify nor require a health plan to return a co-payment amount that is a percentage of some other amount, and only addresses the requirement to return the dollar amount.

III. Operating Rule FAQs - 155: Batch Response Time Rule

The Maximum Response Time For The TA1/997 Is One Hour. What Is The Maximum Response Time For HTTP Message After A File Is Dropped Off?

The maximum HTTP response time is 60 seconds. The CORE 153: Connectivity Rule Version 1.0.0 specifies this because this is specific to the telecommunications method used.

III. Operating Rule FAQs - 156: Real Time Response Time Rule

Why Measure Conformance Based On Number Of Responses Returned Within A Specified Timeframe Rather Than Average Response Time?

Averages can be skewed by outlier responses. The number of responses returned within the specified timeframe gives a better indication of the information source’s capabilities.

Is There A Standard Reporting Form For The Conformance Reporting?

No. CORE does not mandate a particular form.

If A CORE-Certified Information Source Is Communicating With A Non-CORE-Certified Information Receiver, Does The CORE-Certified Entity Have To Respond Within The Response Time Window?

Yes. Providers do not have to be certified by CORE to interact with CORE-certified payers under the CORE Rules.

What Is The Minimum Information From The X12 Transaction That Needs To Be Stored?

Can The Standard Provide A Recommendation For This Data?

CORE does not specify a minimum. However, to uniquely identify an X12 transmission, CORE recommends that entities store the ISA06, ISA08, ISA13, GS02, GS03, GS06, ST02, TRN02, and if sent in the transaction, the BHT03.

III. Operating Rule FAQs - 157: System Availability Rule

My Organization Includes System Availability Schedules In Our Companion Guide. Does This Satisfy The CORE Rule Requirements for System Availability Reporting?

Partially. CORE-certified health plans (or information sources), clearinghouses/switches or other intermediaries must publish their regularly scheduled system downtime in an appropriate manner (e.g., on websites or in companion guides). This allows the healthcare provider to better manage staffing levels. Additionally, the CORE rule outlines requirements for reporting/publishing non-routine downtimes, and unscheduled/emergency downtimes.

Does My Organization Have to Send Back An Eligibility Response If My System Is Down?

As long as your eligibility system is in compliance with the System Availability Rule, then it is not required to send back an eligibility response, either in real-time or batch.

IV. Test Suite, Supplement, and Master Test Bed Data

What Is The Purpose Of The Test Suite?

The CORE Certification Testing Suite Version 1.0.0 defines specific certification testing requirements and detailed test scripts for each of the CORE rules. These detailed test scripts are not intended to exhaustively and comprehensively test all requirements of the CORE rules, rather, they focus on a key subset of each rule’s requirements. CORE-authorized certification testing vendors use the scenarios and test scripts from the CORE Phase I Test Suite in their CORE-certification testing products.

Does The Test Suite Have To Be Used For Certification of All The CORE Rules?

Yes, the CORE Test Suite must be used in order to maintain standard testing results and CORE rule compliance.

Do The Test Scripts Address All The Rules?

Yes, each CORE rule has its own set of test scripts.

What Is The Purpose Of The Master Test Bed Data?

The scope of the CORE Master Test Bed Data is limited to data needed for the entity seeking to become CORE-certified to create and populate its internal files and/or databases for internal pre-certification testing and CORE certification testing for the CORE 154: 270/271 Data Content and CORE 150 and 151 Acknowledgements Rules.Thus, CORE-authorized certification testing vendors will be using only the CORE Master Test Bed Data to conduct CORE certification testing for the CORE 154: 270/271 Data Content and CORE 150 and 151 Acknowledgements Rules.

Can My Organization Use Internal Health Plan Test Data For CORE-Certification Testing Purposes?

No. The CORE Certification Test Suite requires that all organizations seeking CORE certification be tested using the same Master Test Bed Data. The CORE Master Test Bed Data is distributed in the standard X12 format so that organizations may easily extract the key data elements and load them into their internal test databases. The CORE-Authorized Certification Testing Vendors will only use the CORE Master Test Bed Data to conduct CORE certification testing for the CORE 154: 270/271 Data Content and CORE 150 Batch Acknowledgements and 151 Real Time Acknowledgements Rules.

Where Can My Organization Obtain The Test Data Required For CORE-Certification?

The CORE Master Test Bed Data, the CORE Certification Test Suite and the Test Suite Supplement are available from the CAQH website by going to this link.

I am a health plan. The Group number used in the CORE Master Test Bed Data does not align with my organization’s eligibility system requirements for format requirements (length/format/datatype).

The Group number is not validated by either of the CORE-authorized certification testing vendors in any of the certification test scripts. Therefore the Group number can be modified, or not used, by any health plan or information source based on its eligibility system requirements for Group number when undergoing certification testing. This permits health plans or information sources to modify the CORE Master Test Bed Data Group numbers, and as a consequence any revisions performed by a health plan to the Group number in the CORE Master Test Bed Data will not be validated during CORE certification testing.

I am a health plan. The CORE Master Test Bed Data has different benefits for the same Group number. My organization’s eligibility system can not support different benefits for the same Group number.

Both CORE-authorized certification testing vendors can accommodate health plan or information source needs regarding Group number in their testing product. Therefore, a health plan or information source is permitted to change the CORE Master Test Bed Data Group number when loading the test data into its eligibility system.

This permits health plans or information sources to modify the CORE Master Test Bed Data Group numbers, and as a consequence any revisions performed by a health plan or information source to the Group numbers in the Master Test Bed Data will not be validated during CORE certification testing.

If your plan modifies the Master Test Bed Data, you will need to report to CAQH how you adjusted the data so lessons learned can be applied to Phase II.

I am a health plan. The Member ID (MID) in the CORE Master Test Bed Data does not align with my organization’s eligibility system format requirements (length/format/datatype).

Both CORE Authorized Certification Testing Vendors can accommodate health plan or information source needs regarding Member ID (MID) in their testing products.

Please contact CAQH to inquire about how each vendor deals with this issue.

HOWEVER, neither a health plan or information source is permitted to modify any patient demographic or benefit values, as specified in the CORE Master Test Bed Data, and dates in the DTP segment. The exceptions to this is modifying the MID as stated in this FAQ, modifying EB02 from EMP to IND as stated below in FAQ #147 below, and modifying the ISA/GS and NM103 in loop 2100A as stated in FAQ #148 below.

I am a health plan. My organization’s eligibility system assigns/associates the same Member ID to all individuals in a family, including the subscriber and can not handle a unique Member ID for a dependent that is different from that assigned to the associated subscriber.

Both CORE-authorized certification testing vendors can accommodate health plan or information source needs regarding loading dependents in the CORE Master Test Bed Data with a unique Member ID (MID) into the health plan or information source eligibility systems as follows:

A health plan or information source may load the subscriber in its eligibility system using the MID as specified in the CORE Master Test Bed Data for the subscriber and then separately load the dependent from the CORE Master Test Bed Data into it eligibility system as a subscriber using the MID as specified in the CORE Master Test Bed Data for the dependent

A health plan or information source may modify the dependent’s MID in the CORE Master Test Bed Data to correspond to the subscriber’s MID as specified in the Master Test Bed Data and then load the dependent appropriately in its eligibility system.

I am a health plan. My organization’s eligibility system does not support identification of a Plan number as specified in the REF segment in the CORE Master Test Bed Data.

The Plan number is not validated by either of the CORE-authorized certification testing vendors in any of the certification test scripts. Therefore the Plan number can be modified, or not used, by any health plan or information source based on its eligibility system requirements for Plan number when undergoing certification testing. This permits health plans or information sources to modify the CORE Master Test Bed Data Plan numbers, and as a consequence any revisions performed by a health plan to the Plan numbers in the Master Test Bed Data will not be validated during CORE certification testing.

If your plan modifies the Master Test Bed Data, you will need to report to CAQH how you adjusted the data so lessons learned can be applied to Phase II.

I am a health plan. The CORE Master Test Bed Data has specific payer names expected to be returned, e.g., “PlanA” Certification Payer, but my organization uses specific plan names.

The name “PlanA” appears only in the ISA/GS sender/receiver fields and the NM103 segment in the 2100A Information Source loop in the CORE Master Test Bed Data. The ISA/GS sender/receiver fields as well as the name of the Information Source in loop 2100A are not validated by either of the CORE-authorized certification testing vendors in any of the certification test scripts. Therefore these values can be modified by any health plan or information source based on its eligibility system requirements when undergoing certification testing.

HOWEVER, neither a health plan or information source is permitted to modify any patient demographic or benefit values as specified in the CORE Master Test Bed Data and dates in the DTP segment. The exceptions to this is modifying the ISA/GS and NM103 in loop 2100A as stated in this FAQ, modifying the MID as stated in FAQ #144 above and of modifying EB02 from EMP to IND as stated below in FAQ #148 below.

If your plan modifies the Master Test Bed Data, you will need to report to CAQH how you adjusted the data so lessons learned can be applied to Phase II.

I am a health plan. Coverage Level is listed in the CORE Master Test Bed Data, however it is listed for at least one test case as Employee Only. My organization’s eligibility system does not support Employee Only coverage level and instead uses IND for individual.

Both CORE-authorized certification testing vendors can accommodate a health plan or information source modifying the EB02 Coverage Level Code from EMP to IND as needed in order to load the benefit into its eligibility system. Therefore the EB02 Coverage Level Code can be modified, or not used, by any health plan or information source based on its eligibility system requirements for coverage level when undergoing certification testing.

This permits health plans or information sources to modify the CORE Master Test Bed Data coverage level codes, and as a consequence any revisions performed by a health plan to the coverage level codes in the CORE Master Test Bed Data will not be validated during CORE Certification Testing.

HOWEVER, neither a health plan or information source is permitted to modify any patient demographic or benefit values as specified in the CORE Master Test Bed Data and dates in the DTP segment. The exceptions to this is modifying EB02 from EMP to IND as stated in this FAQ, modifying the ISA/GS and NM103 in loop 2100A as stated in FAQ #147 above, and modifying the MID as stated in FAQ #144 above.

If your plan modifies the Master Test Bed Data, you will need to report to CAQH how you adjusted the data so lessons learned can be applied to Phase II.

The NPI is mandated for use to identify providers on and after 5/23/07. Will the CORE Master Test Bed Data be modified to include NPIs?

CORE is working to identify a testing solution that complies with a CMS-approved approach to testing that involved NPIs.

I am a health plan. The Employee ID used in the CORE Master Test Bed Data does not align with my organization’s eligibility system format requirements (length/format/datatype).

The Employee ID is not validated by either of the CORE-authorized certification testing vendors in any of the certification test scripts. Therefore the Employee ID can be modified, or not used, by a health plan or information source based on its eligibility system requirements for Employee ID when undergoing certification testing. This permits health plans or information sources to modify the CORE Master Test Bed Data Employee IDs, and as a consequence any revisions performed by a health plan or information source to the Employee ID in the CORE Master Test Bed Data will not be validated during certification testing.

If your plan modifies the Master Test Bed Data, you will need to report to CAQH how you adjusted the data so lessons learned can be applied to Phase II.

Can I/how do I change the member and provider information in the 270 test files to match the data in our vendor QA environment? The data needs to match our format for member and provider IDs. For example, member IDs for our traditional plan members start with a "W" (e.g., W999999999) but the member ID for task #11a (5638297_request.dat)] is 5638297 and will fail validation.

Please see questions #144, 147 and 148 above.

What Is The CORE Test Suite Supplement?

The CORE Phase I Test Suite Supplement Version 1.0.1 provides additional information and details about the use and format of the CORE Master Test Bed Data, as it applies to the CORE 154: 270/271 Data Content and CORE 150 Batch Acknowledgements and 151 Real Time Acknowledgements Rules. The supplement is to be used in conjunction with the CORE-Certification Test Suite version 1.0.0. The other CORE rules do not require the use of the test data.

My organization’s eligibility system validates zip code against city/state and the CORE Master Test Bed Data contains some invalid zip codes for the city/state.

The zip codes have been corrected and Version 1.0.1 of the Supplement has been uploaded to the CAQH/CORE web site, deprecating Version 1.0.0., which has been removed from the web site.

The zip codes in the X12 formatted test data in the .txt files are correct for the city/state combination.

Do Providers Have to Test For All Of The Rules?

Providers who wish to become CORE-certified must comply with all of the provider-specific CORE rules and complete the CORE certification Tests Scripts for each rule that apply to providers (See CORE Test Suite). Providers can satisfy the certification requirements by either using a provider/vendor's solution or a combination of a provider/vendor's solution plus some in-house work.

V. Phase I Measures of Success

What Is The Measures of Success Program?

The Measures of Success Program is the method CAQH will use to track the financial/operational impact, by stakeholder type, of being compliant to the CORE Phase I rules. Specifically, volunteers from each stakeholder type will track, quarterly, a small set of standard metrics that are agreed upon by the volunteering entities. The purpose of the Measures of Success Program is to:. Support CORE’s momentum by reminding participants of the progress they are/have made.. Demonstrate market need for operating rules by tracking actual direct/indirect RIO benefits of operating rules.. Provide easy story for the press/media: Existence and tracking of concrete health care measures of success that were developed by a group of multi-stakeholder participants.. Participating in the Measures of Success Program is not a requirement for CORE certification.

What Are The Measures Of Success?

The Measures of Success are a realistic set of metrics (e.g., change in call volumes/EDI inquiries) by stakeholder group (health plans, front-end vendors, clearinghouses, and providers) to measure the benefits of Phase I rules adoption. The metrics include agreed upon methodologies that will be applied by each stakeholder group to track each metric. The final metrics will be published soon.

Which Entities Are Participating in the Measures of Success Program?

TBA.

VI. Resources and Links

CAQH Contact Information

CAQH601 Pennsylvania Ave., NW, South Building
Suite 500
Washington, DC 20004 E: info@caqh.org
T: 202-861-1492
F: 202-861-1454
www.caqh.org

CORE Contact Information

CAQH
Re: CORE601
Pennsylvania Ave., NW, South Building
Suite 500
Washington, DC 20004
E: CORE@caqh.org
T: 202-861-6380

CORE-Authorized Testing Vendor Contact Information

Click here for full contact information for all CORE-authorized testing vendors

List of CORE Members

Please click here of CORE members

List of CORE-Certified Entities

Please click here on CORE’s website

List of CORE-Endorsers

Please click here on CORE’s website

List of Standard Development/Advisory Organizations.

Accredited Standards Committee (X12)
American National Standards Organization
Health Level 7 (HL7)
WEDI
NCVHS

Warning: include(incl/footer.php) [function.include]: failed to open stream: No such file or directory in /home/caqhorg/public_html/CORE_cert_faq.php on line 45

Warning: include(incl/footer.php) [function.include]: failed to open stream: No such file or directory in /home/caqhorg/public_html/CORE_cert_faq.php on line 45

Warning: include() [function.include]: Failed opening 'incl/footer.php' for inclusion (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/caqhorg/public_html/CORE_cert_faq.php on line 45