CORE FAQs

I. CORE General FAQs

II. CORE Policy & Certification FAQs

• Pledge
• Certification Policy
• Exemption Policy
• Testing Policy
• Enforcement Policy

III. CORE Operating Rule FAQs

Phase I 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

Phase II FAQs

• 250: Claim Status Rule
• 258: Normalizing Patient Last Name Rule
• 259: AAA Error Code Reporting Rule
• 260: Data Content (270/271) Rule
• 270: Connectivity Rule

IV. Test Suite and Master Test Bed Data FAQs

• Phase I Test Suite/Test Bed Data FAQs
• Phase II Test Suite/Test Bed Data FAQs

V. 5010 FAQs

VI. Phase I Measures of Success FAQs

VII. CORE Resources and Links

I. General



1. 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 was to create, disseminate, and maintain operating rules that enable healthcare providers to quickly and securely obtain reliable healthcare eligibility and benefits information. CORE Phase II extends this capability to include operating rules around the claim status transaction to enable providers to check the status of a claim electronically, or confirm claims receipt, without manual intervention. CORE operating rules will decrease the amount of time and resources providers spend verifying patient eligibility, benefits, claim status and other administrative information at the point of care.

CORE operating rules, 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.

Back to Top

2. 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

See www.caqh.org for more details.



Back to Top

3. 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.

Back to Top

4. Why Develop Operating Rules For Exchange of Healthcare Administrative Information, such as Eligibility and Benefits or Claim Status Information?

HIPAA provides a foundation for the exchange of eligibility/benefits and claim status 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 administrative healthcare information. Interoperability ensures that information can be uniformly requested, provided and understood by all stakeholders.

The CORE Phase I and Phase II operating rules, therefore, will streamline the way eligibility and benefits, claim status 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, providing enhanced information on patient financial responsibility and checking the status of a patient claim.

Back to Top

5. What Do The CORE Phase I and Phase II 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
• Standard testing, certification and enforcement processes to ensures CORE compliance



The CORE Phase II rules extend and enhance the CORE Phase I Operating Rules for HIPAA 270/271 transactions for eligibility and benefits as well as significantly broaden the underlying connectivity standards. HIPAA 276/277 transactions for claim status information have also been added in CORE Phase II. The Phase II Operating Rules address the following information:

• System connectivity safe harbor extended to the envelope level, including support for either:
1. HTTP MIME Multipart
2. SOAP + WSDL
• Continued support of Phase I requirements, including:
• Standard acknowledgements
• Maximum response times (batch and real-time)
• Minimum hours a system must be available (system availability)
• Standard 270/271 and/or 276/277 companion guide flow and format
• Expanded 270/271 eligibility content to include:
• Health Plan requirement to support explicit 270 eligibility inquiry for 39 service type codes
• 271 response must include all patient financial liability for:
• Base contract deductible AND remaining deductible
• Co-pay
• Co-insurance
• In/out of network amounts, if different
• Related dates
• Patient Identifiers Rules
• Last Name Normalization
• Use of AAA Error Codes
• Claim Status
• Standard testing, certification and enforcement processes to ensure CORE compliance.

Additional eligibility/claim status components and other business transactions will be addressed by CORE in Phase III (2009) and later phases (2010 and beyond).

Back to Top

6. 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/benefits and claim status 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 administrative databases. Providers will use the vendor system of their choice to request and receive information.

Back to Top

7. How Do The CORE Operating 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. For example, any entity that agrees to follow the CORE operating rules will be able to provide the eligibility and benefits data as outlined in the CORE Phase I rules or, if following CORE Phase II rules, able to provide both eligibility and claim status information as described in the rules. Likewise, if an entity agrees to follow the CORE Phase II operating rules it will be able to take advantage of enhancements to the 270/271 Data Content rule, such as patient financial responsibility accumulators (year-to-date and remaining deductible and co-pays, etc.) and broader reporting requirements for benefit services, Thus, healthcare providers will select the technology system of their choice and utilize that system as the connecting point for routing their eligibility/benefits or claim status inquiries to payers with whom they have trading partner relationships.

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 as a CORE endorser. Any entity that agrees to follow the CORE operating rules will be able to exchange eligibility/benefits and/or claim status information outlined in the respective Phase I or Phase II rules.

Back to Top

8. How Were The CORE Operating 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.

The CORE Phase II rules-development process took place from May 2006 to June 2008.

CORE's Rules, Technical and Policy Work Groups built upon the Phase I Rules, based on the member-approved scope of proposed Phase II enhancements and presented these draft Phase II rules 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 June 2008. The CORE voting membership approved the rules in June 2008 with an official vote.

The CAQH Board of Directors issued a statement of endorsement for the CORE Phase II rules in July 2008.

Back to Top

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

CAQH determined that CORE could have the most immediate impact if it focused on improving eligibility and benefits verification in Phase I. CORE members made the decision to address only 270/271 electronic data interchange (EDI) eligibility transactions in Phase I with later phases of CORE to include other types of transactions. CORE Phase II, for example, includes operating rules on the 270/271 eligibility transaction and on the 276/277 claims status transaction.

Back to Top

10. Are the CORE Operating Rules for EDI, Direct Data Entry (DDE) and Web-based Transactions?

The CORE operating rules only apply to EDI. DDE and Web-based transactions are not within the scope of the CORE rules. Web-based transactions, as defined in the CORE rules, apply only to transactions that do not use the X12 standard 270/271 format. The CORE web-based definition is similar to the CMS definition for DDE (Direct Data Entry), i.e., defined as a direct interaction between a payer and provider that does not utilize the HIPAA eligibility 270/271 transaction.

Back to Top

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

Yes, the CORE operating rules apply to both batch and real-time processing. If an entity does not offer batch processing, it will only have to undergo certification testing for its real-time systems. If an entity offers both batch and real-time processing, than both processing types have to be in compliance with the CORE rules to pass CORE certification. Real-time is required for all entities, while batch is optional.

Back to Top

12. Who Will Adopt And Comply With The CORE Phase I and Phase II 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 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 the Phase I rules.

