product composer system - pega community

Product Composer System

IMPLEMENTATION GUIDE

7.12

Copyright 2015 Pegasystems Inc., Cambridge, MA

All rights reserved.

This document describes products and services of Pegasystems Inc. It may contain trade secrets and proprietary information. The document and product are protected by copyright and distributed under licenses restricting their use, copying, distribution, or transmittal in any form without prior written authorization of Pegasystems Inc.

This document is current as of the date of publication only. Changes in the document may be made from time to time at the discretion of Pegasystems. This document remains the property of Pegasystems and must be returned to it upon request. This document does not imply any commitment to offer or deliver the products or services provided.

This document may include references to Pegasystems product features that have not been licensed by your company. If you have questions about whether a particular capability is included in your installation, please consult your Pegasystems service consultant.

PegaRULES, Process Commander, SmartBPM® and the Pegasystems logo are trademarks or registered trademarks of Pegasystems Inc. All other product names, logos and symbols may be registered trademarks of their respective owners.

Although Pegasystems Inc. strives for accuracy in its publications, any publication may contain inaccuracies or typographical errors. This document or Help System could contain technical inaccuracies or typographical errors. Changes are periodically added to the information herein. Pegasystems Inc. may make improvements and/or changes in the information described herein at any time. This document is the property of: Pegasystems Inc. 1 Rogers Street Cambridge, MA 02142 Phone: (617) 374-9600 Fax: (617) 374-9620 www.pega.com

Document: Product Composer System Implementation Guide

Software Version: 7.12

Updated: January 2015

http://www.pega.com/

CONTENTS

About this Document ..................................................................................................................... i Intended audience..................................................................................................................... i Guide organization .................................................................................................................... i Features ................................................................................................................................ 1-1 Technical overview................................................................................................................ 1-2

What is Already Set Up ............................................................................................................. 2-1 Introduction ........................................................................................................................... 2-1 Application rule ...................................................................................................................... 2-1 System administrator account ............................................................................................... 2-1 Ruleset hierarchy .................................................................................................................. 2-2 PCS classes .......................................................................................................................... 2-2 Work object naming conventions .......................................................................................... 2-6 Indexes .................................................................................................................................. 2-7 Work groups, workbaskets, and work pools ......................................................................... 2-7 Predefined operators and access groups ............................................................................. 2-9 Security ................................................................................................................................. 2-9 Predefined organizations, divisions, and units .................................................................... 2-11 PCS access groups defined per operator ........................................................................... 2-12 Predefined work parties ...................................................................................................... 2-18 Sample database model ..................................................................................................... 2-18 Portals ................................................................................................................................. 2-19

Benefit, Policy, and Policy Term Rules ..................................................................................... 3-1 Introduction ........................................................................................................................... 3-1 Benefit rules .......................................................................................................................... 3-1 Policy term rules .................................................................................................................... 3-2 Policy rules ............................................................................................................................ 3-2 Limit variations ...................................................................................................................... 3-5 PCS custom rule classes .................................................................................................... 3-12 PCS rulesets ....................................................................................................................... 3-17 Keys and important properties ............................................................................................ 3-17 Policy term rules details ...................................................................................................... 3-25

PCS Landing Pages .................................................................................................................. 4-1 Landing pages ....................................................................................................................... 4-1 PCS configuration ................................................................................................................. 4-1 Document generation .......................................................................................................... 4-10 PCS integration services ..................................................................................................... 4-14

Data maintenance ............................................................................................................... 4-15

Rules for Benefit Sets, Network, and Groupers ........................................................................ 5-1 Introduction ........................................................................................................................... 5-1 Benefit set rule ...................................................................................................................... 5-1 Network rule .......................................................................................................................... 5-1 Grouper rules details ............................................................................................................. 5-2 Benefit set rule details ........................................................................................................... 5-3 Network rule details............................................................................................................. 5-16

Intended audience This document describes the details for a Product Composer System (PCS) implementation. It is intended for anyone who is implementing or extending the PCS Framework.

Guide organization This guide contains the following chapters.

About this Document

Chapter 1: Overview Provides an overview of the framework Chapter 2: What is Already Set Up Describes what is set up in the system. Chapter 3: Benefits, Policy Terms, and Policy Term Rules

Describes benefits, policy terms, and policy term rules.

Chapter 4: PCS Landing Pages Describes PCS landing pages, configuration parameters, Integration Services, and data maintenance

Chapter 5: Rules for Benefit Sets, Network, and Groupers

Describes the rules for benefit sets, network, and groupers

Product Composer System Implementation Guide i

There is often an interpretation gap between what is sold for a healthcare insurance plan and the claim processing logic used to adjudicate the terms of the healthcare insurance plan contracted for an enrollment period. Product Composer System (PCS) provides a collaborative environment with one system for product, policy, and benefit configuration. PCS provides a single source of truth that creates an auditable connection between the documents used for Sales and Product design and the structures, codes, processes, and logic of the adjudication system.

The elapsed time from product design to benefit configuration can be months. PCS allows for the rapid deployment of new products and benefits as the market demands.

Features PCS is a healthcare solution designed to support product design, benefit loading, product setup, approval processes, and lifecycle management.

PCS unique capabilities are powered by Pega’s unified rules processing technology foundation. It is a single environment organically developed over 30 years with award-winning Business Process Management (BPM), Business Rules Engine, Dynamic Case Management, Predictive and Adaptive Analytics, and Decision Management capabilities. Key capabilities included in Pega’s unified platform are:

Multi-user, multi-channel enterprise single source product repository – Enterprise repository for product, policy, and coverage information with the capability to customize responses for members, providers, and brokers to provide information across multiple channels including web, social media, SQL, and direct access by applications.

Multi-level reuse of product information - When a health plan client requests customization to a base product, only the specific information changed by the client is captured and stored. All remaining data is reused from the base product. Maximizing reuse of product information reduces product data by over 80% and substantially reduces the time to load product and benefit information to backend systems.

Code group-driven healthcare terms – PCS mapping logic, authorization requirements, coverage notes, benefit descriptions, and inquiry information are based on configurable terms defined by standard healthcare codes. This eliminates interpretation errors and ensures traceable and auditable information, rules, and logic to all consumers and systems.

Wellness and incentive benefits - Support for non-medical benefits, including wellness, FitBits, guardrails in homes, smoking cessation, and so on.

Capabilities for managing large numbers of plans.

1

Overview

Product Composer System Implementation Guide 1-1

TITLE of INTERNAL DOCUMENT – Arial Bold 12 pt

Extended ability to set search, sort, and filter items according to category, line of business, and effective date

Enhanced capabilities for configuring product information: Cost Share Copay, Deductible, Coinsurance, Out-of-Pocket, Maximums, and Carryover

Capabilities for configuring benefit policy rules:

Coverage, exclusions, limits, authorization requirements and medical policy notes

Condition-based rules to allow cost share and policy variations relative variables such as place of service, provider specialty, bill type, diagnosis, and so on.

Extension point to enable client-specific customizations.

Export capabilities for product, policy, and benefit information.

Configurable approval processes.

Mass Update capabilities to propagate benefit set changes to from product template to product to plan.

Technical overview PCS consists of flows and processing that create custom rules within the Rule-HC-PCS- hierarchy for:

Coverage levels

Benefits

Benefit sets

Groupers

Policies

Policy terms

Networks

Product templates

Products

Plans

Plan bundles

These larger scale objects encapsulate required data and processing to fully describe saleable healthcare insurance products. The objects are both reusable and hierarchically composed to provide leverage over the enormous amount of data required to define insurance products. PCS employs work objects to define, save, and associate rules with one another, and saves these custom rules. PCS implements filtered selections for medical, dental, vision, and pharmacy for each of the custom rule definitions to ease tailoring. Each custom rule is designed and implemented for extensibility.



Benefits rules — Collect and contain all the healthcare code groups and code sets that define a benefit. This data, inherent in the benefit, is referred to as the benefit proper mapping data. Refer to the Healthcare Common Codes Implementation Guide for further details on code groups and code sets. Benefits also contain notes and optionally, wellness data.

Benefit set rules — Contain a set of benefits that are managed as a single unit. Benefit set rules can be selected for inclusion in product templates, and can be tested for benefit mapping conflicts for specific combinations of code sets. When benefits are included in a benefit set, they are locked to that benefit set and can only be changed after being copied to a new benefit set. Benefit set construction also allows you to define groupers. PCS employs benefit set testing functionality to test benefit mapping to claims matching logic.

Groupers — Group benefits within a benefit set. Changes to grouper properties permit the contained benefits to inherit those values. PCS implements two types of groupers - temporary and permanent. Temporary groupers can be created only within the context of a benefit set while permanent groupers are defined by a creation process. Permanent groupers are used to add benefits to a product template when the PCS configuration mode stipulates optional benefit sets.

