Frequently Asked Questions - CAQH CORE Connectivity Rule vC2.2.0

The first version of CORE Connectivity 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.

CAQH CORE Connectivity vC2.2.0 builds upon the initial 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 CAQH CORE Connectivity vC2.2.0 provide requirements for encapsulating an expanded set of metadata needed for routing, submitter identification/authentication and auditing. Additionally, the CAQH CORE Connectivity vC2.2.0 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.

No. Though HITSP T85 (Administrative Transport to Health Plan) uses CAQH CORE Connectivity vC2.2.0, this does not mean that by being CORE certified you will meet HITSP T85 requirements. CAQH CORE Connectivity vC2.2.0 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 CAQH CORE ConnectivityvC2.2.0. For instance, HITSP T17 uses Transport Layer Security (TLS) instead of SSL. CAQH CORE Connectivity vC2.2.0 provides a safe harbor specifying minimum requirements but does not preclude the use of other methods for securing the communications channels. 

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 CAQH CORE Connectivity & Security Subgroup selected HTTP MIME Multipart and SOAP + WSDL as the two standards that both met the majority of CAQH 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 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 may be a goal for future rules to reach. Conformance guidance is provided as part of the CAQH CORE Connectivity Rule for all stakeholders to implement one or both envelope standards.

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 Connectivity vC3.1.0:

1. CAQH CORE Connectivity vC2.2.0 requires the use of MTOM for all SOAP message envelopes only when exchanging data in Batch Processing Mode. CAQH CORE Connectivity vC2.2.0 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 CAQH CORE Connectivity vC2.2.0). 
2. 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.

The CAQH CORE Connectivity & Security Subgroup evaluated the connectivity implementations 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 the first version of CORE Connectivity 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. Like the decision on envelope standards, a decision was made to allow both authentication standards with the necessary conformance guidance for all stakeholders.

Conformance requirements for implementing Submitter Authentication Standards are provided in Section 4.1 of CAQH CORE Connectivity Rule vC2.2.0 by key stakeholder categories acting in either the Client or Server role. The requirements for these stakeholder categories include health plans and health plan vendors, when acting as the Server, must support one of the two submitter authentication standards. Healthcare Providers, provider vendors and clearinghouses, when acting as the Client, must implement the client portions of authentication for both submitter authentication standards.

No. Although the use of SOAP or HTTP/MIME envelopes over private networks like VPNs is possible, the CAQH CORE Connectivity vC2.2.0 Rule requires the use of HTTP/S over the public Internet. CAQH CORE Connectivity vC2.2.0 was based on use of the public Internet for transport, and the CAQH CORE Connectivity vC2.2.0 builds on the first version of CORE Connectivity, while retaining the same underlying transport.

No. Although the use of a non-TCP/IP network (e.g., Frame Relay) is possible, the CAQH CORE Connectivity vC2.2.0 requires the use of HTTP/S over the public internet. The CAQH CORE Connectivity Rule was based on use of the public Internet (which is TCP/IP based) for transport, and the CAQH CORE Connectivity vC2.2.0 builds on existing rule, while retaining the same underlying transport.

No. CAQH CORE Connectivity vC2.2.0 is applicable to and may be used when a CORE-certified entity is exchanging any X12 administrative transaction whether the transaction has been mandated under HIPAA or not. An entity that is CORE certified is required to support the CAQH CORE Connectivity vC2.2.0 as a safe harbor (see Rule Section 5) when exchanging the X12 270/27, X12 276/277, and the ASC X12 Implementation Acknowledgement (999) transactions addressed in the CAQH CORE Operating Rules.

Yes. The CAQH CORE Connectivity vC2.0.0 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 and claim status, specifically for other X12 administrative transactions or other content such as HL7 clinical messages or personal health records.

The URL for the CAQH CORE 2.2.0-compliant XML Schema specification file, CORERule2.2.0.xsd, for use within the WSDL specification is available at https://www.caqh.org/sites/default/files/core/wsdl/CORERule4.0.0.xsd. The URL of the CAQH CORE 2.2.0 WSDL schema is: https://www.caqh.org/sites/default/files/core/wsdl/CORERule4.0.0.wsdl.

Adding extra fields is in conformance with the CAQH CORE Connectivity Rule when this is done within the HTTP+MIME envelope option.

However, additional fields are likely to cause interoperability problems unless trading partners agree on their syntax and semantics, hence the use of such extra fields is discouraged. If fields are added to an HTTP+MIME envelope, such additions should be defined in the entity’s Companion Guide.

Adding SOAP Headers is compliant with the CAQH CORE Connectivity Rule vC2.2.0. The use of custom SOAP Headers may cause interoperability issues unless trading partners agree on their syntax and semantics, hence the use of such fields are discouraged. Instead, the use of open standards-based SOAP Headers such as WS-Security is encouraged. If used, the SOAP Header elements (or open standards that specify the SOAP Header elements) should be specified in the entity’s Companion Guide. 

While the CAQH CORE Connectivity Rule vC2.2.0 references the WS-I Basic Profile 1.1 in the appendix, the rule itself does not specify which version of the Basic Profile is to be used given that no specific version was ubiquitously adopted in the industry at the time the rule was approved. When the CAQH CORE Connectivity vC2.2.0 was developed the Basic Profile Version 1.1 did not support other requirements for CORE Connectivity, e.g., WSDL 1.1, SOAP 1.2, and MTOM. For version 2.2.0 of the CORE Connectivity Rule, compliance with any version of the WS-I Basic Profile is an implementation level decision. Future versions of the CAQH CORE Connectivity Rule will consider the version of the Basic Profile that may exist at the time of such CAQH CORE Rule revisions.