The CORE Phase II operating rules are for use by entities that create, use or transmit eligibility and/or claim status data. Stakeholder entities that wish to adopt the Phase II rules are required to sign the CORE 201: Pledge Version 2.0.0 committing the organization to ensure their IT system(s) can conform to the Phase II rules. A CORE-authorized testing vendor will validate that the entity’s systems complies with CORE rules. NOTE: Prior to becoming Phase II certified, an entity must be Phase I compliant/certified. (refer to FAQ #17)

Back to Top

13. Which CORE Phase Operating Rules Should My Organization Adopt and Follow?

CORE certification is voluntary. Any entity seeking CORE certification must first be certified on Phase I and then choose Phase II certification. An entity cannot become Phase II certified without first becoming Phase I certified, except in the circumstance where a vendor/clearinghouse does not conduct 270/271 eligibility transactions, but does offer 276/277 claim status transactions. In this instance, that entity can become Phase II certified without first becoming Phase I certified.

Each entity should consider certification, and on which CORE phase operating rules to certify, after a review of its business requirements and system capabilities (and those of its trading partners). Each subsequent CORE phase builds and expands on the previous phase. For example, Phase II builds and expands on the content and functionality of the Phase I Connectivity/Security and 270/271 Eligibility Data Content rules and adds new rules for patient identification matching and error reporting and implementation of the 276/277 Claim Status transaction. (refer to FAQ #5)

NOTE: Certified entities must demonstrate compliance with all applicable CORE rules of the given Phase for which they are certifying.

Back to Top

14. What Does It Mean To Be CORE Phase I- or Phase II-Certified?

CORE certification means an entity has demonstrated its compliance with the CORE Phase I or Phase II rules by successfully completing the certification testing requirements with a CORE-authorized testing vendor. CORE-certification indicates an entity has signed the CORE Pledge and successfully completed certification testing of a CORE Phase. Successful certification testing demonstrates an entity’s compliance with the rules for a particular CORE Phase.

Phase I Certification:
Any entity that creates, transmits, or uses eligibility data can become CORE-certified. An entity that agrees to follow the CORE Phase I operating rules is expected to exchange eligibility and benefits information, per the requirements of the CORE Phase I rules and policies, with all of its trading partners.

Phase II Certification:
Any entity that agrees to follow the CORE Phase II operating rules will be expected to exchange eligibility and benefits information and/or claim status information, per the requirements of the CORE Phase II rules and policies, with all of its trading partners – dependent upon whether one or both of these transactions are offered.

After an entity successfully completes the CORE certification process, it can market itself as CORE Phase I or Phase II certified, as appropriate For more information about CORE certification, please refer to the CORE Certification: Step-By-Step Process Webpage.

Notes:

1. CORE-certification does not replace trading partner relationships.
2. CAQH encourages 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 independently, we encourage them to do so.

Back to Top

15. As a CORE Phase I Certified Entity, Is My Organization Required to Become Phase II Certified When These Operating Rules are Approved and Available?

No. Becoming certified under CORE Operating Rules is strictly voluntary and entities that are CORE Phase I certified are not required to become Phase II certified. However, Phase I-certified organizations are encouraged to commit and become Phase II certified as broader adoption of these rules will enhance the usability and content of both the eligibility and claim status transactions as well as decrease associated administrative costs and resources. Therefore, the benefit of the CORE Phase II rules increases with each additional entity that becomes Phase II certified.

Back to Top

16. If We Are CORE Phase I Certified, Do We Stand to Lose the Certification If We Don't Implement the Phase II Rules Within a Specific Timeframe, e.g., Within 6 Months?

No. For each CORE Phase, it is up to the certifying entity to determine when and if it is feasible to become CORE-certified. CORE certification is active unless the entity loses its Seal. The CORE Enforcement Policy dictates that complaints of an entity’s non-compliance with CORE rules must be filed against the entity, the complaints must be verified and the issues must be resolved within a 5 month period before CORE certification is lost (see FAQ #60).

A number of Phase I certified entities have already committed to Phase II certification. For example, CAQH member Health Plans are expected to become Phase II certified by a future date decided upon by the CAQH Board. (For Phase I, the CAQH Board aimed for 12 months after rules become final.)

Back to Top

17. Does My Organization Need to be CORE Phase I Certified Prior to Moving to Become Phase II Certified?

Yes. CORE represents a phased approach to developing operating rules for healthcare administrative transactions and, as such, an entity must successfully complete Phase I certification testing, prior to becoming certified for Phase II. An entity may choose to test and become certified for Phase I and move to Phase II certification at a later time or, alternatively, undergo combined certification testing for Phase I and Phase II concurrently. (See CORE 202: Phase II Certification Policy.)

Note: The singular exception to this policy is the case of vendors and clearinghouses that do not conduct eligibility 270/271 transactions. In this situation where a vendor/clearinghouse offers only 276/277 claim status transactions, that entity can become Phase II certified without being Phase I certified.

Back to Top

18. What Does It Mean To Be A CORE Endorser?

Entities that do not create, transmit, or use eligibility or claim status data are eligible to become CORE Endorsers. Endorsing organizations can demonstrate their support for the CORE mission and the Phase I or Phase II rules by signing the appropriate CORE Pledge (see below) and applying for and using the respective CORE Phase I or CORE Phase II Endorser Seal.

• Endorsement of the CORE Mission and Phase I rules requires signing the CORE 101: Pledge Version 1.0.0.
• Endorsement of the CORE Mission and Phase II rules requires signing the CORE 201: Pledge Version 2.0.0 and CORE Pledge Phase II Addendum.

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 Endorser Seal: Application Process for information on how to obtain a CORE Endorser Seal.

Back to Top

19. How Is CORE Participation Different from CORE Certification and CORE 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 or CORE 202: Pledge & Addendum 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.

Back to Top

20. What Entities Are CORE-Certified Or CORE-Endorsers?

See the CORE Certification and CORE Endorsement lists for further information.

Back to Top

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

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

Back to Top

22. 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.

Back to Top

23. How Do I Become CORE-Certified?

Please refer to the CORE Certification: Step-By-Step Process Webpage for more information on CORE certification.

Back to Top

24. How Do I Become A CORE-Endorser?

Please refer to the CORE Endorser Seal: Application Process for more information on the Seal application process for each Phase.

Back to Top

25. 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 rule requirements for the phase at which you are certified. See the CORE 105: Enforcement Policy Version 1.0.0 or CORE 205: Enforcement Policy Version 2.0.0 for more information on Phase I or Phase II, as appropriate.

Back to Top

26. 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 and Phase II, CORE does not address/include any rules for patient identification requirements.

Back to Top

27. Are There Any CORE Rules that Provide Requirements Regarding How Often Claim Status Inquiries or Eligibility Transactions Should Be Submitted? (Do CORE Rules Either Support or Exclude a Provider or Vendor from Sending Daily Batches of Claim Status Inquiries for Every Outstanding Claim, Regardless of the Status Response Received the Previous Day?

No. Neither Phase I nor Phase II CORE operating rules address the frequency of submission for either eligibility inquiries or claim status inquiries.

However, both Phase I and Phase II require all CORE certified entities to support real–time. The frequency of submission should not be an issue since it is anticipated that eligibility or claim status inquiries can be submitted as frequently as needed by the provider. Per CORE rules, a CORE-certified Health Plan is required to have its systems supporting eligibility and claim status (if Phase II certified) inquiries available 86% of the time over a calendar week.

Batch processing is an option, but not required, by any CORE rule.

Back to Top

28. Do the CORE 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 and Phase II Rules build on the HIPAA 270/271 transactions, the ASP vendor that is acting as a health care clearinghouse for a provider will need to 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 Rules in order to become CORE certified, for either Phase I or Phase II.

Back to Top

29. What Version Of The CORE Rules, CORE Test Suite, and CORE Master Test Bed Data Should I Be Using?

Your organization should use the CORE Rules and Policies, Test Suite and Master Test Bed Data corresponding to the phase for which you are certifying. The most current versions of these documents are available on the CAQH website.

Back to Top

30. How Will The CORE Rules Be Updated?

CORE rules changes, should they occur, 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. 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 202: Certification Policy Version 2.0.0 for more information.

Back to Top

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

No. Use of and participation in CORE is voluntary and 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.

Back to Top

II. CORE Policy & Certification FAQs - CORE Pledge



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

Signing either the CORE 101: Pledge Version 1.0.0 or CORE 201: Pledge Version 2.0.0 for CORE Phase I or Phase II, respectively, 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.

Back to Top

33. Is The Pledge Binding?

Organizations may sign the Pledge at any time after the CORE rules are developed and approved by the CORE voting members, and may withdraw from the Pledge (CORE 101: Pledge Version 1.0.0 or CORE 201: Pledge Version 2.0.0) at any time. However, an organization signing either Pledge is committing to completing CORE certification testing within 180 days of signing.

Back to Top

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

After signing the CORE Pledge, an entity has 180 days to complete CORE-certification testing by working with CORE-authorized testing vendor and submit its CORE certification application to CAQH (per the CORE 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.

Back to Top

II. CORE Policy & Certification FAQs - CORE Certification Policy



35. 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

Clearinghouses:
• Below $75 million in net annual revenue: $4,000 fee
• EHNAC HNAP-EHN accreditation - apply 10% ($400) discount
• $75 million and above in net annual revenue: $6,000 fee
• EHNAC HNAP-EHN accreditation - apply 10% ($600) discount

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

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

Endorsers: (Only for entities that do not create, transmit or use eligibility data).
• No fee

NOTES:
1. There is no charge to Federal or State government entities to receive the CORE Seal.
2. There is no charge to CAQH member plans to receive the CORE Seal.
3. This fee is a one-time cost for Phase I certification, unless an entity becomes decertified or if substantive changes to the rules are approved by a full CORE vote (Reference CORE 102: Eligibility and Benefits Certification Policy, version 1.0.0.)
4. Per the CORE Phase I Certification Policy, vendor products, and not entire vendor organizations, receive the Certification Seal.
5. The CORE Certification Seal fee does not include the fee for CORE certification testing. See http://www.caqh.org for a list of CORE-authorized testing companies and their associated testing fees.
6. Any Clearinghouse/EHN entity actively seeking CORE certification as of June 1, 2009 or later that has already achieved EHNAC HNAP-EHN accreditation can take advantage of the partnership program discount. The Clearinghouse/EHN will indicate that it holds a current EHNAC HNAP-EHN accreditation when submitting a CORE Seal application. (CAQH will confirm EHNAC-EHN accreditation status independently.)




Back to Top

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

Yes. CORE certification is specific to each phase of CORE rules. Major modifications to the CORE rules (requiring vote and approval by the entire CORE membership) would result in a new phase. All entities that wish to be certified for a new phase will need to complete the CORE certification testing and pay all applicable fees. For more information, see the CORE Certification Policy for the applicable CORE phase. (CORE 102: Certification Policy Version 1.0.0 or CORE 202: Certification Policy Version 2.0.0)

Back to Top

37. Why Would An Entity Have To Re-certify for a CORE Phase for Which it Had Previously Been Certified?

CORE re-certification will be required if an entity’s CORE 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 appropriate CORE Enforcement Policy (Version 1.0.0 or 2.0.0) for Phase I or II, respectively, 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 or claim status aspect of the product, the vendor will need to undergo re-certification for that product.

Back to Top

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

All organizations that operate under the CORE 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 appropriate CORE HIPAA Attestation Form (Phase I or Phase II. 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, and/or 276/277 claim status transaction. CORE will not test for HIPAA compliance.

Back to Top

39. My Company Has Many Subsidiaries. Do They All Have To Be Compliant With The CORE Operating Rules?

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

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.

Back to Top

40. 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 or claim status 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.

Back to Top

41. 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 will only 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.

Back to Top

42. 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 for the appropriate phase that you can use in your communication tools/materials. Please refer to the CORE Marketing Guidelines for more information.

Back to Top

43. 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 CORE Phase I or Phase II rules that apply to providers and complete the CORE certification tests for each rule that applies to providers. (See the appropriate phase CORE Test Suite (Phase I or Phase II) 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.

Back to Top

44. 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 rules on which an entity is testing 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 Certification: Step-by-Step Process 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.

Back to Top

45. 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)

Back to Top

46. 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.

Back to Top

47. 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 are covered by the CORE rules for the phase for which it is seeking certification. 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 not 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.

Back to Top

48. Referring To 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. Organizations that share functions can, including the entity that has outsourced some functions, may pursue testing with different testing vendors when seeking CORE-certification.

When an entity outsources some or all of the capabilities required by the CORE 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.

Back to Top

49. As An EHNAC Accredited Clearinghouse, Do I Qualify For Any Discounts?

Any Clearinghouse/EHN entity actively seeking CORE certification as of June 1, 2009 or later that has already achieved EHNAC HNAP-EHN accreditation can take advantage of the partnership program discount.  The Clearinghouse/EHN will indicate that it holds a current EHNAC HNAP-EHN accreditation when submitting a CORE Seal application.  (CAQH staff will confirm EHNAC-EHN accreditation status independently).  The Clearinghouse/EHN will submit its application and apply a 10% discount to the CORE Seal application fee.  (If your organization earned a CORE Seal on any Phase prior to June 1, 2009, your organization is not eligible for a retroactive discount for that Phase).

Back to Top

II. CORE Policy & Certification FAQs - Exemption Policy




50. What Is The CORE Exemption Policy?

The CORE Exemption Policy Version 1.0.0 and 2.0.0 for Phase I and Phase II, respectively, allow 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 market share, 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.

Back to Top

51. 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.

See the appropriate CORE Exemption Policy (Phase I or Phase II) and the CORE Health Plan IT Exemption Request Form for more information.



Back to Top

II. CORE Policy & Certification FAQs - Testing Policy



52. Who Has To Undergo CORE Certification Testing?

All entities that create, transmit or use eligibility and/or claim status 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 transactions 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 Pledge and applying for and using the CORE Endorser Seal.

Back to Top

53. Why Is Testing Required For CORE Certification?

CORE-certification testing is required to confirm that entities comply with all of the CORE operating rules for the phase for which they are being certified. 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.

Back to Top

54. What And Who Are CORE Testing Vendors?

The CORE-authorized certification testing vendors are:

• Edifices (Tests for Phase I and Phase II certification)
• Ingenix (Tests for Phase I certification)

These CORE-authorized certification testing vendors are IT companies that have expertise in healthcare transaction testing. They were chosen by CAQH to conduct CORE certification testing for all of the Phase I rules after a rigorous selection process by the CORE Joint Certification/Testing Subgroup. View the list of CORE-authorized testing vendors’ websites.

Back to Top

55. Besides Edifecs and Ingenix, Are There Any Additional Vendors Authorized by CORE to Perform CORE Certification Testing?

No.

Back to Top

56. 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.

Back to Top

57. 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 appropriate CORE Seal Application Form(s) (Phase I or Phase II) for more information.

Back to Top

58. 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.

Back to Top

59. When a Provider Does Not Wish to Load Test Information into their System (e.g., the provider names, etc.) as Shown in the CORE Master Test Bed Data, can Valid Information About their Organization be Used Instead When Generating the Required 270 Inquiries During CORE Certification Testing?

Yes, a provider should have no difficulty substituting currently valid data such as their own provider name, address information, including identifiers into the 270 documents submitted to a testing vendor for Certification Testing. Some of the Phase I and Phase II master test data element values can be modified. These modifiable data elements and how they may be modified are specified in an appendix in both the Phase I and Phase II Certification Testing.

Back to Top

II. CORE Policy & Certification FAQs - Enforcement Policy



60. Who Can File A Complaint?

Two types of entities may file a complaint:

1. 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 operating rules and/or policies. The complaint needs to be made by submitting a Request for Review of Possible Non-Compliance Form to CORE.
2. Beyond provider end-users, CORE-certified organizations involved in the alleged non-compliant transactions may file a complaint, e.g., vendors, health plans, etc.

Back to Top

61. 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 operating rules at a specific CORE phase. Please see CORE Enforcement Policy for Phase I and Phase II for further details.

Back to Top

62. 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.

Back to Top

63. 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.

Back to Top

64. 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.

Back to Top

III. CORE Operating Rule FAQs
    Phase I Rule FAQs - 150. Batch Acknowledgements



65. 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.

Back to Top

66. 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.

Back to Top

67. 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 Version 1.0.0 will test for your system’s capabilities to return the 997 acknowledgment.

Back to Top

68. 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 on 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 Require 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.

Back to Top

69. [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.

Back to Top

III. CORE Operating Rule FAQs
    Phase I Rule FAQs - 151: Real Time Acknowledgements



70. 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.

Back to Top

71. 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.

Back to Top

72. The TA1 Interchange Acknowledgment is Described in the HIPAA Implementation Guide Appendix B: EDI Control Directory. The Note for the ISA14-I13 Acknowledgment Requested Data Element Indicates that Trading Partners May Mutually Agree on 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 Require 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.

Back to Top

73. 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 both acceptance/rejection and errors found in any message. Accordingly, the CORE Phase I rules are focused on the conduct of the HIPAA-named X12 270/271 transaction sets. 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.

Back to Top

74. Are all CORE Rules with Regard to Acknowledgement Only Applicable to Scenarios Where my Organization Receives Data in a 270 Format?

Please see FAQ above.

Back to Top

75. Is GS08 Supposed to be 004010 or that of the Transaction Set, such as 004010X096A1?

GS08 is a code indicating the version, release, subrelease, and industry identifier of the EDI standard being used, if the code in GS07 (DE455) is an X, then in GS08 (DE480) positions 1-3 are the version number; positions 4-6 are the release and subrelease, level of the version; and positions 7-12 are the industry or trade association identifiers (optionally assigned by user).

In the case of an FA (functional acknowledgement) functional group, the value in GS08 refers to the version, release, subrelease, and industry identifier of the GS08 of the functional group itself and not the functional group being acknowledged.

Therefore in the scenario outlined in the request the proper value for GS08 would be '004010' assuming there was no industry or trade association identifier in use for the 997.

Please note also that the version of the functional acknowledgement does not have to be the same version as the transaction being acknowledged. For example, a version 5010 997 can be used to acknowledge a version 4010 837.

Back to Top

III. CORE Operating Rule FAQs
    Phase I Rule FAQs - 152: Companion Guide Rule



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

Health plans have independently created companion guides that often vary in format and structure. Such variance can be confusing to trading partners and providers. CORE developed its 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.)

Back to Top

77. 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.

Back to Top

78. 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.

Back to Top

III. CORE Operating Rule FAQs
    Phase I Rule FAQs - 153: Connectivity Rule



79. 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.

Back to Top

80. Can 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.

Back to Top

81. Is There a Required Format In CORE Phase I 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, in CORE Phase II and future phases, CORE does require a specific format for sending these data elements. 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.

Back to Top

82. 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.

Back to Top

83. 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.

Back to Top

84. Will All CORE-Authorized Certification Testing Vendors Use the Same Test Scripts and the 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.

Back to Top

85. 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 Phase I 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 beyond the CORE rules, will not be tested by the CORE-authorized certification testing vendors as part of CORE certification testing.

The CORE Phase II Connectivity Rule includes requirements for both Username/Password and X.509 Certificates over SSL as submitter authentication standards, with specific conformance requirements for the client (e.g., submitters/providers) and the server (e.g., health plans.) (See CORE 270 Phase II Connectivity Rule.)

Back to Top

86. 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.

Back to Top

87. 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.

Back to Top

88. 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.

Back to Top

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

HHTTP/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.

Back to Top

90. 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.

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:
   
     ListBatchResponses
     *.271
   

2) Server (payer or their intermediary) responds with a data content of something like:
< Message>
   
      20060208_12345.271
     20060208_543627.271
   

3) Client decides which file to retrieve and sends a request like:
   
     GetFile
     20060208_543627.271
   

4) And the server sends it back in something like:
   
     20060208_543627.271
     
   

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

Back to Top

91. Batch Processing: My Organization’s System Can Provide a 997 Back on Batch Transactions Within 20 Seconds. Why Can’t 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.

Back to Top

92. 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.

Back to Top

93. 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.

Back to Top

94. 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 policies.

Back to Top

95. 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.

Back to Top

96. 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.

Back to Top

97. 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.

Back to Top

98. 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.

Back to Top

99. 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.

Back to Top

100. 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.

Back to Top

101. 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 regard to testing, all of the capabilities defined in this rule to be tested are related to the information source.

Back to Top

102. Is There a Time Period For How Long the Source Needs to Maintain This Transaction 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.

Back to Top

103. 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 submitted to CAQH ( www.caqh.org) – CAQH has created the Phase I HTTPS Examples document based on these submissions.




Back to Top

104. 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. Neither do CORE rules 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 Phase I rules do not require any specific architecture. Rather, CORE rules specify 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, particularly the clause in HIPAA that says payers cannot charge more than the cost of telecommunications for handling the connectivity.

Back to Top

105. 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.

Back to Top

106. Is The Payload ID Outside The X12 Interchange?

Yes.

Back to Top

107. 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.

Back to Top

108. 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.

Back to Top

109. 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.

Back to Top

110. What Should Be Expected from Trading Partners Regarding the Payload IDs, and How It Should Be Used?

An entity should expect to receive a long, possibly alphanumeric, ID from its trading partners and should be able to store that ID and associate it with each X12 real-time message processed from the trading partner through the supported HTTP communication system. 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.

Back to Top

111. 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.

Back to Top

112. 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.

Back to Top

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

An XML-based eligibility inquiry and response equivalent to the X12 270/271 can not be used in place of an ASCII character-based 270/271. However, your organization can accept the 270 into its EDI system either directly from a provider or through a clearinghouse and, then convert it into another format for internal processing, e.g., XML or some other proprietary format.

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

Back to Top

114. For Real Time Transactions, Our System does not Automatically Resend Failed Responses, However the Client Can Go in and Send the Same Request Manually. Must We Prevent the Client from Being Able to Resubmit the Same Request (Even Manually) for 90 Seconds After the Original Request was Sent?

Yes, whether it is an automated or manual re-send the re-send attempts cannot occur more frequently than what is specified in the CORE rule.

Back to Top

115. How Should We Respond to the Transaction if the Date/Time and/or Payload ID are Not Present?

Such a message would represent a CORE non-compliant message. The CORE rule does not require such a message to be either rejected or accepted by the receiver. It is the receiver's decision regarding acceptance of a non-compliant message.

Back to Top

116. Is There a More Precise Definition as to Where User ID, Password, Date/Time and Payload ID Should Appear in the Data Stream? The Document References “HTTP Message Body” and “HTTP Message Header tags”.

There are no more precise specifications in the Phase I Rule. This decision is left to the message originator.

Back to Top

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



117. 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.

Back to Top

118. 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.

Back to Top

119. 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.

Back to Top

120. 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.

Back to Top

121. 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.

Back to Top

122. 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.

Back to Top

123. Does a 271 Response That Conforms to the CORE 154: 270/271 Data Content Rule Version 1.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.

Back to Top

124. When A Plan Has Global Deductibles, Can A Health Plan Satisfy The CORE 154: 270/271 Data Content Rule Version 1.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

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



Example 2 below shows a portion of the 271 response with active health plan coverage for all CORE-required service types, a $500 global deductible and a separate $50 deductible for pharmacy.

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



DTP*307*D8*20060101	Health Plan Coverage Begin Date
EB*1*IND*30	Active Health Benefit Plan Coverage
EB*C*IND*30****500*****Y	Health Benefit Plan Coverage Deductible of $500 for in-network providers
EB*1*IND*1	Active Medical Care Coverage
EB*1*IND*33	Active Chiropractic Coverage
EB*1*IND*35	Active Dental Coverage
EB*1*IND*48	Active Inpatient Hospital Coverage
EB*1*IND*50	Active Outpatient Hospital Coverage
EB*1*IND*86	Active Emergency Services Coverage
EB*1*IND*88	Active Pharmacy Coverage
EB*1*IND*98	Active Professional Office Visit Coverage
EB*1*IND*AL	Active Vision Coverage
EB*C*IND*88****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>





Back to Top

125. 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.

Back to Top

126. How Is Pre-Determination Handled?

CORE Phase I does not address pre-determination.

Back to Top

127. 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.

Back to Top

128. 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 may report only a single date.

Back to Top

129. 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.

Back to Top

130. Some of Our Older Health Plans Do Not Have a Separate Chiropractic Benefit but 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.

Back to Top

131. 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.

Back to Top

132. 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.

Back to Top

133. 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.

Back to Top

134. Can a Clearinghouse or Vendor Act on Behalf of a Health Plan for the Data Content 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.

Back to Top

135. 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.

Back to Top

136. 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.

Back to Top

137. Have Any Other Insurance Companies Expressed Concern Over the "Patient Responsibility" Representation for Coinsurance? My Organization is Concerned That the 90/70 Type of Coinsurance Percentages Used Today (Representing the Percent Paid By the Insurer) Will Be Confusing When Displayed as a 10/30 (Switching to "Patient Responsibility Representation"). I Believe it is an Industry Standard for the Coinsurance to be Displayed as the Percent 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 Percentage?

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.

Back to Top

138. My Organization’s Co-pay Can Be a Dollar Amount, a Percentage, the Greater of Amount and Percent, or the Lesser of 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.

Back to Top

139. In CORE Rule 154 - Data Content, It Says That for Several Service Types (Including Dental, Vision, Pharmacy), Patient Liability Amounts (Co-pay, Coinsurance, Deductible) are Not Required. In the Testing Data Several Scenarios Have Actual Liability Amounts Listed. If the X12 That We Return Does Not Include this Data, Will This Be Acceptable?

Yes, this will be acceptable.

Back to Top

140. Is It a Requirement to Send a 307 in the DTP Segment on the 270 Inquiry in Order to Have a 307 Returned in the Response in the 2100 Level?

Subsection 1.2: CORE Requirements
A date submitted in either the 2100C or 2100D loops is considered to apply globally to all of the service types specified in the EQ segment. A date submitted in either the 2110C or 2110D loop is considered to apply only to the benefit begin service date for the service type specified by each EQ01-1365 service type code. When a date is submitted in either the 2100C, 2100D, 2110C or 2110D loops, all CORE-certified participants are required to submit only code “307” Eligibility.

When code “307” is used in either loop 2100C ore 2100D loop, it means the submitter is requesting the health plan (or information source) to respond in the corresponding 2100C or 2100D loop. When code “307” is used in either loop 2110C or 2110D it means the submitter is requesting the health plan (or information source) to respond in the corresponding 2110C or 2110D loops in the 271 with the date on which the health plan coverage begins only if the benefit begin date is different from the plan begin date specified in either the 2100C or 2100D loops.

This section of the CORE Phase I Data Content Rule does not specify that a submitter (healthcare provider) MUST submit a 270 using code 307 in order to have the health plan respond as required. Thus, it is not a requirement to submit code 307 in order to have a 307 returned in the response in the 2100 level. Section 2: 271 Eligibility Inquiry Response

The HIPAA Implementation Guide for the 270/271 Eligibility Inquiry implementation guide states: “An information source must respond with either an acknowledgment that the individual has active or inactive coverage or that the individual was not found in their system.” The CORE rule for the 271 response imposes these additional requirements: If the individual is located in the health plan’s (or information source’s) system, the following must be returned:

• Subsection 2.1: Status
• Subsection 2.2: Health Plan Name
• Subsection 2.3: Patient Financial Responsibility
• Subsection 2.4: Eligibility Dates

If the individual has active coverage (codes 1 through 5 in EB01-1390), the code “307” Eligibility date (defined to mean health plan begin in the context of this CORE rule) must be returned in the DTP segment in either the 2100C or 2100D loops.

Thus, the requirement imposed on the health plan to return code 307 is **if the individual has active coverage** and not what was submitted in the 270.

Back to Top

141. Does the History on Plan Name Changes Need to Be Kept? If It's Still the Same Plan from Last Year but Has a Different Name this Year, Can the Current Name be Used When Replying to a Request for Last Year?

The CORE rule does not address this aspect of a plan name. It only requires the health plan to return the plan name if it is available.

Back to Top

142. Is a Health Plan Required to Respond Back with the Health Plan Name (Assuming it is Available Within the System(s)) in EB05 Element of all EB Segments Sent Back in the Response?

Since the CORE rule does not explicitly identify which EB segments are to carry the Health Plan Name, it could appear on all or some of the EB segments returned. Therefore, the health plan should include the name of the health plan (when available) in EB05 ONLY when EB03=30 Health Benefit Plan Coverage and NOT return it redundantly on every other EB segment, unless the name of the health plan is different for a given service type.

Back to Top

III. CORE Operating Rule FAQs
    Phase I Rule FAQs - 155: Batch Response Time Rule



143. 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 CORE 153: Connectivity Rule Version 1.0.0 specifies a maximum HTTP response time of 60 seconds because this is specific to the telecommunications method used.

Back to Top

144. If a 270 Is Received in a Batch, Does the 271 Have to be Returned in a Batch?

The CORE rule dos not address this issue. The batch response time rule only requires that a health plan have the batch pf responses available by 7:00am the next business day following a submission of inquiries by 9:00pm ET. Therefore, the CORE rule does not specify one way or another whether or not the batch of 271 responses must match exactly the batch of 270 inquiries.

Back to Top

145. Do the Time Frames Still Apply if it is an Especially Large Batch? Do the CORE Rules Define the Batch Size?

CORE does not define batch size. The rule states that all batch inquiries must be compliant with the rule.

Back to Top

III. CORE Operating Rule FAQs
    Phase I Rule FAQs - 156: Real Time Response Time Rule



146. 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.

Back to Top

147. Is There a Standard Reporting Form for the Conformance Reporting?

No. CORE does not mandate a particular form.

Back to Top

148. 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.

Back to Top

149. What Is the Minimum Information from the X12 Transaction That Needs to Be Stored? Can the Standard Provide a Recommendation for This Data?
     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.

Back to Top

III. CORE Operating Rule FAQs
    Phase I Rule FAQs - 157: System Availability Rule



150. 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.

Back to Top

151. 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.

Back to Top

III. CORE Operating Rule FAQs
    Phase II Rule FAQs - 250: Claim Status Rule



152. To What Specifically Does the Claim Status Rule Apply?

The Claim Status rule applies when a CORE Phase II-certified entity uses, conducts, or processes the HIPAA-adopted 276/277 Health Care Claim Status Request and Response transactions.

Back to Top

153. How Does the Phase II Claim Status Rule Relate to Phase I?

The CORE 250 Claim Status rule relates to CORE Phase I rules in the following ways:

• The Phase I infrastructure rules, which were created to increase access to the 270/271 transaction, also apply to the Claim Status rules for the 276/277 HIPAA transactions.
• As with the other Phase II rules, general CORE policies also apply to the Phase II Claim Status rule as outlined in the CORE Phase II Policies 200-205, e.g., as in Phase I, there will be certification testing for each stakeholder, there is a health plan exemption policy for system migration, and entities only are required to test for and meet Batch rule requirements if they offer Batch.
• All CORE rules are a minimum requirement; a CORE-certified entity is free to offer more than what is required in the rule.
• Providers, vendors, clearinghouses and health plans all need to meet appropriate aspects of the rule and all will be tested via CORE certification testing.

Back to Top

154. What Are the Phase I Infrastructure Rules, in Addition to the Phase I Connectivity Rule, Which Must Be Followed in Conducting the Claim Status Transaction in Phase II?

Detailed infrastructure requirements for conducting Phase II Claim Status transactions include compliance with the following CORE Phase I rules:

• Acknowledgements
• Batch (see CORE 150)
• Real-time (see CORE 151)
• Companion Guide (see CORE 152)
• Response Time
• Batch (see CORE 155)
• Real-time (see CORE 156)
• System availability (see CORE 157)

Back to Top

155. As a Vendor Offering Only Claim Status Transaction Support to Our Clients (We Do Not Use the 270/271 Eligibility Transactions.) Are We Able to Become CORE Phase II Certified for Claim Status?

Yes, vendors and clearinghouses are only required to certify for the transaction type(s) offered (i.e., eligibility and/or claim status). In your case, upon successful completion of Phase II certification requirements for claim status, your organization would receive a CORE Certification Seal for Claim Status.

Back to Top

156. Conversely, Can an Entity Become CORE Phase II Certified if it Processes the 270/271 Eligibility Transactions, but DOES NOT Use or Process Claim Status Transactions?

Yes, an entity that processes 270/271 eligibility transactions, and does not process claim status transactions can become Phase II certified, that is the Phase II operating rules do not require an organization to conduct, use or process the 276/277 claim status transactions if it does not currently do so.

Back to Top

157. As a Phase II-certified Entity, Will I Be Required to Apply and Test for Compliance to the CORE Phase II Patient Identifiers Rules, i.e., Last Name Normalization and AAA Error Code Rules?

No, as with the other Phase II infrastructure rules such as Connectivity, you are not required to apply the Phase II Patient Identifiers rules to the conduct of the claim status transactions. Note, however, that any entity wishing to apply the Phase II infrastructure rules in the processing of claim status transactions may do so at its own discretion.

Back to Top

158. My Organization Is Committed to Becoming CORE Phase II Certified and Will Be in Compliance With All Phase II Rules, Including CORE 270 Connectivity in Supporting the 270/271 Eligibility Transactions. In Implementing the Claim Status Transactions (276/277) Are We Limited to Supporting Connectivity at the Phase I Level since we Use X.509 Certificates Over SSL for Authentication Handling in Addition to Username/Password?

No, as a Phase II-certified entity implementing the 276/277 transaction your organization is not limited to supporting connectivity at the Phase I level. CORE operating rules represent a floor not a ceiling requirement. Though the Phase II Claims Status transaction does require you to support, at a minimum, connectivity at the Phase I level you may at your discretion implement the Phase II Connectivity specifications for these transactions.

Back to Top

159. How Did CORE Decide that HTTP/S Is Secure and Reliable Enough to Protect the Delivery of Healthcare Information Over the Internet?

In Phase I development discussions, 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.

Back to Top

160. May Payers Support Other Versions of HTTPS in Addition To v1.1, as Required in the Rule?

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, which applies to the conduct of this Phase II Claim Status rule, 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.

Back to Top

161. Is There a Required Format in CORE Phase I Connectivity 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, in CORE Phase II and future phases, CORE does require a specific format for sending these data elements. 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.

Back to Top

162. 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, as applies to this Phase II Claim Status 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 this rule.

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.

Back to Top

163. 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 II 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.

Back to Top

164. 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.

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.

Back to Top

165. 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?

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.

The CORE Phase II Connectivity Rule includes requirements for both Username/Password and X.509 Certificates over SSL as submitter authentication standards, with specific conformance requirements for the client (e.g., submitters/providers) and the server (e.g., health plans.) (See CORE 270 Phase II Connectivity Rule.)

Back to Top

166. 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.

Back to Top

167. 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.

Back to Top

168. 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.

Back to Top

169. 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.

Back to Top

170. 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. Please speak with your CORE-authorized certification testing vendor on how they will work with you on this issue during testing. An example of how it could be implemented is below.

1) Client (provider or their intermediary) sends an HTTPS POST message with a data content of: something like:
   
     ListBatchResponses
     *.277
   

2) Server (payer or their intermediary) responds with a data content of something like:
< Message>
   
      20080208_12345.277
     20080208_543627.277
   

3) Client decides which file to retrieve and sends a request like:
   
     GetFile
     20080208_543627.277
   

