Frequently Asked Questions - CAQH CORE Connectivity Rule vC3.1.0

  1. The CAQH CORE Operating Rules include “Safe Harbor” statements. Does this preclude any trading partner’s implementation testing from taking place prior to the trading partners using CAQH CORE Connectivity vC3.1.0 to exchange the transactions?
  2. Can a HIPAA-covered entity or its agent still use connections that are not compliant with the CAQH CORE vC3.1.0?
  3. Do the CAQH CORE Connectivity vC3.1.0 payload types have to be implemented for non-compliant connections to the rule?
  4. Do the CAQH CORE Connectivity vC3.1.0 Processing Modes have to be implemented for transactions addressed by this rule even if non-compliant connections are used to conduct these transactions?
  5. What does the term “in-line files (method)” as used in Section 4.2.9.2, Batch Transactions, mean?
  6. If we use SHA-1 algorithm as specified in Table 4.4.2 CAQH CORE Envelope Metadata for the CORE Envelope CheckSum element, but our trading partner requires SHA-2, how can we resolve the different implementations to use the same algorithm?
  7. Can an organization use user id + password for either internal or external manual user access to an organization’s computers?
  8. Why are non-normative descriptions provided?
  9. Are the non-normative descriptions mandatory to support?
  10. Can I modify the WSDL field names, data types and syntax of existing fields to meet my organization's internal requirements?
  11. Can I add additional SOAP headers?
  12. Does the entire Web Services Definition Language (WSDL) Specification (normative) WSDL need to be implemented for conformance with the CAQH CORE Connectivity vC3.1.0 or only the interactions needed to support the transactions and processing modes we u
  13. Can a HIPAA-covered entity and its agent reference the XSD and WSDL document on the CAQH CORE website as part of the entity’s or agent’s transaction processing; e.g., for the purpose of message envelope validation?
  14. Can a HIPAA-covered entity or its agent use SFTP/FTPS (Secure File Transfer Protocol/File Transfer Protocol/Secure) to exchange transactions for Batch Processing Mode and be compliant with CORE Connectivity vC3.1.0?
  15. Can we continue to use SFTP/FTPS for our batch transactions after we support CORE Connectivity vC3.1.0 requirements?
  16. Do all error conditions addressed in Section 4.2.6 of the CAQH CORE Connectivity vC3.1.0 have to be checked, e.g., the example sequence diagrams do not depict checking SOAP error faults?
  17. Are there recommendations for how frequently to audit the data in Section 4.2.7, Audit Handling?
  18. If a submitter’s transaction real time response is not received from a receiver, can the submitter’s transaction be excluded from the submitter’s response time reporting as a failed transaction caused by external problems?
  19. How is MTOM applied in CORE Connectivity vC2.2.0 and CORE Connectivity vC3.1.0 Rules?
  20. Section 4.1 of the CAQH CORE Payment & Remittance (835) Infrastructure Rule requires entities to support the CAQH CORE Connectivity Rule vC2.2.0 to send/receive the X12 v5010 835. CAQH CORE Connectivity requires health plans and clearinghouses to pub
  21. Does the Payment & Remittance (835) Infrastructure Rule specify processing mode requirements for exchange of the X12 v5010 835?
  22. The CAQH CORE Payment & Remittance (835) Infrastructure Rule requires entities to support the requirements for batch processing of the X12 v5010 835 specified in the CAQH CORE Connectivity Rule vC2.2.0. In Section 4.2.2.1 of the CAQH CORE Connectivit
  23. The CAQH CORE Payment & Remittance (835) Infrastructure Rule require health plans to support transmission of the X12 v5010 835 to providers via the public Internet?
  24. CAQH CORE Payment & Remittance (835) Infrastructure Rule requires health plans to support the CAQH CORE Connectivity Rule vC2.2.0 to transmit the X12 v5010 835. Our organization is a health plan that currently transmits several X12 v5010 835 transact
  25. The CAQH CORE Payment & Remittance (835) Infrastructure Rule requires health plans to support the CAQH CORE Connectivity Rule vC.2.2.0 to transmit the X12 v5010 835. Our organization is a health plan that currently limits the size of the batch X12 v5
  26. Per Section 3.3, the CAQH CORE Payment & Remittance (835) Uniform Use of CARCs and RARCs Rule applies when entities process the X12 v5010 835 in either real time or batch. Does this requirement mean that the CAQH CORE Payment & Remittance (835) Unifo
