Frequently Asked Questions - CAQH CORE Connectivity Rule vC2.2.0

  1. What is the relationship between the first version of the CAQH CORE Connectivity Rule vC1.1.0 and CAQH CORE Connectivity vC2.2.0?
  2. It is my understanding that HITSP T85 (Administrative Transport to Health Plan) is based on the CAQH CORE Connectivity vC2.2.0. Does this mean that if I am CORE certified I will meet HITSP T85 requirements?
  3. Why were two envelope standards chosen in CAQH CORE Connectivity vC2.2.0?
  4. How is MTOM applied in the CAQH CORE Connectivity vC2.2.0 and CAQH CORE Connectivity vC3.1.0?
  5. Why were two authentication standards chosen in the CAQH CORE vC2.2.0 Connectivity?
  6. If my organization wants to conform with the CAQH CORE Operating Rules, which authentication standards are applicable?
  7. We have a private network (e.g., VPN connection) for eligibility transactions. Can we use the SOAP or HTTP-MIME multipart envelopes over this network and get CORE certified?
  8. We use a non-TCP/IP network (e.g., X.25, Frame Relay). Can we use the SOAP or HTTP/MIME envelopes over these networks and get CORE certified?
  9. Is CAQH CORE Connectivity vC2.2.0 applicable only to the ANSI X12 270/271 transactions?
  10. What about non-X12 payloads? Can the same envelope and authentication standards be applied to those payloads?
  11. What is the URL of the WSDL Schema for the SOAP+WSDL implementation?
  12. I need to add some extra fields as part of the message envelope. Is this allowed?
  13. I would like to use this SOAP+WSDL, but I wish to also have additional SOAP headers that are not in this specification. Is this allowed?
  14. What version of the WS Basic Profile is required by the CAQH CORE Operating Rules?
  15. I am not planning to use all fields in the message envelope. Do I still need to have all the fields in the envelope?
  16. I need to add a different payload type/processing mode value than what is listed in CORE Connectivity vC2.2.0. Is this allowed?
  17. Who issues the username/password for use with authentication?
  18. Are there any guidelines/restrictions on the username and passwords that can be used?
  19. My organization requires the use of Transport Layer Security (TLS) for transport security. Can a CORE conformant envelope be used over TLS?
  20. We would like to implement the SOAP envelope but would like to use SOAP 1.1. Is this a valid approach to reaching CAQH CORE conformance?
  21. We need to add some new error codes and messages that are not listed in the CAQH CORE Connectivity vC2.2.0. Is this allowed?
  22. What is the maximum size of each batch file that can be sent?
  23. I am using CAQH CORE Connectivity vC2.2.0 for exchanging SOAP real time transactions. The payload includes non-printable characters. What are the issues I need to be aware of?
  24. To meet the CAQH CORE Connectivity vC2.2.0 requirements for real time processing, what is the minimum set of payload types that must be supported?
  25. To meet the CAQH CORE Connectivity vC2.2.0 requirements for batch processing, what is the minimum set of payload types that must be supported?
  26. In the SOAP+WSDL envelope option, why is the real time request/response payload defined as type=xs:string and the batch counterparts are defined as base64Binary?
  27. Currently the PayloadType values provided within the CAQH CORE Connectivity vC2.2.0 have X12 values listed, e.g., X12_270_004010X092A1. What are the corresponding PayloadType values for transactions using NCPDP payloads?
  28. In the CAQH CORE Connectivity vC2.2.0, when passing a username and password as the authentication tokens, can the password be passed in the clear or encrypted? Are both variants allowed or does CORE specify one or the other?
  29. Batch processing: Must a batch reply file contain replies for every request in a batch request? Is it an error to omit some?
  30. Can my organization run an X12 270/271 transaction on XML?
  31. Do the time frames still apply if it is an especially large batch? Do the CAQH CORE Rules define the batch size?
  32. Is an implementation approach that uses SOAP 1.2 with or without attachments, running on top of HTTP/S 1.1, in conformance with CAQH CORE Connectivity vC2.2.0?
  33. My health plan provides the X12 v5010 835 via an online application only, do the CAQH CORE Connectivity Rule requirements apply?
  34. I am a provider organization that currently receives the X12 v5010 835 via manual download from a health plan’s web portal. Does the connectivity requirement specified in Section 4.1 of the CAQH CORE Connectivity Rule vC2.2.0 mean that my organization
What is the relationship between the first version of the CAQH CORE Connectivity Rule vC1.1.0 and CAQH CORE Connectivity vC2.2.0?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:46
What is the relationship between the first version of the CAQH CORE Connectivity Rule vC1.1.0 and CAQH CORE Connectivity 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.

