No. The number 270 within the rule name is the rule number and is not a reference to X12 270 eligibility transaction. The CAQH CORE 270: Connectivity Rule Version 2.2.0, is payload agnostic, and is designed to carry any X12 v4010 and v5010 administrative transaction payload as well as any other non-X12 payload.
Frequently Asked Questions - XV. CAQH CORE 270: Connectivity Rule
Please refer to the Phase I CAQH CORE 153: Connectivity Rule FAQs. The Phase II CAQH CORE 270: Connectivity Rule builds upon and enhances the Phase I rule, therefore we recommend that you familiarize yourself with these Phase I “foundational” Questions and Answers as they will, in large part, provide a solid basis for understanding the Phase II rule.
NOTE: The HHS Final Rule for operating rules for the eligibility and claim status transactions adopts all the Phase I and II CAQH CORE Eligibility and Claim Status Operating Rules except those requirements pertaining to the use of Acknowledgements. Entities seeking CORE Certification must implement all of the CAQH CORE Eligibility and Claim Status Operating Rules applicable to their stakeholder type, including those rules & rule requirements pertaining to use of Acknowledgments.
- Does the reference to “270” in the name of the CAQH CORE Connectivity Rule mean that the rule is required only for conduct of the X12 270 eligibility transaction?
- How do the envelope standards in the CAQH CORE 270: Connectivity Rule relate to the ones that have been chosen by ONC, HITSP, HL7, and IHE?
- It is my understanding that HITSP T85 (Administrative Transport To Health Plan) is based on the CAQH CORE 270: Connectivity Rule. Does this mean that if I am Phase II CORE-certified I will meet HITSP T85 requirements?
- What is the relationship between the CAQH CORE Connectivity Rules in Phase I and Phase II?
- What is the CAQH CORE Connectivity “Safe Harbor”?
- Why were two envelope standards chosen in the CAQH CORE 270: Connectivity Rule?
- Why were two authentication standards chosen in the CAQH CORE 270: Connectivity Rule?
- Does CAQH CORE have plans to converge on a single envelope/authentication standard in future phases?
- If my organization wants to conform with the Phase II CAQH CORE Operating Rules, which authentication standards are applicable?
- 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 Phase II CORE-certified?
- 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 Phase II CORE-certified?
- Is the CAQH CORE 270: Connectivity Rule applicable only to the ANSI X12 270/271 transactions?
- What about non-X12 payloads? Can the same envelope and authentication standards be applied to those payloads?
- What is the URL of the WSDL Schema for the SOAP+WSDL implementation?
- If I make changes to the WSDL to implement my client or server, will I still be able to get CORE-certified?
- I need to add some extra fields as part of the message envelope. Is this allowed?
- 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?
- What version of the WS Basic Profile is required by the CAQH CORE Operating Rules?
- I am not planning to use all fields in the message envelope. Do I still need to have all the fields in the envelope?
- What are my SenderID and ReceiverID values? Where can I obtain them?
- I need to add a different payload type/processing mode value than what is listed in the CORE Phase II Connectivity Rule. Is this allowed?
- Who issues the username/password for use with authentication?
- Are there any guidelines/restrictions on the username and passwords that can be used?
- Who issues the client certificates for the X.509 client certificate-based authentication?
- Are there any guidelines/restrictions on the use of specific certificate authorities?
- My organization requires the use of Transport Layer Security (TLS) for transport security. Can a CORE conformant envelope be used over TLS?
- 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?
- We need to add some new error codes and messages that are not listed in the CAQH CORE 270 Rule. Is this allowed?
- What is the maximum size of each batch file that can be sent?
- I am using the CAQH CORE 270 Rule for exchanging SOAP real time transactions. The payload includes non-printable characters. What are the issues I need to be aware of?
- To meet the CAQH CORE 270 Rule requirements for real time processing, what is the minimum set of payload types that must be supported?
- To meet the CAQH CORE 270 Rule requirements for batch processing, what is the minimum set of payload types that must be supported?
- 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?
- 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?
- 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?
- 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 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
- Does the CAQH CORE 270 Rule require the use of the MAC address?
- What is the specific method for an entity to conform to the CAQH CORE 270 Rule audit log requirements?
- 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?
- How is MTOM applied in the Phase II and Phase IV CAQH CORE Connectivity Rules?
The CAQH CORE 270: Connectivity Rule is based on the use of SOAP+WSDL or HTTP+MIME Multipart envelopes for transport and routing, and on the use of username/password or X.509 Client Certificate based authentication over SSL for submitter authentication. The SOAP+WSDL envelope option, and the X.509 Client Certificate based authentication option are well aligned with the direction of ONC, HITSP, HL7 and IHE. The HTTP+MIME Multipart envelope was chosen due to its large installed base in this industry. Since the difference in complexity of these two standards is not significant, it is expected that there will be convergence on a single envelope standard and a single authentication standard in the long term.
No. Though HITSP T85 (Administrative Transport to Health Plan) uses the Phase II CAQH CORE 270: Connectivity Rule, this does not mean that by being Phase II CORE-certified you will meet HITSP T85 requirements. The CAQH CORE 270: Connectivity Rule 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 the CAQH CORE 270: Connectivity Rule. For instance, HITSP T17 uses Transport Layer Security (TLS) instead of SSL. The CAQH CORE 270: Connectivity Rule provides a safe harbor specifying minimum requirements, but does not preclude the use of other methods for securing the communications channels.
The Phase I CAQH CORE 153: Connectivity Rule 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.
Phase II CAQH CORE 270: Connectivity Rule builds upon the Phase I 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 Phase II CAQH CORE 270: Connectivity Rule provide requirements for encapsulating an expanded set of metadata needed for routing, submitter identification/authentication and auditing. Additionally, the Phase II CAQH CORE Connectivity 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.
The CAQH CORE Connectivity Safe Harbor requirements that a health plan must use if requested by a provider are described in CAQH CORE 270 Rule, Section 5, CORE Safe Harbor. The CAQH CORE Connectivity Safe Harbor specifies connectivity methods that application vendors, providers, and health plans can be assured will be supported by any HIPAA covered entity and/or a CORE-certified entity, meaning that the entity is capable and ready at the time of the request by a trading partner to exchange data using the CAQH CORE Connectivity Rule. The rule does not require entities to remove existing connections that do not match the rule, nor does it require that all covered entities use this method for all new connections. In some circumstances, you and your trading partners may decide to continue to use your current connection; however, you must implement the capability to use the CAQH CORE Connectivity Safe Harbor and be capable and ready to use it when requested.
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 of these 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 will be a goal for future phases to reach. Conformance guidance is provided as part of the CAQH CORE Connectivity Rule for all stakeholders to implement one or both of these envelope standards.
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 Phase I 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. Similar to the decision on envelope standards, a decision was made to allow both authentication standards with the necessary conformance guidance for all stakeholders.
CAQH CORE expects that in future phases CAQH CORE requirements will include single, specific standards in both of these areas. The Phase II inclusion of two envelope and authentication standards and appropriate conformance requirements greatly improves the situation in the marketplace by reducing variation in options currently available and in use. This phased step will provide the basis for a more informed decision when considering single standard recommendations moving forward.
Conformance requirements for implementing Submitter Authentication Standards are provided in Section 4.1 of CAQH CORE 270: Connectivity Rule Version 2.2.0 by key stakeholder categories acting in either the Client or Server role. Briefly, the requirements for these stakeholder categories are: health plans and health plan vendor, acting as the Server, must support one of the two submitter authentication standards. Healthcare Providers, provider vendors and clearinghouses, 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 270 Rule requires the use of HTTP/S over the public Internet. The Phase I CAQH CORE 153: Connectivity Rule was based on use of the public Internet for transport, and the Phase II CAQH CORE Connectivity Rule builds on Phase I, while retaining the same underlying transport.
The CAQH CORE 270 Rule is applicable only to the public Internet, which is a TCP/IP based network. The Phase I CAQH CORE Connectivity Rule was based on use of the public Internet (which is TCP/IP based) for transport, and the Phase II CAQH CORE Connectivity Rule builds on Phase I, while retaining the same underlying transport.
No. The CAQH CORE 270 Rule is applicable to and may be used when a CORE-certified entity is exchanging any X12 administrative transaction whether or not the transaction has been mandated under HIPAA. An entity that is Phase II CORE-certified is required to support the Phase II CAQH CORE 270: Connectivity Rule 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 270 Rule 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 Phase II CAQH CORE 2.2.0-compliant XML Schema specification file, CORERule2.2.0.xsd, for use within the WSDL specification is available at http://www.caqh.org/SOAP/WSDL/CORERule2.2.0.xsd. The URL of the Phase II CAQH CORE 2.2.0 WSDL schema is: http://www.caqh.org/SOAP/WSDL/CORERule2.2.0.wsdl.
Only those changes to the WSDL that preserve the structure and syntax of the message envelope are allowed. All field names, data types and syntax of existing fields must stay the same.
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 270 Rule. 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 270 Rule 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 270 Rule 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.
SenderID and ReceiverID Values are unique identifiers associated with your organization. They are intended for message routing and processing, or for transaction auditing, or as a reference to a business agreement by a message receiver. CAQH CORE recommends using OIDs from organizations like HL7 or IANA, but you may use other forms of organizational identifiers as well. Section 6.2 of CAQH CORE 270: Connectivity Rule Version 2.2.0 has the URLs of HL7 OID Registry and the IANA OID registration page where organizations can obtain the OIDs.
This is not allowed for ASC X12 payloads. Section 4.4.4 in CAQH CORE 270: Connectivity Rule Version 2.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 270 Rule does not specify guidelines/restrictions on the username and passwords.
Client Certificates may be issued by a trusted third party called a Certificate Authority (CA) such as VeriSign or Entrust, or by the entity that is receiving connections.
CAQH CORE has not specified guidelines/restrictions on the use of certificate authorities at this time. Client certificates used for node authentication over SSL can be issued by the organization that is receiving connections, or by a third party certificate authority that is trusted by the organization to issue these certificates on its behalf.
Since SSL is far more prevalent today than TLS, CAQH CORE 270: Connectivity Rule Version 2.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.
The SOAP+WSDL interfaces in the CAQH CORE 270 Rule must be implemented over SOAP 1.2 for CAQH CORE conformance. An organization may choose to additionally 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 270 Rule. 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 270 Rule.
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. In a future CAQH CORE phase, the use of MTOM will be considered for attaching payloads to SOAP real time request/response.
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 of these transactions. CAQH CORE 270: Connectivity Rule Version 2.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 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.
- 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.
- 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. Note that xs:string could be used to populate any ASCII string including base64.
- 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).
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.
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.
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.
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. Consistent with the Safe Harbor principle (defined extensively in Phase I and Phase II CAQH CORE Connectivity Rules), a CORE-certified entity can implement custom extensions and/or support additional connectivity methods as long as it has implemented one connectivity interface that is fully and exactly as specified in the CAQH CORE Connectivity Rule. This gives CORE-certified partners the assurance they can use their CAQH CORE Connectivity interfaces to connect.
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.”
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. Additionally, message senders must include the CAQH CORE Envelope Metadata element Time Stamp (as specified in the CAQH CORE 270 Rule, Section 4.1.2). Other data may be required for auditing purposes; however, this data can be determined by each entity. CAQH CORE 270 Rule recommends that, in order to uniquely identify an X12 payload, entities store the ISA06, ISA08, ISA13, GS02, GS03, GS06, ST02, TRN02, and if sent in the transaction, the BHT03.
While the CAQH CORE Rules do not require entities to deliver this information to any other entity, the data required to be logged would be used to resolve any issues or concerns regarding the overall response time. The CAQH CORE Rules do not specify how long an entity is to retain the data for auditing purposes.
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.
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:
- The Phase II CAQH CORE 270 Connectivity Rule requires the use of MTOM for all SOAP message envelopes only when exchanging data in Batch Processing Mode. The Phase II CAQH CORE Connectivity 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 Phase II CAQH CORE 270 Connectivity Rule).
- The Phase IV CAQH CORE 470 Connectivity Rule requires the use of MTOM to encapsulate all payloads in a SOAP message for both Real Time AND Batch Processing Modes.