Network rules — Represent the cost share levels associated with a provider network contracted to provide medical coverage for the benefit child items under the network. Networks in PCS are lightweight objects whose properties are expected to be obtained by interacting with an external system.

Product template rules — Contain definitions for various aspects of an insurance product and serve as templates for product creation. During product template construction, provider networks are selected together with the benefits each network covers. This process defines a product template tree structure of provider networks and their covered benefits. Within this structure, relevant insurance options and data are defined including: coverage levels, cost share range values, guardrail rules, and general documentation impacting the insurance product. The product template tree structure facilitates inheriting values from a parent node when values are not set on a specific network or benefit.

Product rules — Defined from product template rules to acquire their definitions and cost share selection ranges. During product creation, cost share selections are required for each network, and then the product tree is displayed to make other selections. Again, the product tree facilitates inheriting network values when none are defined in a specific benefit.

Plans — Define from products as group or individual type; relevant parties are defined accordingly. During plan configuration, you can edit the values. When edits are within acceptable ranges, approval is bypassed; otherwise there is exception processing to request approval.

Policy – Associations of policy terms that are linked to a benefit. Policy term configuration can be inherited by a product template or created within products or plans.

Policy Term - Policy term rules contain code set and code group mappings covered by a benefit rule instance and a Note set, similar to benefits. Policy terms are a component of



policy rules. Once a term is included in a policy rule, it can be configured for variations in Coverage, Exclusions, Limits, Authorization, and Medical Policy.


Introduction This chapter describes what is already set up in the framework, including:

Application rule

System administrator account

Ruleset hierarchy

PCS classes

Work object naming conventions

Indexes

Work groups, workbaskets, and work pools

Predefined operators and access groups

Security

Predefined organizations, divisions, and units

Predefined access roles and privileges

Predefined work parties

Sample database model

Portals

Application rule The application record is HC_USA_Product_Composer • 07.12.01. This application is built on PegaHC 07.12.01.

System administrator account As installed, PCS includes the PCS application. You can access the application using the operator ID listed below, which is the default system administrator account. The password for this operator ID is install.

Application Access Group System Administrator ID HC_USA_Product_Composer 07.12.01 HC-USA-PCS:Administrators Administrator@PegaPCS

Although usernames are not case-sensitive, passwords are case-sensitive.

2 What is Already Set Up



Ruleset hierarchy To view a list of the rulesets in PCS, select DesignerStudio > Application > Structure > RuleSet Stack. The RuleSet Stack tab displays the high-level ruleset stack for each application rule defined in PCS.

PCS classes The PCS classes are:

Index classes

− Index-HC-PCS-BenefitMapping

− Index-HC-PCS-BenefitSet

− Index-HC-PCS-Contract

− Index-HC-PCS-ContractDelta

Index-HC-PCS-RuleLanding pages classes

− Data-Portal

Data classes

− PegaPCS-Data-



− PegaPCS-Data-Bundle

− PegaPCS-Data-Claim

− PegaPCS-Data-ClaimTestProps

− PegaPCS-Data-ClaimTestResult

− PegaPCS-Data-Config

− PegaPCS-Data-Contract

− PegaPCS-Data-Copy

− PegaPCS-Data-Dictionary

− PegaPCS-Data-ExportData

− PegaPCS-Data-PolicyCache

− PegaPCS-Data-Party

− PegaPCS-Data-Party-Broker

− PegaPCS-Data-Party-Insurer

− PegaPCS-Data-Party-PlanSponsor

− PegaPCS-Data-Party-Subscriber

− PegaPCS-Data-Party-TPA

− PegaPCS-Data-Setting

− PegaPCS-Data-UnionData

− PegaPCS-Data-Plan

− PegaPCS-Data-MUChangesBacklog

− PegaPCS-Data-MUChangesErrorLog

Work Classes

− PegaPCS-HC-USA-Work

− PegaPCS-HC-USA-Work-Accelerator

− PegaPCS-HC-USA-Work-Accelerator-Benefit

− PegaPCS-HC-USA-Work-Accelerator-BenefitSet

− PegaPCS-HC-USA-Work-Accelerator-Bundle

− PegaPCS-HC-USA-Work-Accelerator-BulkUpdate

− PegaPCS-HC-USA-Work-Accelerator-CoverageLevels

− PegaPCS-HC-USA-Work-Accelerator-Grouper

− PegaPCS-HC-USA-Work-Accelerator-Network

− PegaPCS-HC-USA-Work-Accelerator-Policy



− PegaPCS-HC-USA-Work-Accelerator-Term

− PegaPCS-HC-USA-Work-Commercial-

− PegaPCS-HC-USA-Work-Commercial-Medical

− PegaPCS-HC-USA-Work-Commercial-Compare

− PegaPCS-HC-USA-Work-Commercial-Quote

− PegaPCS-HC-USA-Work-Commercial-Medical-Contract

− PegaPCS-HC-USA-Work-Commercial-Medical-PTemplate

− PegaPCS-HC-USA-Work-Commercial-Medical-Product

− PegaPCS-HC-Work

− PegaPCS-HC-Work-Accelerator

− PegaPCS-HC-Work-Accelerator-Benefit

− PegaPCS-HC-Work-Accelerator-BenefitSet

− PegaPCS-HC-Work-Accelerator-Bundle

− PegaPCS-HC-Work-Accelerator-CoverageLevels

− PegaPCS-HC-Work-Accelerator-Grouper

− PegaPCS-HC-Work-Accelerator-Network

− PegaPCS-HC-Work-Accelerator-Policy

− PegaPCS-HC-Work-Accelerator-Term

− PegaPCS-Work

Embed Classes

− Embed-HC-PCS-

− Embed-HC-PCS-Accumulator-

− Embed-HC-PCS-Benefit-

− Embed-HC-PCS-BenefitConflict-

− Embed-HC-PCS-BenefitSet

− Embed-HC-PCS-Condition-

− Embed-HC-PCS-ConsumerNote-

− Embed-HC-PCS-ContractDelta-

− Embed-HC-PCS-CostShare-

− Embed-HC-PCS-Coverage-

− Embed-HC-PCS-CoverageLevel-

− Embed-HC-PCS-CoveredIf-



− Embed-HC-PCS-DOIData-

− Embed-HC-PCS-Exclusion-

− Embed-HC-PCS-Grouper-

− Embed-HC-PCS-Guardrail-

− Embed-HC-PCS-GuardrailRule-

− Embed-HC-PCS-IDCard-

− Embed-HC-PCS-Instructions-

− Embed-HC-PCS-InsuranceType-

− Embed-HC-PCS-Limit-

− Embed-HC-PCS-MapData-

− Embed-HC-PCS-Mapping-

− Embed-HC-PCS-MarketType-

− Embed-HC-PCS-Method-

− Embed-HC-PCS-Network-

− Embed-HC-PCS-Pricing-

− Embed-HC-PCS-PolicyCacheEntry-

− Embed-HC-PCS-PolicyTag-

− Embed-HC-PCS-ProductLine-

− Embed-HC-PCS-ProviderTaxonomy-

− Embed-HC-PCS-RangeValues-

− Embed-HC-PCS-Regions

− Embed-HC-PCS-TestBenefitSet-

− Embed-HC-PCS-Validation-

− Embed-HC-PCS-Variation-

− Embed-HC-PCS-Variation-Limit-

− Embed-HC-PCS-Variation-Den-

− Embed-HC-PCS-Variation-Med-

− Embed-HC-PCS-Variation-Rx-

− Embed-HC-PCS-Variation-Vis-

Rule Classes

− Rule-HC-Policy

− Rule-HC-Term



− Rule-HC-PCS-

− Rule-HC-PCS-Authorization

− Rule-HC-PCS-Benefit

− Rule-HC-PCS-Benefit-Den

− Rule-HC-PCS-Benefit-Med

− Rule-HC-PCS-Benefit-Vis

− Rule-HC-PCS-Benefit-Rx

− Rule-HC-PCS-BenefitSet

− Rule-HC-PCS-CoverageLevels

− Rule-HC-PCS-Grouper

− Rule-HC-PCS-Guardrail

− Rule-HC-PCS-Limit

− Rule-HC-PCS-Network

− Rule-HC-PCS-Policy

− Rule-HC-PCS-Product

− Rule-HC-PCS-UnionData

− Rule-HC-PCS-Validation

− Rule-HC-PCS-CostShare

− Rule-HC-PCS-Coverage

PCS also references classes belonging to the Health Care Industry Foundation (HCIF) and PegaX12.

Work object naming conventions The naming convention for the names of the flow actions and their sections are derived from the step being processed. For example, flow action for the Commercial, Medical, Product Template Tree Review is ComMedPTemplateTreeReview. The associated activities that occur before and after processing have pre- and post-suffixes. The Work type pyID prefixes are listed below.