The CAQH CORE Operating Rules include “Safe Harbor” statements. Does this preclude any trading partner’s implementation testing from taking place prior to the trading partners using CAQH CORE Connectivity vC3.1.0 to exchange the transactions?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:32
The CAQH CORE Operating Rules include “Safe Harbor” statements. Does this preclude any trading partner’s implementation testing from taking place prior to the trading partners using CAQH CORE Connectivity vC3.1.0 to exchange the transactions?

No. Per the CAQH CORE Guiding Principles, CAQH CORE Connectivity Rules are built around a Safe Harbor principle (see Section 5 of the CAQH CORE Connectivity vC3.1.0) which allows HIPAA-covered entities or their agents to implement other connectivity/security methods in addition to the requirement to support the CORE Connectivity Rule. Trading partners are permitted to conduct the necessary planning, implementation and testing activities necessary to begin exchanging the various transactions using CAQH CORE Connectivity Rule vC3.1.0 prior to actually using it. 

Back to Top
Can a HIPAA-covered entity or its agent still use connections that are not compliant with the CAQH CORE vC3.1.0?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:33
Can a HIPAA-covered entity or its agent still use connections that are not compliant with the CAQH CORE vC3.1.0?

Yes. A HIPAA-covered entity or its agent must support CAQH CORE Connectivity Rule vC3.1.0 compliant connections, and use these connections when requested by a trading partner for the transactions. Per the CAQH CORE Guiding Principles, the CAQH CORE Connectivity Rules are built around a Safe Harbor principle (see Section 5 of the CAQH CORE Connectivity vC3.1.0) which allows HIPAA-covered entities or their agents to implement other connectivity/security methods in addition to the requirement to support the CORE Connectivity Rule. Such non-compliant connections must support all Payload Processing modes (Batch and Real Time) specified for the transactions in the CAQH CORE vC3.1.0 CAQH CORE-Required Processing Mode and Payload Type Tables. 

Back to Top
Do the CAQH CORE Connectivity vC3.1.0 payload types have to be implemented for non-compliant connections to the rule?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:33
Do the CAQH CORE Connectivity vC3.1.0 payload types have to be implemented for non-compliant connections to the rule?

No. The payload types specified for the transactions in CORE Connectivity vC3.1.0 CAQH CORE-Required Processing Mode and Payload Type Tables do not have to be implemented for non-compliant connections. The CAQH CORE Connectivity vC3.1.0 Payload types must be implemented in compliant connections. 

Back to Top
Do the CAQH CORE Connectivity vC3.1.0 Processing Modes have to be implemented for transactions addressed by this rule even if non-compliant connections are used to conduct these transactions?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:34
Do the CAQH CORE Connectivity vC3.1.0 Processing Modes have to be implemented for transactions addressed by this rule even if non-compliant connections are used to conduct these transactions?

Yes. Such non-compliant connections must support all Payload Processing modes (Batch and Real Time) specified for the transactions in the CAQH CORE Connectivity vC3.1.0 CAQH CORE-Required Processing Mode and Payload Type Tables

Back to Top
What does the term “in-line files (method)” as used in Section 4.2.9.2, Batch Transactions, mean?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:34
What does the term “in-line files (method)” as used in Section 4.2.9.2, Batch Transactions, mean?

The In-line files method means the text is embedded in the SOAP envelope text structure. The in-line method is used by CAQH CORE Connectivity Rule v2.2.0 for SOAP Real Time interactions; this method is no longer allowed in the CAQH CORE Connectivity vC3.1.0, which uses MTOM for both SOAP Real Time and Batch Interactions.

