1. How is MTOM applied in the Phase II and Phase IV CAQH CORE Connectivity 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 the Phase II CAQH CORE 270 Connectivity Rule and the Phase IV CAQH CORE 470 Connectivity Rule:

2. How should entities track the X12 270/271 and/or X12 276/277 transactions when using another connectivity method, as permitted by the CAQH CORE Connectivity Safe Harbor?

When a health plan uses another connectivity method, as permitted by the CAQH CORE 270: Connectivity Rule Safe Harbor, CAQH CORE recommends that the health plan still implement the audit log requirements of CAQH CORE 270 Rule, Section 4.3.4. This log can be used to resolve any issues or concerns regarding compliance and to identify where a bottleneck may occur in meeting the 20-second maximum real time and batch response time requirements.

3. What is the specific method for an entity to conform to the CAQH CORE 270 Rule audit log requirements?

The CAQH CORE 270 Rule does not specify a method for capturing and logging data. The rule only specifies what data must be captured and logged. The method for how to capture and log is determined by the implementer. CAQH CORE 270 Section 4.3.4 requires that, to comply with the CAQH CORE 155, 156, and 250 Rules message response requirements, receivers must track the date, time, and payload ID of any received inbound messages and respond with the outbound message for that Payload ID.

4. Does the CAQH CORE 270 Rule require the use of the MAC address?

Yes. The field constraints or value-sets for PayloadID are specified in CAQH CORE 270, Section 4.4.2, Table of CORE Envelope Metadata. Specifically, the rule specifies “PayloadID will conform to ISO UUID standards (described at ftp://ftp.rfc-editor.org/in-notes/rfc4122.txt), with hexadecimal notation, generated using a combination of local timestamp (in milliseconds) as well as the hardware (MAC) address, to ensure uniqueness.”

5. The Entity-Specific Connectivity Guide (Section 4.3.7 of the CAQH CORE 270 Rule) states that details of the message format and supported transactions, such as returning a list of files to be picked up for batch transactions, can be specified in a Conn

No. By design, the CAQH CORE 270 Rule is highly prescriptive in the envelope metadata and message interactions because the CORE Participants need a Connectivity Rule that provides a high degree of interoperability. Entities may implement custom extensions which must be described in a Companion Guide, but such extensions are not compliant with the CAQH CORE 270 Rule’s normative specifications (i.e., XSD, WSDL) and are therefore considered as non-CAQH CORE connectivity interfaces.

6. In the CAQH CORE 270 Rule, 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?

The CAQH CORE 270 Rule does not specify the use of password digests. The underlying transport is HTTP/S (per the Phase I CAQH CORE Connectivity Rule), 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.

7. Currently the PayloadType values provided within the CAQH CORE 270: Connectivity Rule 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: As of Phase II CAQH CORE, only real time NCPDP transactions are supported by the PayloadType values defined by NCPDP. CAQH CORE is working with NCPDP to identify requirements to be addressed in a future phase of CAQH CORE.

8. I have a suggestion to update field X or to add field Y to the envelopes defined in the Phase II CAQH CORE Connectivity Rule. What is the process for doing this?

Please submit your request to CAQH CORE. Your request will be considered by the CORE membership for inclusion in a future phase of CAQH CORE operating rules.

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 Phase I connectivity), 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 270 Rule 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 Phase II 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.