Prefix Work Object Applies To BEN- Benefit PegaPCS-HC-USA-Work-Accelerator-Benefit BENS- Benefit Set PegaPCS-HC-USA-Work-Accelerator-BenefitSet GRP- Grouper PegaPCS-HC-USA-Work-Accelerator-Grouper PLCY- Policy PegaPCS-HC-USA-Work-Accelerator-Policy TERM- Term PegaPCS-HC-USA-Work-Accelerator-Term PLAN- Plan PEGAPCS-HC-USA-Work-Commercial-Medical-Contract



Prefix Work Object Applies To PRD- Product PEGAPCS-HC-USA-Work-Commercial-Medical-Product PRDT- Product Template PEGAPCS-HC-USA-Work-Commercial-Medical-PTemplate QUOT- Quote PEGAPCS-HC-USA-Work-Commercial--Quote BU- Bulk Update PegaPCS-HC-USA-Work-Accelerator-BulkUpdate

NET- Network PegaPCS-HC-USA-Work-Accelerator-Network CLEVELS- CoverageLevels PegaPCS-HC-USA-Work-Accelerator-CoverageLevels BUNDLE- Bundle PegaPCS-HC-USA-Work-Accelerator-Bundle

Indexes The following index classes and tables are used by PCS.

Class Name Table Name Usage Index-HC-PCS-BenefitMapping

pr_Index_HC_PCS_BenefitMapping Indexes code group mapping information for stand-alone benefits (Definition ) and product templates (Coverage Mapping and Non-Coverage Mapping)

Index-HC-PCS-BenefitSet

pr_Index_HC_PCS_BenefitSet Not used

Index-HC-PCS-Contract pr_Index_HC_PCS_Contract Not used Index-HC-PCS-ContractDelta

pr_Index_HC_PCS_ContractDelta Not Used

Index-HC-PCS-Rule pr_Index_HC_PCS_Rule Index class for storing indices for PCS rules, e.g. benefit indices for a product template etc.

Work groups, workbaskets, and work pools Work groups PCS includes the work groups shown below.



Workbaskets PCS includes the workbaskets shown below.

Work pools The PCS default work pool is PegaPCS-HC-USA-Work.



Predefined operators and access groups PCS 7.12 simplifies the usage model by striving towards a product development configuration environment for healthcare insurance artifacts. As such, most users and their respective portals are deprecated. Underwriting, State Mandate Specialist, Legal Advisor users are still available in support of their respective approvals. Approval flow actions are now optional and hidden by default within Product Template creation, refer to the PCS Configuration section - SELECT APPROVAL'S NEEDED IN TEMPLATE,PRODUCT AND PLAN where check boxes may be selected to expose the approval assignments in respective flows.

PCS includes the operators and access groups listed in this table.

Security Each Access Role to Object rule in PCS contains the privileges listed in the following screenshot. Privileges are named after starter flow processes. For example, the CreateBenefit privilege can be used to secure the CreateBenefit flow. Since each portal has links to the starter flows accessible for that user, the flows are not protected by privileges.

Operator ID Access Group Administrator@PegaPCS HC-USA-PCS:Administrators

ProductDevelopment@ PegaPCS HC-USA-PCS:ProductDevelopment ProductManagerPCS@MyHealthPlan HC-USA-PCS:ProductManager

LegalAdvisorPCS@MyHealthPlan HC-USA-PCS:Legal StateMandateSpecialist@MyHealthPlan HC-USA-PCS:StateMandateSpecialist UnderwriterPCS@MyHealthPlan HC-USA-PCS:Underwriting



For each user, an Access Role to Object rule is defined with the above privileges. The access level is always set to 5 – Production access.



Predefined organizations, divisions, and units PCS uses the organization’s structure, shown below, from HCIF. Refer to the HCIF documentation for further details.



PCS access groups defined per operator PCS provides the following access for each of the user Operator IDs defined within PCS 7.12. In general, the security access for each user listed in the table above is far too large to provide here. The following screenshots provide an indication of the access each user has.

HC_USA_Product_Composer:Administrator



HC_USA_Product_Composer:ProductDevelopment



HC_USA_Product_Composer:ProductManager



HC_USA_Product_Composer:Legal



USA_Product_Composer:StateMandateSpecialist



HC_USA_Product_Composer:Underwriting

Predefined work parties PCS defines the following work parties used within the Create Plan flow:

Group: Third Party Administrator, Insurer, and Broker

Individual: Plan Sponsor / Subscriber, Insurer, and Broker

Sample database model PCS comes with an industry-standard sample database. You can use this sample database model as delivered without additional configuration, or you can add or modify the data to meet your needs.

See the Help system or the PDN for information about how to view and modify the database schema.



Portals PCS has two portals used predominantly within the PCS usage model:

Product Manager

Product Development

Product Manager portal This portal enables monitoring of resolved activities, work volumes, worklists, workbaskets, execution of reports, and final approval of work objects. PCS has three categories of reports:



Panels within the portal are the explorer review list, recently open items, the team worklist sorted according to SLA, the Pega pulse, work per team member and workbaskets. The manager permits easy access to:

PCS References

PCS Work Analysis

PCS Work Monitoring

Product Development portal This portal enables the creation and update of all PCS components including the configuration of the PCS development environment using the PCS Configuration page.

PCS 7.12 composes objects with the following cardinality, hierarchy and data acquisition model:

1 Plan Bundle 1..N Plans

1 Plan 1 Product

1 Product 1 Product Template

Product Template hierarchy

1..N Networks

♦ 1 Benefit Set

1..N Groupers

1..N Benefits

♦ 1..N Benefits

♦ 1..N Groupers

Policy and policy terms are associated with benefits or may be defined in place for templates, products, and plans.

In addition, users of this portal can instigate Mass Update where structural Benefit changes to the benefit set are propagated to product templates, products, and plans that consume the benefit set.


Benefit rules Benefit rules are configured with metadata, mapping, and notes, after which the benefit is reviewed and submitted for approval. Benefit mapping specifies the codeset and codegroup mappings that describe the medical services and products covered by this benefit rule instance. This optional functionality is activated when BenefitMappingMode is set to True in the PCS Configuration. A benefit also includes separate note tabs to further describe the benefit. Note information includes:

Summary plan description

Member services

Provider services

Web services

Summary of benefits and coverage (SBC) description

3

Benefit, Policy, and Policy Term Rules

Introduction Benefits are defined to include sets of code groups that make up the benefit definition as well as general parameters that describe the benefit such as its name, effective date, and end date.

Policies and policy terms are the covered indications, limits, guidelines and authorization requirements associated with a benefit. Both ultimately determine how and whether a benefit is covered during claim adjudication. Two styles of policy configuration are available in PCS:

One where the policy is defined for a benefit outside the product definition

Another where the policy is defined within the context of a product

The former provides for the policy applied to the benefit anytime the benefit is used. The second style is applied specifically to the benefit as used within the specific product. In either case, the policy must be saved during the creation of the template, product, or plan to acquire the benefit’s policy configuration, after which configuration adjustments are possible.

This chapter provides technical details and includes the procedures for:

Creating a benefit

Creating a term

Creating a policy



You can configure the number and titles of note pages in the PCS Configuration. For more technical details, refer to Benefit rules details later in this chapter.

Policy term rules Similar to benefits, policy term rules also contain code sets, code group mappings, and notes that are then associated with a benefit rule instance. Policy terms are a component part of policy rules. Once you associate a policy term with a policy rule, you can configure it for variations in Coverage, Exclusions, Limits, Authorization, and Medical Policy.

For technical details, refer to Technical details about policy rules later in this chapter.

Policy rules Policy rules contain a collection of policy term rules that are related through the benefit selected in the policy configuration. Policy rules also include one or more associated product lines: HMO, POS, PPO, Indemnity, ACO, MediGap, and others. As a policy is defined, all associated policy term rules associated with the same benefit become the components of that policy, thereby allowing specification of Coverage, Exclusions, Limits, Authorization and Medical Policy for each term. Terms within the policy support policy variations to accommodate changes under various conditions.

As the policy is saved, policy cache entries are created for each product line and policy type for the specified benefit as a node-level declare page. Although the data is collected in PCS, it is no longer used because the benefit flat list replaced the summary view of the product tree.

Further technical details are provided in Policy rules.

Policy variation types The same Policy Variation types are used throughout PCS whether defined in a policy rule or during product construction. Note that pharmacy benefit conditions are more specialized offering several drug-related options. Below, the conditions for an Rx benefit are shown for a coverage variation.



Coverage variations Coverage variations and all variations use the class Embed-HC-PCS-Variation-. Embedded within the variation class is the Embed-HC-PCS-Condition- class, a Conditions page list. All PCS policy variation pagelist properties are implemented in the Rule-HC-Term class and include the following:

