Healthcare Appeals and Grievances Manager

IMPLEMENTATION GUIDE 7.4

© 2018 Pegasystems Inc., Cambridge, MA

All rights reserved.

Trademarks

For Pegasystems Inc. trademarks and registered trademarks, all rights reserved. All other trademarks or service marks are property of their respective holders.

For information about the third-party software that is delivered with the product, refer to the third-party license file on your installation media that is specific to your release.

Notices

This publication describes and/or represents products and services of Pegasystems Inc. It may contain trade secrets and proprietary information that are protected by various federal, state, and international laws, and distributed under licenses restricting their use, copying, modification, distribution, or transmittal in any form without prior written authorization of Pegasystems Inc.

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

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

Although Pegasystems Inc. strives for accuracy in its publications, any publication may contain inaccuracies or typographical errors, as well as technical inaccuracies. Pegasystems Inc. shall not be liable for technical or editorial errors or omissions contained herein. Pegasystems Inc. may make improvements and/or changes to the publication at any time without notice.

Any references in this publication to non-Pegasystems websites are provided for convenience only and do not serve as an endorsement of these websites. The materials at these websites are not part of the material for Pegasystems products, and use of those websites is at your own risk.

Information concerning non-Pegasystems products was obtained from the suppliers of those products, their publications, or other publicly available sources. Address questions about non-Pegasystems products to the suppliers of those products.

This publication may contain examples used in daily business operations that include the names of people, companies, products, and other third-party publications. Such examples are fictitious and any similarity to the names or other data used by an actual business enterprise or individual is coincidental.

This information is the property of:

Pegasystems Inc. One Rogers Street Cambridge, MA 02142-1209 USA Phone: (617) 374-9600 Fax: (617) 374-9620 www.pega.com

Healthcare Appeals and Grievances Manager

Document: Implementation Guide

Software Version: 7.4

Updated: April 2018

CONTENTS

Application overview .................................................................................... 1

Implementation delivery methodology ......................................................... 2

Initiate stage ..................................................................................................... 3

Plan ............................................................................................................. 3

Setup ........................................................................................................... 3

Prepare ....................................................................................................... 3

Delivery stage ................................................................................................... 4

Prerequisites .................................................................................................... 4

Initiate stage .................................................................................................. 5

Step 1: Creating the baseline application ...................................................... 5

Running the New Application wizard ....................................................... 5

Results of running the New Application wizard ...................................... 6

Step 2: Loading sample data .......................................................................... 6

Step 3: Performing the gap analysis .............................................................. 6

Generating the Application profile ........................................................... 7

Generating the application document ..................................................... 7

Generating the specification document .................................................. 7

Delivery stage ................................................................................................ 8

Defining requirements .................................................................................... 8

Step 1: Defining the case type modifications and attributes ....................... 9

Updating existing case types .................................................................... 9

Adding a new case type .......................................................................... 10

Mapping case type classes to a database table .................................... 11

Confirming case type locking setting ..................................................... 11

Step 2: Defining the data model ................................................................... 12

Pre-configured data types ...................................................................... 13

Step 3: Define complaint reasons ................................................................ 13

Step 4: Mapping the application data .......................................................... 17

Step 5: Defining integration .......................................................................... 17

Pre-configured REST APIs ........................................................................ 18

Step 6: Defining the security model and organization structure............... 19

Authentication schemes ......................................................................... 20

TITLE of INTERNAL DOCUMENT – Arial Bold 12 pt

Defining your authentication scheme ................................................... 20

Defining your access groups .................................................................. 21

Defining access roles and privileges ...................................................... 21

Defining the organization structure ....................................................... 21

Defining the operator attributes ............................................................ 22

Defining the operator work group ......................................................... 22

Defining the operator skills .................................................................... 22

Defining the operator calendar .............................................................. 23

Step 7: Customizing the user experience .................................................... 23

Designing the portals .............................................................................. 23

Designing application skin and styles .................................................... 24

Designing for screen performance ........................................................ 24

Step 8: Defining reporting requirements .................................................... 24

Building features ......................................................................................... 26

Step 1: Integrating data ................................................................................. 26

Step 2: Implementing the security model ................................................... 26

Step 3: Modifying the user interface ............................................................ 26

Determining which part of the user interface to modify ..................... 27

Locating the user interface element to change .................................... 27

Adding a new property to a section ....................................................... 27

Adding a new section .............................................................................. 27

Updating the skin .................................................................................... 28

Step 4: Creating reports ................................................................................ 28

Testing a new application ............................................................................. 29

Testing in the Build environment ........................................................... 29

Testing in the Test or Production environments .................................. 30

Testing in the UAT environment............................................................. 30

Packaging a new application ........................................................................ 31

Merging application changes .................................................................. 31

Packaging an application for migration ................................................. 31

Importing the packaged application ...................................................... 32

Production maintenance and monitoring ................................................ 33

Maintaining business rules in the production environment ..................... 33

Monitoring the application ........................................................................... 33

Pega Platform application health monitoring ....................................... 33

TITLE of INTERNAL DOCUMENT – Arial Bold 12 pt

Identifying and reporting issues ................................................................... 33

Pega Product Overview 1

The Appeals and Grievances Manager (AGM) application in the Pega® Foundation for Healthcare leverages the stage-based case management capabilities of Pega Platform to manage the complaints received from members and other interested parties (authorized representatives, providers, and third parties such as independent review entities). It provides the capability to create new cases (work objects) for two different types of complaints (appeals and grievances), and processes them through to resolution.

The following are the key features of AGM:

• Stage-based case life cycle using the Pega Platform Case Designer to showcase the Complaint (Appeal or Grievance) process. Each of these are configured as case types and stages are designed to describe each step or process beginning with the creation of the complaint and ending with the resolution of it. The parent case type is Complaint. Within it, you can create one or more Appeal and Grievance subcases.

