Phase I & II CAQH CORE Eligibility & Claim Status Operating Rules

XI. CAQH CORE 250: Claim Status Infrastructure Rule

NOTE: The HHS Final Rule for operating rules for the eligibility and claim status transactions adopts all the Phase I and II CAQH CORE Eligibility and Claim Status Operating Rules except those requirements pertaining to the use of Acknowledgements. Entities seeking CORE Certification must implement all of the CAQH CORE Eligibility and Claim Status Operating Rules applicable to their stakeholder type, including those rules & rule requirements pertaining to use of Acknowledgments.

  1. To what specifically does the CAQH CORE 250: Claim Status Rule apply?
  2. How does the Phase II CAQH CORE 250: Claim Status Rule relate to the Phase I CAQH CORE Operating Rules?
  3. What are the Phase I CAQH CORE infrastructure rules which must be followed in conducting the claim status transaction in Phase II?
  4. As a vendor offering only claim status transaction support to our clients (we do not use the X12 270/271 eligibility transactions), are we able to seek Phase II CORE Certification for claim status?
  5. Conversely, can an entity become Phase II CORE-certified if it processes the X12 270/271 eligibility transactions, but does not use or process claim status transactions?
  6. As a Phase II CORE-certified entity, will I be required to apply and test for compliance to the Phase II CAQH CORE Patient Identifiers Rules, i.e., Last Name Normalization and AAA Error Code Rules?
  7. In implementing the claim status transactions (X12 276/277), can we use Phase I CAQH CORE Connectivity or must we use Phase II CAQH CORE Connectivity?
  8. How did CAQH CORE decide that HTTP/S is secure and reliable enough to protect the delivery of healthcare information over the Internet?
  9. May payers support other versions of HTTPS in addition to v1.1, as required in the CAQH CORE 270: Connectivity Rule specified in Section 4.1 of the CAQH CORE 250 Rule?
  10. Is there a required format in Phase I CAQH CORE Connectivity for the authorization, date/time, and payload ID to be sent in the HTTP message?
  11. Is an implementation approach that uses SOAP 1.2 with or without attachments, running on top of HTTP/S 1.1, in conformance with the Phase II CAQH CORE Connectivity Rule?
  12. 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?
  13. Will all CAQH CORE-authorized testing vendors use the same test scripts and same detailed connectivity method to test the CAQH CORE Connectivity Rule for entities pursuing CORE Certification?
  14. My organization’s security procedures require that clients use a digital certificate to identify themselves. Under the CAQH CORE Operating Rules, can we require that they use the certificate method?
  15. What is the recommended method for allowing entities to receive another entity's root public digital certificate?
  16. Batch processing: How long must a responder maintain response files on their system?
  17. Batch processing: Why not FTP or sFTP for batch transactions instead of HTTP/S?
  18. Batch processing: My organization’s system can provide an ASC X12 Implementation Acknowledgement (999) back on batch transactions within 20 seconds. Why can’t my organization just send the ASC X12 Implementation Acknowledgement (999) in the response to the submission to increase efficiency?
  19. Batch processing: Will a receiver be able to re- pickup a file if needed?
  20. 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?
  21. Batch processing: Will a payload be able to contain different types of responses?
  22. 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?
  23. Batch processing: Is there a one-to-one correspondence between batch input transmissions and batch output files?
  24. Batch processing: Must a batch reply file contain replies for every request in a batch request? Is it an error to omit some?
  25. For the purposes of the re-transmission, what is the definition of a duplicate transaction?
  26. What happens if a provider's system continues to send duplicate transactions within 15 minutes?
  27. Is there a retention time period required by the CAQH CORE Rule for how long the source needs to maintain this transaction tracking information?
  28. Where can I get more information about exchanging data in HTTP/S?
  29. Can my vendor offer HTTP/S on my behalf?
  30. Is the payload ID generated and sent by the submitter?
  31. Is the payload ID unique for each transaction sent by the submitter?
  32. What should be expected from trading partners regarding the payload IDs, and how it should be used?
  33. Can a clearinghouse or vendor act on behalf of a health plan for the CAQH CORE 270: Connectivity Rule?
  34. 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?
  35. How should we respond to the transaction if the date/time and/or payload ID are not present?
  36. Does the real time acknowledgement rule for X12 276 claim status inquiries mean that my organization’s system must always return both of these types of acknowledgements: ASC X12 Implementation Acknowledgement (999) and the X12 277 response?
  37. Can a clearinghouse or vendor act on behalf of a health plan or provider for real time acknowledgments?
  38. The X12 Interchange Acknowledgement TA1 is described in the HIPAA Implementation Guide Appendix B: EDI Control Directory. Do the CAQH CORE Rules require the use of the X12 Interchange Acknowledgement TA1?
  39. Are all CAQH CORE Operating Rules with regard to acknowledgement only applicable to scenarios where my organization receives data in an X12 276 format?
  40. Currently my organization’s EDI System only returns an ASC X12 Implementation Acknowledgement (999) if the functional group is rejected. Must my system be changed to comply with the CAQH CORE Acknowledgement Rule?
  41. My organization’s EDI system was developed in-house and does not currently support the TA1. However, our system does support the ASC X12 Implementation Acknowledgement (999) for rejected functional groups. Is this okay under the CAQH CORE 250 Rule?
  42. If my organization’s system is not changed to always return the ASC X12 Implementation Acknowledgement (999), can my organization become CORE-certified?
  43. In case of batch mode does my organization have to acknowledge the receipt of a batch using the ASC X12 Implementation Acknowledgement (999) even if the data was not sent in the X12 276 format?
  44. When does the 20-second real time requirement for response time described in the CAQH CORE 156 Rule begin and end? Does the 20-second interval include all hops between trading partners?
  45. What happens when a real time response is not received within the required 20-second window?
  46. How should the X12 276/277 transactions be tracked throughout a system/application to demonstrate conformance with the response time requirements specified in the CAQH CORE 250 Rule?
  47. Why measure conformance based on number of responses returned within a specified timeframe rather than average response time?
  48. Is there a standard reporting form for the conformance reporting?
  49. 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?
  50. If an X12 276 is received in a batch, does the X12 277 have to be returned in a batch?
  51. Do the time frames still apply if it is an especially large batch? Do the CAQH CORE Operating Rules define the batch size?
  52. My organization includes system availability schedules in our Companion Guide. Does this satisfy the CAQH CORE Operating Rule requirements for system availability reporting?
  53. Does my organization have to send back a claim status response if my system is down?
  54. Why was the CAQH CORE 152: Companion Guide Rule Version 1.1.0 (which is the basis for the Phase II Claim Status Rule’s Companion Guide template requirement) created?
  55. Can I combine multiple transaction sets (e.g., X12 270/271 and 276/277) in a single Companion Guide?
  56. Will all of the detailed content of my organization’s X12 276/277 Companion Guide be analyzed and evaluated for CORE Certification testing?
  57. For entities seeking CORE Certification, how does CAQH CORE determine conformance with the CAQH CORE v5010 Master Companion Guide Template?
  58. Does the CAQH CORE 250 Rule, Section 4.7, Claim Status Companion Guide, require HIPAA covered entities to publish a Companion Guide if they do not currently do so?
  59. Does the CAQH CORE 250 Rule require health plans to request approval from ASC X12 prior to publication of their CORE-compliant Companion Guide(s)?