Coverage variations

Exclusion variations

Limit variations

Authorization variations

All other benefit types have the following condition selections. Values vary depending on the condition type selected.



Exclusion variations Exclusion variations, identical to coverage variations, comprise a page list in the Embed-HC-PCS-Variation- class which contains exclusion conditions defining excluded from coverage criteria.



Limit variations LimitVariations, embedded within a policy term, have the same embed page list structure discussed previously for conditions. However, PCS 7.12 LimitVariations have improved limit type properties, calculation methods, and benefit step-down logic. Below is the LimitFixed clipboard structure, which, largely unchanged, holds the additional properties supporting the enhancements.



For Limit Comparisons, two individual limits are compared using these operators.



Authorization variations PCS 7.12 has substantial enhancements to the Authorization Variations page. The AuthorizationVariations page list clipboard structure holds the newly added properties as shown below.



The clipboard structure for Policy / Terms / Authorization Variations is shown below.

Medical policy notes MedicalPolicy and NotePage comprise a two-level embedded page list structure (shown below) in the Embed-HC-PCS-ConsumerNote- class, where MedicalPolicy holds a list of note types and the second-level NotePage contains a list of the edited content. Except for groupers, which use .ShortDescription for Notes), all other notes are derived from Benefit Consumer Notes on the PCS Configuration page.



Claim instructions ClaimInstructions are an embedded page list throughout PCS (show next) on a Policy / Term page. The PegaPCS-Data-Config class holds the user-configured claim pend instructions per policy type per variation.



Each page within the Claim Instructions list contains the following page list property of the Embed-HC-PCS-Instructions- class where each Instruction page instance identifies an event, the associated variation, and the pend instruction selection for that variation, based on the configurable conditions listed below:

CoverageInstructions

ExclusionInstructions

LimitInstructions

AuthorizationInstructions

Coverage Claim Instruction



A clipboard screen shot of an example of a pend instruction for a limit variation is shown below in a pre-configured state.

The event property values for instructions are dynamic and originate with the corresponding Variation Rule Description value configured. Below, the LimitVariation is configured in the CreatePolicyScreenFlow.

The ClaimInstructions list is data structure derived from the Claim Systems list on the configuration screen. Values for the Claim Systems appear on the PCS Configuration landing page.



PCS custom rule classes Since PCS 2.3SP2, benefit classes are specialized to accommodate differences in various categories of benefits: Medical, Dental, Vision, and Pharmaceutical. Most categories (Medical, Dental, and Vision) inherit from the previously defined Rule-HC-PCS-Benefit class. Pharmaceutical benefits, however, require special handling for selections, descriptions, and configuration of Benefit Variation Conditions. The Rule-HC-PCS-Benefit-Rx class is defined to hold these differences. For consistency and future expansion, all benefit rule class names have an added suffix: -Med, -Den, -Vis, and -Rx.

The following shows the PCS class pattern hierarchy.



Generally, PCS rule classes inherit from the Rule-HC- and Rule-HC-PCS- classes. Policy and Term custom rules have a different usage scenario, so a separation was implemented for their class inheritance, the Rule-HC- class for both pattern and directed inheritance.

UnionData is a new addition to the PCS family of classes. During development, when simulating expected client component volumes, the clipboard data was so massive in a template, product, and plan processing that special handling was needed to address performance issues to achieve usable page transitions. UnionData data objects (PegaPCS-Data-UnionData) and rules (Rule-HC-PCS-UnionData) are used to reduce the weight of the product tree to get acceptable performance. UnionData structures use the UnionDataObj key, which is unique for the embedded pages of each node in the product tree. Actually, ProductTemplate uses the UnionDataObj key, Product uses the PUnionDataObj key, and Plans use the CUnionDataObj key.

PCS custom rule keys PCS custom rules originated using five key properties: Name, ProductCategory, pyClassName, LOBOffering, and EffectiveDate. Each unique instance of a PCS custom rule has unique values for each of the rule keys. Incidentally, the pzInsKey property is a concatenation of the rule key values and a system date time. Specifically, ObjOpen uses rule key values and uses rule resolution to obtain the object. ObjOpenByHandle requires the pzInsKey and opens the specific object identified by it.

PCS began using rule resolution during composition and various selection scenarios; but as business requirements unfolded with more customer usage, rule resolution access gave way to the need for more specific controls. A first requirement for custom rules was that they could be developed iteratively. Update flows were crafted from the create flows, and custom rule keys were frozen and replaced with user accessible properties. The Name key was created uniquely on create and frozen during update while AliasName was created allowing users to customize it. ProductCategory key was frozen to Medical, allowing users to select Category and Subcategory to align objects to Medical, Dental, Pharmaceutical, and Vision categories. The pyClassName property was frozen to PegaPCS-HC-USA-Work, the work object class for all PCS objects. LOBOffering was frozen to Commercial while LineOfBusiness was used to allow business functionality selection of values such as Commercial, Medicare, Medicaid, and others. EffectiveDate is still a user-defined key and suffices users to specify service dates for objects.

Given the consistency of rule key settings, PCS custom rules require a unique Name and EffectiveDate properties to save unique rule instances. PCS validations also ensure a unique Name and non-overlapping EffectiveDate and TermDate values when saving rules of the same type. For example, an Acupuncture benefit 1/1/2013..1/1/2014 can conflict with another Acupuncture benefit definition of 1/1/2014..12/31/2014 because of the overlapping 1/1/2014 date.

Pending-Approved Draft and Pending-Completion work objects PCS 7.12 has changed its Draft rule processing and now implements Pending-ApprovedDraft and Pending-Completion rule processing. Draft rule processing operates as it did previously and saves custom rules with Pending-ApprovedDraft status when the rule is saved; but not in its



final state. Custom rules saved in Draft mode can be consumed by other objects. Custom rules saved with a Pending-Completion are saved, but not in their final state and are not available for consumption. Both Pending-Completion and Pending-Approved Draft rules are saved in the PCSWorkObjects workbasket where they may be retrieved by anyone with access to continue work.

PCS embed classes Shown below are PCS embedded classes. Some are employed less than in previous releases: BenefitConflict-, ContractDelta-, Coverage-, CoveredIf-, IDCard-, PolicyCacheEntry-, and ProviderTaxonomy-. Other classes have been added, contain new properties and added functionality. Accumulator- is the primary example.



Shown above are the PCS embed classes. PCS has certain development rules to address inherent complexity – class names and clipboard structure of page lists are specific toward cardinality. In other words, plural names are used to indicate more than one of something and an embed class is used when something is contained within something else. This is done to emphasize that the work object contains a rule payload. After the manager approval, the work object process saves the rule payload. You can navigate to the class instances and see the database rule. This helps in debugging during implementation.



PCS work object classes

In the left pane above, under Accelerator are the classes and rules that provide the infrastructure for objects for PCS: Benefits, Groupers, Benefit Sets, and so on. In PCS 7.12 changes were made to the Networks, Groupers, and Coverage Levels classes to allow updates after creation, consistent with all other accelerator classes. Some classes such as Networks, Coverage Levels, and Groupers are used in structuring larger foundational objects such as



product templates. The right pane contains the inheritance hierarchy for the PCS principle objects: Product Templates, Products, and Plans.

In PCS 7.12, the Dental class hierarchy has been removed. Removed rules are backward-compatible through the use of the Deprecated rule status.

PCS rulesets Predominantly, the PCS functionality resides in the PegaHC-USA-PCS and PegaHC-PCS-Foundation rulesets. The foundation is layered within the Healthcare Industry Foundation (HCIF) to provide shared functionality and data structures with other Healthcare applications stacks on HCIF. As such, PCS 7.11 is built on PegaHC: 07-07-71, HCIF, and PCS 7.12 is built on HCIF 7.12.

PCS configuration is preset to create rules in the PegaPCS-SampleRules:07-12-02 ruleset and version. This ruleset version must be created and remain open as outlined in the Product Composer System 7.12 Installation Guide and the Product Composer System 7.12 Upgrade Guide.

Keys and important properties All PCS custom rules have rule keys listed below. As customers required the ability to change displayed properties, PCS rule keys were frozen with specific values and the displayed properties abstracted to allow customers to change their values. A name is generated as unique and the AliasName is exposed and can be changed. LOBOffering is frozen as Commercial and LineOfBusiness property is a user-definable replacement configured on the PCS Configuration page. ProductCategory is frozen as Medical and replaced by Category and SubCategory user-selectable values to align artifacts accordingly with Medical, Dental, Vision, and Pharmacy. The last key is pyClassName is PegaPCS-HC-USA-Work the work pool class.

Name

EffectiveDate

LOBOffering

ProductCategory

pyClassName

