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

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

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

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

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

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

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

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

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

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