Frequently Asked Questions - VI. CAQH CORE Attachments Prior Authorization Infrastructure Rule
- What is the exchange method required for the CAQH CORE Attachments Prior Authorization Infrastructure Rule?
- Why is CAQH CORE Connectivity Rule vC4.0.0 specified instead of the federally mandated version?
- Do the CAQH CORE Attachments Prior Authorization Infrastructure Rules apply if a provider is only compliant with the federally mandated CORE Connectivity vC2.2.0?
- What is the difference between the X12 method requirements and non-X12 requirements for system connectivity?
- Do Batch and/or Real Time Processing Modes apply to the Attachments Prior Authorization Infrastructure Rule?
- What are the differences between the X12 v5010 999 and X12 v6020 824?
- How will X12 v6020 824 be used to communicate errors at the application level?
- What are the processing steps and need for an X12 999 functional acknowledgment (FA) in Real Time Processing Mode where the X12 275 payload is accepted without errors and the X12 824 response is subsequently sent?
- Is there a timing requirement on when an X12 999 response to an X12 v6020 824 must be sent?
- The system availability update allows for 17 hours of scheduled downtime available per calendar week in addition to the weekly system availability requirement. Are there any limitations on how my organization may choose to schedule the allowable additiona
The CAQH CORE Connectivity Rule vC4.0.0 includes requirements for the exchange of messages using both SOAP and REST. The CAQH CORE Connectivity Rule vC4.0.0 also includes support for the X12 v6020X316 275 attachments transaction in the scope of the rule, meaning that the rule applies when trading partners exchange the X12 v6020X316 275.
The rule also applies to other payload types (e.g., HL7 C-CDA, .pdf, .doc, etc.) and as such, serves as a bridge between administrative and clinical data exchange by utilizing both X12 and non-X12 payload types. Per the CAQH CORE Rule development process, published CAQH CORE Operating Rules may be presented to the National Committee on Vital Health Statistics (NCVHS) for federal mandate.
No. Adoption of these rules is currently voluntary and as such can be used between willing trading partners.
Both the X12 and non-X12 methods address usage patterns for Real Time and Batch Processing Modes, including the use of SOAP and REST. Both methods address the exchange of security identifiers, and communications-level errors and acknowledgements and do not attempt to define the specific content of the message payload beyond declaring the formats that must be used between entities and that security information must be sent outside of the message envelop payload.
Yes. Entities may support Batch or Real Time Processing modes for Attachments sent to support Prior Authorization Requests.
The usage of X12 v6020 824 is independent from other X12 responses, such as the X12 v5010 278 Response and X12 v6020 999.
While the X12 v5010 999 returns an acknowledgement at the application layer (payload processing) of the OSI Model, the X12 v6020 824 provides error messages one layer deeper, at the data content level. X12 v5010 999 transaction is more widely used to return common errors and acceptance acknowledgements, while the X12 v6020 824 can provide more information on errors that delay adjudication (e.g., front end edits that can be used to inform the submitter that the transaction will fail adjudication at the next level of processing; for example, invalid patient ID).
The X12 v6020 824 provides error messages at the data content level, which one layer deeper, than X12 v5010 999. The X12 v5010 999 returns an acknowledgement at the application layer (payload processing). The X12 v6020 824 can also provide more information on errors that delay adjudication (e.g., front end edits that can be used to inform the submitter that the transaction will fail adjudication at the next level of processing; for example, invalid patient ID).
When an X12 6020X316 275 is submitted, it goes through several layers of error handling, from HTTP to Payload Processing Layer, to Initial Data Content Processing Layer.
If no errors are encountered at a layer, the submission is passed to the next processing layer. Upon passing the Payload Processing Layer, an X12 999 FA is sent to acknowledge acceptance. Once the Initial Data Content Processing Layer processes the content of the payload, the receiver (server) must return an X12 v6020X257 824 to report acceptance or any errors in the payload.
No. There is no timing requirement set by this rule. However, this may be considered in future rule updates as implementation and use of the X12 v6020 or future versions of the X12 824 become more widely used within the industry.
The 24 hours of additional quarterly downtime can be taken in any increment of time throughout the calendar quarter to allow for larger system upgrades, as needed.
However, to remain conformant with the federally mandated versions of the CAQH CORE Operating Rules, the additional quarterly downtime requirement of 24 hours per calendar quarter should not exceed a maximum of 7 hours in a single calendar week. This allows organizations to take advantage of the quarterly system availability requirements and remain in compliance with mandated operating rules which state system updates should take place within a maximum of 24 hours per calendar week for scheduled downtime.