Default values for LOBOffering and pyClassName are specified on the Declare_PCSSettings data page and are used throughout to define PCS custom rules. Additionally, as mentioned, the PCS Configuration page affords the built-on application properties allowing definition of classes and flows, which replace PCS functionality.



PCS data pages

PCS data pages are shown next. Declare_CSSettings contains the configuration page properties. The following data pages are used to support the flat list D_BuildBenefitList and edit cost shares, policy, metadata, notes, and claim instructions for a benefit and grouper.



The Name key is always unique. It is generated by a call to GeneratePCSRuleName after the user data entry in the metadata screen is complete. The EffectiveDate is a required user data entry in the metadata screens. The Category key provides filtering during component selections throughout PCS, allowing you to compose the larger PCS objects from lists of similarly categorized items.

Although it is not a key property, AliasName is unique within the SampleRules, ruleset, and version. Duplicate AliasNames can exist within different ruleset versions. RuleSet and RuleSetVersion details accompany the saved rules saved to describe the ruleset where saved objects are referenced.



PCS custom rules are mapped to the PAGA.pca_rule_hc_pcs table in the PegaDATA database. In general, the classes used for custom rules follow pattern inheritance to the Rule-HC-PCS- class and direct inheritance to the Rule-PCS- class. An example of the Medical Benefit class mapping is:

Class Rule-HC-PCS-Benefit-Med is mapped to table PEGA.pca_rule_hc_pcs in database PegaDATA.

Benefit rules details The work object used for the CreateBenefit flow and CreateBenefitScreenFlow reside in the PegaPCS-HC-USA-Work-Accelerator-Benefit class. The benefit work object operates on a .Benefit property of the Rule-HC-PCS-Benefit class as its payload. The .Mapping embedded PageList property is used to record the CodeGroups and CodeSets contained. The .ConsumerNotes embedded PageList property contains note data entered for each of the Note tabs. While other properties are defined in the Benefit rule, these are populated within further processing of the benefit.

PCS flows CreateBenefit is the main flow. It calls CreateBenefitScreenFlow and saves the Benefit rule depending on ApprovalProcess. When benefits are approved in Draft mode, they move to the PCSWorkBasket. You can see this functionality within the ApprovalProcess detailed below. This is also true when a benefit is saved as Pending-Completion.



The CreateBenefitScreenFlow initializes a benefit based on whether you create a new one or copy an existing benefit.

To create a benefit:

1. Enter the Metadata.

2. Determine whether to map the benefits.

You optionally choose benefit mapping.

3. Enter appropriate notes.

4. Review the benefit, click Submit, and the CreateBenefit flow resumes.



Indexes A Benefit Mapping Index is generated during benefit construction. This index contains all combinations of CodeGroups entered in the benefit’s mapping structure.

An index of benefits within a BenefitSet rule is generated when a Benefit Set is saved. Benefits included in a BenefitSet rule have the IsLockedByBenefitSet flag set when the associated Benefit Set is saved. When locked, you cannot change the benefit; however, you can copy locked benefits and then modify them.



The .DefinedMapValues embedded page is loaded prior to saving the rule in the saveBenefitRule activity, so Index-HC-PCS-BenefitMapping contains the Benefit CodeGroups associations selected during benefit mapping. Several relationships in PCS use this correspondence between benefits and CodeGroup mappings. The MapIndicator value distinguishes them. For example, Benefit Mapping has MapIndicator equal to zero; other uses include CoverageMapping, NonCoverageMapping, and Authorization Mapping, which use successive values.

Benefits in PCS v7.12 are largely unchanged from previous releases of PCS. However, the Benefit MappingIndex does have two additional properties in 7.12: .PCSRuleSet and .PCSRuleSetIndex.

Embedded structure Below is a snapshot of the clipboard during a benefit work object review. Embedded XXXGroups pages contain configuration-driven, embedded pages used to hold various specifications for this benefit.

Embedded pages are:

AuthIfMappingGroups – Authorization specifications

CoverageMappingGroup – Coverage specifications

Exclusions – Exclusion specifications

MappingGroups – Code group or code set mappings

NonCoverageMappingGroups – Non-coverage specifications

ConsumerNotes – Note data entered by the user

DefinedMapValues - All unique combinations for MappingGroups



Policy term rules details The work object used for the CreateTerm flow and CreateTermScreenFlow is PegaPCS-HC-USA-Work-Accelerator-Term. The policy term work object operates on .Term Rule-HC-Term as its payload. Mapping embedded page lists are used to record the code groups and code sets contained.

Policy term flows CreateTerm is the main flow. It calls CreateTermScreenFlow and saves the term rule. Following the screenshot are the steps.



CreateTerm process The CreateTermScreenFlow subflow is called from CreateTerm. The process occurs as follows:

1. A set of screens is displayed for data entry or modification.

2. Once the information is entered, the work object is dispatched relative to update or create.

3. Draft work objects are approved and saved; completion objects are saved.

4. Approved draft objects are saved and routed to PCSWorkObject. If they are not approved, they are returned to the originator

The Create Term Screen Flow initializes terms, based on whether the term is new or existing.



To create a policy term:

1. Enter the metadata.

Choose whether you want to map terms.

2. Enter the appropriate notes.

The term is reviewed and the Create Term Screen flow resumes.

The title in the above diagram indicates that the work object used to create policy terms is PegaPCS-HC-USA-Work-Accelerator-Term. The subordinate flow used is Create Term Screen Flow.

Approval process The following approval process is used for most of PCS. Flows relying on this approval process require manager approval only.



The work object is sent to the Manager Approval assignment where the manager selects Approve, Draft Approval, or Reject.

If… Then... Approve The work object exits the flow with its work status set to Resolved-Available. Reject The work object status is set to Resolved-Rejected and is then sent to the end of the flow. Draft Approval The work object exits the flow with its work status set to Pending-Approved Draft and is

sent to the PCSWorkObjects basket.

Indexes Saving policy term rules spawns two index records in Index-HC-PCS-Rule through respective Declare Index rules: TermBenefitIndex and TermGrouperIndex. These indexes associate the benefit and possibly grouper key information for the benefit that was selected during the



creation of the term. An index of PolicyTerms within a policy is generated when a policy is saved.

Embedded structure Below is a snapshot of the clipboard during a term work object review:

Mapping Groups with all the defined CodeGroup mappings

CoverageMapping

NonCoverageMapping

SelectedBenefitRule contains key information for the benefit with which the term is associated

Technical details about policy rules You can configure new policy terms in the product tree for product templates and products on the fly.



Two Declarative Indexes are defined in Rule-HC-Policy that populates the Index-HC-PCS-Rule: PolicyTermIndex and PolicyFlagIndex. PolicyTermIndex relates policies and policy terms while the PolicyFlagIndex provides an indication that a policy term has a variation. All PCS index records are written to the Index-HC-PCS-Rule table.

The work object used for the CreatePolicy flow and CreatePolicyScreenFlow is PegaPCS-HC-USA-Work-Accelerator-Policy. The policy work object uses the embedded page property PolicyPage (Rule-HC-Policy) as the payload data used to create the policy rule. Embedded in the PolicyPage payload is the Terms (Rule-HC-Term) page list, containing the list of terms referenced by the policy and associated with the same benefit.

Flows Create policy flow CreatePolicy is the main flow; it calls the CreatePolicyScreenFlow and saves the policy rule.



Create policy process 1. The CreatePolicyScreenFlow is called to display a set of screens to enter or modify data.

2. Relative to create or update, the work object is routed for approval or for completion.

3. If completed, the rule is saved. If approved, the rule is saved. Otherwise, it is routed to the originator.

4. After being saved, the policy is routed to the PCS Work Object workbasket. If Resolved-Available, the flow ends.

CreatePolicyScreenFlow This flow provides a set of screens for you to navigate and enter data. There are two methods available for creating a policy:

Copy from an existing policy

Create a new policy

Copying an existing policy To copy an existing policy:

1. Search and select the name of the existing policy.

The selected benefit and term rules are all pre-loaded in the policy.

2. Navigate through the screens and customize them according to your needs.

Creating a new policy To create a new policy:

1. Select the benefit for which the policy applies.

2. Select one or more product lines.

3. Enter a unique name for the policy.

4. Enter the effective and end dates for the policy.

5. Complete information for policy terms for the selected benefit in the tabs:

− Policies – Add variation rules for Coverage, Exclusions, Limits, Authorization and Medical Policy.

− Claim Instructions – Enter Pend Instructions per Policy variation for various claim systems. Claim systems are defined in the PCS configuration.

The following shows a coverage variation defined in policies, thereby allowing a pend Instruction to be defined for the Facets claim system, defined on the configuration landing page.



6. In the Generate Document Assignment, enter text describing the policy. You can edit in Word.

This shows the CreatePolicyScreenFlow screen.



