Frequently Asked Questions - CAQH CORE Connectivity Rule vC3.1.0

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. 

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. 

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. 

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. 

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.

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.

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

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.

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

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

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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