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

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?

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.

How will X12 v6020 824 be used to communicate errors at the application level?

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).

What is the difference between the X12 method requirements and non-X12 requirements for system connectivity?

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. 

Why is CAQH CORE Connectivity Rule vC4.0.0 specified instead of the federally mandated version?

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.


What is the exchange method required for the CAQH CORE Attachments Prior Authorization Infrastructure Rule?

The only exchange method that is in-scope for this rule is CORE Connectivity vC4.0.0. CORE Connectivity vC4.0.0 supports HTTP, TLS 1.2 or higher, SOAP Version 1.2 or higher, WSDL Version 1.1 or higher, JavaScript Object Notation (JSON), X.509 Digital Certificate addressing authentication, and OAuth 2.0 or higher addressing authorization.