The ApprovalProcess flow is the same as the one already described for the policy term rule.

Indexes The Declare Indexes, PolicyFlagIndex, and PolicyTermIndex, previously mentioned, are defined in Rule-HC-Policy. An index record for each is created in Index-HC-PCS-Rule when the policy rule is saved and the declare index executes. This couples policy to variations defined and policy terms to the policy container.



Policy term index Terms are related to their policies using the term and parent properties within the index record. PCS uses this relationship in reporting and management of policies. Index-HC-PCS-Rule is the source for relating all PCS objects.



PolicyFlagIndex PolicyFlagIndex relates defined variations to the policy using the policy parent properties and for the benefit, it uses benefit-named properties. PCS uses this index to access Policy and PolicyTerm when configuring product template and product rules.

The previously described policy cache indicates that if anything is defined, the indexes provide access to the objects for detailed data.



Embedded structure The clipboard structure for a policy under construction is shown below. The .PolicyPage property containing a policy term with a Limit Variation for Gender and Place of Service Conditions is defined in the Policy Term – Place of Service condition, as shown. Several page lists within a policy term correspond to the data captured during the configuration of the policy term: its variations, the benefit, and claim instructions for the policy. These page lists are shown below.

When the policy is saved for product templates, products, and plans, the .PolicyPage class Rule-HC-Policy rule is created and its Union Data is saved and referred to with UnionDataKeys within the Rule-HC-Policy rule.


This chapter describes PCS landing pages including:

Landing pages

Configuration parameters

PCS Integration Services

Data Maintenance

Landing pages You access the PCS landing pages by selecting Designer Studio > Product Composer.

PCS Configuration

Document Generation

− Manage document template

− Glossary of terms

− Document-generation rules

PCS Integration Services

Data Maintenance

− Business Lines

PCS configuration PCS configuration is extensive, handling many aspects of PCS operation.

4 PCS Landing Pages



Details of the following configuration areas are described below.

You can save PCS configuration settings can be saved system-wide or on an individual user basis. If you save them system-wide, it affects all users. If you save them on an individual basis, it affects only the user saving the configuration settings.

Application settings Application settings are shown below.

Application Settings

Benefit Set Category

Tabs View

Approval Processing

Benefit Consumer Notes

Object Service Dates

Benefit Mapping

Client Configuration

Mass Update

Claim Systems

Cost Share Range

Work Class Names

Draft Mode Processing

Related Services

Line of Business

Benefit Mapping Groups

Mass Update Control Settings

Flow Names



PCS creates custom Pega 7 rules for the objects it creates. Therefore the ruleset version specified in the PCS configuration must be available and unlocked so that you can save the custom rules in the configured ruleset. Using the screenshot above, the application ruleset stack needs to include PegaPCS-SampleRules and version 07-12-02 needs to be unlocked to save created objects without errors.

Presentation and operational parameters The following option sets controls on both the presentation and functional operation of PCS.



Benefit mapping mode Optional: The Define Mapping for Benefits is bypassed, which means that there is no mapping

from benefits to code groups.

Required: The mapping for benefits is required.

Draft mode enabled True: Draft Mode processing is enabled allowing you to create objects iteratively. After you save

the custom rule payload, the work object is placed in a workbasket where you can retrieve it for further updating.

False: Draft mode processing is disabled.

Benefit set category True: Aligns selections in Products and Plans to the selected category in a component.

False: Category is optional with minimal influence on composition in products and plans.



Client configuration enabled True: Makes the Client Configuration tab visible, thereby allowing the editing and saving of

client specific configuration data.

False: Hides the Client Configuration tab and disables client specific configuration handling.

Enable related services True: Makes the Related Services tab visible within Cost Share Limits.

False: Hides the Related Services tab.

Enable tabs view True: Enables tabs within PCS.

False: Disables tabs within PCS

Process mass update option True: Makes the Process -> Mass Update path available within the Product Development

portal.

False: Hides the Mass Update processing path.

Line of business mode Optional: Line of Business is an optional feature within PCS.

Required: Requires the Line of Business configuration.

Approval parameters In PCS 7.12, intermediate approvals are optional. Intermediate approvals occur after the product developer finishes and clicks the Submit button, and before the Product Manager Approval assignment occurs. The approval assignments shown below are now optional.



Claim systems configuration This configuration makes the Claim Instructions tab visible during benefit configuration where specific instructions can be configured for each cost share type and claim system configured.

Resulting claim instruction tab

Code group configuration PCS code group configuration facilitates the customization of additional code group mappings for benefits.



Benefit consumer notes The Benefit Consumer Notes section customizes of the number and title of Benefit Consumer Notes.

Cost Share Range Maximum Number of Range Increments: The maximum number of increments added to the

amount range values, Single max range values, or Final max range values in cost-shares.



Mass update control parameters Maximum Number of MU Retry Count: The maximum number of Mass Update retries that

occur once the mass update fails.

Duration after Error MU Item Processed: The duration after which the Mass Updates fails in processing that the next Mass Updates occur.



Default effective and term dates

Work classes and flow names Work classes and flow names are not hard-coded in PCS. Rather, the names are loaded from PCS configuration page. This allows the implementation of rules within the layer cake to replace PCS rules and reuse PCS functionality implemented in the PCS layer.



Document generation The Document Generation landing page allows you to view and update rules that are used to generate document output such as the SPD or DOI Filing Document.



You can filter rules involved in document generation based on the document category. You can also select a certain rule type, such as word template, correspondence, paragraph, and section by selecting the check boxes and clicking Filter Document Rules. Select the document category and rule types to be used. The right section of the screen shows the results.



It has four columns:

Rule Name: Name of the rule.

Rule Type: Type of Pega 7 rule used.

Versions: A link showing the number of versions of the rule shown. Clicking the link displays all the versions.

Referenced By: References a particular rule if it is used in some other document category. This allows maintaining uniformity in case the rule is changed.

To create a new category:

1. Click the Create New Category link and enter the new category name and description.

2. Click Create Category.

Document rules tree This section allows the generation of the rules tree for templates (Rule-Template-Word) for different document categories. This tree gives a complete view of all rules making up the structure of the document, thereby streamlining editing. There are two sections. In the left



section, you can select the document category for which the Document Template tree needs to be generated. The right section shows the rules tree where the top parent for each entity is the word template. It has three columns:

Rule Name: Name of the rule.

Rule Type: Type of PRPC rule, which is used.

Description: Rule description.

To open any of the rules represented in the tree, right-click, and then click Open Rule.

Glossary of terms Clicking the Glossary of Terms tab on the Document Generation Rules screen displays the glossary of healthcare terms used to support external data consumers or documents such as the Summary of Benefits and Coverage (SBC).



PCS integration services When you access PCS Integration Services, the screen displays the PCS service rules. You can view and run these rules.



Data maintenance Line of Business configuration You can configure lines of business using this path.



Creating an application The first step to create a successful application is capturing the business process and design requirements of your project and application. Pega 7 allows you to directly capture objectives and turn them into executable software.

Direct Capture of Objectives To capture these details for your planned application, use the guided Direct Capture of Objectives (DCO) development tool — the Application Profile — to create an application profile for your application. The application profile for a particular application is a collection of



information that specifies the business processes, case types, use cases, requirements, and other processing elements associated with implementing your application. Using the application profile answers the question: What will we build?


Introduction This chapter describes the rules for:

Benefit sets - Defines a list of benefits that collectively map to the potential claims submitted to the health plan.

Networks - Supports product templates by delineating the various levels of coverage to which a benefit can be configured.

Groupers - Contains multiple benefits allowing you to organize benefits in a common medical area or across benefit accumulators.

Benefit set rule A benefit set contains a collection of benefits and groupers that are managed as a unit. The benefit set is the source of truth for subsequently derived objects: product template, product, and plans. The rule keys and AliasName collection of benefits and groupers within a benefit set are uniquely defined. A category selector enables and filters the benefit and grouper selections. Using the category selector, benefit sets can include a mixture of Medical, Dental, Vision, and Pharmacy categorized benefits and groupers.

As you add benefits to a benefit set, you can mark the benefit as optional or required. This activates your ability to designate whether the benefit is covered in the final composition of the product and its plan. Optional benefits can be covered or may not be covered. Required benefits must be covered. If the benefit set is approved as final, and not Draft, the IsLockedByBenefitSet flag for each benefit is set to True. You cannot modify a benefit, locked in this manner. However, you can copy and then modify a benefit.

For technical details, refer to Benefit set rule details.

Network rule PCS uses the Rule-HC-PCS-Network rules to represent a cost share level associated with the networks of healthcare providers contracted to provide medical coverage for the benefits within that network. Networks contain benefits and groupers using the @baseclass .ChildItem page list property of type $CLASS allowing any object to be a ChildItem of the network. Groupers hold a collection of benefits that inherit properties from their grouper parent.