4) And the server sends it back in something like:
   
     20080208_543627.277
     
   

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

Back to Top

171. Batch Processing: My Organization’s System Can Provide a 997 Back on Batch Transactions Within 20 Seconds. Why Can’t 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.

Back to Top

172. 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.

Back to Top

173. 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.

Back to Top

174. 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 policies.

Back to Top

175. 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.

Back to Top

176. 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.

Back to Top

177. 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 277 response, which is left to the appropriate implementation guide. According to the X12 guide, there is no requirement for a batch 277 to respond to every request included in a batch 276. For the HIPAA-mandated X12 276/277 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.

Back to Top

178. 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 277 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 276/277 for more information on linking batch responses to the corresponding request.

Back to Top

179. For the Purposes of the Re-transmission, What Is the Definition of a Duplicate Transaction?

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

Back to Top

180. 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.

Back to Top

181. Is There a Retention Time Period required by the CORE Rule for How Long the Source Needs to Maintain This Transaction 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.

Back to Top

182. 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
• HTS (the format used by NEHEN in New England) http://www.nehen.org
• MN HIPAA Collaborative (Minnesota) http://www.mnhipaacollab.org/
• Other examples submitted to CAQH (http://www.caqh.org) – CAQH has created the Phase I HTTPS Examples document based on these submissions. The examples document can be provided upon request.

Back to Top

183. 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. Neither do CORE rules 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 Phase I connectivity rules, which apply to the Phase II Claim Status rule, do not require any specific architecture. Rather, CORE rules specify 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, particularly the clause in HIPAA that says payers cannot charge more than the cost of telecommunications for handling the connectivity.

Back to Top

184. 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.

Back to Top

185. Is the Payload ID Outside the X12 Interchange?

Yes.

Back to Top

186. 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.

Back to Top

187. 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 277 response. In the real time usage, the submitter can tie the 277 response to the Payload ID because the 277 response in the real time mode is passed within the same communication session used to send the Payload ID and the requesting 276. In the batch usage, the acknowledging response to the submission is sufficient to record that a particular Payload was successfully delivered.

Back to Top

188. 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.

Back to Top

189. What Should Be Expected from Trading Partners Regarding the Payload IDs, and How It Should Be Used?

An entity should expect to receive a long, possibly alphanumeric, ID from its trading partners and should be able to store that ID and associate it with each X12 real time message processed from the trading partner through the supported HTTP communication system. 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.

Back to Top

190. 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 277 responses be transferred to the provider's system without a need for human intervention.

Back to Top

191. 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.

Back to Top

192. Can my Organization Run a 276/277 Transaction on XML?

An XML-based claim status inquiry and response equivalent to the X12 276/277 can not be used in place of an ASCII character-based 276/277. However, your organization can accept the 276 into its EDI system either directly from a provider or through a clearinghouse and, then convert it into another format for internal processing, e.g., XML or some other proprietary format.

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

Back to Top

193. For Real Time Transactions, Our System does not Automatically Resend Failed Responses, However the Client Can Go in and Send the Same Request Manually. Must We Prevent the Client from Being Able to Resubmit the Same Request (Even Manually) for 90 Seconds After the Original Request was Sent?

Yes, whether it is an automated or manual re-send the re-send attempts cannot occur more frequently than what is specified in the CORE rule.

Back to Top

194. How Should We Respond to the Transaction if the Date/Time and/or Payload ID are Not Present?

Such a message would represent a CORE non-compliant message. The CORE rule does not require such a message to be either rejected or accepted by the receiver. It is the receiver's decision regarding acceptance of a non-compliant message.

Back to Top

195. Is There a More Precise Definition as to Where User ID, Password, Date/Time and Payload ID Should Appear in the Data Stream? The Document References “HTTP Message Body” and “HTTP Message Header tags”.

There are no more precise specifications in the Phase I Rule. This decision is left to the message originator.

Back to Top

196. 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 277 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 277 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.

Back to Top

197. 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.

Back to Top

198. The TA1 Interchange Acknowledgment is Described in the HIPAA Implementation Guide Appendix B: EDI Control Directory. The Note for the ISA14-I13 Acknowledgment Requested Data Element Indicates that Trading Partners May Mutually Agree on 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 Require 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.

Back to Top

199. Is an Acknowledgement Necessary if the User Sends Claim Status Data in a Proprietary (Not a 277) Format in 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 Claim Status rule is focused on the conduct of the HIPAA-named X12 276/277 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 276/277 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.

Back to Top

200. Are all CORE Rules With Regard to Acknowledgement Only Applicable to Scenarios Where my Organization Receives Data in a 276 Format?

Please see FAQ above.

Back to Top

201. Is GS08 Supposed to Be 004010 or That of the Transaction Set, Such as 004010X093A1?

GS08 is a code indicating the version, release, subrelease, and industry identifier of the EDI standard being used, if the code in GS07 (DE455) is an X, then in GS08 (DE480) positions 1-3 are the version number; positions 4-6 are the release and subrelease, level of the version; and positions 7-12 are the industry or trade association identifiers (optionally assigned by user).

In the case of an FA (functional acknowledgement) functional group, the value in GS08 refers to the version, release, subrelease, and industry identifier of the GS08 of the functional group itself and not the functional group being acknowledged.

Therefore in the scenario outlined in the request the proper value for GS08 would be '004010' assuming there was no industry or trade association identifier in use for the 997.

Please note also that the version of the functional acknowledgement does not have to be the same version as the transaction being acknowledged. For example, a version 5010 997 can be used to acknowledge a version 4010 276.

Back to Top

202. 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: Batch Acknowledgements Rule 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.

Back to Top

203. 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, which the Phase II Claim Status transaction follows, 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.

Back to Top

204. 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 Phase II Test Suite to become CORE-certified. The test scripts for the CORE 150: Batch Acknowledgements Rule Version 1.0.0, which the Phase II Claim Status transaction follows, will test for your system’s capabilities to return the 997 acknowledgment.

Back to Top

205. The TA1 Interchange Acknowledgment is Described in the HIPAA Implementation Guide Appendix B: EDI Control Directory. The Note for the ISA14-I13 Acknowledgment Requested Data Element Indicates that Trading Partners May Mutually Agree on 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 Require 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.

Back to Top

206. 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 276 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.

Back to Top

207. 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.

Back to Top

208. Is There a Standard Reporting Form for the Conformance Reporting?

No. CORE does not mandate a particular form.

Back to Top

209. 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.

Back to Top

210. 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.

Back to Top

211. 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 CORE 153: Connectivity Rule Version 1.0.0, which the Phase II Claim Status transaction follows, specifies a maximum HTTP response time of 60 second because this is specific to the telecommunications method used.

Back to Top

212. If a 276 is Received in a Batch, Does the 277 Have to Be Returned in a Batch?

The CORE rule does not address this issue. The batch response time rule only requires that a health plan have the batch responses available by 7:00am the next business day following a submission of inquiries by 9:00pm ET. Therefore, the CORE rule does not specify one way or another whether or not the batch of 277 responses must match exactly the batch of 276 inquiries.

Back to Top

213. Do the Time Frames Still Apply if it is an Especially Large Batch? Do the CORE Rules Define the Batch Size?

CORE does not define batch size. The rule states that all batch inquiries must be compliant with the rule.

Back to Top

214. My Organization Includes System Availability Schedules in Our Companion Guide. Does This Satisfy the CORE Rule Requirements for System Availability Reporting?

Yes, 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.

Back to Top

215. 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.

Back to Top

216. Why Was the CORE 152: Companion Guide Rule Version 1.0.0 (Which Is the Basis For the Phase II Claim Status Rule’s Companion Guide Template Requirement) 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 the 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 (see CORE 250: Claim Status rule, Section 4.7) was adapted from the CAQH/WEDI Best Practices Companion Guide Template.

Back to Top

217. Will All of the Detailed Content of My Organization’s 276/277 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.

Back to Top

III. CORE Operating Rule FAQs
    Phase II Rule FAQs - 258: Normalizing Patient Last Name Rule



218. In Reviewing the Rule, I Could Not Find Any Statement on How Hyphenated or Apostrophized Last Names Would Be Handled, e.g., O'Donnell-Griswold? Would it Be Just ODonnell? Or is This Something Which Is or Has Been Addressed in Another Rule?

The Phase II Last Name Normalization rule DOES require the removal of both the apostrophe and the hyphen in the O’Donnell-Griswold example cited.

The normalized name would be ODONNELLGRISWOLD. Section 3.7 (3) lists the X12-designated “special characters” of the “Basic Character Set” and the list includes both the apostrophe and the hyphen. Section 4.2.1 of the rule then says “remove the special characters specified in §3.7 in the name element.”

Back to Top

219. We Have a Situation in Which Some Beneficiaries May Have Two Last Names as in the Case of Beneficiaries in Puerto Rico in Which a Married Woman Will Keep Her Last Name and Add “De” as the Prefix to Her Husband’s Last Name (e.g., Maria Garcia DeSanchez). Garcia Is the Maiden Name and Sanchez is the Married Name. How Does CORE Propose the Handling of Patient Last Name in This Situation?

The CORE Last Name Normalization Rule does not address this specific scenario. Since the characters “De” are not included in the specified set of character strings to be removed, any validation of the last name performed by the health plan would naturally be against what was submitted in the Last Name data element in the 270 against what the health plan maintains in its eligibility system. This is outside the scope of the CORE rule.

Back to Top

220. With Regard to Section 4.2.2 - Character Strings to be Removed During Name Normalization, What Recommendations Does CORE Have for Instances Where the Last Name Contains Concatenated Last Name + Suffix? For example, With the Patient Name JAMES C POMP II, Last Name May be Stored as “POMPII”. How Can We Tell if the Last Name Should Be “Pomp” and Not “Pompii” and Strip the “II” by Mistake? While the Instance of a JR/SR Suffix Can Easily Be Identified, Others Such as “MD” and “RN” Will Be More Difficult to Identify as in the Case of a Name Ending in “RN” Like “BURN”). In Most Cases the Last Names are Concatenated with Suffixes and Not in a Separate Field and Not Easily Identifiable.