Back to Top
If we use SHA-1 algorithm as specified in Table 4.4.2 CAQH CORE Envelope Metadata for the CORE Envelope CheckSum element, but our trading partner requires SHA-2, how can we resolve the different implementations to use the same algorithm?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:35
If we use SHA-1 algorithm as specified in Table 4.4.2 CAQH CORE Envelope Metadata for the CORE Envelope CheckSum element, but our trading partner requires SHA-2, how can we resolve the different implementations to use the same algorithm?

CAQH CORE Connectivity vC3.1.0 Section 4.3, Publication of Entity-Specific Connectivity Companion Document, requires the publication of a Connectivity Companion Document. Entities acting as Servers specify their required SHA algorithms in their Connectivity Companion Document. Trading partners need to reach mutual agreement regarding the use of SHA-1.

Back to Top
Can an organization use user id + password for either internal or external manual user access to an organization’s computers?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:36
Can an organization use user id + password for either internal or external manual user access to an organization’s computers?

Manual user access, either internal or external, is not addressed in CAQH CORE Connectivity vC3.1.0.

Back to Top
Why are non-normative descriptions provided?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:36
Why are non-normative descriptions provided?

Non-normative descriptions are informational and educational descriptions only on the use of the normative SOAP+WSDL envelope specifications and are not intended to be part of the specification.

Back to Top
Are the non-normative descriptions mandatory to support?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:37
Are the non-normative descriptions mandatory to support?

No. Non-normative descriptions are not mandatory to support.

Back to Top
Can I modify the WSDL field names, data types and syntax of existing fields to meet my organization's internal requirements?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:37
Can I modify the WSDL field names, data types and syntax of existing fields to meet my organization's internal requirements?

No. The WSDL field names, data types and syntax of existing fields cannot be modified.

Back to Top
Can I add additional SOAP headers?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:38
Can I add additional SOAP headers?

Yes. Additional elements within the SOAP Header may be added. Server entities that require the use of additional SOAP Header elements must define the element and its use in the entity’s Connectivity Companion Document. Server organizations that don’t require specific SOAP headers must ignore them.

Back to Top
Does the entire Web Services Definition Language (WSDL) Specification (normative) WSDL need to be implemented for conformance with the CAQH CORE Connectivity vC3.1.0 or only the interactions needed to support the transactions and processing modes we u

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:39
Does the entire Web Services Definition Language (WSDL) Specification (normative) WSDL need to be implemented for conformance with the CAQH CORE Connectivity vC3.1.0 or only the interactions needed to support the transactions and processing modes we use?

The WSDL has both required and optional message interactions (e.g., Real Time interaction is optional in CAQH CORE Connectivity vC3.1.0). Only the interactions needed to support the transactions and processing modes need to be implemented for conformance.

Back to Top
Can a HIPAA-covered entity and its agent reference the XSD and WSDL document on the CAQH CORE website as part of the entity’s or agent’s transaction processing; e.g., for the purpose of message envelope validation?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:39
Can a HIPAA-covered entity and its agent reference the XSD and WSDL document on the CAQH CORE website as part of the entity’s or agent’s transaction processing; e.g., for the purpose of message envelope validation?

The XSD and WSDL documents on the CAQH CORE website are for reference only for an organization to use to develop its own production transaction processing. The two CAQH CORE documents are not meant to be read directly from the CAQH CORE website as part of any organization’s production transaction processing, for example, for the message envelope validation. The CAQH CORE website is not intended to provide high availability or high-performance production read access for these documents, nor is it intended to be part of any organization’s production processing environment.

Back to Top
Can a HIPAA-covered entity or its agent use SFTP/FTPS (Secure File Transfer Protocol/File Transfer Protocol/Secure) to exchange transactions for Batch Processing Mode and be compliant with CORE Connectivity vC3.1.0?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:40
Can a HIPAA-covered entity or its agent use SFTP/FTPS (Secure File Transfer Protocol/File Transfer Protocol/Secure) to exchange transactions for Batch Processing Mode and be compliant with CORE Connectivity vC3.1.0?