The following illustration is a portion of a product template structure.

5 Rules for Benefit Sets, Network, and Groupers



Full networks are associated with benefit sets. Carve-out benefits are not and benefits (not groupers) are manually added one-by-one. Refer to the .BenefitSetTree property within the product template for further details.

Networks can also hold insurance data properties, such as cost shares, that can be inherited by contained groupers and benefits when those objects do not define those properties. Networks can also be added to this structure as Carve-Out networks. Carve-Out networks are not pre-populated with benefits, rather benefits are added to them individually.

Network objects are placeholders for network-specific data expected from an external source using a service. As a result, Rule-HC-PCS-Network rules are defined manually.

For technical details, refer to Network rule details.

Grouper rules details Groupers are container nodes that hold benefits. These container nodes allow their specification and data settings to be inherited by the benefits they contain. Grouper rules are implemented with the Rule-HC-PCS-Grouper rule, which is created and saved with the PegaPCS-HC-USA-Work-Accelerator-Grouper work object.

Creating a new grouper rule Three flows are used to manage groupers:

CreateGrouper



CreateGrouperScreenFlow

ApprovalProcess

CreateGrouper flow CreateGrouper initiates the CreateGrouperScreenFlow, changes the status to Pending-Approval, enters the Approval Process and depending on the Approval status, saves the Grouper Rule in the SaveGrouperRule activity.

Benefit set rule details The work object used for the CreateBenefitSet flow and CreateBenefitSetScreenFlow is PegaPCS-HC-USA-Work-Accelerator-BenefitSet. Continuing the payload theme, the benefit set work object uses the BenefitSet embedded Rule-HC-PCS-BenefitSet page property as its payload for all data used to create the BenefitSet rule. Benefit set rules contain two embedded pageLists, Benefits (Embed-HC-PCS-Benefit-) and .Groupers (Embed-HC-PCS-Grouper-), which contain the list of benefits and groupers referenced. Additionally a Benefit Set tree structure is contained within the embedded ChildItem tree structure. The ChildItem tree structure is copied into the product template during the build structure step creating templates.

A general theme implemented in PCS is to house various properties within pyWorkPage for easier access and simpler coding of activities and transforms. Then when you finish the construction work, move those pages into their final destination – usually the .BenefitSetTree property, which represents the HC insurance product.

Flows This section describes the flows for the benefit set rule:

Benefit Set Flow

Manager Approval

Mass Update Templates

Mass Update Approval Process

Mass Update Agents

Benefit set flow The following shows the flow for creating a benefit set. Following the graphic is a description of the flow.



1. The CreateBenefitSetScreenFlow flow is called to enter metadata and compose the BenefitSet rule with groupers and benefits.

2. Following the screen flow are shapes, which implement Pending-ApprovedDraft and Pending-Completion approval choices.

3. Essentially, all paths save the BenefitSet rule except when the work object is returned to the originator.

4. Approve final executes the benefit locking path.

5. During the Save Benefit Set Rule step, if you select the MUChanges property check box, a search for dependent product templates is performed. If it finds at least one product template, the benefit set is marked as Pending-MassUpdate.

6. After save, the Post Rule Save decision detects the decision to process Mass Update and enters the Mass Update subflow.

Otherwise, the approved BenefitSet is routed to the PCSWorkObject workbasket.



Creating a benefit set This shows the screen flow for the Create Benefit Set Screen flow. Following is a description of the screen flow.

To create a benefit set:

1. Enter the information in the Enter Metadata step.

If you select Copy From, the flow action copies benefits from another benefit set.

2. Select groupers and benefits; the selectable Category allows filtering.

3. The Test and submit flow action facilitates BenefitSet testing using the Detect Conflicts and Clear Results buttons.

Testing is done with activities in the Rule-HC-PCS-BenefitSet. Options are:

− Detect Conflicts: CallDetectBenefitMappingConflicts

− Clear Results

The Test and submit flow action requires that conflict detection occurs and test results appear.

Manager approval flow Approval processing used for BenefitSet is the same as that used for most PCS objects. However with MassUpdate processing, Pending-FinalProcessing and MassUpdateCancel are added.



The Manager Approval is shown below.

Action Work Status Result Approve Pending-FinalProcessing Resume flow in CreateBenefitSet. Reject Pending-Resubmission Resume flow in CreateBenefitSet. Return to Originator Open Resume flow in CreateBenefitSet. Draft Approval Approved-Draft Resume flow in CreateBenefitSet. MassUpdate Cancel MassUpdateCancel Resume flow in CreateBenefitSet.



MassUpdateTemplates flow The following screenshot shows the MassUpdateTemplates flow. Following the graphic is a description of the flow.

The following describes the process when you perform Mass Updates.

1. Enter the MassUpdateTemplatesScreenFlow.

The product development user selects the Perform Edits check box for each template to be updated.

Unchecked Perform Edits saves a record in the PegaPCS-Data-MUChangesBacklog class for later processing; and the work object status becomes Pending-MassUpdateBacklog.

That later processing is started with the Action menu item Mass Update Synchronize in product templates, products, and plans.



Rules involved are: StartMassUpdate, SaveBacklogMUChanges, HeaderActions, HeaderActionMenu, SyncWithBenefitSet, and SyncWithBenefitSetPre.

2. Enter the MassUpdateApproval step.

3. Enter the Mass Update Approved? step.

Action Work Status Result MassUpdate Pending-MassUpdate MassUpdate: Start Mass Update ToOriginator Open ToOriginator: Return to the Mass Update Templates Screen

Flow subflow.

1. Start Mass Update

a. Schedule date and time b. Is PerformEdit true?

- If yes, proceed to step c. - If no, call SaveBacklogMUChanges

c. Create Bulk Update work objects - Create or update per template - pyFlowName = MassUpdateTemplate - AddCoveredWork to BenefitSet cover - Bulk Update work objects processes MassUpdateTemplate and proceeds to finish

the Mass Update assignment in [email protected] workbasket, to be processed on or after their scheduled date time.

d. Save BenefitSet changes 2. Has Mass Update Started?

a. Is CoveredCount > 0 - If yes: Route BenefitSet to Mass Update Workbasket - If MassUpdateComplete: Proceed to End Mass Update - If no: Return to calling flow: CreateBenefitSet

The following shows Mass Update Templates Screen Flow.



1. Select the Update Actions flow action.

The Perform Edit check box lets you save the update in a MassUpdateBacklog record.

The Conflict Override check box allows you to override configuration data potentially. If checked, since BenefitSet Benefits and Groupers do not have configuration data, any configuration data encountered is removed. Otherwise the configuration data is preserved.

In either case of Conflict Override, the CopiedMode property indicates that the benefit or grouper is from the benefit set.

2. Review the Update Actions flow action.

3. Set Status to PendingMassUpdateApproval.

Mass Update Approval Process Flow The following shows the Mass Update Approval Process flow. Following the graphic is a description of the flow.



1. Manager Approval – The manager either selects or clears the Perform Edit check box for each product template. Clearing the Perform Edit check box causes the MassUpdateBacklog processing described earlier.

− Approve: Set Status to Pending-MassUpdate

− Return to Originator: Set Status to Open

− Reject: Set Status to Resolved-Rejected

2. End Mass Update Approval.

Mass Update Agent The Mass Update Agent properties are listed next to show how the agent executes relative to the other agents in the system.



Periodic Pattern

180-second Interval

Advanced Mode

Activity: MUFromBenefitSet

This rule form can only be viewed in Internet Explorer

MUFromBenefitSet The agent executes the MUFromBenefitSet activity specified within the Agent configuration, shown in the previous screenshot. MUFromBenefitSet executes the following algorithm in general to process the mass update work objects queued for execution.

The actual activity contains many more steps than the following; if you are working in this area; you need to approach it iteratively – it is complex and will take time. As a best practice, verify your results at each stage.

1. Call LogInfo.

2. The GetMUWorkList report collects the Bulk Update assignments for processing. It sorts MUDatetime from lowest to highest.

3. Has scheduled time occurred?

− Is CurrentDateTime > MUDatetime? If yes, execute ProcessAssignment. PerformFlowAction MassUpdateTemplate.

− If no, proceed to next list entry.

4. When there is an Error of Bulk Update processing, it creates a log entry.



5. MU Agent process finishes.

MassUpdateTemplate

From step 3 above, the MassUpdateTemplate flow action is executed and performs the following steps:

1. Completes the Finish Mass Update assignment.

2. Performs the Mass Update Edits.

a. Sets MUChanges(1).ChangeCodeStatus if Error b. Sets Work Status with Specific Error

3. Has Retry Exhausted: Yes, No



Actions Conditions: .MURetryCount >= Results Yes Configuration.MaxMURetryCount Route to Product Manager No Otherwise Continue flow