• Grievance Management Workflows — Start-to-end process for managing member grievances. This process includes the creation of a grievance case, capturing required information including information about the requestor party and the grievance reason, assigning standard or expedited urgency status, and applying appropriate service levels to ensure timely processing.

• Appeals Management Workflows — Start-to-end process for managing appeals filed for denial of service or claim payment. Capabilities include the creation of an appeal case, capturing required information including information about the requestor party, appeal level, appeal category, service and or claim information, assigning an owner and standard or expedited urgency status, and applying appropriate service levels to ensure timely processing.

• Directed Web Access for External Users — A secure one-time link to the system sent to the provider who is the subject of a grievance to seek feedback on the issue when the grievance is related to providers or providers office staff (such as, appointments, staff behavior, and prolonged wait times). After the provider submits the required information, the process automatically resumes and is routed to the owner of the case for review.

• Service Levels, Routing, Prioritization, and Escalation — Tracking of each complaint case with priority assigned based on urgency status, type and level of complaint, and type of denial. Service level rules monitor goal and deadline times based on predefined standard parameters (14 days or 30 days). When the case reaches goal times, additional priority points escalate the case relative to other cases in the queue. Routing capabilities include requesting input from supporting departments such as provider network services or utilization and claims management.

• Correspondence Generation — Preconfigured letter templates for communicating with the involved parties at various stages of the complaint process. You can quickly and easily customize standard templates for acknowledging a complaint, requesting

Application overview

Healthcare Appeals and Grievances Manager Implementation Guide 2

additional information, and communicating final disposition to meet your specific needs. The letter templates are dynamically compiled and include re-usable correspondence fragment rules for common sections such as headers, footers, style sheets, and logos. You have the flexibility to generate correspondence automatically in the background or to allow and require editing as well as verification before you finalize it.

• Quality Improvement Audit — Pre-configured auditing of complaints based on frequency for a specific provider. The process creates a quality review case that is forwarded to the Quality Improvement department for further review.

• Legacy System Information — Retrieval and display of commonly referenced legacy system information such as member’s eligibility as well as processing feedback comments from all involved parties (member research and provider network departments).

• Reporting — Pre-configured productivity reporting to track process assignments, activity, quality, and performance. The Reporting Wizard allows managers to build custom reports necessary to manage the complaint resolution processes.

• Connectors to External Systems — Leverage of the comprehensive integration capabilities of Pega Platform. The complaint management process enables the retrieval and display of pertinent information from the health plan’s existing legacy systems, making it readily available for users during the process of resolving the complaint. The member’s eligibility information and the original authorization or claim information are automatically retrieved and made available as part of the case history. This availability avoids the need to toggle back to legacy systems for lookup and research of the information required to efficiently resolve the complaint.

Appeals and Grievances provide the foundation for health plans to build for change. It comes with a working configuration that you can extend to create your own solution. The remaining part of this chapter provides some suggestions as to where you might extend Appeals and Grievances.

Implementation delivery methodology Pegasystems recommends that you use an agile delivery model, more specifically a scrum-based standard for a Pega application implementation. In the rare cases where a waterfall-based implementation methodology is better suited, Pegasystems recommends that you use Pega’s Iterative Waterfall approach. These two implementation methodologies help break down the work into a manageable scope of work that you can deliver into production faster. The Pegasystems delivery approach has two primary stages:

• Initiate

• Delivery

Healthcare Appeals and Grievances Manager Implementation Guide 3

Initiate stage In the Initiate stage, the implementation teams build out the foundation or baseline of the application and prepare for the work that is necessary to configure the first production release and subsequent extension releases. Building a strong foundation to support expansion and reuse is core to the success of an implementation.

The Initiate stage is further organized into three sub-stages:

• Plan

• Setup

• Prepare

Plan Align the vision and roadmap to establish the foundation for the implementation. High-level tasks include:

• Defining the production release milestone

• Refining scope alignment

• Determining the implementation methodology

Setup Validate and review the Pega-provided features and capabilities with customer requirements and expectations. Tasks include:

• Establishing environments and processes

• Creating the baseline application

• Loading sample data

• Demonstrating the baseline application

• Performing a gap analysis

• Reviewing business needs and outcomes

Prepare Prepare for the delivery of the AGM application. These topics are outside the scope of this guide and this document does not discuss them further. Tasks include:

• Confirming resources

• Enabling team members

• Establishing governance

Healthcare Appeals and Grievances Manager Implementation Guide 4

At the conclusion of the Initiate stage, you define the scope of the work for the first production release. For Scrum, you identify the scope of the work with an initial backlog. For Iterative Waterfall, a specification list and schedule are prepared and finalized.

Delivery stage The delivery stage is dependent on the methodology selected during the Initiate stage. During this stage, the implementation team designs, builds, configures, and tests the application by using the selected implementation methodology (Scrum or Iterative Waterfall). The goal of the delivery stage is to accomplish the tasks described in this document by organizing the Application Feature backlog so that the delivery team can configure the application incrementally with the outcome of having a fully tested and performance-tuned application in production.

This guide provides information to support both implementation methodologies during the delivery stage.

Prerequisites Before you start your Pega AGM application deployment, be sure that you understand the following information:

• Support for various browser versions. Review the Platform Support Guide.

• The sections of the Designer Studio home page, and the menu names in the header section.

Pega Product Overview 5

The Initiate stage includes the following tasks:

• Creating the baseline application

• Loading sample data

• Performing the gap analysis

Step 1: Creating the baseline application Before you create the baseline application, be sure that you install and test Pega AGM. See the Pega Foundation for Healthcare 7.4 Installation Guide on the Pega Foundation for Healthcare product page.

Use the Application Wizard to create a new application built on Pega Healthcare Appeals and Grievances Management 7.4. The wizard creates the application structure for you. See Creating an application with the New Application wizard for an example on completing these fields.

Running the New Application wizard To create an application on Pega AGM, use the New Application wizard.