The CORE rule includes the character string “II” in the set of specified character strings to be removed during normalization (Section 4.2.2.) Additionally, the rule in Section 4.2.1 defines how to normalize the last name, to wit: “To normalize the submitted and stored last name remove all of the character strings specified in Section 4.2.1 when they are preceded by one of the punctuation values specified in Section 4.2.3 and followed by a space or when they are preceded by one of the punctuation values specified in Section 4.2.3 and are at the end of the data element and remove the special characters specified in Section 3.7 in the name element.

If the last name as submitted and as stored is not delimiting the suffix using one of the specified punctuation values or store the suffix separately, the normalization logic will not remove the character string “II”. The CORE rule does not specify HOW an entity must store a last name, but does make recommendations on this issue in Sections 4.1.1 and 4.1.2.

Back to Top

221. If A Health Plan Receives The Subscriber ID Number And The Subscriber Last Name In The 270 Inquiry, Does The Health Plan Have To Use The Subscriber Last Name Or Can They Ignore The Subscriber Last Name When Processing The 270 Inquiry?

The CORE Phase II Normalizing Patient Last Name Rule does not require that a health plan use the patient’s last name in its search and matching logic for locating an individual within its systems. Further, the rule does not specify the search criteria used by a health plan (or information source) to identify a patient in its systems. That is, when the last name is not used in the health plan’s search/match logic – the rule does not apply – and if the health plan receives the patients unique ID number in a 270 eligibility inquiry, it may use or ignore the name or other demographic data about the individual if not needed or used to uniquely locate that individual in the plan’s systems.