4. HasMassUpdateError: Yes, No

Actions Conditions: Work Status Result Yes Pending-MUErrorTargetNotFound Call HandleMassUpdateErrors Yes Pending-MUErrorWONotFound Call HandleMassUpdateErrors Yes Pending-MUErrorWONotOpen Call HandleMassUpdateErrors Yes Pending-MUErrorWONotSaved Call HandleMassUpdateErrors Yes Pending-MUErrorTargetNotSaved Call HandleMassUpdateErrors Yes Pending-MUErrorRulesetNotFound Call HandleMassUpdateErrors Yes Pending-MUErrorRulesetLocked Call HandleMassUpdateErrors No otherwise Continue flow

5. Route to the Product Manager if Error retries are exhausted.

6. Mass Update Errors – Enter HandleMassUpdateErrors subflow.

7. Update Status – Resolved-Completed

8. Update Cover Item – Pending-ApprovedDraft when pxCoveredCount==0

Indexes An index is created when the benefit set is saved by the saveBenefitSetRule activity. A Declarative Index (BenefitIndex rule) is defined in the Rule-HC-PCS-BenefitSet that populates the Index-HC-PCS-Rule. This index rule records which benefits are contained in which benefit sets.



Benefits are related to their benefit sets using the benefit and parent properties within the index record. PCS uses this relationship in reporting and managing benefit sets. The Index-HC-PCS-Rule is the source for relating all PCS objects. Index records are distinguished by Purpose and an Indicator property when the same declare index rule serves multiple purposes.



Embedded Structure The clipboard structure for a benefit set under construction is shown below. The .Benefits and .Groupers PageLists show the embedded structures for benefits and groupers selected while the ChildItem tree depicts their composition within the BenefitSet. Several pages are used for testing:

BenefitConflicts

TestMappings

When the benefit set is saved, the payload .BenefitSet of the Rule-HC-PCS-BenefitSet class is used to create the BenefitSet rule. The .Benefits embed PageList, class Embed-HC-PCS-Benefit-, is used to lock respective benefits.

Previously, groupers were not locked because draft versions of them could not be created. However, benefits contained within them are locked if the benefit set is approved as final. Currently, groupers can be updated. However, groupers are not locked during final approvals of a BenefitSet.

The BenefitSet .Benefits property, embedded pagelist contains all benefits composed within the BenefitSet, even those acquired by including one or more Groupers.

With Mass Update, the .MUChanges property is added.

Shown next is the clipboard structure portraying all of the above. MUChanges is shown since it is pivotal to Mass Update functionality.



Network rule details Creating a new network rule Previously, the CreateNetwork flow was added to PCS. Now, the create network flow has been enhanced to allow updating network rules.



1. Following the PCS theme, the CreateNetworkProcess subflow is called to configure metadata and notes for the network rule.

2. Relative to create or update, the approval subflow is called or the work object status is set to Pending-Completion.

3. The network rule is saved - Rule-HC-PCS-Network unless it is rejected and returned to the originator.

4. For Approved final, CreateNetwork ends.

5. After saving the rule, the work object is saved in the PCSWorkObject workbasket.

CreateNetworkScreenFlow All PCS create flows have a Create<Object>ScreenFlow. The following shows CreateNetworkScreenFlow.

1. Metadata for the network is entered and captured.

2. Notes are entered



Indexes Although Index-HC-PCS-Rule has entries for network, networks have no Declare Index rules where those properties are populated.

Embedded structure The following clipboard structure shows the data structure for a network. The BenefitSetTree .ChildItem properties form a hierarchy holding a product template in this case, three network rules, and the grouper and benefits for network (1) are displayed.

Union data Each node in the product tree has embedded data that only has meaning when that object is contained under its parent. Embedded data within the BenefitSetTree is referred to as union data since the data only has meaning when there is a union between the parent and child nodes. For performance reasons, union data is removed from the BenefitSetTree when it is not needed and restored when users edit or review it. Smaller clipboard means faster work objects.



UnionDataKey accesses the product template union data. PUnionDataKey references the product union data, and plans have CUnionDataKeys. (Plans were formerly contract objects - the important aspects of the software were converted where it made the most sense and offered return on investment)

Union data rules (Rule-HC-PCS-UnionData class) are created when one of the big three objects is saved (templates, products, or plans). The data, union data objects (PegaPCS-Data-UnionData class) are used during the edit phase (read, updated, and saved) but separate union data rules are created when the objects are saved. Making them rules provides greater leverage in packaging PCS artifacts during the export of the SampleRules rulesets. Rule instances also enable functionality such as the 7.12 enhancement of Reset to Original functionality to Restore Inheritance.

Another advantage of encapsulating all the embedded pages for a ChildItem node into a UnionData instance is that it is easy to accommodate adding or removing an embedded page. You can adjust the CreateUnionData / GetUnionData activities that create and retrieve the union data. They support the data acquisition model of the relationships between templates to products, and products to plans. Copy the product tree and then iterate the ChildItem tree structure saving node-level union data instances under different keys, and set the key properties appropriately in the ChildItem node. The UnionData instances must be separated; otherwise different product tree instances share their embedded pages.

In PCS 7 releases, union data handling was altered to employ the Pega 7 data page mechanism. The Benefit flat list is implemented on the clipboard using the D_BuildBenefitsList and each node type has a corresponding D_BenefitConfigurations, D_GrouperConfigurations, or D_NetworkConfigurations depending on the node type. CurrentEntityPage is used in opening a node for editing and has a copy of the node-level information. The following shows the clipboard while editing cost shares and policy on a Medical Benefit.



CurrentEntityPage.RelatedNetworks is used during Save Across functionality allowing node changes to be copied to the same benefit in other selected networks. D_BuildBenefitList.pxResults serves to render the benefit flat list with links used to open nodes for editing.

Union data key structure The following shows examples of UnionData keys for a product template, product, and plan (top to bottom). Notice that the property names are keyed to the type of object – UnionDataKey, PUnionDataKey, and CUnionDataKey. This supports copying of UnionData from one object type



to another to expedite configuration from template to products to plans, saving the same data instance under a new key.

Product template

Product

Plan

The keys themselves are crafted from the PegaPCS-Data-UnionData object type and then express the hierarchy of objects that the union data is found in by concatenating unique Name properties. For product template, the key structure is:

<PRDT…><NET…><BEN…> - benefit- level union data.

Product key structures are:



<PRD…><NET…><BEN…>

if benefit-level union data exists.

Finally, Plan key structures are:

<PLAN…><NET…><BEN…>

in CUnionDataKey. UnionData keys give you an absolute address for where the union data object resides in the product tree structure.



1. Being well behaved, the CreateGrouper flow calls the CreateGrouperScreenFlow to enter metadata and compose the list of benefits.

2. Again, relative to create (first time) or update (saved once), the work object follows an approval flow or Pending-Completion status. Mentioned briefly in a previous section, Pending-Completion allows iterating an object without fearing it being consumed in other objects.

3. After the approval subflow, the work object is returned to the originator if rejected. If approved either final or draft, the rule is saved. The rule is also saved for Pending-Completion.

4. After saving the rule payload, if approved final, CreateGrouper terminates. If Pending-ApprovedDraft, the work object is parked in the PCSWorkObject workbasket for another



ProductDevelopment operator to continue updating it. Pending-ApprovedDraft means that the rule is still being updated, but complete enough to be consumed by other objects.

CreateGrouperScreenFlow Rule The CreateGrouperScreenFlow is shown below.

1. Metadata for the Grouper is entered.

2. If Copy From another Grouper was selected during metadata, it’s processed in the Copy From Grouper step.

3. Benefits are selected for the grouper according to the metadata criteria entered.

Approval process rule PCS 7.11 Groupers did not support Draft mode; with PCS 7.12 Groupers can be updated; and have statuses Pending-ApprovedDraft and Pending-Completion. This functionality being implemented in the CreateGrouper flow means that the existing approval flow for the product manager is largely unchanged from previous releases – a minor status change.

The Product Manager is the only person to approve groupers. Three choices are available: Pending-Resubmission (was Resolved-Rejected where the work object is returned to the originator), Pending-ApprovedDraft, and Resolved-Available. When the manager returns the work object to the originator, the grouper has an Open status and the work object is sent to the originator’s worklist.



Embedded structure Shown next is the Embedded page structure for a Grouper being created. Its ProductCategory is Medical causing it to only allow the selection of Medical Benefits. Groupers support multiple Lines of Business (LOBs), so the embed structure shows that three LOBs were selected.



Indexes Groupers Rule-HC-PCS-Grouper define two indexes: BenefitIndex and GrouperIndex. Although similar, they contain slight differences used in the PCS GrouperIndex as shown below.



GrouperIndex



Benefit Index


product composer system - pega community

Documents