No. The CAQH CORE Connectivity Rule vC3.1.0 requires HTTP/S. SFTP/FTPS does not meet the requirements of the rule.

NOTE: Per the CAQH CORE Guiding Principles, the CORE Connectivity Rules are built around a Safe Harbor principle (see Section 5 of the CAQH CORE Connectivity vC3.1.0) which allows HIPAA-covered entities or their agents to implement other connectivity/security methods in addition to the requirement to support the CAQH CORE Connectivity vC3.1.0.

Back to Top
Can we continue to use SFTP/FTPS for our batch transactions after we support CORE Connectivity vC3.1.0 requirements?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:41
Can we continue to use SFTP/FTPS for our batch transactions after we support CORE Connectivity vC3.1.0 requirements?

CAQH CORE Connectivity Rule vC3.1.0 requires the use of HTTP/S. Section 5, CAQH CORE Safe Harbor, permits trading partners to agree to use different communication method(s) and/or security requirements than those described in this Rule. When a HIPAA-covered entity or its agent implements a different communication method(s) as permitted by the CAQH CORE Safe Harbor provisions all payload processing modes specified for the transactions addressed by the rule must be supported in each connectivity gateway implemented.

Back to Top
Do all error conditions addressed in Section 4.2.6 of the CAQH CORE Connectivity vC3.1.0 have to be checked, e.g., the example sequence diagrams do not depict checking SOAP error faults?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:41
Do all error conditions addressed in Section 4.2.6 of the CAQH CORE Connectivity vC3.1.0 have to be checked, e.g., the example sequence diagrams do not depict checking SOAP error faults?

Yes. All applicable error conditions that may occur must be checked, including SOAP error faults, even if not displayed in the sequence diagrams examples.

Back to Top
Are there recommendations for how frequently to audit the data in Section 4.2.7, Audit Handling?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:42
Are there recommendations for how frequently to audit the data in Section 4.2.7, Audit Handling?

No. Auditing is a local decision by each trading partner, which includes the frequency of audits.

Back to Top
If a submitter’s transaction real time response is not received from a receiver, can the submitter’s transaction be excluded from the submitter’s response time reporting as a failed transaction caused by external problems?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:43
If a submitter’s transaction real time response is not received from a receiver, can the submitter’s transaction be excluded from the submitter’s response time reporting as a failed transaction caused by external problems?

No, all transactions should be recorded for response time tracking. Failed transactions due to external timeouts should be reported and investigated with external trading partners.

Back to Top
How is MTOM applied in CORE Connectivity vC2.2.0 and CORE Connectivity vC3.1.0 Rules?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:43
How is MTOM applied in CORE Connectivity vC2.2.0 and CORE Connectivity vC3.1.0 Rules?

The W3C Message Transmission Optimization Mechanism (MTOM) is a method of efficiently sending binary data to and from Web Services which use SOAP over the HTTP protocol. Requirements addressing use of MTOM are specified in both CAQH CORE Connectivity vC2.2.0 and CAQH CORE ConnectivityvC3.1.0:

  • CAQH CORE Connectivity vC2.0.0 requires the use of MTOM for all SOAP message envelopes only when exchanging data in Batch Processing Mode. The rule does not permit the use of MTOM in SOAP message envelopes for Real Time Processing Mode. The SOAP message for Real Time Processing Mode requires the use of an inline CDATA element to carry the payload (for more information, see the normative XSD schema in Section 4.2.2 of the CAQH CORE Connectivity vC2.0.0). 
  • The CAQH CORE Connectivity vC3.1.0 requires the use of MTOM to encapsulate all payloads in a SOAP message for both Real Time AND Batch Processing Modes.
Back to Top
Section 4.1 of the CAQH CORE Payment & Remittance (835) Infrastructure Rule requires entities to support the CAQH CORE Connectivity Rule vC2.2.0 to send/receive the X12 v5010 835. CAQH CORE Connectivity requires health plans and clearinghouses to pub

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:44
Section 4.1 of the CAQH CORE Payment & Remittance (835) Infrastructure Rule requires entities to support the CAQH CORE Connectivity Rule vC2.2.0 to send/receive the X12 v5010 835. CAQH CORE Connectivity requires health plans and clearinghouses to publish a Connectivity Companion Guide. Is this Connectivity Companion Guide the same as the health care claim payment/advice Companion Guide referenced in Section 4.4 of the CAQH CORE Payment & Remittance (835) Infrastructure Rule?