1. Log in to the application as Administrator@MyHealthPlan using the password that you specified when you enabled this operator; to enable Pega-provided operators, see Enabling operators.

2. Click Application > New Application.

3. In the What type of application would you like to create? list, leave the default value (Enterprise application) selected.

4. Click Create new application.

5. Complete the Application Settings page. If this is the first time that you are running the wizard, be sure that:

The Built on application field is set to Healthcare Appeals and Grievances Management 7.4.

The Application structure field is set to Framework and Implementation. For more information about the Application Settings page, see Configuring application settings in the New Application wizard.

6. Click Next.

7. Enter each known business objective, and click Add business objective.

8. When you finish adding business objectives, click Next.

9. Select the application-provided case types to include, and click Next.

Initiate stage

Healthcare Appeals and Grievances Manager Implementation Guide 6

10. Select the application-provided data types to include. Click Preview to see the application records and structure that will be created for you by the wizard.

11. After confirming the proposed application structure, click Create.

12. Once the application is created, note the operator IDs created. Log out and then log in using the administrator ID created.

Results of running the New Application wizard The New Application wizard creates the application class structure for you. You can reuse the classes and rulesets created by the wizard in future applications that you create. As you implement this application and future applications, you can apply reuse and version management principles to help you decide where in the class structure to create your rules to improve the maintainability and overall efficiency of your application.

For more information on the structure and rulesets generated by the wizard, see Understanding the class structure and rulesets generated by the Application Accelerator.

Step 2: Loading sample data Pega Foundation for Healthcare ships with sample data to support the Pega-provided demonstration of the Appeals and Grievances application. Pega recommends that customer-supplied sample data be loaded so that the gap analysis efforts are more meaningful for the client.

For more information, see "Importing sample data" in the Pega Foundation for Healthcare 7.4 Installation Guide on the Pega Foundation for Healthcare product page.

Step 3: Performing the gap analysis Review the application to perform a gap analysis and focus on identifying the specific requirements of your site. The following three documents define what your application contains:

• Application profile

An artifact that includes a collection of business-related information. The document includes processes, case types, reports, specifications, participants, collaborators, and actors that are associated with the implementation of your project.

• Application document

An artifact that includes specifications, process-flow snapshots, and requirements associated with your application.

• Specification document

Healthcare Appeals and Grievances Manager Implementation Guide 7

An artifact that includes specifications and linked requirements details associated with your application.

Generating the Application profile The Application Profile (AP) provides an inventory of specifications and requirements as it exists at a specific time. When you first generate an Application Profile, it shows the Pega-provided components.

1. Log in to the application as AGMAdmin@MyHealthPlan using the password that you specified when you enabled this operator; to enable Pega-provided operators, see Enabling operators.

2. Follow the steps in Generating an application profile document in the Pega Platform 7.4 help.

Generating the application document You can generate information about the rules that are already included with the application. This allows you to see what the application provides for you so that you can focus on identifying your site's specific requirements.

To document the rules provided by the application:

1. Log in to the application as AGMAdmin@MyHealthPlan using the password that you specified when you enabled this operator; to enable Pega-provided operators, see Enabling operators.

2. Follow the steps in Generating an application document in the Pega Platform 7.4 help.

Tip: You can control the level of detail included in the Application Document by modifying the settings in the Options section. For more information, see the Pega Platform 7.4 help.

Generating the specification document The specification document provides an inventory of specifications and requirements as it exists at a specific time.

1. Log in to the application as AGMAdmin@MyHealthPlan using the password that you specified when you enabled this operator; to enable Pega-provided operators, see Enabling operators.

2. Follow the steps in Generating a specification document in the Pega Platform 7.4 help.

Healthcare Appeals and Grievances Manager Implementation Guide 8

The Delivery stage includes the following tasks:

• Defining requirements

• Building features

• Testing a new application

• Packaging a new application

Defining requirements To ensure that you stay on target for a successful deployment, use a structured approach for your implementation methodology. You will need to prepare for your implementation and determine key aspects of the design that will affect the behavior of your application. Defining requirements for an implementation includes the following tasks:

• Reviewing extension requirements

• Refining customizations and determining the availability of required data and integrations

• Prioritizing, for example, revising the solution backlog, re-estimating effort for extensions and customizations, and confirming the project scope

Defining your requirements also involves Direct Capture of Objectives (DCO) sessions and incorporating those requirements into the application design. During these sessions, you review each of the case types and process flows that the application already provides.

Update the application specifications with planned changes as described in the Pega Platform 7.4 help topic About Application Specifications.

The AGM Implementation Planning Workbook helps you capture decisions as you define your requirements. You can download the AGM Implementation Planning Workbook from the Pega Foundation for Healthcare product page.

Follow these steps to define requirements:

1. Define the case type modifications and attributes

2. Define the data model

3. Define complaint reasons

4. Map the application data

5. Define integration

6. Define the security model and organization structure

7. Customize the user experience

Delivery stage

Healthcare Appeals and Grievances Manager Implementation Guide 9

8. Define reporting requirements

Step 1: Defining the case type modifications and attributes Your AGM application includes predefined case types for Complaint, Appeal, and Grievance. Each case contains one or more processes that you can extend or create to meet your business requirements. You can create new case types based on the needs of your application during your planning process.

Each case type has one or more processes associated with it. When you define a new case type, you provide stages for that case type. A stage is the first level of organizing work in your case type. Each stage has one or more steps.

Updating existing case types AGM includes 3 case types:

• Complaint

• Appeal

• Grievance

Appeal and Grievance are child cases of the parent complaint case. With every request you create a new complaint case. Depending on the reasons for the complaint selected during the request intake process, the system creates one or more appeal and/or grievance sub-cases.

If an existing case type is close to meeting your business requirements, you can modify it and use it.

Complaint case type

Healthcare Appeals and Grievances Manager Implementation Guide 10