Yes. You are required to use each of the metadata element fields flagged as “Required” in Table 4.2.2, Table of CORE Required Metadata, specifically as indicated for both real time and batch mode processing.

NOTE: Some fields may be optional, as specified in Table 4.2.2. For example, the Error Code and Error Message fields are only required in the Response message for real time and batch as these fields are not used in the Request message.

This is not allowed for ASC X12 payloads. Section 4.4.4 in CORE Connectivity Rule vC2.2.0 has a table with a normative and comprehensive set of all payload types for X12 payloads.

Yes, for non-X12 Payloads. The naming convention for non-X12 payloads such as HL7 and NCPDP payloads is also defined in this section.

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., X12 270) are sent, such as a Health Plan or Clearinghouse.

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

Since SSL was far more prevalent than TLS at the time CAQH CORE Connectivity vC2.2.0 was published, CAQH CORE Connectivity Rule vC2.2.0 specifies the use of HTTP over SSL. This does not preclude the optional use of TLS 1.0 (or a higher version as required for FIPS 140 compliance) for connectivity with trading partners that require FIPS 140 compliance. CORE Certification requires testing with SSL 3.0 for transport security. Future version of CAQH CORE Connectivity require the use of HTTP over TLS as SSL.

The SOAP+WSDL interfaces in the CAQH CORE Connectivity Rule vC2.2.0 must be implemented over SOAP 1.2 for CAQH CORE conformance. An organization may choose to also offer the same interfaces over SOAP 1.1, but these would not be considered CAQH CORE conformant.

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 CAQH CORE Connectivity vC2.2.0. 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 CAQH CORE Connectivity vC2.2.0.

CAQH CORE Connectivity vC2.2.0 does not specify a size limit on batch files. If your implementation imposes a limit, this should be described in your Connectivity Guide.

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.

Real time processing mode is required for all payload types (transactions) that are currently addressed by a CAQH CORE Rule, i.e., X12 270/271 eligibility and X12 276/277 claim status. Batch processing mode is optional for both transactions. CAQH CORE Connectivity Rule vC2.2.0 applies to both the X12 270/271 and the X12 276/277 transactions.

Batch processing mode is optional for all payload types. If an organization does perform batch processing and is seeking CORE Certification for CAQH CORE Connectivity using batch processing, one of the following payload types must be supported: 1) Mixed payload, 2) X12 270/271, or 3) X12 276/277.

1. CORE Participants’ 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 CORE Connectivity version 1), 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).

The values for the PayloadType for NCPDP transactions have been defined by NCPDP and appear in the latest publication of the NCPDP External Code List. 

NOTE: Only real time NCPDP transactions are supported by the PayloadType values defined by NCPDP.

CAQH CORE Connectivity vC2.2.0 does not specify the use of password digests. The underlying transport is HTTP/S (per the CAQH CORE Connectivity Version 1), 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.

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 Technical Report Type 3 (TR3) 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.

An XML-based eligibility inquiry and response equivalent to the X12 270/271 cannot be used in place of HIPAA-mandated standard form as specified in the X12 270/271 TR3. However, your organization can accept the X12 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 CAQH CORE Connectivity Rule, organizations can specify an XML based message "wrapper" around the X12 Interchange of 270 and 271 transactions.

Section 6 of the CAQH COR Connectivity Rule vC2.2.0 defines a large batch file (payload) as "A single submission of a message payload that contains more than one X12 Interchange, each of which may contain one or more Functional Groups, each of which may contain one or more X12 transaction sets."

The conformance guidelines for different stakeholder types for implementing the two envelope standards (SOAP 1.2 and HTTP+MIME Multipart) defined in CAQH CORE Connectivity Rule vC2.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 Connectivity Rule vC2.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

The CAQH CORE Operating Rules apply to HIPAA transactions, which are healthcare electronic data interchanges (EDI); as such, the CAQH CORE Connectivity Rule vC2.2.0 does not apply when the X12 v5010 835 is provided via Direct Data Entry. Section 4.1, Health Care Claim Payment/Advice Connectivity Requirements of the 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. Health plans may continue to offer the X12 v5010 835 via DDE; however, use of only a website to provide the X12 v5010 835 to providers does not satisfy the connectivity requirements of the CAQH CORE Connectivity Rule.

No. Section 4.1, Health Care Claim Payment/Advice Connectivity Requirements, of the CAQH CORE Connectivity Rule vC2.2.0 requires all HIPAA covered entities to support use of the CORE Connectivity Safe Harbor described in the CAQH CORE Connectivity Rule vC2.2.0 to transmit or receive the X12 v5010 835. However, the CAQH CORE Connectivity Rule vC2.2.0 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 rule.

As a “Safe Harbor”, CORE Connectivity specifies connectivity methods that application vendors, providers, and health plans can be assured is supported by any HIPAA covered entity and/or a CORE-certified entity. Supporting the CAQH CORE Connectivity Safe Harbor means that the entity is capable and ready to exchange data at the time a request is made by a trading partner. The CORE Safe Harbor allows for an automated EDI-based process to conduct the X12 v5010 835 rather than a manual download process. In some circumstances, you and your trading partners may decide to continue to use your existing connection to transmit or receive the X12 v5010 835, as permitted by the CAQH CORE Connectivity Safe Harbor; however, you must implement the capability to use the CAQH CORE Connectivity Safe Harbor and be capable and ready to use it when requested by a trading partner.