Frequently Asked Questions - II. Benefit Enrollment (834) Infrastructure Rule

  1. What was included in the April 2022 CAQH CORE Infrastructure update and how did it impact the CAQH CORE Benefit Enrollment (834) Infrastructure Rule?
  2. We are a health plan. Why would we consider implementing the client requirement for retrieving enrollment data from the source?
  3. How does an entity determine which version of CAQH CORE Connectivity to use when implementing the CAQH CORE Benefit Enrollment (834) Infrastructure Rule?
  4. Do the rules have requirements for a health plan that retrieves or pulls the X12 v5010 834 from another entity that is acting as a server?
  5. What if my entity transmits or receives enrollment information in something other than an X12 v5010 834; e.g., Excel spreadsheet, an XML document, a proprietary flat file, etc.?
  6. What are the CAQH CORE Benefit Enrollment (834) Infrastructure Rule requirements for entities to support real time and/or batch processing?
  7. Are there any requirements in the CAQH CORE Benefit Enrollment (834) Infrastructure Rule regarding how often X12 v5010 834 transactions should be submitted? (e.g., Do CAQH CORE Operating Rules either support or exclude an entity from sending daily batc
  8. Do the time frames for the CAQH CORE Benefit Enrollment (834) Infrastructure Rule still apply if it is an especially large batch? Do the CAQH CORE Operating Rules define the batch size?
  9. If an X12 v5010 834 is received in a batch, does the X12 v5010 999 Acknowledgment have to be returned in a batch?
  10. Can a clearinghouse or vendor act on behalf of a health plan for providing X12 v5010 834 transaction Acknowledgments?
  11. Currently my organization’s EDI system only returns a positive X12 v5010 999 Acknowledgment reporting acceptance of the X12 v5010 834 that is submitted in Real Time Processing Mode. If the Functional Group is rejected, must my system be changed to com
  12. Why does this “Elapsed Time for Enrollment System Processing of Received Benefit Enrollment Data” requirement exist in the CAQH CORE Benefit Enrollment (834) Infrastructure Rule?
  13. Do the CAQH CORE Benefit Enrollment (834) Infrastructure Rule Real Time Acknowledgement Requirements require that my organization’s system must always return an X12 v5010 999 Acknowledgment for an X12 v5010 834?
  14. Currently my organization’s EDI system only returns a positive X12 v5010 999 Acknowledgment reporting acceptance of the X12 v5010 834. If the Functional Group is rejected, must my system be changed to comply with the Batch Acknowledgement Requirements
  15. My organization’s EDI system was developed in-house and does not currently support the TA1. However, our system does support the X12 v5010 999 Acknowledgment for rejected Functional Groups. Is this conformant under the CAQH CORE Benefit Enrollment (83
  16. Is an Acknowledgement necessary if the user sends benefit enrollment data in a proprietary (not an X12 834) format in a real time mode?
  17. Are all CAQH CORE Benefit Enrollment (834) Infrastructure Rule requirements regarding Acknowledgement only applicable to scenarios where my organization receives data in an X12 v5010 834 format?
  18. The TA1 Interchange Acknowledgment is described in the HIPAA Implementation Guide Appendix B: EDI Control Director. Does the CAQH CORE Benefit Enrollment (834) Infrastructure Rule require its use?
  19. Does my organization have to send back an X12 v5010 999 Acknowledgment response if my system is down?
  20. Will there be a difference in system availability requirements for Batch versus Real Time Processing Modes?
  21. Why did the CAQH CORE Participants increase the weekly system availability requirement from 86% to 90% system availability for the CAQH CORE X Infrastructure Rule in 2022?
  22. Is the additional 24-hour downtime available per calendar quarter required to be taken in one 24-hour period?
  23. Is the additional 24-hour downtime per calendar quarter in addition to the weekly allocated downtime?
  24. Does the new quarterly system availability downtime requirement define calendar quarter?
  25. My organization includes system availability schedules in our Companion Guide. Does this satisfy the CAQH CORE Benefit Enrollment (834) Infrastructure Rule requirements for system availability reporting?
  26. Why was the CAQH CORE Master Companion Guide Template updated?
  27. Why was the Master Companion Guide Template created for entities conducting benefit enrollment electronically?
  28. Does the CAQH CORE Benefit Enrollment (834) Infrastructure Rule require HIPAA-covered entities to publish a Companion Guide if they do not currently do so?
  29. Can I combine multiple Transaction Sets in a single companion guide?
What was included in the April 2022 CAQH CORE Infrastructure update and how did it impact the CAQH CORE Benefit Enrollment (834) Infrastructure Rule?

Submitted by tfuchs@caqh.org on Mon, 04/18/2022 - 14:46
What was included in the April 2022 CAQH CORE Infrastructure update and how did it impact the CAQH CORE Benefit Enrollment (834) Infrastructure Rule?

§  Substantive Update to System Availability Requirements. The weekly system availability requirement was updated across the CAQH CORE Infrastructure Rules including CAQH CORE Benefit Enrollment (834) Infrastructure Rule from 86% per calendar week to requiring systems to be available 90% per calendar week.  Additionally, a new quarterly system availability requirement was added allowing systems 24 additional downtime hours per calendar quarter, in excess of the allowable weekly system downtime or 17 hours (10% system downtime per calendar week).

§  Non-Substantive Update to CAQH CORE Connectivity. Per CAQH CORE Certification Policy, CORE-certified entities are required to comply with the most recent published version of the CAQH CORE Connectivity Rule within two years of publication. Therefore, by January 1, 2023, CAQH CORE Connectivity vC4.0.0 will be required for all CAQH CORE Infrastructure Operating Rules. To align the rule requirements with this policy, the connectivity requirement language in the CAQH CORE Benefit Enrollment (834) Infrastructure Rule was updated to require “most recent published and CAQH CORE adopted version of the CAQH CORE Connectivity Rule.

§  Non-Substantive Update to CAQH CORE Master Companion Guide Template. Past versions of the CAQH CORE Master Companion Guide referenced a specific version of the ASC X12N Implementation Guides, e.g., v5010. [EW1] However, with the creation of new operating rules such as CAQH CORE Attachments Operating Rules which use a different X12 version, not all operating rules use the same X12 version. To align with the need to address multiple X12 versions and enable greater flexibility, references to a specific X12 version were adjusted to be modifiable in the CAQH CORE Master Companion Guide.


 [EW1]Made this generic since the original companion guide templates actually referenced v4010.

Back to Top
We are a health plan. Why would we consider implementing the client requirement for retrieving enrollment data from the source?

Submitted by tfuchs@caqh.org on Mon, 04/18/2022 - 14:47
We are a health plan. Why would we consider implementing the client requirement for retrieving enrollment data from the source?

As stated in the CAQH CORE Benefit Enrollment (834) Infrastructure Rule, Section 4.1, Benefit Enrollment and Maintenance Processing Mode Requirements, a HIPAA-covered health plan is not required to implement the client requirements, but “may also elect to implement the client requirements as specified in the Connectivity Rule  in addition to implementing the server requirements. When a HIPAA-covered health plan or its agent elects to implement the client requirements as specified in the CAQH CORE Connectivity Rule it must comply with all requirements specified in Sections 4.2, 4.3, 4.4, 4.5, 4.6, 5 and all respective Subsections.”

A health plan may wish to implement the client requirements for the conduct of the 834 transactions for a variety of reasons. One example may include managed care entities with which the health plan has partnered and therefore may conduct a pull (or fetch) of the 834 transactions from the health plan rather than the health plan pushing it out to these entities.

Back to Top
How does an entity determine which version of CAQH CORE Connectivity to use when implementing the CAQH CORE Benefit Enrollment (834) Infrastructure Rule?

Submitted by tfuchs@caqh.org on Mon, 04/18/2022 - 14:47
How does an entity determine which version of CAQH CORE Connectivity to use when implementing the CAQH CORE Benefit Enrollment (834) Infrastructure Rule?

All CAQH CORE Infrastructure Operating Rules including CAQH CORE Benefit Enrollment (834) Infrastructure Rule most recent published and CAQH CORE adopted version of the CAQH CORE Connectivity Rule” (please see the CAQH CORE Connectivity webpage for more information).  

Per CORE Certification Policy, entities seeking CORE Certification are required at a minimum to implement the version of CORE Connectivity published two years prior from when pursuing certification testing. Optionally, entities can choose to implement any newer versions of CORE Connectivity published within the past two years and attain certification depending on testing availability.

Back to Top
Do the rules have requirements for a health plan that retrieves or pulls the X12 v5010 834 from another entity that is acting as a server?

Submitted by tfuchs@caqh.org on Mon, 04/18/2022 - 14:48
Do the rules have requirements for a health plan that retrieves or pulls the X12 v5010 834 from another entity that is acting as a server?

Yes. As stated in Section 4.1 of the CAQH CORE Connectivity Rule, “when a HIPAA-covered health plan or its agent elects to implement the client requirements as specified in the CAQH CORE Connectivity Rule  it must comply with all requirements specified in Sections 4.2, 4.3, 4.4, 4.5, 4.6, 5 and all respective Subsections.”

Back to Top
What if my entity transmits or receives enrollment information in something other than an X12 v5010 834; e.g., Excel spreadsheet, an XML document, a proprietary flat file, etc.?

Submitted by tfuchs@caqh.org on Mon, 04/18/2022 - 14:48
What if my entity transmits or receives enrollment information in something other than an X12 v5010 834; e.g., Excel spreadsheet, an XML document, a proprietary flat file, etc.?

As stated in Section 3 of the CAQH CORE Connectivity Rule, the rule only “applies when a HIPAA-covered health plan or its agent uses, conducts, or processes the X12 v5010 834 transaction.” If something other than an X12 v5010 834 is received or transmitted, e.g., an Excel spreadsheet, an XML document, or a proprietary file, etc., then the CAQH CORE Connectivity Rule v4.0.0 does not apply.

Back to Top
What are the CAQH CORE Benefit Enrollment (834) Infrastructure Rule requirements for entities to support real time and/or batch processing?

Submitted by tfuchs@caqh.org on Mon, 04/18/2022 - 14:49
What are the CAQH CORE Benefit Enrollment (834) Infrastructure Rule requirements for entities to support real time and/or batch processing?

The CAQH CORE Benefit Enrollment (834) Infrastructure Rule requires that a HIPAA-covered health plan or its agent must implement the server requirements for Batch Processing Mode for the X12 v5010 834 transaction as specified in the Rule. Optionally, a HIPAA-covered health plan or its agent may elect to implement the server requirements for Real Time Processing Mode for the X12 v5010 834 transaction as specified in the CAQH CORE Connectivity Rule.

A HIPAA-covered health plan or its agent may also elect to implement the client requirements as specified in the CAQH CORE Connectivity Rule in addition to implementing the server requirements. When a HIPAA-covered health plan or its agent elects to implement the client requirements as specified in the CAQH CORE Connectivity Rule it must comply with all requirements specified in Sections 4.2, 4.3, 4.4, 4.5, 4.6, 5 and all respective Subsections.

A HIPAA-covered health plan or its agent conducting the X12 v5010 834 transaction is required to conform to the processing mode requirements specified in this section regardless of any other connectivity modes and methods used between trading partners.

Back to Top
Are there any requirements in the CAQH CORE Benefit Enrollment (834) Infrastructure Rule regarding how often X12 v5010 834 transactions should be submitted? (e.g., Do CAQH CORE Operating Rules either support or exclude an entity from sending daily batc

Submitted by tfuchs@caqh.org on Mon, 04/18/2022 - 14:49
Are there any requirements in the CAQH CORE Benefit Enrollment (834) Infrastructure Rule regarding how often X12 v5010 834 transactions should be submitted? (e.g., Do CAQH CORE Operating Rules either support or exclude an entity from sending daily batches of X12 v5010 834 transactions?)

No. The CAQH CORE Benefit Enrollment (834) Infrastructure Rule does not address the frequency of submission of X12 v5010 834 transactions in Batch Processing Mode. 

Back to Top
Do the time frames for the CAQH CORE Benefit Enrollment (834) Infrastructure Rule still apply if it is an especially large batch? Do the CAQH CORE Operating Rules define the batch size?

Submitted by tfuchs@caqh.org on Mon, 04/18/2022 - 14:50
Do the time frames for the CAQH CORE Benefit Enrollment (834) Infrastructure Rule still apply if it is an especially large batch? Do the CAQH CORE Operating Rules define the batch size?

The CAQH CORE Benefit Enrollment (834) Infrastructure Rule and the CAQH CORE Connectivity Rule do not define batch size. The maximum size of a batch file that is accepted by a Server is outside the scope of the rule; the implementer of a Server may publish its file size limit, if any, in its Connectivity Companion Guide. Therefore, the response time frame for all Acknowledgements specified when an X12 v5010 834 benefit enrollment transaction is submitted in Batch Processing Mode applies to all batches. 

Back to Top
If an X12 v5010 834 is received in a batch, does the X12 v5010 999 Acknowledgment have to be returned in a batch?

Submitted by tfuchs@caqh.org on Mon, 04/18/2022 - 14:50
If an X12 v5010 834 is received in a batch, does the X12 v5010 999 Acknowledgment have to be returned in a batch?

The rule requirement addressing response time when an X12 v5010 834 is submitted in Batch Processing Mode by 9:00 pm ET on a business day only requires that a health plan have the batch of responses available by 7:00 am ET by the third business day following submission of an X12 v5010 834. The CAQH CORE Benefit Enrollment (834) Infrastructure Rule does not specify whether or not the batch of responses must match exactly the batch of X12 v5010 834 submissions.

Back to Top
Can a clearinghouse or vendor act on behalf of a health plan for providing X12 v5010 834 transaction Acknowledgments?

Submitted by tfuchs@caqh.org on Mon, 04/18/2022 - 14:50
Can a clearinghouse or vendor act on behalf of a health plan for providing X12 v5010 834 transaction Acknowledgments?

Yes. The CAQH CORE Benefit Enrollment (834) Infrastructure Rule defines the specific requirements that HIPAA-covered health plans or their agents must satisfy. In this context, an agent is “one who agrees and is authorized to act on behalf of another, a principal, to legally bind an individual in particular business transactions with third parties pursuant to an agency relationship.” (Source: West’s Encyclopedia of American Law, edition 2, Copyright 2008 The Gale Group, Inc. All rights reserved).

 

Please note that a HIPAA-covered health plan or its agent must return an X12 v5010 999 Acknowledgment to indicate that a Functional Group(s) or Transaction Set(s) is accepted, accepted with errors, or rejected and must report each error detected to the most specific level of detail supported by the X12 v5010 999 Acknowledgment.

Back to Top
Currently my organization’s EDI system only returns a positive X12 v5010 999 Acknowledgment reporting acceptance of the X12 v5010 834 that is submitted in Real Time Processing Mode. If the Functional Group is rejected, must my system be changed to com

Submitted by tfuchs@caqh.org on Mon, 04/18/2022 - 14:51
Currently my organization’s EDI system only returns a positive X12 v5010 999 Acknowledgment reporting acceptance of the X12 v5010 834 that is submitted in Real Time Processing Mode. If the Functional Group is rejected, must my system be changed to comply with the Real Time requirements?

Yes. Per the CAQH CORE Benefit Enrollment (834) Infrastructure Rule, a HIPAA-covered health plan or its agent must return an X12 v5010 999 Acknowledgment to indicate that a Functional Group(s) or Transaction Set(s) is accepted, accepted with errors, or rejected and must report each error detected to the most specific level of detail supported by the X12 v5010 999 Acknowledgement.

Back to Top
Why does this “Elapsed Time for Enrollment System Processing of Received Benefit Enrollment Data” requirement exist in the CAQH CORE Benefit Enrollment (834) Infrastructure Rule?

Submitted by tfuchs@caqh.org on Mon, 04/18/2022 - 14:52
Why does this “Elapsed Time for Enrollment System Processing of Received Benefit Enrollment Data” requirement exist in the CAQH CORE Benefit Enrollment (834) Infrastructure Rule?

The intent of this requirement is to ensure that the health plan updates its internal enrollment application systems on a timely basis. Thus, when a provider tries to verify eligibility or submits a claim, the health plan can base its response or claim processing on more timely data which may reduce claim rejection/denial, coordination of benefit, or other issues. 

Back to Top
Do the CAQH CORE Benefit Enrollment (834) Infrastructure Rule Real Time Acknowledgement Requirements require that my organization’s system must always return an X12 v5010 999 Acknowledgment for an X12 v5010 834?

Submitted by tfuchs@caqh.org on Mon, 04/18/2022 - 14:52
Do the CAQH CORE Benefit Enrollment (834) Infrastructure Rule Real Time Acknowledgement Requirements require that my organization’s system must always return an X12 v5010 999 Acknowledgment for an X12 v5010 834?

Yes. When a HIPAA-covered health plan or its agent receives a Functional Group of the X12 v5010 834 it must return an X12 v5010 999 Acknowledgment to indicate that the Functional Group or Transaction Set(s) is accepted, accepted with errors, or rejected.

Back to Top
Currently my organization’s EDI system only returns a positive X12 v5010 999 Acknowledgment reporting acceptance of the X12 v5010 834. If the Functional Group is rejected, must my system be changed to comply with the Batch Acknowledgement Requirements

Submitted by tfuchs@caqh.org on Mon, 04/18/2022 - 14:52
Currently my organization’s EDI system only returns a positive X12 v5010 999 Acknowledgment reporting acceptance of the X12 v5010 834. If the Functional Group is rejected, must my system be changed to comply with the Batch Acknowledgement Requirements?

Yes. The CAQH CORE Benefit Enrollment (834) Infrastructure Rule CAQH CORE Benefit Enrollment (834) Infrastructure Rule requires that the HIPAA-covered health plan or its agent must always return an X12 v5010 999 Acknowledgment for all Functional Groups, whether or not the Functional Group is rejected. This requirement allows the submitter of the enrollment and maintenance transaction(s) to know within a reasonable timeframe if the submitted batch of enrollment and maintenance transaction(s) was accepted by the health plan and will be processed. 

Back to Top
My organization’s EDI system was developed in-house and does not currently support the TA1. However, our system does support the X12 v5010 999 Acknowledgment for rejected Functional Groups. Is this conformant under the CAQH CORE Benefit Enrollment (83

Submitted by tfuchs@caqh.org on Mon, 04/18/2022 - 14:53
My organization’s EDI system was developed in-house and does not currently support the TA1. However, our system does support the X12 v5010 999 Acknowledgment for rejected Functional Groups. Is this conformant under the CAQH CORE Benefit Enrollment (834) Infrastructure Rule requirements?

Yes. The CAQH CORE Benefit Enrollment (834) Infrastructure Rule requirements address only the X12 v5010 999 Acknowledgment; therefore, your organization’s system must be able to return an X12 v5010 999 Acknowledgment for all Functional Groups to indicate that the functional group(s) was either accepted, accepted with errors, or rejected. If it is unable to do so, your organization will need to remediate the system to be in conformance with the CAQH CORE Rule in order to become CORE- certified. 

Back to Top
Is an Acknowledgement necessary if the user sends benefit enrollment data in a proprietary (not an X12 834) format in a real time mode?

Submitted by tfuchs@caqh.org on Mon, 04/18/2022 - 14:53
Is an Acknowledgement necessary if the user sends benefit enrollment data in a proprietary (not an X12 834) format in a real time mode?

Good business practices for electronic message exchange encourage all senders and receivers to appropriately acknowledge receipt and both acceptance/rejection and errors found in any message. Accordingly, the CAQH CORE Prior Authorization & Referrals (278) Operating Rules are focused on the conduct of the HIPAA-named X12 Transaction Sets and on the X12 standards as well. Thus, the CAQH CORE Benefit Enrollment (834) Infrastructure Rule only addresses the use of the X12 v5010 999 Acknowledgment and when to use it when a HIPAA-covered Health Plan conducts the X12 v5010 834 transaction. Additionally, in order to become CORE-certified, an entity is required to attest to its compliance with HIPAA, which requires the use of the appropriate X12 implementation guides.

Back to Top
Are all CAQH CORE Benefit Enrollment (834) Infrastructure Rule requirements regarding Acknowledgement only applicable to scenarios where my organization receives data in an X12 v5010 834 format?

Submitted by tfuchs@caqh.org on Mon, 04/18/2022 - 14:54
Are all CAQH CORE Benefit Enrollment (834) Infrastructure Rule requirements regarding Acknowledgement only applicable to scenarios where my organization receives data in an X12 v5010 834 format?

Yes. Good business practices for electronic message exchange encourage all senders and receivers to appropriately acknowledge receipt and both acceptance/rejection and errors found in any message. Accordingly, the CAQH CORE Prior Authorization & Referrals (278) Operating Rules are focused on the conduct of the HIPAA-named X12 Transaction Sets and on the X12 standards as well. Thus, the CAQH CORE Benefit Enrollment (834) Infrastructure Rule only addresses the use of the X12 v5010 999 Acknowledgment and when to use it when a HIPAA-covered Health Plan conducts the X12 v5010 834 transaction. Additionally, to become CORE-certified, an entity is required to attest to its compliance with HIPAA, which requires the use of the appropriate X12 implementation guides.

Back to Top
The TA1 Interchange Acknowledgment is described in the HIPAA Implementation Guide Appendix B: EDI Control Director. Does the CAQH CORE Benefit Enrollment (834) Infrastructure Rule require its use?

Submitted by tfuchs@caqh.org on Mon, 04/18/2022 - 14:54
18. The TA1 Interchange Acknowledgment is described in the HIPAA Implementation Guide Appendix B: EDI Control Director. Does the CAQH CORE Benefit Enrollment (834) Infrastructure Rule require its use?

No. The CAQH CORE Benefit Enrollment (834) Infrastructure Rule does not address the use of the X12 Interchange Acknowledgement TA1.

Back to Top
Does my organization have to send back an X12 v5010 999 Acknowledgment response if my system is down?

Submitted by tfuchs@caqh.org on Mon, 04/18/2022 - 14:55
Does my organization have to send back an X12 v5010 999 Acknowledgment response if my system is down?

If your system is in conformance with the CAQH CORE Benefit Enrollment (834) Infrastructure Rule, then it is not required to send back an X12 v5010 999 Acknowledgment response, either in real time or batch when your system is down. When your system is back up such Acknowledgements should be made available to the submitter.

Back to Top
Will there be a difference in system availability requirements for Batch versus Real Time Processing Modes?

Submitted by tfuchs@caqh.org on Mon, 04/18/2022 - 14:56
Will there be a difference in system availability requirements for Batch versus Real Time Processing Modes?

No. The system availability requirements apply to Batch and Real Time Processing Modes, with no difference in system availability based on the processing mode. CAQH CORE will conduct research and environmental scans to obtain data on the feasibility of separate system availability requirements in potential future infrastructure updates, as separate requirements may make better business sense as the industry moves to more API-driven interactions between providers and health plans.

Back to Top
Why did the CAQH CORE Participants increase the weekly system availability requirement from 86% to 90% system availability for the CAQH CORE X Infrastructure Rule in 2022?

Submitted by tfuchs@caqh.org on Mon, 04/18/2022 - 14:56
Why did the CAQH CORE Participants increase the weekly system availability requirement from 86% to 90% system availability for the CAQH CORE X Infrastructure Rule in 2022?

Each set of CAQH CORE Operating Rules includes an infrastructure rule with requirements for system availability and reporting, including the CAQH CORE Benefit Enrollment (834) Infrastructure Rule. In response to feedback from CAQH CORE Participants and the CAQH CORE Board, in September 2021 CAQH CORE surveyed Participating Organizations to determine where there may be consensus to update the CAQH CORE Infrastructure Operating Rule requirements to align with evolving business needs and technology. The survey focused on system availability and response time requirements across all rule sets and clear consensus emerged to update the system availability requirements across the CAQH CORE Infrastructure Rules.

Significant discussions occurred related to system availability needs. Ultimately, CORE Participants compromised by approving a new quarterly system availability requirement to accommodate large system migrations if weekly system availability was increased from 86% per calendar week to 90% per calendar week. With this weekly availability increase, the new quarterly system availability allows health plans and their agents to use 24 additional hours of system downtime per calendar quarter for system migrations, mitigations, and other system needs that may require additional downtime.

Back to Top
Is the additional 24-hour downtime available per calendar quarter required to be taken in one 24-hour period?
Back to Top
Is the additional 24-hour downtime per calendar quarter in addition to the weekly allocated downtime?

Submitted by tfuchs@caqh.org on Mon, 04/18/2022 - 14:57
Is the additional 24-hour downtime per calendar quarter in addition to the weekly allocated downtime?

Yes, the new requirement specifies an additional 24 hours available quarterly in excess of the 17 hours weekly allowable downtime, or 10% of a calendar week.

Back to Top
Does the new quarterly system availability downtime requirement define calendar quarter?
Back to Top
My organization includes system availability schedules in our Companion Guide. Does this satisfy the CAQH CORE Benefit Enrollment (834) Infrastructure Rule requirements for system availability reporting?

Submitted by tfuchs@caqh.org on Mon, 04/18/2022 - 14:58
My organization includes system availability schedules in our Companion Guide. Does this satisfy the CAQH CORE Benefit Enrollment (834) Infrastructure Rule requirements for system availability reporting?

Yes, HIPAA-covered health plans (or information sources), clearinghouses/switches, or other intermediaries must publish their regularly scheduled system downtime in an appropriate manner (e.g., on websites or in Companion Guides). This allows the healthcare provider to better manage staffing levels. Additionally, the CAQH CORE Benefit Enrollment (834) Infrastructure Rule outlines requirements for reporting/publishing non-routine downtimes and unscheduled/emergency downtimes.

Back to Top
Why was the CAQH CORE Master Companion Guide Template updated?
Why was the Master Companion Guide Template created for entities conducting benefit enrollment electronically?

Submitted by tfuchs@caqh.org on Mon, 04/18/2022 - 14:59
Why was the Master Companion Guide Template created for entities conducting benefit enrollment electronically?

For many years health plans independently created companion guides that often varied in format and structure. Such variance can be confusing to trading partners and providers. CAQH CORE adapted its CAQH CORE Master Companion Guide Template for the CAQH CORE Benefit Enrollment (834) Infrastructure Rule based on the CAQH/WEDI Best Practices Companion Guide Template, with input from multiple health plans, system vendors, provider representatives and healthcare/HIPAA industry experts. The CAQH CORE Master Companion Guide Template organizes information into several simple sections and provides for a common information flow and format, while at the same time giving health plans the flexibility to tailor the document to meet their needs. The CAQH CORE Master Companion Guide Template may be used for all HIPAA-mandated Transaction Sets.

Back to Top
Does the CAQH CORE Benefit Enrollment (834) Infrastructure Rule require HIPAA-covered entities to publish a Companion Guide if they do not currently do so?

Submitted by tfuchs@caqh.org on Mon, 04/18/2022 - 14:59
Does the CAQH CORE Benefit Enrollment (834) Infrastructure Rule require HIPAA-covered entities to publish a Companion Guide if they do not currently do so?

No. Section 4.9 of the CAQH CORE Benefit Enrollment (834) Infrastructure Rule specifies that should an entity publish a companion guide it must conform to the format/flow as defined in the CAQH CORE Master Companion Guide Template.

Back to Top
Can I combine multiple Transaction Sets in a single companion guide?

Submitted by tfuchs@caqh.org on Mon, 04/18/2022 - 15:00
Can I combine multiple Transaction Sets in a single companion guide?

Yes. Entities may combine their companion guides for separate transactions into a single document. The flow and format of the CAQH CORE Master Companion Guide Template would still need to be followed, but sections would need to be repeated, tables added for each additional transaction, etc., without altering the flow and format.

Back to Top