Back to Top

III. CORE Operating Rule FAQs
    Phase II Rule FAQs - 259: AAA Error Code Reporting Rule



222. Can a Health Plan/Information Source Return a AAA Error Segment That Contains Only the First Error Condition Detected or Must They Return as Many AAA Segments as There Are Errors in the 270?

A Health Plan/Information Source is required to return a AAA segment for each error condition that it detects in a 270 request, as described in sections 4.3-4.5 of the rule.

Back to Top

223. Is the Receiver of the 271 Response Expected to Be Able to Detect All AAA Segment Error Conditions Reported by the Vendor/Health Plan and Display Them to an End User?

Yes, the receiver of the 271 response, i.e., the system that originated the 270 inquiry, is required to detect all combinations of error conditions from the AAA segments in the 271 responses, as defined in Table 4.5-1 Error Reporting Codes & Requirements, and to display to the receiving system’s end user text that uniquely describes the specific error condition(s) and data elements returned by the health plan in the 271 response.

Back to Top

224. When a Health Plan’s Search Criteria Detects Errors During Its Subscriber/Dependent Verification Editing Process, Does The CORE AAA Error Reporting Rule Specify In What Loop (Subscriber Or Dependent) The Error Should Be Reported?

The Phase II CORE 259 AAA Error Code Reporting Rule identifies 18 error conditions, some of which may occur in the subscriber loop and others which may occur in the dependent loop. Section 4.4 of the CORE rule states that “when a health plan detects any of the specified error conditions it must return an appropriate AAA segment for each error detected and return other data elements as specified.” Thus, the health plan would determine the loop in which to return the appropriate AAA error codes required by the CORE rule as long as it is consistent with the HIPAA v4010A1 Implementation Guide.

Back to Top

225. Does the AAA Error Code Reporting Rule Require a Health Plan to Validate DOB?

No, this CORE rule does not require a health plan (or information source) to validate a DOB; however, when a DOB is validated and errors are found, the receiver of the 270 inquiry is required to return a 271 response as specified in the rule.

Back to Top

226. Does the AAA Error Code Reporting Rule Require That Certified Entities Use Specific AAA03 Error Codes for Specific Errors?

Yes, the rule specifically identifies the AAA03 error codes that must be returned for each error condition, which may occur in either or both of the Subscriber or Dependent loops (refer to rule section 4.5 and the Error Reporting Codes & Requirements Table.

Back to Top

227. Does This Rule Require Specific Search or Match Criteria Logic to Be Used When Validating Member Demographic Data?

No, the AAA Error Code Reporting Rule does not require a Health Plan/Information Source to use any specific search and match criteria or logic.

Back to Top

228. Is A Health Plan Or Information Source Required To Return A 271 Response With The Specified AAA Error Codes For Each Of The Six Test Scripts For The AAA Error Code Reporting Rule? 

No. Due to the variability in search and match logic and the data elements used by health plans and information sources, some health plans and information sources may actually match the member in the 270 Inquiry test case rather than return the expected AAA error code in the 271 Response. A certifying entity can successfully pass the test for this rule by generating at least one 271 Response with an AAA Error Code for at least one of the six test scripts.

Back to Top

III. CORE Operating Rule FAQs
    Phase II Rule FAQs - 260: Data Content (270/271) Rule




Please refer to the FAQs posted for the CORE 154: Phase I Eligibility & Benefits (270/271) Data Content Rule. The Phase II Data Content (270/271) Rule builds upon and enhances the Phase I rule, therefore we recommend that you familiarize yourself with these foundational Questions and Answers as they will, in large part, provide a basis for understanding the Phase II rule as well.

229. What is the Relationship Between the Eligibility Data Content (270/271) Rules in Phase I and Phase II?

The CORE Phase I 270/271 Data Content Rule provides an important first step toward improving eligibility and benefits verification. It outlines a set of requirements for health plans to return base patient financial responsibility amounts related to deductible, co-pay and co-insurance for a set of 9 services in the 271 eligibility response transaction. It also includes requirements for vendors, clearinghouses and providers to transmit and use this financial data.

The CORE Phase II Eligibility and Benefits Data Content (270/271) Rule extends and enhances the Phase I 271 response transaction by requiring the return of remaining deductible amounts for both the Phase I-required 9 service type codes and an additional 39 other service type codes. The Phase II Rule also requires, in addition to base patient financial responsibility, that year-to-date remaining or accumulated amounts be returned for explicit benefits eligibility requests.

Back to Top

230. My Health Plan Supports 270 Eligibility Inquiries Using Diagnosis/Procedure Codes In Addition To Service Type Codes. Are We Required To Return Comprehensive Benefit Level Details In Our 271 Response As If The 270 Inquiry Were a Generic Inquiry Using Service Type Code 30 When We Receive a 270 Eligibility Inquiry That Includes Diagnosis/Procedure Codes?

No. The CORE rules do not address the use of diagnosis/procedure codes in either a 270 eligibility inquiry or a 271 response. Therefore, the health plan or information source can determine data content for a 271 response to such a 270 inquiry as long as it is consistent with the HIPAA v4010A1 Implementation Guide.

Back to Top

231. As a Health Plan, If I Receive a 270 Request for a Service Type Not Required By the CORE Phase II Data Content (270/271) Rule AND the Plan Does Not Support That Service Type, are We Required to Respond and, If So, How?

Yes. If a request is submitted for a service type that is not required by this rule, and the receiving Health Plan does not support the service type(s), that Health Plan is required to respond with a “generic inquiry” response.

Back to Top

232. As a Health Plan, Are We Required to Respond to Explicit Benefit Inquiries? We Do Not Currently Return Patient Financial Responsibility Information, i.e., Co-pay and Deductible, for Several Behavioral Health-related Benefits/Services That Are Required.

Yes, Phase II certified entities are required, at a minimum, to return the coverage status for each specific benefit (service type) included in a 270 eligibility request that is required in response to an explicit inquiry (see Table 4.1.1.2 in the Rule). That is, even if you are exercising your company’s discretion not to return patient financial liability information for one of the eight listed “discretionary” service types, you must return the health plan coverage status for that code in the EB01 segment in the 2110C or 2110D loop, as appropriate.

Back to Top

233. With Regard to Co-insurance, When it Says a Certain Percentage (e.g., 20%) vs. a Certain Percentage After Deductible (Say 20% after deductible), How Is This Supposed to Be Interpreted in the EB Segment? Or, Is This Supposed to Be Noted in the MSG Segment?

Phase II test data is no different from Phase I test data. The Health Plan is free to align co-insurance responses with their own benefit plan structures when loading the test data. The Data Content Rules specify how to return co-insurance percent amount and do not address these other aspects. CORE rule section 4.1.3.3 specifies which data elements are addressed by the CORE rule in the EB segment for co-insurance. Other situational data elements and segments are not addressed by the CORE rules; thus the health plan can either use or not use these other data elements and segments as consistent with their own internal health plan benefit structures.

Back to Top

234. If a Benefit is Covered for In-network Providers Only, How Does a Health Plan Indicate That There is No Coverage for Out-of-network Provider Services?

A Health Plan, or information source, must indicate non-covered status for out-of-network providers for each service type by returning code “I” (non-covered) in the EB01 data element and a “N” in the EB12-1073 Yes/No – In Plan Network indicator as follows:
     EB01 = I-Non Covered)
     EB02 =
     EB12 = N