Connectivity Companion Guides are entity-specific guides that outline the requirements to establish and maintain a connection with the entity. Section 4.3.7, Publication of Entity Specific Connectivity Guide, of the CAQH CORE Connectivity Rule vC2.2.0 requires that all information servers (i.e., health plans and clearinghouses) publish an entity-specific Connectivity Companion Guide on their public web site. The Connectivity Companion Guide must include the entity’s detailed specifications for the CAQH CORE Connectivity Safe Harbor, any custom extensions to the CAQH CORE Connectivity Safe Harbor, and any additional non-CAQH CORE connectivity methods supported by the entity. Per the requirements in Section 4.1, Health Care Claim Payment/Advice Connectivity Requirements, of the CAQH CORE Payment & Remittance (835) Infrastructure Rule, the Connectivity Companion Guide must also include the entity’s connectivity requirements for transmitting the X12 v5010 835.

Beyond the Connectivity Companion Guide, health plans and clearinghouses can also choose to publish a Companion Guide describing the specifics of how the entity implements a particular HIPAA-mandated transaction standard. Health plan and clearinghouse Companion Guides often vary in format and structure, which can be confusing to trading partners and providers. To address this issue, the CAQH CORE Operating Rules require that entity Companion Guides follow the flow and format defined in the CAQH CORE v5010 Master Companion Guide Template.

The CAQH CORE Operating Rules do not require any entity to publish a Companion Guide if they do not already do so. However, per Section 4.4, Health Care Claim Payment/Advice Companion Guide, of the CAQH CORE Payment & Remittance (835) Rule, if a health plan or clearinghouse chooses to publish a Companion Guide for the X12 v5010 835 transaction, it must conform to the format/flow as defined in the CAQH CORE v5010 Master Companion Guide Template.

If a health plan or clearinghouse chooses to publish an X12 v5010 835 Companion Guide, it may choose to include the Connectivity Companion Guide in the X12 v5010 835 Companion Guide or choose to publish it separately.

Back to Top
Does the Payment & Remittance (835) Infrastructure Rule specify processing mode requirements for exchange of the X12 v5010 835?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:45
Does the Payment & Remittance (835) Infrastructure Rule specify processing mode requirements for exchange of the X12 v5010 835?

Yes. Section 4.1, Health Care Claim Payment/Advice Connectivity Requirements, of the CAQH CORE Payment & Remittance (835) Infrastructure Rule requires entities to support the use of the CORE Connectivity Safe Harbor, as described in the CAQH CORE Connectivity Rule vC2.2.0, to send/receive the X12 v5010 835. Per Section 4.1, “This requirement addresses usage patterns for batch transactions, the exchange of security identifiers, and communications-level errors and acknowledgements.”

To comply with the CAQH CORE Payment & Remittance (835) Infrastructure Rule requirements, entities must support batch processing of the X12 v5010 835, in conformance with the CAQH CORE Connectivity Rule vC2.2.0 requirements for batch processing mode. While the CAQH CORE Payment & Remittance (835) Infrastructure Rule does not require the exchange of the X12 v5010 835 in real time, it does not prohibit it; therefore, conducting the X12 v5010 835 in real time could be mutually agreed to between trading partners.

Back to Top
The CAQH CORE Payment & Remittance (835) Infrastructure Rule requires entities to support the requirements for batch processing of the X12 v5010 835 specified in the CAQH CORE Connectivity Rule vC2.2.0. In Section 4.2.2.1 of the CAQH CORE Connectivit

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:45
The CAQH CORE Payment & Remittance (835) Infrastructure Rule requires entities to support the requirements for batch processing of the X12 v5010 835 specified in the CAQH CORE Connectivity Rule vC2.2.0. In Section 4.2.2.1 of the CAQH CORE Connectivity Rule the payload value for the Batch Results Retrieval Request is specified as “minOccurs=’0’.” Does this value mean that entities are not required to include a Payload in the request?

