Phase V CAQH CORE Operating Rules

Phase V CAQH CORE Prior Authorization 278 Request/Response Data Content Rule

  1. Does the Phase V CAQH CORE Prior Authorization (278) Data Content Rule only address pended responses?
  2. Is the industry required to adopt the 5010X217 278 transaction?
  3. Will limiting the scenarios for the required use of PWK01 Attachment Report Type Code and Logical Identifiers Names and Codes (LOINCs) hinder prior authorization automation and adoption of the 5010X217 278 transaction?
  4. Are entities required to use LOINCs in the HI Loop?
  5. How many times can LOINCs and the PWK loop be repeated at the Patient Event Level and Service Event Level?
  6. To request additional documentation for a pended response, how many HR03 Industry Codes can be returned?
  7. In Section 4.2.3 Requesting Additional Documentation for a Pended Response, how was the list of service categories determined?
  8. Are vendors who send requests on behalf of the payer able to go beyond the specificity of the list of services categories in the Phase V CAQH CORE Prior Authorization (278) Data Content Rule?
  9. When requesting additional documentation for a pended response for a patient with more than one service preformed for the same diagnosis, which service category would it be categorized under? (For example, surgery, imaging, laboratory, oncology and inpatient services that all apply to a lung cancer diagnosis).
  10. Why is there a requirement to return HCSDRC 09 (Out of Network) when this type of transaction is rejected using a AAA*35 (Error Code 35 – Out of Network)?
  11. Does last name normalization required by the Phase V CAQH CORE Prior Authorization (278) Data Content Rule mirror that of the Eligibility Transaction Rule requirements?
  12. Why are the Date-of-Birth and DMG segments included in patient identification, but member ID is not included?
  13. Why are all HCR03 Industry Codes included as options in the Phase V CAQH CORE Prior Authorization (278) Data Content Rule?
  14. Does the Phase V CAQH CORE Prior Authorization (278) Data Content Rule refer to only to the 5010X217 278 and no other transactions?
  15. When a provider receives a LOINC from the health plan, are they required to respond using the CDA standard?
  16. Why is the Extended Character Set outside the scope of the Phase V CAQH CORE Prior Authorization (278) Data Content Rule?
  17. Why are referrals in scope for the Phase V CAQH CORE Prior Authorization Web Portal Rule and out of scope for the Phase V CAQH CORE Prior Authorization (278) Data Content Rule?
  18. In Section 4.1 Requirements for Providers, Sub-Section 4.1.1 Patient Identification of the Phase V CAQH CORE Prior Authorization (278) Data Content Rule, when the patient is a subscriber or when the patient is a dependent, why are providers required to submit subscriber and dependent date-of-birth in addition to subscriber and dependent first and last name, as the 5010X217 278 Request TR3 does not permit a UMO to require the submission of all of these data elements?
1. Does the Phase V CAQH CORE Prior Authorization (278) Data Content Rule only address pended responses?

No, the Phase V CAQH CORE Prior Authorization (278) Data Content Rule has requirements that apply to the data content of the 278 Inquiry and Response transactions beyond just pended responses (e.g., last name normalization, uniform and consistent use of AAA Error Codes and Action Codes, etc.)

2. Is the industry required to adopt the 5010X217 278 transaction?

Under the HIPAA provisions, health plans are “required to have the capacity to accept and/or send (either itself, or by hiring a health care clearinghouse to accept and/or send on its behalf) a standard transaction that it otherwise conducts but does not urgently support electronically. The rule does not require other modalities/solutions such as web portals to be discontinued.

3. Will limiting the scenarios for the required use of PWK01 Attachment Report Type Code and Logical Identifiers Names and Codes (LOINCs) hinder prior authorization automation and adoption of the 5010X217 278 transaction?

While Section 4.2.3.1 and 4.2.3.2 list types of events that, when additional medical information is required, necessitate the return of the appropriate HCR01 306 Action Code and HCR03 Industry Code and either a PWK or PWK and LOINC, the rule does not prohibit health plans and its agent from using the same methods to request additional documentation for events outside of the listed event categories. The requirements are placed on the health plan and its agent to process a limited set of use cases for when a service, procedure, etc. requires additional documentation when these types of service fall into a set of categories as defined in the rule. When procedure codes, diagnosis codes and revenue codes fall outside these categories of service the rule requirements do not apply, but health plans and its agent are encouraged to use the PWK segments and LOINC codes. The rules set a floor not ceiling, health plans and their agents can go above and beyond the rule requirements and include additional categories of service, for example.

