Setting the configuration when building an implementation layer

From PegaWiki
This is the approved revision of this page, as well as being the most recent.
Jump to navigation Jump to search

Setting the configuration when building an implementation layer

Description Instructions for updating the configuration page in Pega Care Management
Version as of 8.5
Application Pega Care Management
Capability/Industry Area Healthcare and Life Sciences

You can more efficiently implement your Pega Care Management application by using the single-source configuration page to update the application settings. The configuration page offers access to work classes, rule classes, data classes, and other configuration settings. Through the use of the configuration page, implementation teams have one location to update the settings for their implementation layer. The configured settings are referenced using the Declare_CM_Env data page reflected when you run your cases.

8.5 configuration page.jpg

Creating your application

To configure and extend the out-of-the-box application to meet your business needs, first, create a new application on top of Pega Care Management by running the New Application wizard. The new application, known as the implementation application, is where you configure the features that differ from the installed application.

An organization that consists of multiple companies or entities might require more than one implementation application. A client can configure the number of data elements required for Health Insurance Portability and Accountability Act (HIPAA) validation on the configuration page. For example, a company might require different work or data classes or have a different workflow to enforce stricter HIPPA validations. In this situation, you create a framework application that contains the features that are common to all parts of the organization, and then you build the implementation application on top of the framework application. It is important to make sure that the configuration page is updated and saved for the design of your implementation layer.

Use case examples

The following describes some use cases for updating the configuration page:

A new client is implementing Pega Care Management and wants to update or confirm that the classes properly reflect the application-layer naming conventions

Application work classes These fields show the work classes and cases in the application. When you build your application on Pega Care Management, change the names of the work class and case fields to meet your business needs. Associate each work class and case as appropriate.  Use your naming convention to update the fields to reflect your structure and custom configuration if required. For example, change PegaHC-Care-Work-AdmissionCase in the Admission Work Class field to <ORG name>-<application name>-Work-AdmissionCase.

A new client wants to update the fields on the configuration page for use with the Social Determinant of Health initiatives

Social Determinant of Health options on the configuration page

A client wants to set the HIPAA validations within the application because identity verification is important for maintaining privacy and protecting personal health information

You can update these settings on the configuration page.

Patient identifiers on the configuration page

Updating the Care Management Configuration landing page

Dynamic Class Referencing (DCR) is a pattern that enables you to avoid hard-coding of class names, flow names, and workbasket names so that the implementation layers can easily extend the application. Pega care management implemented the DCR approach using Declare_CM_ENV data page and the implementation layers can configure the relevant settings from the configuration landing page. As of 8.6 version this is a manual process and system architect should ensure valid details are configured.

After generating the implementation layer, configure the application settings by navigating to the Care Management Configuration landing page (Configure > Care Management Configuration).

Update the implementation layer classes in the relevant tabs such as Work classes, Rule classes, Accelerator classes, and Data classes

Work queues are cases or work objects that are pending an action and can be routed to common work queues for work assignment to the staff. The Work queues tab lists the work queues that are used in different flows of the application.

Specify whether you want to perform HIPAA verification as part of your Schedule call and Schedule assessment task

This compliance activity ensures the protection of member health and identity information. Because some organizations have other processes to ensure HIPPA compliance, this setting gives an organization the opportunity to remove the verification step from the Schedule call and Schedule assessment tasks. Update the Require member verification in tasks setting in the Other settings tab.

Update the application perspective in the Other settings tab if needed.

When you create your application, you select either the payer or provider perspective. However, as an organization, you might want to change the perspective. If a provider organization used an earlier version of the application and did not customize the labels, for example, changing Member to Patient, they might now choose the Provider option. In this case, when changing to the provider perspective, all references to Member are automatically changed to Patient

Configure the patient identifiers in the Patient Identifiers tab according to your organizational needs

The number of identifiers configured on this tab is based on the values that you configured in the Minimum patient identifiers and Maximum patient identifiers fields. You can configure your list with all the properties that are used for patient identification according to HIPAA recommendations.

For more details on the various applications settings that are supported by Pega Care Management, refer to the Implementation guide