Creating an authorization is easy enough. Go to the context you want, click add, enter an authorization number, specify an action and a selection, or two, and – BAM! – you’ve got an authorization. But things can get complicated as you go deeper into the plan design process. In this article, we will discuss the benefits of actions for authorization management and delve into a real-world scenario that showcases how a newly created action can be effectively utilized within an existing framework.

 

About Actions

Actions are administrator-defined categories the system uses to organize authorizations into sets. They classify authorizations, describe the managed parameter, and specify whether processing behaviors should be overridden (i.e., p-codes). Each action is comprised of a code and a value.

Action codes are abbreviated descriptions of the parameter associated with the authorization, such as COST (allow cost), ONFORM (on formulary), or DRUG (allow drug). Action values are tags that describe the intended behavior of the authorization; examples include yes, no, and ignore.

How the System Uses Actions

During claims processing, the Authorization System goes through authorizations with the same action code in ascending order. An authorization with a “Drug” action will be grouped with other authorizations with the “Drug” action, an authorization with a “Cost” action will be grouped with other authorizations with a “Cost” action, and so on. Selectors set in the authorizations are compared to claim facts. Once a match is identified between the authorization selectors and claim facts, the system either processes the claim or generates a rejection message for the pharmacy. The outcome depends on whether the matched authorization has a rejection tied to it or not.

The diagram below shows claim facts being checked against authorizations at runtime. In the diagram, a match is found on A/N 89999-996. The matched authorization has a rejection attached. So, the system returns a rejection message to the pharmacy.

Conceptual graphic of claim facts checked against authorization criteria at runtime.

Expanding the Action Set

The system comes loaded with a set of actions to help you get started quickly. These are based on parameters commonly used in plan design, such as drug, cost, and day supply allowances. And now, new actions can be added at any time!

Creating new actions allows you to:

  • define categories for different types of authorizations.
  • streamline authorization tracking and management.
  • align action codes and values to the terminology used by your organization.

Currently, only EHO360 account managers can add new actions in the system, but this feature may be expanded to users in the future. In the meantime, let your account manager know your requirements, and they will collaborate with you to develop actions to meet your needs.

Scenario

Let’s look at a scenario that shows how to utilize a new action within an existing framework.

The plan designer needs to implement an administrative block on paroxetine at the Group level. It must take priority over the current formulary.

The contexts, authorization number (A/N) ranges, action codes, and action values for the existing authorizations on the plan (Plan A) are in the tables below.

Plan A – A/N Contexts and Ranges

Context A/N Range
Patient 10000000 – 20000000
Group 30000000 – 70000000
Global 80000000 – 90000000

Plan A – Action Codes and Values

Codes Values
Drug  (DRUG) Yes, No
Day Supply (DAYSUP) Yes, No
Cost (COST) Yes, No

The existing authorizations for Plan A are listed in the table below. 

Plan A Authorizations
A/N Action Policy Selections Rejection Number (R/N)
55000-005 DRUG: Yes PlanA-Approved Drugs
89999-996 DAYSUP: No Over: 30 76 Plan Limitations Exceeded
89999-997 COST: No Over: 1000 78 Cost Exceeds Maximum
89999-998 DRUG: No 75 Prior Authorization Required

🛈 Dashes are included in A/Ns to improve readability. Do not include dashes when entering A/Ns into the system interface or imported files.

Scenario Solution

We’ll address the scenario with an action called “Admin Blocks.” The action code is  ADMIN and the value is Block.

In the swimlane diagram below you can see the new action, ADMIN, together with the existing authorizations for Plan A. The authorizations are grouped by action code: DRUG (yellow), COST (green), DAYSUP (purple), and ADMIN (orange).

DRUG COST DAYSUP  ADMIN

A/N: 55000-005, DRUG: Yes, Policy: PlanA-Approved Drugs

A/N: 89999-998, FORM: Off, R/N: 75 Prior Authorization Required

 

A/N: 89999-997, COST: No, Over: 500, R/N: 78 Cost Exceeds Maximum

A/N: 89999-996, DAYSUP: No, Over: 30, R/N: 76 Plan Limitations Exceeded

 

 

Next, we’ll create a policy calledBlocked Drugs.”

Every policy requires at least one authorization. Our policy will have two: a disabled comment authorization (A/N 64900-000) and an enabled authorization for paroxetine with the GPI selector (A/N 64900-005). Both are listed in the table below.

