General Procella Health Platform Concepts

The Procella Platform is made up of various parts.  These parts, or components, are designed to offer flexibility and reusability.  Understanding how these components work individually and together is important. To understand the system, we need to understand the different status types used in the system and the use of point-in-time architecture (PTA).

Brand Class

The Brand Class is defined by the PBM using Criteria and established in the PBM record of the System Hierarchy.  The system supports 4 defined Brand Classes:

• Brand, Multi-Source
• Brand, Single Source
• Generic, Multi-Source
• Generic, Single Source

The 4 brand classes are used throughout the platform.  This enables very distinct management.  We also established what is called a DEFAULT level.  This is used when a Brand Class is not defined.

The option of Default also allows quick setup if needed.  For instance, if there is no difference in Copay/Coinsurance between brands and generics, setting up the copay at the DEFAULT level will apply the copay to all brand classes.  While this is not recommended as the typical setup, it may be useful in select circumstances.

Draft – Active – Inactive

There are 3 states that are used throughout the platform.  It is important to understand what the state means and how it impacts your workflow.  Almost all records in the platform have an Active/Draft/Inactive state associated.  Essentially, only records with an ACTIVE state are used in the production processing.

Draft  

The Draft state simply means you are working on the record and are not ready to consider it ready for production.  A Draft state allows you to work on the record, save it as a draft so you don’t lose your work.  Draft is the precursor state to Active.

Simply, a Draft state indicates the record is not ready for use in production.

 

BEST PRACTICE:  As a standard process, it is encouraged that the User who creates the record in Draft does not promote it to an Active state.  Another User who is knowledgeable would then review the work before promoting it to an Active state.

This is very important especially as it relates to Edits. 

Active

The Active state indicates the record can be used in the processing of claims.  We do recommend that the User who creates the record in DRAFT is not the same User who converts the record to ACTIVE.  This is a best practice to ensure the information is accurate and has been reviewed by a separate User.  We understand that this is not always practical or possible in your business.

Simply, an Active record is a record ready for production use.

 

Inactive  

The Inactive state is essentially a logical deleting of the item.  The difference, though, is important.  The system does not delete items.  The state of Inactive means that the system will ignore the record entirely.  It is also important to note that an Inactive record cannot be reactivated. 

Again, an Inactive record is maintained but never again used in production.  It can also never be re-activated.

 

About Edits 

The Procella Health System has a comprehensive system of edits that can be used throughout the system.  These control financials (ingredient rates, dispensing fees, accumulations, etc), claim limits (Claim Min/Max, Quantity Limits, Age Limits, Days Supply limits, etc), benefit maximums (units, quantities, fills, etc), and clinical rules (Step Therapy, DUR, etc) . All edits are created in the Edit Manager.  Edits are a special object within the system.  Specifically, these edits, once created and activated, cannot be changed.

FINANCIAL EDITS

The financial edits specifically control how rates, fees, deductibles, etc. are applied in the system.

LIMITATION EDITS

These edits control the limits of the claim. For eg., Claim Min/Max, Quantity limit, Age limit, Days Supply limits etc.

BENEFIT MAXIMUM EDITS

These edits validate against the accumulated values. For eg., Maximum # of Rxs, Maximum dollars spent

CLINICAL EDITS

Clinical limitations like Refill too soon, Step Therapy, DUR etc

In order to facilitate accurate processing, the system shall be designed to support default processing rules which shall work out of the box based on logic we have determined to be appropriate for most cases. In addition, we shall allow the user to configure their plan using advanced configuration options and shall give them full control over the design. The default options just pre-selects options also available in Advanced Processing.

Default Processing

• Include in Plan Accumulation radio box
• Use Plan Accumulation radio box

For default processing basic assumptions are made about how the edit shall process. 

Accumulation tests against the edit shall use the adjudicated Provider Network Type and Provider Network Classification accumulations. We are assuming the user would set the edit up this way anyway. For example, Use Network Type Accumulation "Specialty" and Use Network Classification Accumulation "In Network". Note: this basic default behavior is the key difference between Default and Advanced.

For example, if the claim is Network Type "Specialty" and "In Network", we would look for accumulated values for the edit which are stored as In Network Specialty and In Network.

Similar to advanced configuration below, the user shall also have the option to include the accumulated values at the Plan Default level. This is set with the Include In Plan Accumulation radio box.

Similar to advanced configuration below, the user shall also have the option for the edit to use the accumulated values at the Plan Default level. This is set with the Include Use Plan Accumulation radio box.

Advanced Configuration and Processing

• Include in Plan Default Accumulation check box
• Use Plan Default Accumulation check box
  • When set to Yes (On; True) the Network Type and Network Classification options shall not be available 

• Use Network Type Accumulation check boxes (at least one required)
  • Mail
  • Specialty
  • Retail
  • Retail 90

• Use Network Classification Accumulation check boxes
  • In Network
  • Out of Network

When Use Plan Accumulation is not checked, the accumulation tests against the edit shall use the specified Provider Network Type and Provider Network Classification accumulations. When more than one item of either is checked, the accumulators for the selected items shall be summed together.

 

For example, if Mail and Retail90 were selected, then the edit test will be against the sum of Mail and Retail90 accumulations.

The difference between this setup and default is that we are allowing the user to control all of the logic.

Similar to above, the user shall also have the option to include the accumulated values at the Plan Default level. This is set with the Include In Plan Accumulation radio box.

Similar to above, the user shall also have the option for the edit to use the accumulated values at the Plan Default level. This is set with the Use Plan Accumulation radio box.

 

Use Plan Accumulation Configuration

For Plan Default, Provider Default level rules, all Accumulated Expenditures (if the system shall store accumulators within a container such as a BLOB) are stored according to the network classification and network type which was adjudicated for the submitted claim, regardless of the accumulation settings specified in the rule. Accumulations are stored in this way by default, so that all accumulation data will be available in the event that the member changes plans.

So what does this mean? When storing data for default level accumulations, we should have data on the record which has the adjudicated network classification and type.

However, when this checkbox is not selected for an applicable rule, the user can specify which types of network contributions (Use Network Type Accumulation and Use Network Classification Accumulation) will contribute to the accumulation limit for the rule by configuring the accumulation use values.

 

Include in Plan Accumulation Configuration

For exception level rules, you can also designate the exception deductible to be included with the plan default accumulation by using the Include in Plan configuration field.

For example, a plan exception rule for generic product might specify that the individual deductible is $10.

The plan rule says all other deductibles are $25.

If the, Include in Plan, indicator is selected in the exception rule, the $10 for the generic product is also applied to the Plan Default accumulation, effectively reducing the plan deductible to $15 for any remaining claims.