Appeal case type

Grievance case type

1. In the explorer panel, click Cases.

2. Click the first case type.

3. Update the case-wide properties.

4. Update the processes associated with the case type.

5. Repeat these steps for all case types.

Alternatively, you can add processes by using the Case Designer.

Adding a new case type Create a new case type that meets your business requirements.

1. In the explorer panel, click Cases.

2. Click Add a case type.

3. Provide a name and description for the case.

4. Click Next.

5. Define the stages for the case type.

Healthcare Appeals and Grievances Manager Implementation Guide 11

6. Click Finish.

You will configure the steps for each stage later.

Mapping case type classes to a database table When you run the New Application wizard to create your initial case types, you create a default class group mapping for each case type. You can change the class group setting for each case type to ensure that each case is mapped to a table name that conforms to your site's naming conventions.

Mapping a class to a physical database table impacts data storage and security decisions. If you expect the volume of the case types to be low, consider sharing the table with other case types. If access to instances of this case type needs to be restricted, create a separate class group for each case type.

For each class corresponding to the case type:

1. In the explorer panel, click App.

2. Right-click the class name and select Definition.

3. In the Settings section, review the This Class setting.

4. Determine whether the class is a class group or belongs to a class group. If the class belongs to a class group, determine to which class group it belongs.

5. In the Test Connection section, click Test Connection to determine the name of the table currently mapped to this class.

6. Determine the name of your database table.

7. Repeat these steps for each class in your application.

8. Record your decision in the Case type modifications planning worksheet.

Confirming case type locking setting When you created your case types using the New Application wizard, you reviewed the case type settings for each case type. One of those settings is the locking behavior on the case, which affects concurrent access to cases.

You can choose one of two types of locking:

• A case is opened

Allows one user at a time to open and work on a case.

• An action taken on case

Allows multiple users to work on a case at the same time.

Healthcare Appeals and Grievances Manager Implementation Guide 12

If you have already considered and set the locking behavior for each case type, you can skip this step.

Identifying the most appropriate lock setting for your application is important because it can affect the throughput of work in your application. For example, if user1 locks a case to work on it, then other users cannot work on the locked case until user1 unlocks the case or the lock expires according to the timeout period.

Contrary to this, if you allow multiple users to work on a case simultaneously, the case content could be modified for one or more users while they work on the case. For example, assume that user1 is working on a case then user2 opens the same case a few minutes later. When user1 saves changes to the case, user2 is notified of the changes and is enforced to accommodate changes done by user1 in the case.

Use the Case type modifications worksheet in the Implementation Planning Workbook to record your decisions during this procedure.

1. In the explorer panel, click Cases.

2. Click the first case type.

3. Click Locking in the case-wide settings.

4. Determine if you should lock the case when the case is opened or when an action is taken on the case.

5. Determine the lock timeout period for this case.

6. If you are certain at this point how you should handle locking for this case type, you can update this setting now.

7. Repeat these steps for each case type.

Step 2: Defining the data model Data modeling involves relating a conceptual model of how data items relate to each other in an application. The data model in Pega Platform refers to a set of rules that work together to populate the data in your application. The user interface displays the data to help the user process the case and can help automate decisions in your business processes. The following rule types constitute your data model:

• Data types

The data type is another name for a class in your application that holds the data the application uses. A data type has one or more data pages and several property definitions associated with it.

• Properties

Healthcare Appeals and Grievances Manager Implementation Guide 13

Properties define the format and visual presentation of data in your application.

• Data pages

Data pages define the content of a clipboard page. Data pages also control the loading of that data from a source system as shown here.

A related concept to data pages is integration. Integration controls how the data is retrieved from the systems of record to populate your application data pages. Data mapping rules determine how the data from the system of record corresponds to your application data model.

When planning your data model, work with the data modeling resource at your site to understand attributes of data types that your application needs to support.

Pega AGM is rarely the system of record for application data. Integrating your application data with your site's system of record is critical to the success of your deployment.

Pre-configured data types AGM provides pre-configured Data Types for managing complaints. Pega Foundation for Healthcare provides a comprehensive data model with many Data Types and Data Pages for commonly used data objects that you can leverage in your application.

See the Pega Foundation for Healthcare 7.4 Implementation Guide on the Pega Foundation for Healthcare product page for additional details on the data model.

Step 3: Define complaint reasons You can select the type(s) of complaint and the reason(s) for the complaint during the complaint intake or creation process.

Healthcare Appeals and Grievances Manager Implementation Guide 14

Based on the complaint type selected, the system displays corresponding reason options based on the data table that stores the complaint type – reason combinations. The selected combination also determines whether the complaint sub-case is an appeal or a grievance. As you can select more than one complaint type during a request, the system can create more than one appeal and/or grievance subcase.

• The complaint type of Health Plan has the following pre-configured reasons:

• The complaint type of Payment Copayment has the following pre-configured reasons:

Healthcare Appeals and Grievances Manager Implementation Guide 15

• The complaint type of Provider has the following pre-configured reasons:

• The complaint type of Treatment/Procedure has the following pre-configured reasons:

Healthcare Appeals and Grievances Manager Implementation Guide 16

The Complaint Type – Reason combinations are stored in a data table of class PegaHC-AG-Data-ComplaintReason that you can extend based on your business needs. Based on the Complaint Type and Reason selected, the system automatically creates Grievance and/or Appeal sub-cases to the parent Complaint case. There can be more than one grievance and/or appeal cases created as part of one complaint.

Complaint category Complaint reason Appeal or grievance Payment/Copayment General dissatisfaction Grievance Amount different than last year Grievance Change in premium Grievance Plan responsibility Appeal Type of service not correct or not at

right level Appeal

Discontinued Service Appeal Timing of plan payment Appeal Should be a covered service and plan

responsibility Appeal

Treatment/Procedure Notification of termination of service Appeal Notification of denial of service Appeal Reduction of previously approved

