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.
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.
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.
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).
The usage of X12 v6020 824 is independent from other X12 responses, such as the X12 v5010 278 Response and X12 v6020 999.
Yes. Entities may support Batch or Real Time Processing modes for Attachments sent to support Prior Authorization Requests.
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.
No. Adoption of these rules is currently voluntary and as such can be used between willing trading partners.
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 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.