Yes. Section 4.2.2.1, CORE Connectivity XML Schema Specification (normative), of CAQH CORE Connectivity Rule vC2.2.0 specifies a value of minOccurs=”0” for the Payload element because the Batch Results Retrieval Request does not always require a payload (e.g., if there is no batch available for retrieval). As the intent of the Batch Results Retrieval Request is to pick up a batch (or batches) and not to deliver a payload, the Batch Results Retrieval Request may have only a SOAP envelope and no payload.

Please Note: The CAQH CORE Payment & Remittance (835) Infrastructure Rule does not prohibit entities from using other connectivity methods to conduct the X12 v5010 835 or require entities to remove existing connections that do not match the CORE Connectivity.

Back to Top
The CAQH CORE Payment & Remittance (835) Infrastructure Rule require health plans to support transmission of the X12 v5010 835 to providers via the public Internet?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:46
The CAQH CORE Payment & Remittance (835) Infrastructure Rule require health plans to support transmission of the X12 v5010 835 to providers via the public Internet?

Yes. Section 4.1, Health Care Claim Payment/Advice Connectivity Requirements, of the CAQH CORE Payment & Remittance (835) Infrastructure Rule requires health plans and other information sources to support the CAQH CORE Connectivity Rule vC2.2.0 to transmit the X12 v5010 835 ERA to providers. (NOTE: Other connectivity methods can also be used.) The CAQH CORE Connectivity vC2.2.0 Rule requires entities to support delivery of the X12 v5010 835 via the public Internet using HTTP with SSL as the minimum security for the communications channel with specific envelopes, metadata, and submitter authentication methods.

Please Note: The CAQH CORE Payment & Remittance (835) Infrastructure Rule does not prohibit entities from using other connectivity methods to transmit the X12 v5010 835 nor require entities to remove existing connections that do not match the CAQH CORE Connectivity Rule vC2.2.0.

Back to Top
CAQH CORE Payment & Remittance (835) Infrastructure Rule requires health plans to support the CAQH CORE Connectivity Rule vC2.2.0 to transmit the X12 v5010 835. Our organization is a health plan that currently transmits several X12 v5010 835 transact

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:47
CAQH CORE Payment & Remittance (835) Infrastructure Rule requires health plans to support the CAQH CORE Connectivity Rule vC2.2.0 to transmit the X12 v5010 835. Our organization is a health plan that currently transmits several X12 v5010 835 transactions in a single payload. Does the CAQH CORE Connectivity Rule vC2.2.0 specify a maximum number of X12 v5010 835 transactions that can be sent in a single payload?

No. Section 4.1, Health Care Claim Payment/Advice Connectivity Requirements, of the CAQH CORE Payment & Remittance (835) Infrastructure Rule requires all health plans to support use of the CAQH CORE Connectivity Safe Harbor described in the CAQH CORE Connectivity Rule vC2.2.0 to transmit the X12 v5010 835. (NOTE: Providers are also required to support use of the CAQH CORE 835 Infrastructure Rule to receive the X12 v5010 835.)

The CAQH CORE Connectivity Rule vC2.2.0 neither requires nor prohibits the inclusion of multiple transaction sets, Functional Groups, or ASC X12 Interchanges in a single payload. Section 6.1, Appendix and Definitions Used in this Rule, of the CAQH CORE Connectivity Rule vC2.2.0 defines a payload of batch files as a single submission containing either:

  • One X12 Interchange containing one Functional Group containing one X12 transaction set consisting of more than one business transaction. OR
  • More than one ASC X12 Interchange, each of which may contain one or more Functional Groups, each of which may contain one or more ASC X12 transaction sets.

Information sources of the X12 v5010 835 (i.e., health plans and clearinghouses/vendors acting as a business associate of a health plan) may choose to include multiple X12 v5010 835s in a single payload or send each X12 v5010 835 transaction in separate payloads.