4. Are entities required to use LOINCs in the HI Loop?

No, when a health plan requests additional documentation for a pended response, the plan and its agent must return a PWK segment and are encouraged to return a PWK segment AND a LOINC in the HI Loop. The use of LOINCs is not dependent on a CMS regulation addressing attachments. LOINCs are supported within the 5010X217 278 Request and Response TR3 and are used throughout clinical data exchange. The use of LOINCs is an option and is not required, as the use of the PWK can be used to request the additional documentation required for processing a pended prior authorization. The intent of this requirement is to allow progressive steps to be made by the industry in the adoption and use of the LOINCs.

5. How many times can LOINCs and the PWK loop be repeated at the Patient Event Level and Service Event Level?

The HI Loop supports up to twelve occurrences of LOINCs and the PWK Loop can be repeated up to ten times at both the Patient Event Level and the Service Level. Health plans and their agents are encouraged to use LOINCs to identify specific additional data and attachments to accommodate adjudication of the prior authorization. The use of LOINCs is an option and is not required, as the use of the PWK can be used to request the additional documentation required for processing a pended prior authorization. The intent of this requirement is to allow progressive steps to be made by the industry in the adoption and use of the LOINCs.

6. To request additional documentation for a pended response, how many HR03 Industry Codes can be returned?

A health plan and its agent can return up to five HR03 Industry Codes for a pended response requiring additional documentation.

7. In Section 4.2.3 Requesting Additional Documentation for a Pended Response, how was the list of service categories determined?

To encourage movement toward a more automated and streamlined processing of the request and flagging the need for additional documentation, the rule requires that the health plan process submitted Diagnosis, Procedure and Revenue Codes that fall into types of services that are often pended for medical necessity. The categories of services were determined and agreed to by the Prior Authorization Subgroup as the most frequently pended for additional documentation. This will allow for the industry to make progress in building logic into adjudication systems for prior authorization.

8. Are vendors who send requests on behalf of the payer able to go beyond the specificity of the list of services categories in the Phase V CAQH CORE Prior Authorization (278) Data Content Rule?

Yes, health plans and its agent are strongly encouraged to evaluate and respond to all received procedure, diagnosis or revenue codes, not only those listed in rule. The rule does not prohibit health plans and its agent from using the same methods to request additional documentation for services outside of the listed service categories. The requirements are placed on the health plan and its agent to process a limited set of use cases for when a service, procedure, etc. requires additional documentation when these types of service fall into a set of categories as defined in the rule. The rules set a floor not ceiling, health plans and their agents can go above and beyond the rule requirements and include additional categories of service, for example

9. When requesting additional documentation for a pended response for a patient with more than one service preformed for the same diagnosis, which service category would it be categorized under? (For example, surgery, imaging, laboratory, oncology and inpatient services that all apply to a lung cancer diagnosis).

The X12/v5010X217 278 TR3 supports submission of up to twelve different ICD-10 codes from 3 different X12 External Code Sources.

10. Why is there a requirement to return HCSDRC 09 (Out of Network) when this type of transaction is rejected using a AAA*35 (Error Code 35 – Out of Network)?

A transaction being rejected using a AAA*35 assumes that the prior authorization was rejected due to being out of network. While this is often true, it is not always the case. Setting up the out of network flag at the HCSDRC 09 level allows for that flexibility.

11. Does last name normalization required by the Phase V CAQH CORE Prior Authorization (278) Data Content Rule mirror that of the Eligibility Transaction Rule requirements?

Yes, Sections 3.6, 4.1 and 4.2 of the Phase V CAQH CORE Prior Authorization (278) Data Content Rule address the use of a patient’s last name to the extent permitted by the X12/v5010X217 278 Request/Response and the requirements for providers, health plans, and their agents and are nearly identical; however, since the X12/v5010X279 270/271 Eligibility Benefit Inquiry and Response focus is on patient verification, the requirements are slightly different; i.e. the Phase II CAQH CORE Eligibility & Benefits 270/271 Normalizing Patient Last Name Rule requires the return of the last name in the INS Loop when the last name submitted in the 270 Request is different than the last name stored by the health plan. There is nothing comparable in the 278 transaction as there is no INS Segment in the 278 Response transaction.

12. Why are the Date-of-Birth and DMG segments included in patient identification, but member ID is not included?

