The Criteria Manager is where criteria are created and updated. But what is a Criteria in the Procella Platform. A Criteria is a set of fields and values used to create an equation. This outcome of the equation will indicate if an edit or process will occur. What does this really mean?
A Criteria, at its core, is a Condition made up of a simple expression. An expression includes an Attribute, an Operator, and a Value. In the example below, the attribute is the Multi-Source Code from the drug data. The Operator is an EQUAL sign [ = ]. The Value is Y.
- A set of one or more Expressions is a Condition. The condition is either an INCLUDE or EXCLUDE.
- A Criteria includes one or more prioritized conditions.
The search screen follows the standard search process as used throughout the system. Most searches are based on Criteria Name, requiring only partial text. The other search option frequently used is the STATUS, which allows Active, Draft, and Inactive.
Criteria Base
The base of the criteria includes the following elements and drive how conditions and expressions can be built.
Criteria Name: The Criteria Name is required to be unique within the PBM. The field allows 30 alphanumeric characters.
Effective Start: This is the earliest date for the criteria to be used.
Effective End: This is the last day the criteria will be effective.
Criteria Category: This drop down allows you to categorize the criteria. This does not restrict how you can use the criteria in the system.
Criteria Format: A criteria is designed around data. The identification of the various data elements is classified or categorized in Domains. Simply, a domain is a grouping or table of data. The options available in this drop down are Single-Domain and Multi-Domain.
A Single Domain Criteria format allows you to select one group of data. For example, a Drug Domain will have the fields that reflect the drug data.
A Multi-Domain Criteria format allows you to select 1 or more groups of data to define your criteria. This enables you to use various data elements to create complex conditions and expressions. For instance, you could use information on the claim being processed and the drug data to create complex rules.
So why aren’t Criteria always Multi-Domain? Some functionality within the system only allows you to use Single Domains. For instance, the Plan’s Benefit Coverage rule is limited only to Single-Domain criteria. In addition, single domain criteria are more high performing that multi domain criteria.
Expression
The expression is the most basic component of a criteria. At its most basic, an expression is a formula whose components include an Attribute with an Operator and the Value to match.
Attribute ID
The Attribute ID is the data element, or attribute, that you want to use in the condition. For instance, DEA Class is an attribute of the Drug Domain. Another common Attribute ID is NDC (national drug code).
When you access the Expression, clicking on the Attribute ID will open the Select an Attribute window. If the Criteria is a Multi-Domain criteria, select the domain where the Attribute is found. Then select the Attribute to use by clicking on ADD. For long lists, use the search to quickly find the attribute needed.
Operator
The Operator is simply the comparator that is used with the Attribute ID. While each Attribute ID has specific operators, common operators include:
- = (equal to)
- != (not equal to)
- >= (Greater than or equal to)
- < (less than)
- <= (less than or equal to)
- bgwt (Begins with)
- edwt (Ends with)
- cnts (Contains)
Value
The value is the heart of your condition. For instance, you may wish to have a condition that identifies only Brand drugs. The Attribute ID, GPI-10, and your value would be 5925001500 for Aripiprazole. Another example would be where you want to identify Single Source OTC drugs. The Attribute ID would be Rx/OTC indicator and the value would be O (Single Source OTC).
The expression below is another example. The expression simply states that an action will occur when the Multi-Source Code is equal to Y (generics). If the claim has a Multi-Source Code of N (or M or O), the claim does not positively qualify and therefore will advance to the next condition or criteria in the process.
If the expression positively qualifies (Multi-Source Code is equal to Y), the condition action moves ahead.
Multiple Expressions
Multiple expressions can be used through the use of Parenthesis and Conjugators. Below is a simple multiple-expression example. The multiple expressions compare the NDC11 of 49281072010 OR NDC11 of 49281072088. If the NDC on the claim is equal to either of the NDC Values entered, the claim satisfies the expression.
Another example of a multiple expression is below. This combination of expressions identifies the drug Ziprasidone but only ORAL forms of the drug.
As previously noted, one or more expressions create a Condition. In the upper left corner, the multiple expressions are presented in a formula approach.
Condition
A Condition is one or more expressions which, together, are set to INCLUDE or EXCLUDE. A condition set to INCLUDE will process, while an EXCLUDE will deny.
Completing the condition is the next step in creating the Criteria. A Condition is either an Include or an Exclude. Using the example above, Multi-Source Code = Y (generic):
When the condition is an INCLUDE and the claim positively qualifies through the condition’s expressions (in the example, if the claim is a generic (Multi-Source Code = Y), the claim should be included, and processing continues.
When the condition is EXCLUDE and the claim positively qualifies (in the example, if the claim is a generic Multi-Source Code = Y), the claim will be denied.
A simple way to consider the condition’s Include/Exclude is to consider that an INCLUDE will pay and an EXCLUDE to deny. This only occurs when the claim matches the criteria.
NOTE: Most Criteria are designed as an INCLUDE. There is still power in an EXCLUDE.
There is another outcome of the Criteria, a claim does not match, or meet, the criteria expression. For instance, if the Condition is set as INCLUDE and the expression is Multi-Source Code = Y, but the claim has a drug whose Multi-Source Code does not equal [ != ] a Y. Let’s say the drug has a multi-source code is an M-multisource brand.
When a claim is processed against criteria, there are 3 logical outcomes:
- INCL_MATCH: A Match Include means that the claim information satisfies the condition, and the Condition’s Include/Exclude indicator is set to INCLUDE.
- EXCL_MATCH: A Match Exclude means that the claim information satisfies the condition, and the Condition’s Include/Exclude indicator is set to EXCLUDE.
- NO_MATCH: A Match None means that the claim information did not satisfy the condition and the process will continue evaluating.
Multiple Conditions
There are scenarios that require multiple conditions. This occurs for business reasons or ease of maintenance.
In the example below, there are 3 conditions. These conditions are prioritized with 1 being the first condition evaluated then the second (2) and then the third (3). When the cursor hovers over the specific conditions, the elongated equal sign will appear. This allows the user to move the condition to the correct priority.
On the right side of the individual conditions there is an ⁞ ellipse. This provides two options for the condition. Remove condition will take the condition out of the Criteria. The Edit Condition option will open that Condition and allow changes to occur. The copy/Edit Expressions is introduced particulary to avoid the UI screen fail, when expressions are larger ( more than 6000 counts ). copy/Edit Expressions will open a text area where users can perform edit or delete of any kind of needed expressions without any UI fail.
Edit Condition
When the Edit window opens, the entire Condition is available to modify. Items to note on the example screen below:
- The Condition is set as an INCLUDE condition.
- The listed expressions are written out for easier reading.
- The first expression has an AND connection to the other expressions. In this case, any drug that has a Multi-Source Code of Y (generics) and meets the following expressions.
- The second line starts with an open PARENTHESIS.
- The GPI-14 expressions are connected to each other with ORs.
- The last expression does not have a connector.
The condition overall is looking at the claim to see if its Product Service ID (aka NDC11) reflects a GENERIC drug and is part of one of the listed GPI14 codes.
Copy/Edit Expression
When the Copy/Edit Expression window opens, the entire Condition is available to modify. Items to note on the example screen below:
- This option is available only for created criteria's ,we don't support Copy/Edit Expression option while creating a brand new criteria creation
- All expression should have 2 tab space intervals like the same how criteria batch load file format is available.
- Copy to clipboard is available on the top right side of the pop-up , total data in the window will get copied and user can edit/delete any counts of expressions by pasting it in excel or notepad based on user comfortability.
Domains and Attributes
The base of a criteria is the data it has access to. The data are called Domains and reflect common data elements. For instance, DRUG is a domain. This Domain would have data attributes that reflect drug data information. For instance, NDC11, NDC9, RX/OTC Indicator, GPI14, DEA Class Code, and Dosage Form are common DRUG domain attributes.
The system currently supports the following data domains:
- Drug: The attributes available are related to the fields in the drug tables.
- Claim: The attributes available reflect fields on the incoming claim.
- Provider: The attributes available are reflective of fields in the Provider data.
- Member: The attributes available are the member fields in the stored Member data.
- Claim History: The attributes are claim data from a Member’s claims history.
NOTE: Attributes are case sensitive for batch loads. Please refer to the Domain/Attribute listing.
Domain and Attribute detail are available in the Domain Information section below.
Criteria, Batch Load
The system also supports the batch file loading of a criteria. This is a critical item as Criteria are the basis of rules throughout the system. Any batch load process for Criteria should be undertaken with caution, testing, and verification.
Required Preparation
Batch loading a Criteria has certain requirements. First, the Criteria must be created in the UI manually. It may be in a DRAFT or ACTIVE status. All required fields, those before the conditions section, must be populated.
Once the Criteria has been saved, either as Draft or Active status, the Criteria ID is established.
The Criteria for which the batch file is to be loaded must be established in the target PBM. When a Criteria is created in the system, an ID is established. This value can be seen on the criteria in the upper right corner to the left of the status. In the example below, the Criteria ID is 610.
Domain Information
The following are the domains and attributes currently supported and available.
| Claim | BIN | Claim.bin |
| Claim | Cardholder ID | Claim.cardholderId |
| Claim | Carrier ID | Claim.carrierId |
| Claim | Claim End Date | Claim.claimEndDate |
| Claim | Claim/Reference ID | Claim.claimReferenceId |
| Claim | Claim Type | Claim.claimType |
| Claim | Compound Code | Claim.compoundCode |
| Claim | Coupon Number | Claim.couponNumber |
| Claim | Coupon Type | Claim.couponType |
| Claim | Coupon Value Amount | Claim.couponValueAmount |
| Claim | Date of Injury | Claim.dateOfInjury |
| Claim | Date of Service | Claim.dateOfService |
| Claim | Date Prescription Written | Claim.datePrescriptionWritten |
| Claim | Day of Service | Claim.dayOfService |
| Claim | Days Supply | Claim.daysSupply |
| Claim | Days Supply Intended to be Dispensed | Claim.daysSupplyIntendedToBeDispensed |
| Claim | Dispense as Written (DAW)/Product Selection Code | Claim.dispenseAsWrittenDawProductSelectionCode |
| Claim | Dispensing Status | Claim.dispensingStatus |
| Claim | Drug Coverage Status Code | Claim.drugCoverageStatusCode |
| Claim | DUR/PPS Level of Effort | Claim.durPpsLevelOfEffort |
| Claim | Eligibility Clarification Code | Claim.eligibilityClarificationCode |
| Claim | Formulary Compliance Code | Claim.formularyComplianceCode |
| Claim | Formulary Status Code | Claim.formularyStatusCode |
| Claim | Group Id | Claim.groupId |
| Claim | Level of Service | Claim.levelOfService |
| Claim | Month of Service | Claim.monthOfService |
| Claim | Other Coverage Code | Claim.otherCoverageCode |
| Claim | Patient Gender Code | Claim.patientGenderCode |
| Claim | Patient Relationship Code | Claim.patientRelationshipCode |
| Claim | PCN | Claim.pcn |
| Claim | Pharmacy Service Type | Claim.pharmacyServiceType |
| Claim | Place of Service Code | Claim.placeOfServiceCode |
| Claim | Preferred Drug Status | Claim.preferredDrugStatus |
| Claim | Prescriber ID | Claim.prescriberId |
| Claim | Prescription Origin Code | Claim.prescriptionOriginCode |
| Claim | Prior Authorization Number Submitted | Claim.priorAuthorizationNumberSubmitted |
| Claim | Prior Authorization Type Code | Claim.priorAuthorizationTypeCode |
| Claim | Product/Service ID | Claim.productServiceId |
| Claim | Professional Service Code | Claim.professionalServiceCode |
| Claim | Quantity Dispensed | Claim.quantityDispensed |
| Claim | Quantity Intended to be Dispensed | Claim.quantityIntendedToBeDispensed |
| Claim | Reason for Service Code | Claim.reasonForServiceCode |
| Claim | Result of Service Code | Claim.resultOfServiceCode |
| Claim | Service Provider ID | Claim.serviceProviderId |
| Claim | Service Provider ID Qualifier | Claim.serviceProviderIdQualifier |
| Claim | Submission Clarification Code | Claim.submissionClarificationCode |
| Claim | Year of Service | Claim.yearOfService |
| Drug | GPI-2 | Drug.GPI2 |
| Drug | GPI-4 | Drug.GPI4 |
| Drug | GPI-6 | Drug.GPI6 |
| Drug | GPI-8 | Drug.GPI8 |
| Drug | GPI-10 | Drug.GPI10 |
| Drug | GPI-12 | Drug.GPI12 |
| Drug | GPI-14 | Drug.GPI14 |
| Drug | NDC-9 | Drug.NDC9 |
| Drug | NDC-11 | Drug.NDC11 |
| Drug | Brand Name Code | Drug.brandNameCode |
| Drug | DEA Class Code | Drug.deaClassCode |
| Drug | Drug Descriptor ID | Drug.descriptorId |
| Drug | Dosage Form | Drug.dosageForm |
| Drug | Labeler ID | Drug.labelerId |
| Drug | Maintenance Drug Code | Drug.maintenanceDrugCode |
| Drug | Multi-Source Code | Drug.multiSourceCode |
| Drug | Name Type Code | Drug.nameTypeCode |
| Drug | PBM Brand Class | Drug.pbmBrandClass |
| Drug | Route of Administration | Drug.routeOfAdmin |
| Drug | RX-OTC Indicator Code | Drug.rxOtcId |
| Drug | Third Party Restriction Code | Drug.thirdPartyRestriction |
| Drug | Criteria | criteria_id |
| Provider | Dispense Class | Provider.dispenserClass |
| Provider | Provider Group Id | Provider.groupId |
| Provider | Name | Provider.name |
| Provider | Network Assignment | Provider.networkAssignment |
| Provider | Network Classification | Provider.networkClassification |
| Provider | Network External Network Assignment | Provider.networkExternalNetworkAssigment |
| Provider | Provider Parent Id | Provider.parentId |
| Provider | Provider Primary Type | Provider.primaryType |
| Provider | Provider Id | Provider.providerId |
| Provider | Reporting Network | Provider.reportingNetwork |
| Provider | Secondary Provider Type Code | Provider.secondaryTypeCode |
| Provider | Service Provider Id Qualifier | Provider.serviceIdQualifier |
| Provider | Source of Type | Provider.sourceOfType |
| Provider | State | Provider.state |
| Provider | Tertiary Provider Type Code | Provider.tertiaryTypeCode |
| Member | Account Id | Member.accountId |
| Member | Age | Member.age |
| Member | Cardholder Id | Member.cardholderId |
| Member | Carrier Id | Member.carrierId |
| Member | Country Code | Member.countryCode |
| Member | Coverage Effective Date | Member.coverageEffectiveDate |
| Member | Coverage Term Date | Member.coverageTermDate |
| Member | Date of Birth | Member.dateofbirth |
| Member | First Name | Member.firstName |
| Member | Gender | Member.gender |
| Member | Group Id | Member.groupId |
| Member | Language Name Code | Member.languageNameCode |
| Member | Last Name | Member.lastName |
| Member | Member Alias Id | Member.memberAliasId |
| Member | Member Alias Id Qualifier | Member.memberAliasIdQualifier |
| Member | Member City | Member.city |
| Member | Member Id | Member.memberId |
| Member | Member State | Member.state |
| Member | Member Zip5 | Member.zip5 |
| Member | Month of Birth | Member.monthofbirth |
| Member | Multi Birth Code | Member.multiBirthCode |
| Member | Person Code | Member.personCode |
| Member | Plan Id | Member.planId |
| Member | Primary Secondary Coverage Indicator | Member.primarySecondaryCoverageIndicator |
| Member | Relationship Code | Member.relationshipCode |
| Member | Sponsor Id | Member.sponsorId |
| Member | Year of Birth | Member.yearofbirth |
Criteria are designed to use data from various domains.
File Naming Convention
For the system to select and accurately load the batch file, the naming of the file is critical. Only one Criteria can be represented within the file. The file must be a tab delimited file with a CSV file extension.
Elements of the filename
The file name consists of 6 elements, each separated by an underscore (_). Below is the required format for a criteria batch load file.
<pbmid>_<jobtype>_<criteriaid>_<statusid>_<effectivestartdate>_<effectiveenddate>.csv
PBMID: This is the external PBM ID that represents the PBM where the criteria is to be loaded. At this time, this information is stored in the database. The Technical Team can identify the appropriate value to use. Each PBMID identifies one PBM in your environment. PBMID’s are different between the production environment and the UAT or Stage environments.
To find the PBMID to use, go to CLIENT SERVICE heading, PBM level. The PBM ID is in the upper right corner.
JOBTYPE: The job type identifies the processing job for the batch file. For Criteria batch loads, the JOBTYPE must be CRITERIA. Criteria must be in ALL CAPS.
CRITERIAID: This is the Criteria ID associated with the target Criteria. See Required Preparation above for identifying this value.
STATUSID: The Status ID value indicates if the batch load data is automatically ACTIVE based on the start/end dates or saved in DRAFT status. For ACTIVE, the value will be A. For DRAFT, the value will be D.
Effective Start Date: This value, in CCYYMMDD format, identifies the Effective Start Date of the Criteria with the batch load information.
Effective End Date: This value, in CCYYMMDD format, identifies the Effective End Date of the Criteria with the batch load information. A value is required here, and the end of time value of 99991231 can be used.
File Name Extension: The file extension must be CSV.
Below is a sample batch file name.
ACME_CRITERIA_610_A_20210101_99991231.CSV
This filename indicates the batch file is for a CRITERIA which is located in PBM ID 1, and updating Criteria ID 610, while setting the status as ACTIVE (A) with an effective start date of 1/1/2021 and an effective end date of 12/31/9999.
Data File Format
The format of the file is straight forward. There are two levels of the Criteria represented in the file format, Condition and Expression. Criteria can be a single condition with one or more expressions, or multiple Conditions with one or more Expressions.
The format of each line within the file begins with the record type identification. Either COND (condition) or EXPR (expression) is a valid value.
The delimiter between fields is a TAB. No other delimiters are supported at this time.
Each Criteria must have a Condition and an Expression. For the batch file, the Condition must precede the Expression information.
NOTE: Attributes are case sensitive. Please refer to the Domain/Attribute listing.
Condition
The options for the Condition are include or exclude. The values are straightforward, use I for an INCLUDE and E for EXCLUDE.
COND - This record type holds information like whether the condition need to be included or not. This records type should hold only: I or E.
Example:
COND<TAB>I<RETURN>
Expressions
The Expression setup has more elements just as it does in the UI.
EXPR - This record type holds all the expressions need to be included. It contains totally 6 values separated by TAB.
Example:
EXPR<TAB>leftparanthesis<TAB>attribute<TAB>operator<TAB>value<TAB>rightparanthesis<TAB>conditionaloperator<RETURN>
Conditional Operators
There are 2 conditional operators that may be used. One represents AND while one represents OR.
- || or a double pipe, reflects an OR.
- && or a double ampersand, reflects an AND.
Sample View
Below is a sample text view of a batch file. Note TAB and RETURN characters. Also, the COND record only has one TAB and a RETURN.
Example Record Set – One Condition, One Expression
The example data set below indicates the Condition as an INCLUDE and the expression is, from the DRUG domain, GPI14 equal to 99402020300130.
COND I
EXPR ( Drug.GPI14 = 99402020300130 )
Example Record Set – One Condition, Many Expressions
The example data set below indicates the Condition as an INCLUDE and multiple expressions. Each expression, except the last line, has an operator. In this case, the operator is ||, an OR.
COND I
EXPR Drug.NDC11 = 59148001870 ||
EXPR Drug.NDC11 = 59148001871 ||
EXPR Drug.NDC11 = 59148001970 ||
EXPR Drug.NDC11 = 59148001971 ||
EXPR Drug.NDC11 = 59148004580 ||
EXPR Drug.NDC11 = 59148007280
Example Record Set – Many Conditions, Many Expressions
The example data set below indicates multiple Conditions and multiple expressions. Each expression, except the last line, has an operator. In this case, both operators are in use, && (and) ||, (or).
COND I
EXPR ( Drug.NDC11 = 59148001871 ) ||
EXPR ( Drug.NDC11 = 59148001871 &&
EXPR Drug.NDC11 = 59148001970 ) ||
EXPR Drug.NDC11 = 59148001971
COND E
EXPR ( Drug.NDC11 = 59148001871 ) ||
EXPR ( Drug.NDC11 = 59148001871 &&
EXPR Drug.NDC11 = 59148001970 ) ||
EXPR Drug.NDC11 = 59148001971
COND I
EXPR ( Drug.NDC11 = 59148001871 ) ||
EXPR ( Drug.NDC11 = 59148001871 &&
EXPR ( Drug.NDC11 = 59148001970 ||
EXPR Drug.NDC11 = 59148001970 ) ||
EXPR Drug.NDC11 = 59148001971
NOTE: When parenthesis are used, they must be used in pairs. Also, operators are used between expressions. Therefore, no operator should be in the last line of any Condition. There is no operator connecting Conditions. Each condition stands on its own. The order of Conditions in the batch file is the same order as will be applied in the Criteria.
Data Management, Batch Load, Criteria
The Batch load setup is performed through the system. This setup will establish the parameters used for processing batch files. Go to Administration section of the system. Once in Administration, use the menu to access Data Management.
Data Management is where all batch process management will be established.
When accessing the Data Management window, you are presented with the standard search screen for established batch jobs.
NOTE: Batch jobs are available for claims extract, prescriber loads, and Criteria loads.
Data Management, Search
The Data Management Search allows quick searches using the available filters.
Job
A Job is either an Extraction (pulling data out of the Procella system) or a Load (putting data into the Procella system).
Job Type
The batch type is being searched. The batch types currently supported include Claims, Prescriber, and Criteria.
Job Name
The name associated with the Job when created. No spaces or special characters are allowed when creating a Job.
Job ID
The system assigned Job ID.
Status
The status of the batch job being searched. Active, Draft, and Inactive are all available statuses.
Effective Date
The Effective Date, as in other search screens, will allow you to search for records with an Effective Start Date on or before this Effective Date.
Create Batch Job
To create a Batch Job, click on the plus icon in the lower left corner of the screen. This will start the process of creating a batch job record.
First, identify the Job Type to be created. In this case, select Criteria. A blank template will open.
The Job Name will identify the Job. The Name supports only letters, numbers, and underscore. Spaces and special characters are not allowed.
Effective Start Date indicates when the batch job is effective and when it is put into the process. The Effective End Date is when the batch job will complete its last run based on the schedule. Remember, the End Date is a through date.
Job Configuration Details
Job Criteria indicates if this is a load or an extract.
Client Code is not supported for this type of batch process today.
Registration Code is system generated based on the job name and job ID. Registration Code will be created and auto-populated once the record has been activated.
Run Time Settings
The Runtime Settings instruct the Job to process at a predetermined period and time. Criteria have limited run time options. In addition, there is always the option to run the process as needed.
Schedule Run Time indicates the frequency of running the job. For Criteria, daily is the only option available.
UTC Time is defaulted to 2:00am UTC time for all Criteria Batch Jobs. Select Run Time Day is unavailable as it is a daily job.
Email is required and should be sent to the User or group email that should receive notification.
Input File Path is where the source data file is to be placed. This will be created and populated once the record has been ACTIVATED. To access the Input File Path, open the ACTIVE record and click on the Copy to Clipboard link.
Once the information has been entered and activated, the record will be put into the standard process.
Data Management, Job Menu
As with other search results in the Procella system, there are menu options available at the Batch Job level. Click on the ⁞ ellipse. The menu will present.
View Job Configuration presents the setup for the Job.
View Job Execution Details will list each Job result, providing the Job Run ID, the Job Execution ID, the Start Date/Time and the End Date Time, and the status of the job run.
Run/Load Now enables the user to execute the Job immediately.
Inactivate removes the Batch Job from processing. Once the batch job is inactivated, it can no longer be used or reactivated.
Data Management, Run Batch Now
The batch process runs automatically. There is the opportunity to run the batch process immediately. To run the process immediately, search for the Job to run in the Data Management search screen.
Click on the ellipsis icon and select Run/Load Now to run the job.
A confirmation window pops up. Select Run/Load Now to run the job
Once the Run/Load Now option is selected, the process will begin. Once the process has concluded, a notification will be emailed to the registered email.
For the process to run, a file must be available to process.
Batch Notification
The Batch notification will send the results of the Batch Job to the registered email. A sample email is provided below.
Data File Upload
The batch file upload is performed in AWS. The location to place the source data can be captured in the Batch Job under Input File Path. A Copy to Clipboard link is available for easy copy-paste.