Article Contents

🛈 Actions have two parts: a code (such as ONFORM, DRUG, or COST) and a value (such as Yes, No, or Ignore). The term “action” is often used as a catch-all to refer to both the code and the value together. 

Background

Some of the first authorizations added to a plan are the “default rules.” They are typically used to manage things like covered medications and cost limits. Whenever a new authorization is added, it needs to be able to interact with these plan defaults and, if necessary, take priority over them. This is where actions and authorization numbers come into play.

Terminology Refresher

• Actions are administrator-defined categories that the system uses to sort authorizations into sets. For example, if an authorization has a “formulary” action it will be grouped with other authorizations with the “formulary” action, an authorization with a “cost” action will be grouped with other authorizations with a “cost” action, and so on.
• Authorization numbers determine the order the system checks authorizations. Within each action group, the system checks from smallest to largest number, looking for a match between claim details and selections. The smallest-numbered match takes priority.
• Selections/selectors define what claim details (aka facts) must match for an authorization to get applied to the claim.

Overriding Plan Defaults

Let’s consider two scenarios that involve coordinating actions on authorizations to override plan defaults.

• The first scenario describes a common approach to defining a limit in an existing authorization that overrides a plan default.
• The second scenario highlights a common mistake that can result in unintended outcomes during claims processing – and how you can avoid making the same mistake. 

The table below shows the plan we will be using in scenarios. It has three authorizations: two Group authorizations (plan defaults) and one Patient authorization.

Here is the function of each authorization:

• 89999-999 stops claims for unapproved medications from processing.
• 89999-998 caps the cost of approved medications at $1,000.
• 35000-500 approves a medication for a patient (GPI: 1234567).

Key: A/N = Authorization Number, N = No, ONFORM = On Formulary, Y = Yes

Since there is already an authorization approving a drug for a patient, it might seem easier to add limits there instead of creating a new authorization. But if your limit is less strict than the plan default, you may run into problems.

Keep reading to see examples of when this approach works and when it doesn’t.

Scenario 1: Cost Approved < Cost Limit

Here, we’ll go over how to modify an existing authorization to address the following:

The plan administrator has approved a drug for a patient and needs to limit the cost to a value that is less than the allowance on the plan default.

This table shows a modified version of the Patient authorization described in the previous section, 35000-500. The plan administrator has entered an allowed cost of up to $750 (cell highlighted in yellow).

Key: A/N = Authorization Number, N = No, ONFORM = On Formulary, Y = Yes

With this modification, claims for GPI 1234567 will process as long as the cost is no more than $750. If the $750 limit is exceeded, the system will match on 89999-999 and send a rejection message to the pharmacy (i.e., 70 NDC Not Covered). A 78 Cost Exceeds Maximum rejection message will only go to the pharmacy if the $1000 limit is exceeded.

Why the modified authorization works as expected: 

The cost limit on the Patient authorization (35000-500) is stricter than the cost limit on the plan default. Authorization 35000-500 sets an additional cost limit, but it does not grant any additional permissions. This means that it only needs to override 89999-999, not 89999-998.

 

The action on the Patient authorization (35000-500) matches the action of the authorization it needs to override, 89999-999. Because the actions on both authorizations are the same they are able to interact with one another. The authorization number on the Patient authorization is smaller than the plan default allowing it to take priority and override it.

The authorizations in the table above are completely acceptable and will behave as expected…until you need to selectively override a plan limitation. Check out the next scenario to see what we mean.

Scenario 2: Cost Approved > Cost Limit

Now, let’s see what happens when we modify an existing authorization to address the following:

The plan administrator has approved a drug for a patient and needs to approve a cost that is greater than the allowance on the plan default.

The next table shows a modified version of the Patient authorization from the previous section (35000-500). It has been updated with an allowable cost of up to $2,000 (cell highlighted in yellow).

Key: A/N = Authorization Number, N = No, ONFORM = On Formulary, Y = Yes

This is a common approach, but it does not work the way you would expect. When a claim is processed for GPI: 1234567 the setup shown in the table above will cause a rejection because authorization 89999-998 will override the cost allowance set on authorization 35000-500.  

Why the modified authorization doesn’t work as expected:

The patient authorization allows a cost that is higher than the plan’s default limit. Two plan defaults have to be overridden:

1. The formulary rule.
2. The cost limit.

The patient authorization uses the ONFORM action. An authorization with this action can only interact with other ONFORM authorizations. It cannot override the plan’s cost limit rule that has a COSTCAP action on its own.

As a result, when the claim is processed, the plan’s cost limit authorization (89999-998) overrides the patient authorization and causes the claim to reject.

Recommended Approach

In this scenario, one authorization is being used to override two different plan rules. Instead, create separate authorizations, each with an action that matches the rule it needs to override. An example of this setup is shown in the next section.

Override Plan Defaults with Separate Authorizations

You can avoid the outcome described in Scenario 2 by creating separate authorizations to override plan defaults.

The authorizations should have:

• actions that match the plan defaults they are meant to interact with and override.
• smaller authorization numbers relative to the authorizations they are meant to override.
• relevant selections (should relate to the parameter they are meant to control).

Let’s look back at Scenario 2:

The plan administrator has approved a drug for a patient and needs to approve a cost that is greater than the allowance on the plan default.

The next table has two Patient authorizations, along with the plan defaults we have been using in all examples (A/N 89999-998 and 89999-999). Notice the action and selections in the highlighted cells and how they meet the criteria described above.

Key: A/N = Authorization Number, N = No, ONFORM = On Formulary, Y = Yes

With this approach, claims for GPI 1234567 will process as long as the cost is less than $2,000. If the cost goes over the allowable amount of $2,000, the system will default to 89999-998 and return a rejection message to the pharmacy (i.e., 78 Cost Exceeds Maximum).

Takeways

• Matching actions allow authorizations to interact and override one another. The authorization with the lowest number takes priority.
• If you need to make multiple allowances, it is best to create separate authorizations for each.
• Maintaining awareness of how authorizations and their actions interact helps prevent unexpected outcomes, such as claims being approved when they should have been rejected, or rejected when they should have been approved.

Contact Support

Our team is here to help!

For plan-specific or urgent needs, contact your account manager directly.

For general Authorization System questions, contact EHO360 Operations at ops@ehorx.com