service Appeal

Refusal to authorize service Appeal Provider Current provider no longer contracted Appeal Timeliness of service Grievance Quality of Service Grievance Rudeness/disrespect by staff Grievance Health Plan Rudeness/disrespect by staff Grievance Enrollment/disenrollment issue Grievance Plan Benefit issue Grievance

Healthcare Appeals and Grievances Manager Implementation Guide 17

Pharmacy access issue Grievance Customer service issue Grievance

Use the Complaint Reason planning worksheet in the AGM Implementation Planning Workbook to record the desired modifications to the list defined above as needed by the application.

Step 4: Mapping the application data The application data types provide a default set of properties for your use. You can add or remove properties from these data types depending on your requirements. You can also add new data types.

1. In the explorer panel, click Data.

2. Click the desired data type.

3. On the Data model tab, determine the properties to add, remove, or leave unchanged.

4. Repeat these steps for all other desired data types.

You can also use the Data planning worksheet to record any new data types needed by the application.

Step 5: Defining integration You must inventory which external applications exist at your site and plan how to connect to them. Some common integration points for the Pega AGM include interfaces to:

• Membership and enrollment systems of record

• Plan benefit and eligibility management systems

• Practitioner and provider system of records

• Provider networks and contracting systems

• Medical (utilization) management systems

• Claims system

Tip: Identify integration points as early in your planning as possible. If a connection to an external data source is required and either the data itself does not exist or the interface to that data does not exist, you must account for the time to build the interface to this application.

Healthcare Appeals and Grievances Manager Implementation Guide 18

Pre-configured REST APIs The Pega Foundation for Healthcare provides following pre-configured REST APIs for commonly referenced Resources that you can use to connect with your source of truth systems.

REST API Rest connector data page name Data type (class) name

GetAuthorization D_ConnectAuthorization PegaHC-Data-Authorization

GetMemberAuthorizations D_ConnectMemberAuthorizations PegaHC-Data-Authorization

GetBenefitCoverage D_ConnectBenefitCoverage PegaHC-Data-Benefit-Coverage

GetPlanDetails D_ConnectGetPlanDetails PegaHC-Data-Plan

GetContract D_ConnectContract PegaHC-Data-Contract

GetMember D_ConnectMember PegaHC-Data-Party-Member

GetPayer D_ConnectPayer PegaHC-Data-Party-Payer

GetPolicy D_ConnectPolicy PegaHC-Data-Policy

MemberPolicies D_ConnectMemberPolicies PegaHC-Data-Policy

MemberPoliciesByID D_ConnectMemberPoliciesByID PegaHC-Data-Policy

GetProvider D_ConnectProvider PegaHC-Data-Party-Provider

GetBusinessAffiliation D_ConnectBusinessAffiliation PegaHC-Data-BusinessAffiliation

BusinessAffiliation D_ConnectBusinessEntities PegaHC-Data-Party-BusinessEntity

MemberNetworks D_ConnectMemberNetworks PegaHC-Data-Network

GetNetwork D_ConnectNetwork PegaHC-Data-Network

PlanNetworks D_ConnectPlanNetworks PegaHC-Data-Network

ProviderNetworks D_ConnectProviderNetworks PegaHC-Data-Network

RateSheet D_ConnectRateSheet PegaHC-Data-RateSheet

To navigate to the pre-configured external data pages:

Healthcare Appeals and Grievances Manager Implementation Guide 19

1. Log in to the application as Administrator@MyHealthPlan using the password that you specified when you enabled this operator; to enable Pega-provided operators, see Enabling operators.

2. Navigate to Designer Studio > Data Model > View external data entities.

To view REST API data model schema:

1. Log in to the application as Administrator@MyHealthPlan using the password that you specified when you enabled this operator; to enable Pega-provided operators, see Enabling operators.

2. Navigate to Designer Studio > Healthcare > Healthcare API > Business Requests entities.

3. Click on the desired Resource Link to view the pre-configured REST methods as well as the schema data model associated with each Resource API.

For additional information, refer to the Healthcare API Technical Specifications document on the Pega Foundation for Healthcare product page. Use the Integration worksheet in the Implementation Planning Workbook to record your decisions on APIs any schema model changes needed for your application.

Step 6: Defining the security model and organization structure Security planning involves defining authorization and authentication strategies for your application.

• Authentication

Proving to the application that you are who you say you are.

• Authorization

Determines the functions that the application allows you to perform. This corresponds to access group and role configuration.

Security planning also involves setting up the organization structure and operator attributes.

The application provides a fine level of security in the form of access settings and denial rules. Many integration rules also incorporate authentication. For more information on the additional aspects of security, enroll in the Lead System Architect course on Pega Academy and cover the security lessons corresponding to the following topics:

• Defining authentication scheme

• Defining authorization scheme

Healthcare Appeals and Grievances Manager Implementation Guide 20

• Defining organizational structure

• Defining operator attributes

Authentication schemes Pega Platform offers the following authentication types:

• PRBasic

Based on passwords in the Operator ID data instances and the login form (defined by the HTML rule @baseclass.Web-Login, which your application can override).

• PRSecuredBasic

Similar to PRBasic but passes credentials using Secure Sockets Layer (SSL) using Basic HTTP authentication. The HTML rule @baseclass.Web-Login-SecuredBasic defines the login form, which your application can override.

• PRCustom

Supports access to an external LDAP directory or a custom authentication scheme.

• PRExtAssign

Supports external assignments (Directed Web Access).

• J2EEContext

Specifies that the application server in which Pega Platform is deployed uses JAAS to authenticate users.

Defining your authentication scheme Your site can use a centralized, automated means of maintaining operator data instead of maintaining it manually in the AGM.

Use the Security model worksheet in the Implementation Planning Workbook to record your decisions during this procedure.

1. Discuss Authentication schemes with your site's security and application server teams.

2. Determine the appropriate authentication type.