1. To what specifically does the CAQH CORE 250: Claim Status Rule apply?

The CAQH CORE 250: Claim Status Rule applies when an entity uses, conducts, or processes the HIPAA-adopted X12 276/277 Health Care Claim Status Request and Response transactions.

2. How does the Phase II CAQH CORE 250: Claim Status Rule relate to the Phase I CAQH CORE Operating Rules?

The CAQH CORE 250: Claim Status Rule relates to the Phase I CAQH CORE Rules in the following ways:

  • The Phase I CAQH CORE Infrastructure Rules, which were created to increase access to the X12 270/271 transactions, also apply to the Claim Status Rule for the X12 276/277 HIPAA transactions. These infrastructure rules address real time and batch response times, the use of the ASC X12 Implementation Acknowledgement (999), system availability, and a common flow/format for a Companion Guide.
  • As with the other Phase II CAQH CORE Rules, general CAQH CORE policies also apply to the Phase II CAQH CORE Claim Status Rule as outlined in the Phase II CAQH CORE Policies 200-205, e.g., as in Phase I, there is CORE Certification testing for each stakeholder, a health plan exemption policy for system migration, and entities are required to test only for and meet batch rule requirements if they offer batch.
  • All CAQH CORE Rules are a minimum requirement; entities are 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.