Back to Top

235. With Regard to How Health Plans Currently Handle Co-ordination of Benefits (COB), How Should Plans Respond to a 270 Eligibility Request If that Plan Is Not the Primary Payer? Specifically, Should the Payer Respond With an EBR (Electronic Batch Report) Explaining This, or Return the Plan Information That Is the Secondary Coverage?

This is an aspect of the 271 eligibility response’s capability that is not currently addressed in either the CORE Phase I or Phase II Eligibility & Benefits Data Content (270/271) rules. CAQH has recommended that a request be submitted to the X12 WG1 Eligibility Work Group via the X12 HIPAA Interpretation Request (HIR) portal at http://www.x12n.org/portal/. X12’s interpretation could then be used, if appropriate, in Phase III rule-writing discussions for possible inclusion in Phase III rule requirements.

Back to Top

236. If a Plan Member Has Primary and Secondary Coverage Through a Plan, Should the Health Plan Acknowledge This In the 271 Response?

If an individual is covered by a plan as primary, that Health Plan should respond with the 271 according to both the HIPAA implementation guide and the CORE 270/271 Data Content rules.

Back to Top

237. Do The CORE Eligibility Data Content Rules Specify That The Range Of Dates Applicable To Deductibles That May Be Returned In a 271 Eligibility Response Must Be For a Full Year, Or Can The Range Of Dates Be For Less Than a Full Year?

The Phase II CORE 260 Eligibility & Benefits (270/271) Data Content Rule does not restrict the range of dates applicable to deductibles to be a full year. The CORE rule requires that a begin date applicable to deductibles must be returned for the health plan coverage and that alternatively a range of dates may be returned. The range of dates is determined by the health plan and may be less than or greater than a full year. See §4.1.4 and §4.1.4.2.

Back to Top

III. CORE Operating Rule FAQs
    Phase II Rule FAQs - 270: Connectivity Rule




Please refer to the FAQs posted for the CORE 153: Phase I Connectivity Rule. The Phase II Connectivity Rule builds upon and enhances the Phase I rule, therefore we recommend that you familiarize yourself with these Phase I “foundational” Questions and Answers (FAQs 78 – 115) as they will, in large part, provide a solid basis for understanding the Phase II rule.

238. How Do the Envelope Standards in CORE Phase II Connectivity Rule Relate to the Ones That Have Been Chosen by HITSP, HL7, and IHE?

CORE Phase II Connectivity Rule is based on the use of SOAP+WSDL or HTTP+MIME Multipart envelopes for transport and routing, and on the use of username/password or X.509 Client Certificate based authentication over SSL for submitter authentication. The SOAP+WSDL envelope option, and the X.509 Client Certificate based authentication option are well aligned with the direction of HITSP, HL7 and IHE. The HTTP+MIME Multipart envelope was chosen due to its large installed base in this industry. Since the difference in complexity of these two standards is not significant, it is expected that there will be convergence on a single envelope standard and a single authentication standard in the long term.

Back to Top

239. It Is My Understanding That HITSP T85 (Administrative Transport To Health Plan) Is Based On The CORE 270 Connectivity Rule. Does This Mean That If I Am CORE Phase II Connectivity Certified I Will Meet HITSP T85 Requirements?

No. Though HITSP T85 (Administrative Transport to Health Plan) uses the CORE 270 Connectivity Rule, this does not mean that by being CORE Phase II Connectivity certified you will meet HITSP T85 requirements. The CORE 270 Connectivity Rule specifies the use of the public Internet using HTTP with SSL as the minimum security for the communications channel, using specific envelopes, and metadata and submitter authentication methods. HITSP T85 instead uses HITSP/T17 Secured Communications Channel, which exceeds the requirements of CORE 270 Connectivity Rule. For instance, HITSP T17 uses Transport Layer Security (TLS) instead of SSL. The CAQH CORE 270 Connectivity Rule provides a safe harbor specifying minimum requirements, but does not preclude the use of other communications channels.

Back to Top

240. What Is the Relationship Between the Connectivity Rules in Phase I and Phase II?

The Phase I Connectivity Rule provided an important first step toward connectivity by including requirements for:

• Use of HTTP/S transport protocol over the public Internet,
• Use of a specified minimum data set of metadata outside the X12 payload, e.g., date/time and payload ID,
• Response times, acknowledgements and error notification

Phase II Connectivity builds upon the Phase I foundation continuing to provide a safe harbor for CORE-certified entities while including more definitive requirements beyond the transport level to the message envelop level. These enhancements in the Phase II Connectivity Rule provide requirements for encapsulating an expanded set of metadata needed for routing, submitter identification/authentication and auditing. Additionally, the Phase II Connectivity requirements for message envelope and submitter authentication standards usage will significantly reduce the variation that exists in current implementations, thus supporting greater interoperability between trading partners.

Back to Top

241. Will CORE Continue to Offer Both Phase Certifications, or Will Phase I Certifications Not Be Supported After Some Time?

Yes. Certifications for both CORE Phase I and Phase II rules will continue to be available, as there is no currently established policy for withdrawing or deprecating previous phases of CORE operating rules. CORE represents a phased approach to developing operating rules for healthcare administrative transactions, and to become CORE Phase II certified an entity must be Phase I certified. Alternatively, an entity that is not yet Phase I certified may elect to test for Phase I and Phase II concurrently.

As CORE moves to future phases, certified entities and entities wishing to become CORE-certified are encouraged to adopt and become certified at the highest, most recently-approved, CORE phase rules. Broader adoption of advanced CORE rules will enhance the usability and content of various administrative transactions while decreasing associated administrative costs and resources.

Back to Top

242. Does an Organization Need to Comply With All Aspects of the CORE Phase II Rule (e.g., Data, Connectivity) In Order to be Phase II Certified?

In general terms, the answer is yes - an organization must comply with all aspects of the CORE Phase II Rules to become Phase II certified, with several specific exceptions:

• Connectivity Rule: Certification is available for both real-time and batch processing. However, if an entity does not support batch transactions, it will not be required to comply with the batch rules. An entity supporting both real-time and batch will be required to comply with rules for both.
• Compliance is only required for the transaction(s) offered by the certifying entity. If a Vendor or clearinghouse does not offer a product/service for which CORE certification exists in Phase II it may be certified after submitting an attestation to this fact. For example, when a vendor or clearinghouse does not conduct eligibility 270/271 transactions, but rather offers only 276/277 claim status transactions; it will not have to comply with the rules applicable to eligibility.

Back to Top

243. Is Certification Available on Specific Aspects of the CORE Phase II Rule, such as Connectivity alone?

No. An entity seeking CORE Phase II certification must comply with all of the Phase II operating rules to become CORE Phase II certified, with the exceptions noted in the above FAQ.

Back to Top

244. My Organization is Not CORE Certified. Which Phase Certification is Applicable to Us?