For more information on authentication scheme planning, see Authentication in the Pega Platform.

Pega AGM comes with a predefined set of access groups, roles, and privileges. You can use the application roles as a starting point, but you should create your own application-specific access groups and roles to avoid any problems when upgrading.

Other rule types such as sections, flow actions, and activities use roles and privileges to allow access to these rules at run time.

Healthcare Appeals and Grievances Manager Implementation Guide 21

Tip: You can review the Pega AGM access groups and roles. Click Designer Studio > Org & Security > Groups & Roles > Access Groups or Designer Studio > Org & Security > Groups & Roles > Access Roles.

Defining your access groups Use the Security model worksheet in the Implementation Planning Workbook to record your decisions during this procedure.

1. Identify additional access groups needed for your application.

2. Identify portals associated with these access groups.

Defining access roles and privileges You can associate one or more roles to an access group. Roles are additive. The more roles that you add to an access group, the more the authorization. You can associate privileges with one or more roles.

Use the Security model worksheet in the AGM Implementation Planning Workbook to record your decisions during this procedure.

1. Determine which roles you need for your application. You can use the AGM roles as a starting point.

2. Determine which privileges to associate with each role.

3. Associate each role with an access group.

For more information, see Groups & Roles configuration in the Pega Platform 7.4 help.

Defining the organization structure Leverage the organization structure for routing and reporting within the application. Typically, the application organization structure does not map operators exactly to the site's organization chart but instead, it maps the work that those operators do.

Tip: For design guidance, see the Organization section on the Pega Platform 7.4 help.

Use the Organization structure worksheet in the Implementation Planning Workbook to record your decisions during this procedure.

1. Click Designer Studio > Org & Security > Organization > Organizational Chart.

2. Review the existing structure.

3. Determine the organization, division, and unit levels of the hierarchy.

Healthcare Appeals and Grievances Manager Implementation Guide 22

Defining the operator attributes An operator's access group affects what the operator can do in the application. In addition to the access group, three fields in the operator record influence how the application handles assignment of work to the user:

• Work group

• Skills

• Calendar

Tip: In many implementations, it is more efficient for the application to set values on the operator record during the authentication process than it is to have an administrator manually maintain these records. You must configure these rules as part of the authentication mechanism for your site. For more information, see About Authentication Services.

Defining the operator work group The work group setting on the operator record affects how the application delivers work to the operator.

1. Review the Operator record.

2. Determine the rules for assigning a work group to an operator or the role that multiple operators hold.

Use the Organization structure worksheet in the Implementation Planning Workbook to record your decisions during this procedure.

3. Click Designer Studio > Org & Security > Organization > Operators.

4. Click the Operator ID.

5. On the Work tab, review the work group information for the operator record.

6. Determine your policy for assigning a work group to an operator or the role that multiple operators hold.

Defining the operator skills Skill settings in the operator record affect how the application routes work to the operator. Skill settings also affect how the application gets the most appropriate work when using the Get Next Work feature. You must determine the skills that are appropriate for your application and operators.

Use the Organization structure worksheet in the Implementation Planning Workbook to record your decisions during this procedure.

1. Define the skills needed for the application.

Healthcare Appeals and Grievances Manager Implementation Guide 23

2. Determine which operator records or roles should be associated with those skills.

Defining the operator calendar The application calendar affects date calculations within the application, such as the date between business days calculation, and the SLA goal and deadline date calculation.

The calendar on the operator record is relevant only if you have users who are not working in the same time zone as the rest of the organization. Otherwise, the application uses the calendar on the organization record and you can skip this step.

Use the Organization structure worksheet in the Implementation Planning Workbook to record your decisions during this procedure.

1. Determine the calendar instances needed for your application.

2. Determine which operator roles need a distinct calendar.

3. Determine the operator location.

For more information, see About calendar data instances.

Step 7: Customizing the user experience While Pega AGM is fully functional immediately upon installation, you will want to change portions of the user experience (UX) to meet the needs of the users at your site.

Follow these steps to design the user experience:

1. Design the portals

2. Design application skins

3. Design for screen performance

Designing the portals Review the content of the AGM Manager and AGM User portals to ensure that you present only the relevant data.

1. Log in to the application as AGMAdmin@MyHealthPlan using the password that you specified when you enabled this operator; to enable Pega-provided operators, see Enabling operators.

2. From the Launch menu, select AGM Manager.

3. Review each of the portal sections.

4. Record your decision in the Portals planning worksheet.

5. Repeat this process for the AGM User portal.

Healthcare Appeals and Grievances Manager Implementation Guide 24

Designing application skin and styles Your site very likely has standards for the appearance of your application. Your task is to determine which styles have to change to adhere to those standards.

1. Click Designer Studio > User Interface > Skins & Portals.

2. On the Skins tab, double-click the HCIF skin.

3. Click the Component Styles tab.

4. Review each component.

5. Record your decision in the Skinning planning worksheet.

As you are planning your application styles, you want to consider using mixins to provide incremental style changes. For more information, see Using mixins in the skin to drive consistency and efficiency.

Designing for screen performance You want your application to respond immediately as your end users interact with customers. As you design your user interface, determine:

1. The existing business service level agreements. For example, the customer details must be available in one second or less while a representative is on the phone with the customer.

2. The time it takes for the backend systems to gather the data needed to display customer details.

3. The fields the representatives need for the task that they need to perform.

4. If any network configuration could cause latency, for example, if there are representatives logged in through a corporate VPN or in a remote location.

Step 8: Defining reporting requirements Based on your login and portal, Pega AGM provides pre-configured reports to monitor case and work inventory as well as monitor workforce productive and quality. The case and work object lifecycle infrastructure as well as the work and assignment-level service level rules for goals and deadlines used in managing the life cycle of a case drive these standard reports.

Consider your reporting requirements early in the planning process. Before introducing a new report, answer these questions:

