CAQH CORE solicited input on this topic during the rules-development process from the CORE Technical Work Group members and experts within healthcare and other industries, such as financial services. Based on this input, including the information that other healthcare industry projects, such as the Markle Foundation’s Connecting for Health project and the CMS Nationwide Health Information Network architecture prototypes, are using HTTP/S over the Internet, CAQH CORE determined that HTTP/S is an appropriate choice as the baseline standard for delivery of healthcare information. Email CAQH CORE at CORE@caqh.org for more background information
Frequently Asked Questions - VI. CAQH CORE 153: Connectivity Rule
Please refer to the Phase II CAQH CORE 270: Connectivity Rule FAQs. As the Phase II CAQH CORE 270 Rule builds upon and enhances the Phase I rule, both rules must be combined when determining the overall CAQH CORE Connectivity requirements.
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.
- How did CAQH CORE decide that HTTP/S is secure and reliable enough to protect the delivery of healthcare information over the Internet?
- Can payers support other versions of HTTPS as well as v1.1?
- Is there a required format in Phase I CAQH CORE for the authorization, date/time, and payload ID to be sent in the HTTP message?
- If implementing SOAP 1.1 with attachments running on top of HTTP/S is compliant, how would an entity seeking CORE Certification that elects this implementation approach satisfy the CORE Certification testing requirements of the rule?
- Will all CAQH CORE-authorized testing vendors use the same certification test scripts and the same detailed connectivity method to test the Phase I CAQH CORE Connectivity Rule?
- My organization’s security procedures require that clients use a digital certificate to identify themselves. Under the CAQH CORE Operating Rules, can we require that they use the certificate method?
- What is the recommended method for allowing entities to receive another entity's root public digital certificate?
- Batch processing: how long must a responder maintain response files on their system?
- Batch processing: Why not FTP or sFTP for batch transactions instead of HTTP/S?
- Batch processing: Can CAQH CORE provide more specificity for the actual HTTP messages to use in the batch request and response?
- Batch processing: My organization’s system can provide an ASC X12 Implementation Acknowledgement (999) back on batch transactions within 20 seconds. Why can’t my organization just send the ASC X12 Implementation Acknowledgement (999) in the response t
- Batch processing: Will a receiver be able to re-pickup a file if needed?
- Batch processing: Will there be a maximum number of response files that a receiver will be able to pickup in one session due to payload sizes?
- Batch processing: Will a payload be able to contain different types of responses?
- Batch processing: How is a batch reply matched with its request without downloading each file and parsing it? Are reply filenames to somehow encode the payload ID?
- Batch processing: Is there a one-to-one correspondence between batch input transmissions and batch output files?
- Batch processing: Must a batch reply file contain replies for every request in a batch request? Is it an error to omit some?
- For the purposes of the re-transmission, what is the definition of a duplicate transaction?
- What happens if a provider's system continues to send duplicate transactions within 15 minutes?
- Is there a retention time period required by the CAQH CORE 153 Rule for how long the source needs to maintain this transaction tracking information?
- Where can I get more information about exchanging data in HTTP/S?
- Can my vendor offer HTTP/S on my behalf?
- What is the payload identifier (ID)?
- Is the payload ID outside the X12 interchange?
- Is the payload ID generated and sent by the submitter?
- Does the responder need to return the payload ID on the response?
- Is the payload ID unique for each transaction sent by the Submitter?
- What should be expected from trading partners regarding the Payload IDs, and how it should be used?
- For batch response pick-up, does CAQH CORE intend for this to be a programmatic interface or a human interface?
- Can a clearinghouse or vendor act on behalf of a health plan for the CAQH CORE 153: Connectivity Rule?
- Can my organization run an X12 270/271 transaction on XML?
- For real time transactions, our system does not automatically resend failed responses, however the client can go in and send the same request manually. Must we prevent the client from being able to resubmit the same request (even manually) for 90 seco
- How should we respond to the transaction if the date/time and/or payload ID are not present?
- Is there a more precise definition as to where user ID, Password, date/time and payload ID should appear in the data stream? The document references “HTTP Message Body” and “HTTP Message Header Tags.”
Yes. Payers may support other versions, but they must support HTTPS 1.1 in order to achieve CORE Certification. The intent of the CAQH CORE 153: Connectivity Rule Version 1.1.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.
No. CAQH CORE decided not to require a format for these data elements for Phase I. However, in Phase II and future phases, CAQH CORE does require a specific format for sending these data elements. Please speak with your CAQH CORE-authorized certification testing vendor on how they will work with you on CORE Certification testing given your organization’s current HTTP format requirements and those used by the certification testing vendor.
When completing CORE Certification testing with a CAQH CORE-authorized testing vendor, the entity should check the NO REVISIONS NEEDED (not applicable) box for the detailed certification testing script(s) that do not apply when using SOAP (e.g., the 403 error messages tested under the Connectivity Test Script #2 because SOAP requires other types of error messages). As with all the Phase I CAQH CORE Test Scripts, if an entity checks NO REVISIONS NEEDED for a Test Script it will need to indicate to the testing vendor, in writing, rationale for why the Test Script does not apply. In this case, the rationale would be that the entity is using SOAP over HTTP/S to transport the X12 transactions.
For every rule, including the Phase I Connectivity Rule, each CAQH CORE-authorized testing vendor will use the same test scripts by stakeholder. Additionally, each CORE-certified entity will be responsible for being in compliance with the rules, understanding that not all aspects of rules compliance are tested during CORE Certification testing, e.g., maintaining system availability.
Because the CAQH CORE-authorized testing vendors each operate a little differently with regard to how they connect to their clients, they may use different approaches to test for the detailed CORE Connectivity Test Scripts. The CAQH CORE-authorized testing vendor you select to work with to conduct your CORE Certification testing will provide your organization with the details necessary to complete the CAQH CORE Connectivity Rule certification tests.
Yes. Phase I CAQH CORE requires that entities use a User ID/Password to authenticate the sender at a minimum. If your organization’s policies require a higher level of security, Phase I implementation does not prevent you from implementing additional security mechanisms.
NOTE: These additional mechanisms, like any other additional requirements beyond the CAQH CORE Operating Rules, will not be tested by the CAQH CORE-authorized testing vendors as part of CORE Certification testing. The Phase II CAQH CORE 270: Connectivity Rule includes requirements for both Username/Password and X.509 Certificates over SSL as submitter authentication standards, with specific conformance requirements for the client (e.g., submitters/providers) and the server (e.g., health plans).
CAQH CORE does not make recommendations for this process. Please discuss this with your individual trading partners.
CAQH CORE recognizes that every organization has its own record-retention policies and, therefore, does not mandate a strict requirement for retention of response files. However, CAQH CORE recommends that a copy of responses be kept available for a minimum of six months after they are ready in order to support the process of discovery in the case of a complaint against a CORE-certified entity regarding CAQH CORE conformance.
HHTTP/S is robust and has a proven track record with batch transactions. The benefits of a single communication standard were a compelling reason to mandate its availability. Information sources that allow FTP and/or sFTP for batch transactions still can support those transmission methods.
CAQH CORE does not specify the batch request/response flow. An example of how it could be implemented is below. Please speak with your CAQH CORE-authorized testing vendor on how they will work with you on this issue during testing. See below for an example.
- Client (provider or their intermediary) sends an HTTPS POST message with a data content of: something like: <Message><Operation>ListBatchResponses</Operation><FilePattern>*.271</FilePattern> </Message>
- Server (payer or their intermediary) responds with a data content of something like: <Message><FileList><File>20060208_12345.271</File> <File>20060208_543627.271</File> </FileList></Message>
- Client decides which file to retrieve and sends a request like: <Message><Operation> GetFile</Operation> <File>20060208_543627.271</File></Message>
- And the server sends it back in something like: <Message> <File>20060208_543627.271</File> </Message>
- The client could then request other files or decide they are done.
For consistency and ease of development, CAQH CORE decided that it was important to have a single standard. Based on that decision, and the fact that many batch processing information sources cannot commit to having the ASC X12 Implementation Acknowledgement (999) available in 20 seconds, CAQH CORE elected to mandate that the ASC X12 Implementation Acknowledgement (999) not be provided in the HTTP response.
CAQH CORE does not specify this, but recommends that information sources allow for re-pickup for at least one month after the initial pickup of a batch response file. Please refer to your own internal policies.
CAQH CORE does not set a maximum on the number of response files that a receiver will be able to pickup. Information sources should create policies to specify the limit to the number or size of files that can be picked up and document those policies in their Companion Guide.
Yes. CAQH CORE does not specify the different types of responses a payload can contain. Please refer to your own internal policies.
CAQH CORE does not specify any convention for linking the batch response to the batch request beyond the X12 requirements. Some information sources may provide this information as part of the file name, or as meta-data included in a file listing, and this should be documented in the information source’s Companion Guide.
CAQH CORE does not specify the content of the physical file returned by the batch processing. Information sources should specify in their Companion Guide the expected contents of the batch files.
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.
CAQH CORE does not define a duplicate transmission. Please refer to your own internal policies.
CAQH CORE does not define the recourse for information sources in this case.
CAQH CORE recognizes that every organization has its own record-retention policies and does not mandate a strict requirement for retention of tracking information. To support ongoing tracking of response times and performance measurement, CAQH CORE recommends that entities keep this information for at least 18 months, if that is in accord with the organization’s existing policies.
The Phase I CAQH CORE Operating Rules do not require that an entity (provider or health plan) implement the technology directly into their own data center. The Phase I CAQH CORE Rules implicitly acknowledge that both providers and health plans will use technology solutions provided by vendors to accomplish all that must be done. Neither do CAQH CORE Operating Rules require a "direct" connect - meaning that providers connect directly to the health plan's data center and do not connect to any intermediary, such as a clearinghouse. Thus, the Phase I CAQH CORE Rules do not require any specific architecture. Rather, CAQH CORE Operating Rules specify the capabilities that need to be enabled by any CORE-certified entity.
An entity seeking CORE Certification, working with or without their vendor providing the HTTP/S connectivity capability, will have to demonstrate conformance with the Phase I CAQH CORE Connectivity Rule through the CORE Certification testing.
CAQH CORE encourages payers who are using vendors to review their compliance to make sure that they are fully in compliance with both CAQH CORE and HIPAA, particularly the clause in HIPAA that says payers cannot charge more than the cost of telecommunications for handling the connectivity.
Within the context of the CAQH CORE Connectivity Rule the payload ID is an identifier that uniquely identifies the X12 interchange(s) transported by the HTTP message and is used to allow submitters and information receivers to easily reconcile their records of submissions and responses. CAQH CORE elected to use an ID outside of the X12 message for this purpose because many information receivers' systems separate the HTTP communication processing from the X12 message processing. The payload ID is generated and sent by the entity that initiates the HTTP communication session.
Usually this is the provider or clearinghouse that is sending the request to the health plan or other information source. It is one of the CAQH CORE-required HTTP message parameters (along with authorization information and date and time stamps) and it must be unique to each HTTP message and the X12 interchange(s) being transported by the HTTP message instance. All CORE-certified entities are required to capture, log and be able to report on each HTTP message transporting an X12 interchange and to be able to link the X12 interchange to a specific HTTP message instance. The payload ID (Message Body identifier) is the mechanism used to associate a given instance of an X12 interchange to the HTTP message instance.
Yes, it is generated by the system that creates the HTTP request message. Typically this is the provider’s system or the clearinghouse’s system that is working on the provider's behalf.
The payload ID does not get carried through to the content of the X12 271 response. In the real time usage, the submitter can link the X12 271 response to the payload ID because the X12 271 response in the real time mode is passed within the same communication session used to send the payload ID and requesting the X12 270. In the batch usage, the acknowledging response to the submission is sufficient to record that a particular payload was successfully delivered.
No. It is unique to each HTTP message instance and the payload being transported by HTTP.
An entity should expect to receive a long, possibly alphanumeric, ID from its trading partners and should be able to store that ID and associate it with each X12 real time messages processed from the trading partner through the supported HTTP communication system. From a technical perspective, most submitters will use some sort of globally unique ID or universally unique ID (GUID or UUID) as their payload ID so receivers should allocate a data field that can contain at a minimum the 128 bits required to store a GUID/UUID. The Phase I CAQH CORE Operating Rules do not specify any detailed requirements in this area.
Under the CAQH CORE Operating Rules, information sources must provide a programmatic interface to allow an automated task whereby the provider's system requests the batch of X12 271 responses be transferred to the provider's system without a need for human intervention.
Yes. Each health plan seeking CORE Certification would have to work with its clearinghouse and/or vendor to jointly complete CORE Certification testing in order for the health plan to be awarded the CORE Certification Seal. A clearinghouse or vendor would not be able to certify “generically” as a health plan and then transfer such certification to any health plan.
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.
Yes, whether it is an automated or manual re-send, the re-send attempts cannot occur more frequently than what is specified in the CAQH CORE Operating Rule.
Such a message would represent a CAQH CORE non-compliant message. The Phase I CAQH CORE 153: Connectivity Rule does not require such a message to be either rejected or accepted by the receiver. It is the receiver's decision regarding acceptance of a non-compliant message.
There are no more precise specifications in the Phase I CAQH CORE 153: Connectivity Rule. This decision is left to the message originator.