Back to Top
It is my understanding that HITSP T85 (Administrative Transport to Health Plan) is based on the CAQH CORE Connectivity vC2.2.0. Does this mean that if I am CORE certified I will meet HITSP T85 requirements?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:47
It is my understanding that HITSP T85 (Administrative Transport to Health Plan) is based on the CAQH CORE Connectivity vC2.2.0. Does this mean that if I am CORE certified I will meet HITSP T85 requirements?

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. 

Back to Top
Why were two envelope standards chosen in CAQH CORE Connectivity vC2.2.0?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:48
Why were two envelope standards chosen in CAQH CORE Connectivity vC2.2.0?

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.

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

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

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.
Back to Top
Why were two authentication standards chosen in the CAQH CORE vC2.2.0 Connectivity?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:50
Why were two authentication standards chosen in the CAQH CORE vC2.2.0 Connectivity?

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.

Back to Top
If my organization wants to conform with the CAQH CORE Operating Rules, which authentication standards are applicable?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:50
If my organization wants to conform with the CAQH CORE Operating Rules, which authentication standards are applicable?

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.

Back to Top
We have a private network (e.g., VPN connection) for eligibility transactions. Can we use the SOAP or HTTP-MIME multipart envelopes over this network and get CORE certified?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:51
We have a private network (e.g., VPN connection) for eligibility transactions. Can we use the SOAP or HTTP-MIME multipart envelopes over this network and get CORE certified?

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.

Back to Top
We use a non-TCP/IP network (e.g., X.25, Frame Relay). Can we use the SOAP or HTTP/MIME envelopes over these networks and get CORE certified?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:52
We use a non-TCP/IP network (e.g., X.25, Frame Relay). Can we use the SOAP or HTTP/MIME envelopes over these networks and get CORE certified?

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.

Back to Top
Is CAQH CORE Connectivity vC2.2.0 applicable only to the ANSI X12 270/271 transactions?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:52
Is CAQH CORE Connectivity vC2.2.0 applicable only to the ANSI X12 270/271 transactions?

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.

Back to Top
What about non-X12 payloads? Can the same envelope and authentication standards be applied to those payloads?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:53
What about non-X12 payloads? Can the same envelope and authentication standards be applied to those payloads?

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.

Back to Top
What is the URL of the WSDL Schema for the SOAP+WSDL implementation?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:53
What is the URL of the WSDL Schema for the SOAP+WSDL implementation?

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.

Back to Top
I need to add some extra fields as part of the message envelope. Is this allowed?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:54
I need to add some extra fields as part of the message envelope. Is this allowed?

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.

Back to Top
I would like to use this SOAP+WSDL, but I wish to also have additional SOAP headers that are not in this specification. Is this allowed?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:55
I would like to use this SOAP+WSDL, but I wish to also have additional SOAP headers that are not in this specification. Is this allowed?

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. 

Back to Top
What version of the WS Basic Profile is required by the CAQH CORE Operating Rules?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:55
What version of the WS Basic Profile is required by the CAQH CORE Operating Rules?

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.

Back to Top
I am not planning to use all fields in the message envelope. Do I still need to have all the fields in the envelope?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:56
I am not planning to use all fields in the message envelope. Do I still need to have all the fields in the envelope?

Yes. You are required to use each of the metadata element fields 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.

Back to Top
I need to add a different payload type/processing mode value than what is listed in CORE Connectivity vC2.2.0. Is this allowed?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:56
I need to add a different payload type/processing mode value than what is listed in CORE Connectivity vC2.2.0. Is this allowed?

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.

Back to Top
Who issues the username/password for use with authentication?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:57
Who issues the username/password for use with authentication?

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

Back to Top
Are there any guidelines/restrictions on the username and passwords that can be used?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:58
Are there any guidelines/restrictions on the username and passwords that can be used?

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

Back to Top
My organization requires the use of Transport Layer Security (TLS) for transport security. Can a CORE conformant envelope be used over TLS?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:58
My organization requires the use of Transport Layer Security (TLS) for transport security. Can a CORE conformant envelope be used over TLS?

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.

Back to Top
We would like to implement the SOAP envelope but would like to use SOAP 1.1. Is this a valid approach to reaching CAQH CORE conformance?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:59
We would like to implement the SOAP envelope but would like to use SOAP 1.1. Is this a valid approach to reaching CAQH CORE conformance?

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.