• Who needs the report?

• When do they need the report?

• What is the content of the report?

Healthcare Appeals and Grievances Manager Implementation Guide 25

• Why do they need the report?

• Where will it be run? Will it be run in the Pega application, or using another reporting tool and source?

With reporting, you should plan your reporting needs ahead of time to give you the maximum flexibility later. To do this:

• Determine reporting architecture.

• Review existing reports.

• Identify key operational metrics.

• Identify dashboard reports.

• Determine which reports you will generate from the application, and which you will generate using a different reporting tool.

• To record your decisions during this procedure, use the worksheet in "Reports" in the

Implementation Planning Workbook.

• To understand reporting requirements, read the Reporting Overview PDN article. The concepts in this article apply to all versions of the platform.

• Review the description of each application-provided report, identify the expected volume of data, and determine how often each you expect to run each report.

• Identify other reporting tools at your site.

Healthcare Appeals and Grievances Manager Implementation Guide 26

Follow these steps to leverage and extend preconfigured data models, integration APIs, and other capabilities of the AGM to build you application features:

1. Integrate data

2. Implement the security model

3. Modify user interface

4. Create reports

Step 1: Integrating data To integrate data into your AGM application:

1. Select the desired data class (member, provider, claim, and authorization).

2. Open the desired Data Page for the selected data class.

3. Update the Data Source of the data class to leverage the appropriate connector, data transform, or report definition configured to retrieve data from your system of record.

4. Create or update the response data transform rule to map the interface and data classes.

5. Repeat the steps for each data type.

Pega applications come with data types that you need to configure to point to a site’s data. You must configure these data types to integrate the site’s data source into the application. To configure, go to Designer Studio > Data Model > View External data entities. For more information, see Viewing external data entities.

Step 2: Implementing the security model Once you review the existing groups and roles, and determine additional ones that you want to create, click Designer Studio > Org & Security > Groups and Roles to create new groups and roles. Make sure that you are logged in as an administrator.

For information on configuring groups and roles, see Groups & Roles and related Pega Platform 7.4 help topics.

Step 3: Modifying the user interface You can:

• Add a new property to a section

• Add a new section

• Modify the application appearance

Building features

Healthcare Appeals and Grievances Manager Implementation Guide 27

Determining which part of the user interface to modify When you first access AGM, you will have access to the Case Manager and Code Manager Portal, where you will see a dashboard, which typically contains a dashboard menu at left. This dashboard is completely customizable and can display any data that you have integrated into your application.

Locating the user interface element to change To determine which user interface element to modify to implement your change, you can use the Live UI feature of Pega Platform.

1. Click Live UI.

2. Select an element to observe.

When selected, Live UI gives you all the information about that UI element. You are able to see the sections and harnesses that an element is a part of.

3. Click the Magnifying glass icon to open that rule in Designer Studio and update it as needed.

Adding a new property to a section AGM uses standard Pega Platform user interface components, so the update process is the same as any Pega Platform application.

1. Click Live UI and determine the section that you want to modify.

2. Click the Magnifying glass icon to open the rule in Designer Studio.

3. In Application Explorer, locate the property that you want to add to the section and drag it onto the section where you want it to display.

4. Click Save as and then save the rule to the default Applies to class and make sure that the ruleset is for your application.

5. Click Create and open and click Save.

Adding a new section AGM uses standard Pega Platform user interface components, so the update process is the same as any Pega Platform application.

1. Click Live UI and determine the section that you want to add a section to.

2. Click the Magnifying glass icon to open the rule in Designer Studio.

3. In Application Explorer, locate the section that you want to add and drag it into the section where you want it to display.

Healthcare Appeals and Grievances Manager Implementation Guide 28

4. Click Save as and save the rule to the default Applies to class. Make sure that the ruleset is for your application.

5. Click Create and open and then click Save.

Also, you can use When rules to update which layouts and sections are visible. This is helpful for a manager to see content that a non-manager cannot see.

To do this:

1. Click the Gear icon to configure the layout or section.

2. Change the Visibility to Condition.

3. Enter a When rule or conditional expression.

4. Click OK and then click Save.

Updating the skin You can update the look and feel of your application to reflect the color scheme of your company. The application takes advantage of the standard Pega Platform skinning features within an application.

1. In Designer Studio, click the hyperlink on the Application Name > click on Skin.

2. Update the options as needed, and then click Save as.

To learn more about skins, click Help.

3. Click Create and open.

4. Click Save.

5. If you give your skin a different name, update the application to reflect it.

6. In Designer Studio, click Application Name > Open Application.

7. Change the Skin field to the skin that you created.

8. Click Save.

Step 4: Creating reports AGM provides pre-configured reports that are customized for the various work objects, cases, and business processes used in the application. These reports give you complete control in managing your business. With real-time insights into case inventories and aging, you can respond with the agility needed to comply with your internal and external service level agreements as well as compliance mandates.

To create other reports, see Running reports from the Report Browser.

Healthcare Appeals and Grievances Manager Implementation Guide 29

Testing a new application Testing a new application includes the following procedures:

• Testing in the Build environment

• Testing in the Test or Production environments

• Testing in the UAT environment

Testing in the Build environment Test a new application in the Build environment before migrating the new application to a Test or Production environment. Testing in the Build environment enables you to verify that basic functionality and interfaces work correctly and also that performance is acceptable.

1. Run functional tests to test specific features from the end-user perspective.

2. Run automated unit tests to test features such as security, eligibility, search, and loading of data.

3. Use the Performance tool (PAL) to measure the performance of the application. For information about the PAL tool, see About the Performance tool.

Prior to extending your site-specific Pega implementation, Pegasystems recommends that you establish a performance benchmark (baseline) using PAL. This allows subsequent, iterative performance tests against the established baseline to help identify any degradation in performance resulting from development efforts.

Use PAL to check the performance of the following:

• Search

• Loading of components

