Averages can be skewed by outlier responses. The number of responses returned within the specified timeframe gives a better indication of the information source’s capabilities.
Frequently Asked Questions - IX. CAQH CORE 156: Real Time Response Time Rule
- Why measure conformance based on number of responses returned within a specified timeframe rather than average response time?
- Is there a standard reporting form for the conformance reporting?
- If a CORE-certified information source is communicating with a non-CORE-certified information receiver, does the CORE-certified entity have to respond within the response time window?
- What is the minimum information from the X12 transaction that needs to be stored? Can the standard provide a recommendation for this data?
- When does the 20-second real time requirement for response time described in the CAQH CORE 156 Rule begin and end? Does the 20-second interval include all hops between trading partners?
- What happens when a real time response is not received within the required 20-second window?
- How should the X12 270/271 transactions be tracked throughout a system/application to demonstrate conformance with the response time requirements specified in the CAQH CORE 156 Rule?
No. CAQH CORE does not mandate a particular form.
Yes. Providers do not have to be certified by CAQH CORE to interact with CORE-certified payers under the CAQH CORE Rules.
CAQH CORE does not specify a minimum. However, to uniquely identify an X12 transmission, CAQH CORE recommends that entities store the ISA06, ISA08, ISA13, GS02, GS03, GS06, ST02, TRN02, and if sent in the transaction, the BHT03.
The 20-second requirement described in the CAQH CORE 156 and 250 Rules is the duration for the entire round-trip of the transaction. The 20 seconds begin when the X12 270 Inquiry or X12 276 Request is first submitted, and ends when the X12 271 Response or X12 277 Response is delivered to the provider. All ensuing hops are included in these 20 seconds. Conformance with the rule is determined when 90 percent of all required responses are returned within the specified maximum response time as measured within a calendar month. Each HIPAA-covered entity is required to conform to the Federally mandated CAQH CORE Eligibility & Claim Status Operating Rules. Each HIPAA covered entity within the transaction flow is bound by the CAQH CORE Rule requirements for meeting the 20-second round trip of the transaction (CAQH CORE recommends no more than 4 seconds per hop).
The CAQH CORE 270: Connectivity Rule requires that the connection remain open for 60 seconds to accommodate any potentially delayed responses. In the event that a specific real time response message is not received within the 20-second window, the requirements described in CAQH CORE 270 Rule, Section 4.3.6, Response, Timeout and Retransmission Requirements, would apply.
NOTE: The CAQH CORE 156 and 250 Rules require that 90 percent of all X12 271 and X12 277 responses be returned within the 20-second maximum response time within a calendar month to be in conformance with the rule requirements.
The CAQH CORE Response Time Rules (CAQH CORE 155 & 156 Rules) require HIPAA covered entities to capture, log, audit, match, and report the date, time, and control numbers from their own internal systems, and corresponding data received from their trading partners. The auditing requirement is included so that each entity will have the log of data to be used to resolve any issues or concerns. For the 20-second maximum real time response requirement, this log could also be used to identify where a bottleneck may be occurring.
Section 4.3.4 of the CAQH CORE 270: Connectivity Rule also specifies that, to comply with the CAQH CORE 155 and 156 Rules, message receivers will be required to track the times of any received inbound messages, and respond with the outbound message for that payload ID. Additionally, message senders must include the 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 recommends that, in order to uniquely identify an X12 transmission, entities store the ISA06, ISA08, ISA13, GS02, GS03, GS06, ST02, TRN02, and if sent in the transaction, the BHT03.
The audit log requirement was purposefully specified at a high level in each rule to enable each entity along the transaction pathway to design and develop its own process for audit handling. Additionally, the rules do not specify how long an entity is to maintain the data for auditing purposes. (See “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?” for guidance on tracking when using a non-CAQH CORE Connectivity method.)