While CORE certification is voluntary, both the decision to become CORE certified and determination on which phase certification is applicable is an internal business decision. An entity’s decision should be based on a review of its business requirements and system capabilities (and those of its trading partners) as well as scope and functionality of the rule phases being considered (See FAQ #5).

Notes:
1. Organizations must complete certification testing in succession (i.e., must be Phase I certified before testing for Phase II or test concurrently for both).
2. Certified entities must demonstrate compliance with all applicable CORE rules of the given Phase for which they are certifying.

Back to Top

245. My Organization is CORE Phase I Certified. If we Go Through CORE Phase II Certification, Are We Required to Continue to Accept Connections From Partners Who Are Only CORE Phase I Compliant/Certified?

No. If your organization has achieved CORE Phase II certification, it is not required to support or accept connections from CORE Phase I certified entities. Rather, it is left up to the trading partners to determine if Phase I or Phase II rules will be followed.

Back to Top

246. Why Were Two Envelope Standards Chosen in CORE Phase II Connectivity Rule?

After extensive analysis of the open standards currently in use for enveloping messages or payloads, e.g., X12 transactions or other types of data, the Connectivity Subgroup selected HTTP MIME Multipart and SOAP + WSDL as the two standards that both met the majority of CORE’s agreed-upon criteria and were in wide use in the marketplace. Further lengthy discussions of the pros and cons of each envelop methodology confirmed considerable argument for each standard meeting the industry’s needs with no clear winner emerging.

The Subgroup debated the advantages and challenges associated with forwarding a single envelope standard rule versus one which included both of these standards and whether a single standard facilitated better interoperability. The Subgroup came to a consensus on the two envelope standards as it is believed to allow broader acceptance for the future installed base. The Subgroup also agreed that a single message envelope standard will be a goal for future phases to reach. Conformance guidance is provided as part of the Connectivity Rule for all stakeholders to implement one or both of these envelope standards.

Back to Top

247. Why Were Two Authentication Standards Chosen in CORE Phase II Connectivity Rule?

The Connectivity Subgroup evaluated the connectivity implementations currently used by its members, including what types of submitter authentication methods were being used. The results showed widespread use of both username/password and X.509 client certificate authentication. Though username/password is the base requirement with Phase I and is widely implemented across the industry, X.509 Certificates was agreed to be an important step toward ensuring data security over the public Internet and a direction in which the industry is heading. Similar to the decision on envelope standards, a decision was made to allow both authentication standards with the necessary conformance guidance for all stakeholders.

Back to Top

248. Does CORE Have Plans to Converge on a Single Envelope/Authentication Standard in Future Phases?

CORE expects that in future phases CORE requirements will include single, specific standards in both of these areas. The Phase II inclusion of two envelope and authentication standards and appropriate conformance requirements greatly improves the situation in the marketplace by reducing variation in options currently available and in use. This phased step will provide the basis for a more informed decision when considering single standard recommendations moving forward.

Back to Top

249. If My Organization Wants to Become CORE Phase II Compliant, Which Envelope Standards Must We Support?

As the Phase II Connectivity Rule supports two envelope standards, it is necessary to specify conformance requirements for stakeholders, based on the role they play in the transaction. Section 4.1 Basic Conformance Requirements for Key Stakeholders provides detailed requirements for which of the envelope standards you must support, based on whether your organization is acting as a client or server in the request/response transactions. Briefly, the requirements for these stakeholder categories are:

• Health Plans and Health Plan Vendors acting as the Server must support both message envelope standards.
• Clearinghouses and Other Intermediaries, i.e., clearinghouses, switches, and information exchanges, acting as both Client and Server, must implement both message envelope standards when acting in the capacity as Server, and must support one of the two envelope standards if acting the Client in transactions.
• Providers and Provider Vendors, which act as Clients must implement one of the two message envelope standards.

(See Connectivity Rule: Section 4.1)

Back to Top

250. If My Organization Wants to Become CORE Phase II Compliant. Which Authentication Standards Are Applicable?

Conformance requirements for implementing Submitter Authentication Standards are provided in Section 4.1 of the Phase II Connectivity Rule by key stakeholder categories acting in either the Clint or Server role. Briefly, the requirements for these stakeholder categories are:

• Health Plans and Health Plan Vendors, acting as the Server, must support one of the two submitter authentication standards.
• Healthcare Providers, Provider Vendors and Clearinghouses, acting as the Client must implement the client portions of authentication for both submitter authentication standards.

(See Connectivity Rule: Section 4.1)

Back to Top

251. We Have a Private Network (e.g., VPN Connection) for Eligibility Transactions. Can We Use the SOAP or HTTP-MIME Multipart Envelopes Over This Network and Get CORE Phase II Certified?

Although the use of SOAP or HTTP/MIME envelopes over private networks like VPNs is possible, CORE Phase II Connectivity Rule requires the use of HTTP/S over the public Internet. The CORE Phase I Connectivity was based on use of the public Internet for transport, and CORE Phase II Connectivity Rule builds on Phase I, while retaining the same underlying transport.

Back to Top

252. We Use a Non-TCP/IP Network (e.g., X.25, Frame Relay). Can We Use the SOAP or HTTP/MIME Envelopes Over These Networks and Get CORE Phase II certified?

CORE Phase II Connectivity Rule is applicable only to TCP/IP based networks. In fact, the use of HTTPS over public Internet (which in turn is based on the use of TCP/IP) is required. The CORE Phase I Connectivity was based on use of the public Internet (which is TCP/IP based) for transport, and CORE Phase II Connectivity Rule builds on Phase I, while retaining the same underlying transport.

Back to Top

253. Is the CORE Phase II Connectivity Rule Applicable Only to the ANSI X12 270/271 Transactions?

Yes. The Phase II Connectivity Rule is only applicable—required to be followed—when a certified entity is using the 270/271 Eligibility transactions, though Phase II Connectivity may also be applied to other HIPAA administrative X12 transactions or payload types., e.g., even though CORE Phase II only requires Phase I Connectivity compliance for the Claim Status transaction, entities may decide to also apply the Phase II Connectivity Rule to Claim Status. Note: CORE rules specify a baseline requirement. Entities are welcome to expand on the CORE rules.

Back to Top

254. What About non-X12 Payloads? Can the Same Envelope and Authentication Standards Be Applied to Those Payloads?

Yes. The Phase II Connectivity Rule is designed to be payload agnostic, and as such it is expected, though not required, that CORE-certified entities will use this methodology for payloads other than Eligibility, specifically for other X12 administrative transactions or other content such as HL7 clinical messages or personal health records.

Back to Top

255. What Is the URL of the WSDL Schema for the SOAP+WSDL Implementation?

The URL for the CORE Phase II-compliant XML Schema specification file, CORERule2.0.1.xsd, for use within the WSDL specification is available at http://www.caqh.org/SOAP/WSDL/CORERule2.0.1.xsd.

The URL of the CORE Phase II WSDL schema is: http://www.caqh.org/SOAP/WSDL/CORERule2.0.1.wsdl.

Back to Top

256. If I Make Changes to the WSDL to Implement My Client or Server, Will I Still Be Able to Get CORE Certified?

Only those changes to the WSDL that preserve the structure and syntax of the message envelope are allowed. All field names, data types and syntax of existing fields must stay the same.

Back to Top

257. I Need to Add Some Extra Fields As Part of the Message Envelope. Is This Allowed?

Please contact CAQH staff member Steve Zlotkus at 202-778-3226 or szlotkus@caqh.org for more information. 

Back to Top

258. I Would Like to Use This SOAP+WSDL, but I Wish to Also Have Additional SOAP Headers That are Not in This Specification. Is This Allowed?

Yes. Adding additional SOAP headers is allowed.

Back to Top

259. I Am Not Planning to Use All Fields in the Message Envelope. Do I Still Need to Have All the Fields in the Envelope?

Yes. You are required to use each of the metadata element fields as described in Table 4.4.2 Table of CORE Required Metadata, and specifically as indicated for Real-time transactions, Batch transactions, or Both. Note: The Error Code and Error Message fields are only required in the Response transaction for real-time and batch as these elements are not used in the Request transaction.

Back to Top

260. What are My SenderID and ReceiverID Values? Where Can I obtain Them?

These are unique identifiers associated with your organization. They are intended for message routing and processing, or for transaction auditing, or as a reference to a business agreement by a message receiver. CORE recommends using OIDs from organizations like HL7 or IANA, but you may use other forms of organizational identifiers as well.

Back to Top

261. I Need to Add a Different Payload Type/Processing Mode Value Than What is Listed in the CORE Phase II Connectivity Rule. Is This Allowed?

Yes. Additional payload types / processing modes may be used to indicate other HIPAA administrative x12 transactions, or standard payloads such as HL7 or NCPDP transactions. Refer to Phase II Connectivity Rule, Section 4.4.4.

Back to Top

262. Who Issues the Username/Password for Use with Authentication?

The username and passwords are issued by the organization that is in the role of a Server, or by a third party that is handling user identity management on behalf of the Server organization. This is the Server to which requests (e.g., ANSI X12 270) are sent, such as a Health Plan or Clearinghouse.

Back to Top

263. Are There Any Guidelines/Restrictions on the Username and Passwords That Can Be Used?

The length of username and password should not exceed 50 characters. Beyond this, CORE Connectivity Rule does not specify guidelines/restrictions on the username and passwords.

Back to Top

264. Who Issues the Client Certificates for the X.509 Client Certificate-based Authentication?

Client Certificates may be issued by a trusted third party called a Certificate Authority (CA) such as VeriSign or Entrust, or by the entity that is receiving connections.

Back to Top

265. Are There Any Guidelines/Restrictions on the Use of Specific Certificate Authorities?

CORE has not specified guidelines/restrictions on the use of certificate authorities at this time. Client certificates used for node authentication over SSL can be issued by the organization that is receiving connections, or by a third party certificate authority that is trusted by the organization to issue these certificates on its behalf.

Back to Top

266. My Organization Requires the Use of (Transport Layer Security) TLS for Transport Security. Can a CORE Compliant Envelope Be Used Over TLS?

Since SSL is far more prevalent today than TLS, CORE Phase II Connectivity Rule specifies the use of HTTP over SSL. For CORE compliance, an entity needs to support the CORE Phase II compliant connections over SSL, but organizations may choose to additionally also support the same envelopes over TLS.

Back to Top

267. We Would Like to Implement the SOAP Envelope But Would Like to Use SOAP 1.1. Is This a Valid Approach to reaching CORE Compliance?

The SOAP+WSDL interfaces in the CORE Phase II Connectivity Rule must be implemented over SOAP 1.2 for CORE compliance. An organization may choose to additionally also offer the same interfaces over SOAP 1.1, but these would not be considered CORE compliant.

Back to Top

268. We Need to Add Some New Error Codes and Messages That Are Not Listed In the CORE Phase II Connectivity Rule. Is This Allowed?

Yes, new error codes and messages may be added when there is an error condition that is not addressed using the error codes listed in the CORE Phase II Connectivity Rule. In such cases, we recommend using standards based error codes (e.g., SOAP faults) to the extent possible. If custom error codes and messages are used, they should be described in the Entity Specific Connectivity Guide, and they should preserve the naming conventions of the error codes in the CORE Phase II Connectivity Rule.

Back to Top

269. What Is the Maximum Size of Each Batch File That Can Be Sent?

The CORE Phase II Connectivity Rule does not specify a size limit on Batch files. If your implementation imposes a limit, this should be described in your Connectivity Guide.

Back to Top

270. I Am Using the CORE Phase II Connectivity Rule for Exchanging SOAP Real-time Transactions.  The Payload Includes Non-printable Characters.  What Are the Issues I Need to Be Aware Of?

When sending or receiving payloads that contain non-printable characters; e.g., separator characters in an X12 Interchange, or in a non-X12 Interchange payload, using SOAP Real-time request/response envelope, the payload must be base64 encoded.  In CORE Phase III, the use of MTOM will be considered for attaching payloads to SOAP Real-time request/response.

Back to Top

271. To Meet CORE Phase II Connectivity Requirements For Real Time Processing, What Is The Minimum Set Of Payload Types That Must Be Supported?

Real time processing mode is required for all payload types (transactions) that are currently addressed by a CORE rule. Batch processing mode is optional. The CORE Phase II connectivity rule applies to the 270/271 transaction and can be optionally applied to the 276/277 transactions.

Back to Top

272. To Meet CORE Phase II Connectivity Requirements For Batch Processing, What Is The Minimum Set Of Payload Types That Must Be Supported?

Batch processing mode is optional for all payload types. If an organization does perform batch processing, and is certifying for Phase II connectivity using batch processing, one of the following payload types must be supported: 1) Mixed payoad, 2) 270/271, or 3) 276/277.

Back to Top

273. In The SOAP+WSDL Envelope Option, Why Is The Real Time Request/Response Payload Defined As type=xs:string And The Batch Counterparts Are Defined As base64Binary?
1. CORE member consensus was to use SOAP’s MTOM feature only for batch SOAP transactions. For real time SOAP transactions, payload is sent in-line within the envelope.
2. The real-time XSD/WSDL schemas were based on implementation examples from CORE members (from Phase I connectivity), which had xs:string for the payload type. Some implementations use CDATA tag to embed strings that should not be XML encoded. Note that xs:string could be used to populate any ASCII string including base64.
3. The base64Binary data type for payload was adopted for batch transactions to use MTOM to optimize the payload (SOAP processors optimize base64Binary data types when using MTOM).

Back to Top

274. I Have A Suggestion To Update Field X Or To Add Field Y To The Envelopes Defined In The CORE Phase II Connectivity Rule. What Is The Process For Doing This?

Please submit your request to CORE. Your request will be considered by the CORE membership for inclusion in a future phase of CORE operating rules.

Back to Top

275. Currently The PayloadType Values Provided Within The CORE Phase II Connectivity Rule Have X12 Values Listed (e.g., X12_270_004010X092A1). What Are The Corresponding PayloadType Values For Transactions Using NCPDP Payloads?

The values for the PayloadType for NCPDP transactions have been defined by NCPDP and upon their approval will appear in a new publication of the NCPDP External Code List. This list will be available to NCPDP members in the “Members” section of the website at www.ncpdp.org. Non-members may obtain all NCPDP documents with membership; please see www.ncpdp.org or contact the NCPDP office at 480-477-1000, or via email at ncpdp@ncpdp.org.

NOTE:

1. As of CORE Phase II, only Real-time NCPDP transactions are supported by the PayloadType values defined by NCPDP. CORE is working with NCPDP to identify requirements to be addressed in CORE Phase III.
2. Additional information that is pertinent to NCPDP’s use of CORE real time SOAP+WSDL schemas is detailed in CORE connectivity FAQ #264.

Back to Top

