Article Contents

About Override Policies

An override policy is a pre-defined set of authorizations that can override limitations on a plan. Just like traditional policies, override policies can be created in advance, saved for later use, and reused multiple times. Since they are built in advance rather than in real-time, they are testable and less prone to error than individual authorizations created on the fly.

Contexts

Override policies are created in the Policy context. Once built, an override policy can be used by including it on a Patient or Group authorization.

Benefits of Override Policies

They save time.

An override policy allows you to utilize a single authorization to override multiple actions. To use it, include the override policy in a Group or Patient authorization when an override is needed.

They are highly customizable.

Override policies can be as general or specific as required. It’s even possible to create sets of override policies with different permissions, such as nurse manager and claims adjuster overrides.

They help streamline change management.

Changes can be managed all in one place – the override policy.

They are testable.

After an override policy is created, use the checker tool to rule out formatting errors and confirm it is working as intended.

🛈 Note: When creating an override authorization or override policy, pay close attention to the formatting. If the assigned action and selection(s) do not align with those set in existing authorizations, a submitted claim could bypass authorizations meant to cause a rejection.

Scenario

A pharmacy submits a claim for Gleveec and it is not a covered drug on the plan’s formulary. The cost and day supply submitted also exceed plan limitations. The plan administrator wants to approve the drug, cost, and day supply submitted.

This scenario can be addressed by creating three separate authorizations to override individual actions or using an override policy to override multiple actions. Before we go over both approaches, take a look at the formulary policy in the table below, it contains the authorizations we will be overriding in our scenario.

Key: A/N = Authorization Number, D/S = Day Supply, N = No, ONFORM = On Formulary, Y = Yes

🛈 The grayed-out authorizations in the table are comment authorizations. Check out the article Organizing with Comment Authorizations to learn more. 

Override Individual Actions with Separate Authorizations

These are the three actions we need to override based on the policy described in the table above:

• Allow Drug (DRUG) to approve the drug, Gleevec (A/N 89999-999).
• Day Supply (DAYSUP) to approve the submitted day supply over 30 days (A/N 89999-998).
• Allow Cost (COST) to approve the submitted cost over $1000 (A/N 89999-997).

Since the claim in our scenario is for an individual patient, we will add authorizations in the Patient context. Three separate Patient authorizations need to be created to override each action set on the policy’s plan defaults. They are shown in the next table.

Key: A/N = Authorization Number, D/S / DAYSUP = Day Supply, N = No, ONFORM = On Formulary, Y = Yes

Each Patient authorization overrides an action on one of the plan defaults. Here, the Patient authorizations are shown with the authorization they are overriding:

Once all three authorizations are added to the Patient’s profile, the claim for Gleevec can be processed. If the submitted cost or day supply exceeds the allowance in the Patient authorizations ($5,000 and 60 days), the system will match on the corresponding plan defaults (A/N 89999-998 and 89999-997) and return a rejection message to the pharmacy.

Using this approach means you’ll need to complete the process of adding separate authorizations to override individual actions every time the patient needs a fill of Gleevec. The formulary policy in our scenario is simple, but if more constraints were added overriding them one by one becomes increasingly complicated and time-consuming. Creating authorizations this way also comes with a risk of error because they are often added on the fly and untested before use. 

 If there is a chance that the scenario could happen again, if the policy you are overriding is complex, or if you anticipate other patients will have a similar need, it would be better to create an override policy. Go to the next section for an example.

Override Multiple Actions with One Override Policy

The table below shows an override policy called Management Override (MGMTORIDE). To address our scenario we can create one Patient authorization with the MGMTORIDE override policy included and the GPI for the approved drug specified.

But first, review the authorizations in the table and note the following:

• actions assigned to authorizations in the override policy match the actions in the authorizations we need to override (i.e., DRUG, DAYSUP, COST) ;
• the selection field for A/N 50000-003 is blank, making it applicable to any medication;
• the day supply and cost authorization limits (A/N 50000-002 and -003) are less strict than the limitations in the policy being overridden (A/N 899-9998 and -997).

Key: A/N = Authorization Number, D/S / DAYSUP = Day Supply, mgmt = management, N = No, ONFORM = On Formulary, Y = Yes

The authorization allowing the drug in this override policy does not have an NDC or GPI specified, which means it can be used to approve any medication and for any patient. Something like this could easily be set up in advance and matched with existing authorizations in a policy, like the formulary policy in our scenario.

Here we can see the relationship between the authorizations in the MGMTORIDE policy and the formulary policy:

To resolve the issue in our scenario, we can create a single Patient authorization with the MGMTORIDE override policy included and the GPI for the approved drug, Gleevec, specified. Everything else, including the action, has been defined in the override policy.

Here is an example of a Patient authorization with the override policy above included:

🛈 Note: We don’t need to set an action in the Patient authorization. The actions have already been defined in the override policy! Authorizations with the same action will interact and can override each other. We need to override the actions in the plan defaults and the override policy is already designed to do this.  Setting an additional action will change authorization behavior and, as a result, the claims processing outcome.

When the pharmacy submits the claim for Gleevec, the Patient authorization (A/N 10000-020) will override all the plan defaults on the formulary policy. The tables below illustrate this concept.

Now, the claim in our scenario will process! What’s more, the same policy can be used to approve future fills for any patient.

If a submitted claim:

• exceeds the allowable cost set in A/N 50000-001, the system will match on A/N 89999-997 and return a rejection message to the pharmacy;
• exceeds the day supply set in A/N 50000-002, the system will match on A/N 89999-998 and return a rejection message to the pharmacy;
• is for an unapproved drug, the system will match on A/N 89999-998 and return a rejection message to the pharmacy.

Summary

Creating authorizations one by one to override individual actions is valid but can be time-consuming and error-prone. Pre-built override policies offer an alternative solution. Although they require planning, override policies improve long-term efficiency. Override policies for common scenarios can be created in advance and included in a single authorization, streamlining the override process. This approach also allows for review and testing before use, ensuring confidence in its effectiveness.