The Procella Platform is made up of various parts.  These parts, or component, 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 hierarchies within the platform as each plays a critical role.

 

  • The Procella Platform has multiple hierarchies designed to achieve your plan goals. At the apex sits the instance level (blue).  This is reflected in the figure below. The apex is a technical level, the Procella Instance, which contains central information such as the drug data, as well as the production and test areas for you.  This level is not accessed by the standard user, this is typically accessible by the Technical Staff.
  • Some environment settings are established at this level including a default, instance brand class list.  The Brand Class List is a coded rule that classifies drugs as brand or generic.  This rule is used when the PBM level brand class rules do not encounter a match. 

  • The System Hierarchy (orange) is the next level of the platform and includes primarily reporting levels to best support your business objectives.
  • The Benefit Plan Hierarchy (green) controls the benefit design and is the next level.  This is where coverage, copays, adjudication rules are defined.
  • The most specific level of the hierarchy is the Member Level.  The member level defines those rules that specifically apply to the member.

System Hierarchy


Our system supports multiple PBMs.  This can be used to achieve various outcomes and management approaches.  For instance, if your company would like to separate different lines of business into “PBMs” or perhaps your company supports other PBMs, the option exists to create separate PBMs with different User Logins, separate rules are readily achievable.  Outside of the technical level of instance, PBM is the highest level.

 

The PBM level is the highest in the System Hierarchy.  Beneath the PBM are various levels that are primarily used for Reporting.  The levels, from the top down, are Sponsor, Carrier, Account, and Group.  The Group level has more functionality than the preceding levels and its Group ID is what the providers submit on the transaction claim.

 

While the System Hierarchy has the PBM at the pinnacle, we reference the system Hierarchy in its reverse order.  We do this because that is how the system views the hierarchy.  For instance, a Group is associated with one Account.  An Account is associated with one Carrier.  Therefore, what we represent in the platform is represented in the image below.

 

When it is time to associate a Group with a Benefit Plan, the association level is called, Group-Plan.  It is less of a hierarchy level and more of a bridge between the System Hierarchy and the Benefit Plan Hierarchy.  It is important to note that the Group can be associated with multiple Benefit Plans.

 

The Group-Plan association is accessed within the Group level.


Member Level

The Member Level, as it relates to claims processing rules, incorporates Prior Authorization, coverage overrides, exclusions, lock-ins, and lock-outs among other functions.

Client Services

The Client Services menu brings you to the System Hierarchy sub-menu.  There are many ways to establish your system hierarchy.  Consider that once you have established records, you cannot change the hierarchy associated.  As noted, when a Carrier record is associated with a specific Sponsor, that Carrier cannot change to a different Sponsor. Below is an example. 

Ratkaisiko tämä ongelman?