🛈 Discover how comment authorizations can help you stay organized. Read the article Organizing with Comment Authorizations here.

Policy Blocked Drugs
A/N Description Action Selections Rejection
64900-000 Blocked Drugs
64900-005 Paroxetine GPI: 58160060

🛈 Did you know: You can leave the action field empty in your policy and set it in the “include authorization” instead. This way the same policy can be reused in various contexts and with different actions, without modification.

Now that the policy is created, we need to activate it by including it in an authorization.

The scenario states the block applies at the group level. So, we will include the policy in a Group authorization with the following:

    • An eight-digit A/N within the established range for Group authorizations. For our purposes, the number should be smaller than the approved drug authorization (A/N 55000-005) so it is checked first.
    • The Blocked Drugs policy included. 
    • The action code and value, ADMIN: Block, set.
    • No selectors; the GPI selector is already specified in the policy!
    • A relevant rejection code, such as 70 Product/Service Not Covered.

Here’s an updated list of authorizations for Plan A. The new Group authorization with the Blocked Drugs policy included is highlighted in orange.

Plan A Authorizations
A/N Action Policy Selections Rejection
54900-020 ADMIN: Block Blocked Drugs 70 Product Not Covered
55000-005 DRUG: Yes PlanA-Approved Drugs
89999-996 DAYSUP: No Over: 30 76 Plan Limitations Exceeded
89999-997 COST: No Over: 1000 78 Cost Exceeds Maximum
89999-998 DRUG: No 75 Prior Authorization Required

 🛈 It is important to have a rejection authorization to counter approval authorizations, but it is possible to have a rejection authorization without an approval authorization!

Here are the same authorizations from the table above organized into swimlanes according to action. The new authorization is in the ADMIN column (orange). 

DRUG COST DAYSUP  ADMIN

A/N: 55000-005, DRUG: Yes, Policy: PlanA-Approved Drugs

 

 

 

 

A/N: 89999-998, FORM: Off, R/N: 75 Prior Authorization Required

 

 

 

A/N: 89999-997, COST: No, Over: 500, R/N: 78 Cost Exceeds Maximum

A/N: 89999-996, DAYSUP: No, Over: 30, R/N: 76 Plan Limitations Exceeded

A/N: 54900-020, ADMIN: Block, Policy: Blocked Drugs, 70 Product Not Covered

A block on paroxetine has been added at the Group level (A/N 54900-020). The system will apply the authorization to incoming claims as appropriate. A “70 Product Not Covered” message will be returned if a claim for paroxetine is submitted. Utilizing a policy for the block means more drugs can be added to the list if needed. Additionally, the same authorization (A/N 54900-020) can be applied to incoming claims for drugs on the list. There is no need to create multiple authorizations.

Different vs Matching Actions

We could have created an authorization with a matching action to override A/N 55000-005 in our scenario. But, utilizing an authorization with a different action has advantages in comparison.

 

Matching Actions Different Actions
Potential to unintentionally override existing authorizations in the future.  Keeps authorization sets separate (in their own swimlane).
Ambiguous message returned to the pharmacy, potential for unnecessary phone calls and messages to support personnel. Clear rejection message returned to the pharmacy, minimizing pharmacy, patient, and personnel frustration.

 

Claim Facts Checked Against Authorizations

The following diagram is an updated version of the graphic introduced earlier in this article. In this image, the system performs a check between claim facts and authorizations. A match is found on A/N 54900-020, and the system sends a rejection message to the pharmacy. The rejection message is specific to the reason for the rejection, ensuring easy interpretation by the pharmacy.

Conceptual graphic of claim facts checked against authorization criteria at runtime.

Conclusion

In this article, we discussed how developing your own actions can aid in authorization management. The scenario described  illustrates the utilization of a new action within an existing framework in combination with a policy. Consult with your account manager for help developing and integrating new actions into your plan design.

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

Next Steps

  • Visit the Primary Concepts page to familiarize yourself with Authorization System concepts before you get started.
  • Explore the interface and learn how to set up your first authorization in the New User Guide.
  • Whether you are a first-time user or a seasoned plan designer, there is always more to learn! Read all about the latest Authorization System features and get helpful tips for using the system on the Articles page.