276. In The CORE Connectivity Rule, When Passing A Username And Password As The Authentication Tokens, Can The Password Be Passed In The Clear Or Encrypted? Are Both Variants Allowed Or Does CORE Specify One Or The Other?

The CORE Phase II connectivity rule does not specify the use of password digests. The underlying transport is HTTP/S (per the CORE Phase I connectivity rule), and this provides encryption / confidentiality of the envelope and payload contents in transit. The non-normative examples show how username/password authentication has been implemented by early implementers.

Back to Top

277. The Entity-Specific Connectivity Guide (Section 4.3.7 Of Phase II Connectivity Rule) States That Details Of The Message Format And Supported Transactions, Such As Returning A List Of Files To Be Picked Up For Batch Transactions, Can Be Specified In A Connectivity Companion Guide. Does This Mean That We Can Make Any Custom Extensions To The Envelope Metadata And Message Exchanges, And As Long As Such Extensions Are Specified In A Companion Guide, Can We Get Certified For CORE Phase II Connectivity?

No. By design, the CORE Connectivity Phase II Rule is highly prescriptive in the envelope metadata and message interactions because the CORE participants need a Connectivity Rule that provides a high degree of interoperability.  Entities may implement custom extensions which must be described in a companion guide, but such extensions are not compliant with the CORE Phase II Connectivity Rule's normative specifications (i.e., XSD, WSDL) and are therefore considered as non-CORE connectivity interfaces.  Consistent with the Safe Harbor principle (defined extensively in CORE Phase I and Phase II Connectivity Rules), a CORE certified entity can implement custom extensions and/or support additional connectivity methods as long as it has implemented one connectivity interface that is fully and exactly as specified in the CORE Connectivity Rule.  This gives CORE certified partners the assurance they can use their CORE Connectivity-certified interfaces to connect.

Back to Top

IV. Test Suite and Master Test Bed Data FAQs
    Phase I Test Suite/Test Bed Data FAQs



278. What Is The Purpose Of The Test Suite?

The CORE Certification Testing Suite Version 1.0.1 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.

Back to Top

279. 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.

Back to Top

280. Do The Test Scripts Address All The Rules?

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

Back to Top

281. 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.

Back to Top

282. 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 an Excel spreadsheet 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.

Back to Top

283. Can the CORE Master Test Bed Data be modified (length/format/datatype) in order to load into my organizations internal system? 

Yes. Refer to the CORE Certification Testing Suite Version 1.0.1 Appendix for the specific data elements which can be modified and detailed instructions on use and loading of Master Test Bed Data.

Back to Top

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

The CORE Master Test Bed Data and the CORE Certification Test Suite are available from the CAQH website.

Back to Top

285. 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.

Back to Top

286. 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.

Thus, a health plan or information source may modify the MID in the CORE Master Test Bed Data in order to load the test data into its eligibility system.

Refer to the CORE Certification Testing Suite Version 1.0.1 Appendix for specific data elements which can be modified and detailed instructions on use and loading of Master Test Bed Data.  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 future CORE phases.

Back to Top

287. 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
      Or alternatively
• 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.

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 future CORE phases.

Back to Top

288. 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 future CORE phases.

Back to Top

289. 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.

Refer to the CORE Certification Testing Suite Version 1.0.1 Appendix for specific data elements which can be modified and detailed instructions on use and loading of Master Test Bed Data.  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 future CORE phases.

Back to Top

290. 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.

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.

Refer to the CORE Certification Testing Suite Version 1.0.1 Appendix for specific data elements which can be modified and detailed instructions on use and loading of Master Test Bed Data.  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 future CORE phases.

Back to Top

291. 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 future CORE phases.

Back to Top

292. 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.

Back to Top

293. I Am a Health Plan. My Organization’s Eligibility System Does Not Support Identification of a Primary Care Provider as Specified in the CORE Master Test Bed Data, as We Do Not Support Products with Primary Care Providers, Therefore are We Required to Return This Information?

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

Refer to the CORE Certification Testing Suite Version 1.0.1 Appendix for specific data elements which can be modified and detailed instructions on use and loading of Master Test Bed Data.  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 future CORE phases..

Back to Top

294. I Am a Health Plan. It Appears that in Much of the Base Data the Member's Address, City, State, Zip Have Been Included, which is Currently Not Included in our 271 Responses. Is this Data Required or is it Okay if the Response Does Not Include this Information?

Any entity seeking CORE Phase I Certification must attest that it is compliant with HIPAA. The X12N 004010X092 Implementation Guide and 004010X092A1 Addenda imposes the following requirement for both Subscriber and Dependent address segments: "Use of this segment is required if the transaction is not rejected and address information is available from the information source’s database."

Since the address information for the member is included in the CORE Master Test Bed Data, it is expected that health plans will not only load the address information for certification testing but will also use it to create the appropriate HIPAA-compliant 271 response even though the CORE rule does not address the address information. On the other hand, if your production eligibility system does not currently maintain any member address information then, according to the 270/271 implementation guide, you would not be required to return it on a 271 response.

Back to Top

295. When a Health Plan Indicates It Does Not Support Dependents, is it Necessary for the Dependent Test Cases to be Loaded into the Health Plan's Eligibility System?

If a Health Plan indicated that it did not support Subscribers w/ Dependents then they would be taken through the tasks using Master Test Bed Cases 1 through 16, and they should not receive any data using the Cases 17 through 24.

The only exception to that rule is entities who select to do the non-HTTP/s testing; then the test cases provided to all users come from the Subscriber Only Case 1 through 16 set. This was a default selection made to quickly accommodate the non-HTTP/s testing, and the assumption that even entities who can support Subscribers w/ Dependents can also handle cases where the membership is Subscriber Only.

Back to Top

IV. Test Suite and Master Test Bed Data FAQs
    Phase II Test Suite/Test Bed Data FAQs



296. Is the CORE Phase II Master Test Bed Data Different than the Phase I Data?

The CORE Phase II Master Test Bed Data includes all of the CORE Phase I Master Test Bed Data along with additional data necessary for appropriate testing of the Phase II CORE 260 Data Content (270/271) Rule.

Both Phase I and Phase II Master Test Bed Data are available in an Excel spreadsheet format. The Phase I and Phase II Master Test Bed Data is available on the CAQH website as two separate files.

Back to Top

297. In terms of modifying data, are there allowable exceptions for loading the Phase II Master Test Bed Data? 

Yes, the exceptions are the same as for the CORE Phase I Master Test Bed Data.  Allowable exceptions relate to the modification or non-use of some of the test data elements. In general, testers are not permitted to modify dates and patient demographic data. The Phase II data also includes deductible and co-pay amounts explicitly shown as zero (0$) dollar amounts that are NOT modifiable.

Refer to CORE Certification Testing Suite Version 2.0.1 Appendix for the specific data elements which can be modified and detailed instructions on use and loading of Master Test Bed Data.

Back to Top

298. My organization is conducting concurrent Phase I and Phase II Certification Testing.  Can I load all 32 Master Test Bed members as subscribers?

Yes. Refer to the CORE Certification Testing Suite Version 2.0.1 Appendix for detailed instructions on use and loading of the Master Test Bed Data.

V. 5010 FAQs



299. What will the adoption of the NPRM for the next set of HIPAA Standards (version 5010) mean to CORE?

CAQH-CORE staff members completed a thorough examination of the 5010 NPRM in comparison to CORE operating rules. CAQH, on behalf of the CORE participants, has issued public comments to CMS for this NPRM. Our analysis suggests that proposed changes introduced by 5010 were well anticipated in the CORE planning process for both Phase I and Phase II rules. This is a reflection of the significant resources devoted by CAQH to following and participating in the X12N Subcommittee of the ASC X12 Standards Committee deliberations and discussions as well as coordination with other industry efforts.

Back to Top

300. Will CORE-certified entities need to be recertified? If so, is there a charge for that recertification?

No, when an entity becomes CORE-certified, it is required to attest, with executive level signature, to HIPAA compliance with whatever version of HIPAA is required by the Federal government. Whenever CORE creates a rule, it uses the current federally-mandated standards upon which to build the rule. If a new version of the standards is mandated by the government, the CORE rule references are changed accordingly.

Given the 5010, the likely scenario is that minor modifications may have to be made to CORE operating rules to align with 5010. Since entities will be required to implement the requirements set forth in 5010 and CORE rules will be aligned with those requirements, there will not be a need for recertification as a result of 5010 requirements.

NOTE: CORE certification does not test for HIPAA compliance. Entities undergoing CORE certification testing are required to attest to being HIPAA compliant. This HIPAA attestation will be updated to reference 5010 when it becomes the Federal mandate, and not until then.

Back to Top

301. Since the 5010 version of the 270/271 Eligibility Inquiry (named in the new NPRM) requires more than a "yes/no" response as in the current HIPAA 4010 version, will that mean changes to the CORE rule used in the Certification process?

The CAQH CORE initiative was borne out of the need observed in the industry to provide robust and consistent eligibility information above and beyond the current “yes/no” requirement. Since CORE operating rules are already requiring more than a “yes/no” response, the additional 5010 requirements will not impact CORE except for minor code adjustments. Moreover, with regard to eligibility, because CORE rules already incorporate some of what is in 5010, e.g., support of service type codes, reporting static and year-to-date deductibles, and providing effective dates of health care coverage, CORE-certified entities are closer to being 5010 compliant than those who are not CORE-certified.

CORE’s rules and certification testing will be updated to be in compliance with 5010. However, CORE does not test for 5010 compliance, just CORE rules compliance. With regard to 5010 requirements, CORE requires an attestation that entities are, and will remain, in compliance with HIPAA. All CORE-certified entities have attested to their compliance with HIPAA.

Back to Top

VI. Phase I Measures of Success



302. What Is The Measures of Success Program?

The Measures of Success Program is the method CAQH used to track the financial/operational impact, by stakeholder type, of operating in accordance with the CORE Phase I rules. Specifically, volunteers from each stakeholder type tracked, 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.

Back to Top

303. 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), used to measure the benefits of CORE Phase I rules adoption. The metrics include agreed upon methodologies that were applied by each stakeholder group to track the impact of CORE. Results from the Phase I Measures of Success Program are published and available at http://www.caqh.org/COREIBMstudy.php.

Back to Top

304. Which Entities Are Participating in the Measures of Success Program?

The following entities participated in the Phase I Measures of Success Program:

• Aetna, Inc.
• Blue Cross and Blue Shield of North Carolina
• Cedars-Sinai Health System
• East Carolina University School of Medicine Physicians
• Emdeon
• Health Net, Inc.
• IBM Corporation
• RelayHealth
• Montefiore Medical Center
• NaviNet,Inc.
• RealMed Corporation
• WellPoint, Inc.

Back to Top

VII. CORE Resources and Links



305. CAQH Contact Information

CAQH
601 Pennsylvania Avenue, NW
South Building, Suite 500
Washington, DC 20004
E: info@caqh.org
T: (202) 861-1492
F: (202) 861-1454
www.caqh.org

Back to Top

306. CORE Contact Information

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

Back to Top

307. CORE-Authorized Testing Vendor Contact Information

Please see link for full contact information for all CORE-authorized testing vendors

Back to Top

308. List of CORE Members

Please click here for listing of CORE members on the CORE website

Back to Top

309. List of CORE-Certified Entities

Please click here for a listing of CORE-certified entities on the CORE website

Back to Top

310. List of CORE-Endorsers

Please click here for a listing of CORE Endorsers on the CORE website

Back to Top

311. List of Standard Development/Advisory Organizations.
• Accredited Standards Committee (X12): http://www.x12.org


• American National Standards Organization: http://www.ansi.org/


• Health Level 7 (HL7): http://www.hl7.org


• WEDI: http://www.wedi.org/


• NCVHS: http://www.ncvhs.org

Back to Top