3. What are the Phase I CAQH CORE infrastructure rules which must be followed in conducting the claim status transaction in Phase II?

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

4. As a vendor offering only claim status transaction support to our clients (we do not use the X12 270/271 eligibility transactions), are we able to seek Phase II CORE Certification 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 CORE Certification for claim status, your organization would receive a CORE Certification Seal for Claim Status.

5. Conversely, can an entity become Phase II CORE-certified if it processes the X12 270/271 eligibility transactions, but does not use or process claim status transactions?

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

6. As a Phase II CORE-certified entity, will I be required to apply and test for compliance to the Phase II CAQH CORE Patient Identifiers Rules, i.e., Last Name Normalization and AAA Error Code Rules?

No, you are not required to apply the Phase II CAQH CORE Patient Identifiers Rules to the conduct of the claim status transactions as it is specific to the conduct of eligibility/benefits transactions.

7. In implementing the claim status transactions (X12 276/277), can we use Phase I CAQH CORE Connectivity or must we use Phase II CAQH CORE Connectivity?

No, as an entity implementing the X12 276/277 transactions your organization is required to support CAQH CORE Connectivity 270 v 2.2.0 as specified in the CAQH CORE 250 Rule, Section 4.1.

8. How did CAQH 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, CAQH 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, CAQH CORE determined that HTTP/S is an appropriate choice as the baseline standard for delivery of healthcare information.

9. May payers support other versions of HTTPS in addition to v1.1, as required in the CAQH CORE 270: Connectivity Rule specified in Section 4.1 of the CAQH CORE 250 Rule?

Yes. Payers may support other versions, but they must support HTTPS 1.1 in order to achieve CORE Certification. The intent of CAQH CORE 270: Connectivity Rule Version 2.2.0, which applies to the conduct of this Phase II CAQH CORE 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.

10. Is there a required format in Phase I CAQH CORE Connectivity for the authorization, date/time, and payload ID to be sent in the HTTP message?

No. CAQH CORE decided not to require a format for these data elements for Phase I. However, in Phase II CAQH CORE and future phases, CAQH CORE does require a specific format for sending these data elements. Please speak with your CAQH CORE-authorized 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 the CAQH CORE-authorized testing vendor.

11. Is an implementation approach that uses SOAP 1.2 with or without attachments, running on top of HTTP/S 1.1, in conformance with the Phase II CAQH CORE Connectivity Rule?

The conformance guidelines for different stakeholder types for implementing the two envelope standards (SOAP 1.2 and HTTP+MIME Multipart) defined in CAQH CORE 270: Connectivity Rule Version 2.2.0 are provided in the rule. SOAP 1.2 is one of the two supported envelope standards, and needs to be implemented over HTTP/S 1.1. The use of attachments is applicable to Batch processing, and is not applicable to Real time processing. Further, the intent of CAQH CORE 270: Connectivity Rule Version 2.2.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.