The rule expands upon the 5010X217 278 Request and Response TR3 requirements while not conflicting with them, to allow for the most accurate patient matching (and therefore reduction in pended requests due to related errors). The member ID is not included in the rule requirement because it is already required by the TR3.

13. Why are all HCR03 Industry Codes included as options in the Phase V CAQH CORE Prior Authorization (278) Data Content Rule?

The CAQH CORE Prior Authorization Subgroup and Rules Work Group participants responded to several feedback forms and straw polls to offer insight into challenges with the X12/v5010X217 278 Request/Response data content. One of the challenges widely reported with the Response, is the inconsistency in the use of the HCR codes. This requirement encourages consistency and uniformity in their use. Health plans and their agents are encouraged to use all HCR codes to better return specific messages to the provider.

14. Does the Phase V CAQH CORE Prior Authorization (278) Data Content Rule refer to only to the 5010X217 278 and no other transactions?

Yes, the Phase V CAQH CORE Prior Authorization (278) Data Content Rule builds upon the foundational infrastructure requirements for prior authorization established by the Phase IV CAQH CORE Prior Authorization (278) Infrastructure Rule and applies only to the 5010X217 278 transaction.

15. When a provider receives a LOINC from the health plan, are they required to respond using the CDA standard?

No. The Phase V CAQH CORE Prior Authorization (278) Data Content Rule does not require a provider to respond using the CDA standard. Response/transport method of additional documentation is mutually defined by trading partner agreement, contract, etc. between the provider and the health plan or its agent.

16. Why is the Extended Character Set outside the scope of the Phase V CAQH CORE Prior Authorization (278) Data Content Rule?

To remain consistent with the Phase II CAQH CORE Last Name Normalization Rule, the Phase V CAQH CORE Prior Authorization (278) Data Content Rule requirement on last name normalization only applies to the use of basic character set.

17. Why are referrals in scope for the Phase V CAQH CORE Prior Authorization Web Portal Rule and out of scope for the Phase V CAQH CORE Prior Authorization (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.

Based on feedback collected, the CAQH CORE Participants determined that for the use case of prior authorizations pended for the need for additional documentation to prove medical necessity, data content enhancements would be beneficial. The Subgroup developed requirements for the Phase V CAQH CORE Prior Authorization (278) Data Content Rule that reduce common errors that result in pends or denials and assist with communicating those errors back to the provider in an actionable and consistent manner. Given that research revealed that referrals do not often fall into this particular use case, referrals are not included in the scope of the 278 Data Content Rule.

It should be noted that excluding referrals, emergency/urgent cases from the Data Content Rule does not prevent or prohibit entities from using the 5010X217 278 Request and Response for these requests. Additionally, entities are not required to have a Web Portal to conduct a referral or use a portal for this purpose if it does not already do so.

Referral requests and prior authorizations for emergency and urgent services are not out of scope for the Phase V CAQH CORE Prior Authorization Web Portal Rule - the rule requirements do pertain to them. The focus of the Web Portal Rule is on the system availability requirements and using standard labels and names for data fields.

18. In Section 4.1 Requirements for Providers, Sub-Section 4.1.1 Patient Identification of the Phase V CAQH CORE Prior Authorization (278) Data Content Rule, when the patient is a subscriber or when the patient is a dependent, why are providers required to submit subscriber and dependent date-of-birth in addition to subscriber and dependent first and last name, as the 5010X217 278 Request TR3 does not permit a UMO to require the submission of all of these data elements?

In the 5010X217 278 Request and Response TR3, subscriber date-of-birth is not included in the list of maximum data elements that a Utilization Maintenance Organization (UMO) can require to identify a dependent. However, the Phase V CAQH CORE Prior Authorization (278) Data Content Rule expands upon the 5010X217 278 Request and Response TR3 requirements by requiring providers to submit date-of-birth for both the subscriber and the dependent when the patient is either the subscriber or the dependent to facilitate the most accurate patient matching.

While the Phase V CAQH CORE Prior Authorization (278) Data Content Rule requires providers to send the subscriber and dependent date-of-birth in addition to subscriber and dependent first and last name when the patient is a dependent, it does not require the health plan or UMO to require these data elements nor does the health plan have to process the additional data elements sent by the provider.  

Therefore, the Phase V CAQH CORE Prior Authorization (278) Data Content Rule expands upon the 5010X217 278 TR3 while not conflicting with it, requiring providers to send the additional data elements in order to allow for the most accurate patient matching (and therefore reduction in pended requests due to related errors).