Back to Top
We need to add some new error codes and messages that are not listed in the CAQH CORE Connectivity vC2.2.0. Is this allowed?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:00
We need to add some new error codes and messages that are not listed in the CAQH CORE Connectivity vC2.2.0. Is this allowed?

Yes. New error codes and messages may be added when there is an error condition that is not addressed using the error codes listed in the 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.

Back to Top
What is the maximum size of each batch file that can be sent?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:17
What is the maximum size of each batch file that can be sent?

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.

Back to Top
I am using CAQH CORE Connectivity vC2.2.0 for exchanging SOAP real time transactions. The payload includes non-printable characters. What are the issues I need to be aware of?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:17
I am using CAQH CORE Connectivity vC2.2.0 for exchanging SOAP real time transactions. The payload includes non-printable characters. What are the issues I need to be aware of?

When sending or receiving payloads that contain non-printable characters, e.g., separator characters in an X12 Interchange, or in a non-X12 Interchange payload, using SOAP real time request/response envelope, the payload must be base64 encoded.

Back to Top
To meet the CAQH CORE Connectivity vC2.2.0 requirements for real time processing, what is the minimum set of payload types that must be supported?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:18
To meet the CAQH CORE Connectivity vC2.2.0 requirements for real time processing, what is the minimum set of payload types that must be supported?

Real time processing mode is required for all payload types (transactions) that are currently addressed by a 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.

Back to Top
To meet the CAQH CORE Connectivity vC2.2.0 requirements for batch processing, what is the minimum set of payload types that must be supported?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:19
To meet the CAQH CORE Connectivity vC2.2.0 requirements for batch processing, what is the minimum set of payload types that must be supported?

Batch processing mode is optional for all payload types. If an organization does perform batch processing and is 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.

Back to Top
In the SOAP+WSDL envelope option, why is the real time request/response payload defined as type=xs:string and the batch counterparts are defined as base64Binary?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:20
In the SOAP+WSDL envelope option, why is the real time request/response payload defined as type=xs:string and the batch counterparts are defined as base64Binary?
  1. CORE 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).
Back to Top
Currently the PayloadType values provided within the CAQH CORE Connectivity vC2.2.0 have X12 values listed, e.g., X12_270_004010X092A1. What are the corresponding PayloadType values for transactions using NCPDP payloads?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:20
Currently the PayloadType values provided within the CAQH CORE Connectivity vC2.2.0 have X12 values listed, e.g., X12_270_004010X092A1. What are the corresponding PayloadType values for transactions using NCPDP payloads?

The values for the PayloadType for NCPDP transactions have been defined by NCPDP and 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.

Back to Top
In the CAQH CORE Connectivity vC2.2.0, when passing a username and password as the authentication tokens, can the password be passed in the clear or encrypted? Are both variants allowed or does CORE specify one or the other?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:21
In the CAQH CORE Connectivity vC2.2.0, when passing a username and password as the authentication tokens, can the password be passed in the clear or encrypted? Are both variants allowed or does CORE specify one or the other?

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.

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

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:22
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 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.

Back to Top
Can my organization run an X12 270/271 transaction on XML?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:22
Can my organization run an X12 270/271 transaction on XML?

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.

Back to Top
Do the time frames still apply if it is an especially large batch? Do the CAQH CORE Rules define the batch size?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:23
Do the time frames still apply if it is an especially large batch? Do the CAQH CORE Rules define the batch size?

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

Back to Top
Is an implementation approach that uses SOAP 1.2 with or without attachments, running on top of HTTP/S 1.1, in conformance with CAQH CORE Connectivity vC2.2.0?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:24
Is an implementation approach that uses SOAP 1.2 with or without attachments, running on top of HTTP/S 1.1, in conformance with CAQH CORE Connectivity vC2.2.0?

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

Back to Top
My health plan provides the X12 v5010 835 via an online application only, do the CAQH CORE Connectivity Rule requirements apply?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:24
My health plan provides the X12 v5010 835 via an online application only, do the CAQH CORE Connectivity Rule requirements apply?

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.

Back to Top
I am a provider organization that currently receives the X12 v5010 835 via manual download from a health plan’s web portal. Does the connectivity requirement specified in Section 4.1 of the CAQH CORE Connectivity Rule vC2.2.0 mean that my organization

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 13:31
I am a provider organization that currently receives the X12 v5010 835 via manual download from a health plan’s web portal. Does the connectivity requirement specified in Section 4.1 of the CAQH CORE Connectivity Rule vC2.2.0 mean that my organization can now only receive the X12 v5010 835 via the CAQH CORE Connectivity Safe Harbor?

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.

Back to Top