Do Web Portal operators need to create a 278 transaction from the Web Portal data submitted by the provider or is the rule requiring that Web Portal submissions be mapped to 278 transactions?

No. The rule does not require the Web Portal operator to map the data collected from the web form to the X12 v5010X217 278 Request or Response transaction. The rule does require that if a Web Portal operator maps the data collected from the web form to the X12/v5010X217 Health Care Services Review – Request for Review and Response (278) Transaction, it must conform with the CAQH CORE Prior Authorization and Referrals (278) Data Content Rule.

Is the bulleted list of potential next steps that a Web Portal operator could display along with confirmation of receipt of the web form submission an exhaustive list of options?

No. The bulleted list only contains examples of potential next steps that may take place (not rule requirements). It is not comprehensive, nor does it indicate other processing requirements that may need to occur at the health plan, e.g., medical necessity review, etc.

Are Web Portals that do not translate prior authorization requests into a 5010X217 278 Request included in the scope of the rule?

The CAQH CORE Prior Authorization and Referrals Web Portal Rule is applicable to any entity that currently offers prior authorization through a Web Portal application; this can include health plans, clearinghouses, vendors, etc., regardless of whether they utilize a 5010X217 278 Request and Response. One goal of this rule is to provide uniformity and consistency to Web Portal data field labels via the existing standard data element names; this benefit can be applied regardless of whether or not the Web Portal operator conducts the HIPAA-mandated standard transaction.

Is the 278 Request/Response transaction data identical to that in the Web Portal Rule?

The rule requires Web Portal operators to map data field labels to their corresponding 5010X217 278 Request and Response Technical Report Type 3 (TR3) or base standard IMPLEMENTATION NAME or Alias. It also requires Web Portal operators to adhere to the data content rule requirements if it maps the data collected from the web form to the 5010X217 278 Request and Response transaction.

What happens if the IMPLEMENTATION NAME or other standards referenced in the CAQH CORE Prior Authorization & Referrals Web Portal Rule change between versions? Is it intended that the rule would only apply prior to the adoption of the next version of t

Note: The term IMPLEMENTATION NAME is used in the X12 Technical Report Type 3 (TR3) to describe the data field label name. The names are influenced by the intended use of the segment in a specific position of the Transaction Set and the industry names for data elements in the segment. Examples of IMPLEMENTATION NAMES can be found in the X12 v5010 X217 (278) Health Care Services Request for Review and Response TR3.

How does the standardization of portals encourage technology solutions that minimize the need for providers to submit information to multiple Web Portals?

Web Portal use for prior authorization is widespread and the pain points associated with usage are vast. Mitigating some of these pain points today via an operating rule allows for near-term relief and builds a bridge towards familiarity and consistency with the transaction standard. The standardization of portals supports an interim strategy to bring greater consistency to Web Portals given current widespread industry use, with a long-term goal of driving adoption standard transaction.

Why are referrals in scope in the CAQH CORE Prior Authorization & Referrals Web Portal Rule and out of scope for the CAQH CORE Prior Authorization & Referrals (278) Data Content Rule?

During CAQH CORE’s extensive environmental scan period (which included multi-stakeholder interviews, provider site visits, a vendor product assessment, and an All-CORE Participant Survey), one of the biggest pain points cited involved the scenario where a prior authorization request is pended due to the need for additional information (to prove medical necessity for medical services). Another burden for providers is lack of uniformity across Web Portals, as each plan has a portal tool with inconsistent and non-uniform data requirements, field names, etc.