Back to Top
The CAQH CORE Payment & Remittance (835) Infrastructure Rule requires health plans to support the CAQH CORE Connectivity Rule vC.2.2.0 to transmit the X12 v5010 835. Our organization is a health plan that currently limits the size of the batch X12 v5

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:47
The CAQH CORE Payment & Remittance (835) Infrastructure Rule requires health plans to support the CAQH CORE Connectivity Rule vC.2.2.0 to transmit the X12 v5010 835. Our organization is a health plan that currently limits the size of the batch X12 v5010 835 file sent in a single payload to prevent problems with the receiver’s system performance. Does the CAQH CORE Connectivity Rule vC2.2.0 prohibit health plans from setting a maximum limit for the size of the X12 v5010 835 batch file sent in a single payload?

No. Section 4.1, Health Care Claim Payment/Advice Connectivity Requirements, of the CAQH CORE Payment & Remittance (835) Infrastructure Rule requires all health plans to support use of the CAQH CORE Connectivity Safe Harbor described in the CAQH CORE Connectivity Rule vC2.2.0 to transmit the X12 v5010 835. (NOTE: Providers are also required to support use of the CAQH CORE Connectivity Rule vC2.2.0 to receive the X12 v5010 835).

Section 3.6, Outside the Scope of this Rule, of the CAQH CORE Connectivity Rule vC2.2.0 specifies that the maximum size of a batch file accepted by a server is out of scope of the CAQH CORE Connectivity Rule vC2.2.0. This applies both when batch files are “pushed” by the health plan to the provider (i.e., the health plan acts as a server) and when the provider sends a request to receive available files (i.e., the provider is acting minimally as a client). The CAQH CORE Connectivity Rule vC2.2.0 does require entities that conduct batch processing to have the capability to receive and process large batch transaction files ; however, per Section 4.3.5, Capacity Plan, of the CAQH CORE Connectivity Rule vC2.2.0, the maximum number of transaction sets to be included in a large batch file is an issue to be negotiated between trading partners. 

Senders of the X12 v5010 835 (i.e., health plans and clearinghouses/vendors acting as a business associate of a health plan) should work with their trading partners to establish reasonable limits for the maximum size of batch files that can be supported by their trading partners. Any system size limitations should be specified in an entity’s Connectivity Companion Guide.

Back to Top
Per Section 3.3, the CAQH CORE Payment & Remittance (835) Uniform Use of CARCs and RARCs Rule applies when entities process the X12 v5010 835 in either real time or batch. Does this requirement mean that the CAQH CORE Payment & Remittance (835) Unifo

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:48
Per Section 3.3, the CAQH CORE Payment & Remittance (835) Uniform Use of CARCs and RARCs Rule applies when entities process the X12 v5010 835 in either real time or batch. Does this requirement mean that the CAQH CORE Payment & Remittance (835) Uniform Use of CARCs and RARCs Rule requires entities to support both batch and real time processing of the X12 v5010 835?

No. Per Section 3.3, When the Rule Applies, of the CAQH CORE Payment & Remittance (835) Uniform Use of CARCs and RARCs Rule, the rule applies when an entity uses, conducts, or processes the X12 v5010 835, either in real time or batch processing mode. The CAQH CORE Payment & Remittance (835) Uniform Use of CARCs and RARCs Rule does not specify requirements regarding what processing mode entities must support for the X12 v5010 835.

The CAQH CORE Payment & Remittance (835) Infrastructure Rule does specify one processing mode that entities must offer for the X12 v5010 835 (other processing modes can also be offered). Section 4.1, Health Care Claim Payment/Advice Connectivity Requirements, of the rule requires entities to support the use of the CORE Connectivity Safe Harbor, as described in the CAQH CORE Connectivity Rule vC2.2.0, to send/receive the X12 v5010 835. Per Section 4.1, “This requirement addresses usage patterns for batch transactions, the exchange of security identifiers, and communications-level errors and acknowledgements.”

Back to Top