12. 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 CAQH CORE-authorized certification testing vendor check the NO REVISIONS NEEDED (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 CAQH CORE Certification Test Scripts, if you check NO REVISIONS NEEDED 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.

13. Will all CAQH CORE-authorized testing vendors use the same test scripts and same detailed connectivity method to test the CAQH CORE Connectivity Rule for entities pursuing CORE Certification?

For every CAQH CORE Rule, including the Connectivity Rule, each CAQH CORE-authorized testing vendor will use the same Certification Test Scripts by stakeholder. Additionally, each CORE-certified entity will be responsible for being in conformance with the rules, understanding that not all aspects of rule conformance are tested during CORE Certification testing, e.g., maintaining system availability. The CAQH CORE-authorized testing vendor you select to work with to conduct your CORE Certification testing will provide your organization with the details necessary to complete the CAQH CORE Connectivity Rule certification tests.

14. My organization’s security procedures require that clients use a digital certificate to identify themselves. Under the CAQH CORE Operating Rules, can we require that they use the certificate method?

Yes. Section 4.1.1 of CAQH CORE 270: Connectivity Rule Version 2.2.0 requires health plans to implement one of the two Submitter Authentication Standards, one of which is an X.509 Certificates over SSL.

15. What is the recommended method for allowing entities to receive another entity's root public digital certificate?

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

16. Batch processing: How long must a responder maintain response files on their system?

CAQH 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, CAQH 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 of non-conformance against a CORE-certified entity.

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

18. Batch processing: My organization’s system can provide an ASC X12 Implementation Acknowledgement (999) back on batch transactions within 20 seconds. Why can’t my organization just send the ASC X12 Implementation Acknowledgement (999) in the response to the submission to increase efficiency?

For consistency and ease of development, CAQH 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 ASC X12 Implementation Acknowledgement (999) available in 20 seconds, CAQH CORE elected to mandate that the ASC X12 Implementation Acknowledgement (999) not be provided in the HTTP response.

19. Batch processing: Will a receiver be able to re- pickup a file if needed?

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

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

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

21. Batch processing: Will a payload be able to contain different types of responses?

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

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

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

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

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

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

CAQH CORE does not specify the detailed data content of the X12 271 response, which is addressed by the appropriate implementation guide. According to the X12 271 Implementation Guide, there is no requirement for a batch X12 271 to respond to every request included in a batch X12 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.

25. For the purposes of the re-transmission, what is the definition of a duplicate transaction?

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

26. What happens if a provider's system continues to send duplicate transactions within 15 minutes?

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

27. Is there a retention time period required by the CAQH CORE Rule for how long the source needs to maintain this transaction tracking information?

CAQH 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, CAQH CORE recommends that entities keep this information for at least 18 months, if that is in accord with the organization’s existing policies.

28. Where can I get more information about exchanging data in HTTP/S?

A good general source of information regarding HTTP/S can be found in this link: Transferring Files Using HTTP and HTTPS.

29. Can my vendor offer HTTP/S on my behalf?

The Phase I CAQH CORE Rules do not require that an entity (provider or health plan) implement the technology directly into their own data center. The Phase I CAQH CORE 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 CAQH CORE Operating 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 Phase I CAQH CORE Rules do not require any specific architecture. Rather, CAQH CORE Operating Rules specify the capabilities that need to be enabled by any CORE-certified entity.

An entity seeking CORE Certification, working with or without their vendor providing the HTTP/S connectivity capability, will have to demonstrate conformance with the Phase I CAQH CORE Connectivity Rule through the CORE Certification testing.

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

30. 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’s system or the clearinghouse’s system that is working on the provider's behalf.

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

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

33. Can a clearinghouse or vendor act on behalf of a health plan for the CAQH CORE 270: Connectivity Rule?

Yes. Each health plan seeking CORE Certification will have to work with its clearinghouse and/or vendor to jointly complete CORE Certification 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 that CORE Certification to any health plan.

34. 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 CAQH CORE Rule.

35. How should we respond to the transaction if the date/time and/or payload ID are not present?

Such a message would represent a CAQH CORE non-conformance message. The CAQH 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-conformance message.

36. Does the real time acknowledgement rule for X12 276 claim status inquiries mean that my organization’s system must always return both of these types of acknowledgements: ASC X12 Implementation Acknowledgement (999) and the X12 277 response?

No. For real time X12 276 claim status inquiries, your organization’s system must return an ASC X12 Implementation Acknowledgement (999) if the functional group is rejected, or the X12 277 response, to be conformant with this rule. CAQH CORE Rules do not address usage of the X12 Interchange Acknowledgement TA1.

37. Can a clearinghouse or vendor act on behalf of a health plan or provider for real time acknowledgments?

Yes. Each health plan seeking CORE Certification will have to work with its clearinghouse and/or vendor to jointly complete CORE Certification 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 that CORE Certification to any health plan.

38. The X12 Interchange Acknowledgement TA1 is described in the HIPAA Implementation Guide Appendix B: EDI Control Directory. Do the CAQH CORE Rules require the use of the X12 Interchange Acknowledgement TA1?

No. The CAQH CORE Acknowledgements Rules do not address the use of the X12 Interchange Acknowledgement TA1.

39. Are all CAQH CORE Operating Rules with regard to acknowledgement only applicable to scenarios where my organization receives data in an X12 276 format?

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, CAQH CORE 250: Claim Status Rule is focused on the conduct of the HIPAA-named X12 276/277 transaction sets, and the CAQH CORE Operating Rules are focused on the X12 as well. Thus, the CAQH CORE 250 Rule only addresses the use of the ASC X12 Implementation Acknowledgements (999) and when to use it when conducting the X12 276/277 transaction sets. Additionally, in order to meet CORE Certification requirements, an entity is required to attest to its compliance with HIPAA, which requires the use of the appropriate X12 TR3.

40. Currently my organization’s EDI System only returns an ASC X12 Implementation Acknowledgement (999) if the functional group is rejected. Must my system be changed to comply with the CAQH CORE Acknowledgement Rule?

Yes. Section 4.3 of the CAQH CORE 250 Rule requires that the health plan or information receiver must always return an ASC X12 Implementation Acknowledgement (999) 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 an ASC X12 Implementation Acknowledgement (999) for all functional groups whether or not the group is rejected, thereby allowing timely resolution of any issues.

41. My organization’s EDI system was developed in-house and does not currently support the TA1. However, our system does support the ASC X12 Implementation Acknowledgement (999) for rejected functional groups. Is this okay under the CAQH CORE 250 Rule?

Yes. In accordance with the CAQH CORE 250 Rule Section 4.3, Claim Status Batch Acknowledgement Requirements, only the ASC X12 Implementation Acknowledgement (999) is required to be supported. CAQH CORE Rules do not address the use of the X12 TA1 Interchange Acknowledgement.

42. If my organization’s system is not changed to always return the ASC X12 Implementation Acknowledgement (999), can my organization become CORE-certified?

No. Your organization must successfully complete all of the required certification test scripts required by the Phase II CAQH CORE Certification Test Suite to become CORE-certified.

43. In case of batch mode does my organization have to acknowledge the receipt of a batch using the ASC X12 Implementation Acknowledgement (999) even if the data was not sent in the X12 276 format?

The ASC X12 Implementation Acknowledgement (999) 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.

44. When does the 20-second real time requirement for response time described in the CAQH CORE 156 Rule begin and end? Does the 20-second interval include all hops between trading partners?

The 20-second requirement described in the CAQH CORE 156 and 250 Rules is the duration for the entire round-trip of the transaction. The 20 seconds begin when the X12 270 Inquiry or X12 276 Request is first submitted, and ends when the X12 271 Response or X12 277 Response is delivered to the provider. All ensuing hops are included in these 20 seconds. Conformance with the rule is determined when 90 percent of all required responses are returned within the specified maximum response time as measured within a calendar month. Each HIPAA-covered entity is required to conform to the Federally mandated CAQH CORE Eligibility & Claim Status Operating Rules. Each HIPAA covered entity within the transaction flow is bound by the CAQH CORE Rule requirements for meeting the 20-second round trip of the transaction (CAQH CORE recommends no more than 4 seconds per hop).

45. What happens when a real time response is not received within the required 20-second window?

The CAQH CORE 270: Connectivity Rule requires that the connection remain open for 60 seconds to accommodate any potentially delayed responses. In the event that a specific real time response message is not received within the 20-second window, the requirements described in CAQH CORE 270 Rule, Section 4.3.6, Response, Timeout and Retransmission Requirements, would apply.

NOTE: The CAQH CORE 156 and 250 Rules require that 90 percent of all X12 271 and X12 277 responses be returned within the 20-second maximum response time within a calendar month to be in conformance with the rule requirements.

46. How should the X12 276/277 transactions be tracked throughout a system/application to demonstrate conformance with the response time requirements specified in the CAQH CORE 250 Rule?

CAQH CORE 250: Claim Status Rule requires HIPAA covered entities to capture, log, audit, match, and report the date, time, and control numbers from their own internal systems, and corresponding data received from their trading partners. The auditing requirement is included so that each entity will have the log of data to be used to resolve any issues or concerns. For the 20-second maximum real time response requirement, this log could also be used to identify where a bottleneck may be occurring.

Section 4.3.4 of the CAQH CORE 270: Connectivity Rule also specifies that, to comply with the CAQH CORE 250 Rule, message receivers will be required to track the times of any received inbound messages, and respond with the outbound message for that payload ID. Additionally, message senders must include the CORE Envelope Metadata element Time Stamp (as specified in the CAQH CORE 270 Rule, Section 4.1.2).

Other data may be required for auditing purposes; however, this data can be determined by each entity. CAQH CORE recommends that, in order to uniquely identify an X12 transmission, entities store the ISA06, ISA08, ISA13, GS02, GS03, GS06, ST02, TRN02, and if sent in the transaction, the BHT03. The audit log requirement was purposefully specified at a high level in each rule to enable each entity along the transaction pathway to design and develop its own process for audit handling. Additionally, the rules do not specify how long an entity is to maintain the data for auditing purposes.

(See “How should entities track the X12 270/271 and/or X12 276/277 transactions when using another connectivity method, as permitted by the CAQH CORE Connectivity Safe Harbor?” for guidance on tracking when using a non-CAQH CORE Connectivity method.)

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

48. Is there a standard reporting form for the conformance reporting?

No. CAQH CORE does not mandate a particular form.

49. 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 CORE-certified to interact with CORE-certified payers under the CAQH CORE Rules.

50. If an X12 276 is received in a batch, does the X12 277 have to be returned in a batch?

The CAQH 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:00 AM the next business day following a submission of inquiries by 9:00 PM ET the previous business day. Therefore, the CAQH CORE Rule does not specify whether or not the batch of X12 277 responses must match exactly the batch of X12 276 inquiries.

51. Do the time frames still apply if it is an especially large batch? Do the CAQH CORE Operating Rules define the batch size?

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

52. My organization includes system availability schedules in our Companion Guide. Does this satisfy the CAQH CORE Operating 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 CAQH CORE Operating Rule outlines requirements for reporting/publishing non-routine downtimes and unscheduled/emergency downtimes.

53. Does my organization have to send back a claim status response if my system is down?

As long as your claim status system is in conformance with the CAQH CORE System Availability Rule, then it is not required to send back a claim status response, either in real time or batch.

54. Why was the CAQH CORE 152: Companion Guide Rule Version 1.1.0 (which is the basis for the Phase II Claim Status Rule’s Companion Guide template requirement) 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. CAQH CORE adapted its Master Companion Guide Template based on the CAQH/WEDI Best Practices Companion Guide Template developed jointly 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.

55. Can I combine multiple transaction sets (e.g., X12 270/271 and 276/277) in a single Companion Guide?

Yes. Entities, may, if they wish, combine their Companion Guides for separate transactions into a single document. The flow and format of the CAQH CORE v5010 Master Companion Guide Template would still need to be followed, but sections could be repeated, tables added for the second transaction, etc., without altering said flow and format.

56. Will all of the detailed content of my organization’s X12 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 CAQH CORE-authorized testing vendor will assess these documents to determine that your Companion Guide conforms to the CORE required flow and format.

57. For entities seeking CORE Certification, how does CAQH CORE determine conformance with the CAQH CORE v5010 Master Companion Guide Template?

The CAQH CORE 152 and 250 Rules require health plan Companion Guides covering the X12 270/271 and X12 276/277 transactions to follow the format/flow as defined in the CAQH CORE v5010 Master Companion Guide Template.

As part of CORE Certification testing, CAQH CORE-authorized testing vendors evaluate the following to determine if an entity’s Companion Guide(s) conforms to the CAQH CORE 152 and 250 Rules Companion Guide Requirements:

  • If the order of the Companion Guide table of contents matches the table in the CAQH CORE v5010 Master Companion Guide Template
  • If the Companion Guide format for specifying the X12 270/271 &/or X12 276/277 data content requirements is consistent with the format in the CAQH CORE v5010 Master Companion Guide Template

If a specific section(s) of the CAQH CORE v5010 Master Companion Guide Template is not appropriate for a particular entity’s Companion Guide, the CAQH CORE Rules do allow the entity to exclude this section(s) from their guide.

58. Does the CAQH CORE 250 Rule, Section 4.7, Claim Status Companion Guide, require HIPAA covered entities to publish a Companion Guide if they do not currently do so?

No. The CAQH CORE Eligibility & Claim Status Operating Rules do not require any entity to publish a Companion Guide if they do not already do so. CAQH CORE 250: Claim Status Rule specifies that should an entity publish a company guide, it must conform to the format/flow as defined in the CAQH CORE v5010 Master Companion Guide Template.

59. Does the CAQH CORE 250 Rule require health plans to request approval from ASC X12 prior to publication of their CORE-compliant Companion Guide(s)?

No. The Federally mandated CAQH CORE Eligibility & Claim Status Operating Rules, as adopted by HHS, do not require any entity to submit its Companion Guide to ASC X12 for review and approval prior to publication.

Entities seeking CORE Certification are required to submit to the CAQH CORE-authorized testing vendor: 1) The Companion Guide’s table of contents and 2) A page showing the organization’s requirements for the presentation of segments, data elements and codes. The CAQH CORE-authorized testing vendor will evaluate these documents to determine if they are consistent with the format in the CAQH CORE v5010 Master Companion Guide Template.