Save the PAL test results so that you can compare them to future PAL test results to determine whether an application update has a performance impact.

1. Verify that the Pega-provided reports and your custom reports run successfully, and that they show your implementation layer data, rather than the default demonstration data. This can be an automated test.

2. Test all integrations, both independently and with associated integrations.

3. Test security. Test the most common roles to ensure that the required access groups are configured and point to the correct software version.

Healthcare Appeals and Grievances Manager Implementation Guide 30

Testing in the Test or Production environments After you import the application to a Test or Production environment, test the application in the new environment to verify that it works correctly in that environment.

The testing performed in the Test environment should include usability testing to ensure that the application meets the UI standard.

1. Verify that the source (Build environment) and destination (Test or Build environment) files are the same.

2. Run functional tests to test specific features from the end-user perspective.

3. Run automated unit tests to test features such as security, eligibility, search, and loading of data.

4. In the Test environment, run the Application Guardrails Compliance Score to ensure that the application meets guardrails.

5. Verify that the Pega-provided reports and your custom reports run successfully, and that they show your implementation layer data, rather than the default demonstration data. This can be an automated test.

6. Test all integrations, both independently and with associated integrations.

7. Verify that the integrations point to the correct system of record, and not to the system of record for the Build environment.

8. Test security. Test the most common roles to ensure that the required access groups are configured and point to the correct software version. Use these common roles in your smoke tests (see next step).

9. Run a smoke test to compare the source and destination environments. Verify that all tests that pass in the Build environment also pass in the Test or Production environment. If anything fails, compare the environments to determine whether a difference in environment could cause the test to fail. If the environment caused the failure, either fix the issue that caused the failure or adjust the test as appropriate for the new environment.

10. Run performance tests to verify that performance meets expectations. Pega recommends automated performance testing. Save the results so that you can compare them to future performance test results to determine whether an application update has a performance impact.

Testing in the UAT environment After you complete testing in a Test environment, it is common to perform User Acceptance Testing (UAT) in a designated UAT environment, which could be a Pre-production environment. UAT ensures that end users will be able to successfully complete work and meet business objectives.

Healthcare Appeals and Grievances Manager Implementation Guide 31

Organizations that use Scrum for application development will complete less formal UAT as part of each sprint cycle.

1. Verify the integrity of the UAT environment.

2. Have the end-users (or BAs acting the role of end-users) run scripts to test all scenarios including boundary and exception testing. The end-users (that is, the trainers, managers, and directors), do the following during UAT:

Verify that there are no major issues. Review changes in order to better understand the features.

Packaging a new application To migrate a new application to a different environment, you must first package the application so that it can be imported to the new environment.

Packaging and importing a new application includes the following procedures:

1. Merging application changes

2. Packaging an application for migration

3. Importing the packaged application

Merging application changes If you developed your application features in separate branches, use the Merge Branches wizard to merge the branches before you package the application. The wizard shows any merge conflicts so that you can correct them before you merge the branches.

For information about how to use the Merge Branches wizard, see Merging branches.

Packaging an application for migration Before you can migrate a new application to a different environment, you must package the relevant data instances and rulesets into a product rule. The product rule is an instance of Rule-Admin-Product, and it is referred to as the RAP file.

1. Click Designer Studio > Application > Distribution > Package to start the Application Packaging wizard. For information about how to use that wizard, see Application Packaging wizard.

2. Complete each page of the Application Packaging wizard.

3. On the last page of the wizard, click Preview.

4. Review the contents of the generated RAP file.

5. On the last page of the wizard, click Modify to make any changes.

Healthcare Appeals and Grievances Manager Implementation Guide 32

6. When the RAP file is complete, click Export. The wizard creates a .ZIP file in the ServiceExport directory on the current application server node.

Importing the packaged application To deploy a new application to a different environment, import the .ZIP file that contains the packaged application to the new environment.

1. Click Designer Studio > Application > Distribution > Import.

2. Use the Import Gadget to import the target .ZIP file. For detailed information about how to use that gadget, see Import wizard landing page in the Pega Platform 7.4 help.

For information about how to swap the database connection pointers to your Production database after an import to a Production environment, see the Pega Platform 7.4 Upgrade Guide.

Healthcare Appeals and Grievances Manager Implementation Guide 33

Production maintenance and monitoring includes the following:

• Application monitoring

• Identifying and reporting issues

Maintaining business rules in the production environment As a manager, you can update Dialogs, Coaching Tips and Expert Skills in the Production environment using the Tools > Configuration option available in each process action of the case type. This feature allows managers to change these options without having to wait for a rule deployment.

Skills instances need to be created in order for them to be available in the selection of available Expert Skills.

Managers can also create reports in the My Reports section of the portal. For more information, see Running reports from the Report Browser.

The manager can be given the ability to update other rule types in the Production environment. For example, the manager can update the Goals and Deadline for a certain case type. These rules must be delegated in the Designer Studio first. After the rule has been delegated, you can access it by clicking your operator profile > My rules. For more information on rule delegation, see Delegating a rule or data type.

Monitoring the application Pega Platform application health monitoring In addition to your site's database and application server monitor tools that you already have in place, the Pega Platform offers an application called Autonomic Events Services (AES). AES is an application that automatically monitors, retrieves, and organizes the alert data from one or more clustered systems throughout the enterprise. Pegasystems also provides the Predictive Diagnostic Cloud (PDC), which allows you to benefit from AES without installing it locally. PDC is a Software as a Service offering of AES.

Identifying and reporting issues As with any application, your users will encounter issues that they need to report as they begin to use the application. When deploying your application to the production environment, you must do the following:

Production maintenance and monitoring

Healthcare Appeals and Grievances Manager Implementation Guide 34

1. Identify operational staff who will be responsible for responding to issues reported in the production environment.

2. Establish procedures with those resources to triage, respond to, and escalate issues.

3. Determine procedures for delivery of changes to the production environment.