Pre-emptively notify customers about benefit issues
|Description||Learn how to use data flows|
|Version as of||8.5|
Coverage issues such as benefit limits, out-of-pocket expenses, and cost share changes are some of the root causes for customer calls to healthcare contact centers. If the customers can be reached ahead of time and notified about the potential coverage issues that they might encounter, they can take the necessary actions, thus reducing the number of call center calls and increasing customer satisfaction.
Before you begin
Before you begin, ensure that you complete these actions:
- Install Pega Customer Service for Healthcare
- Obtain a license for Pega Customer Decision Hub to use the Event Strategy manager
The PreemptivelyNotifyBenefits data flow
A data flow is a Pega rule type that can ingest, process, transform, and enrich data by using event strategies. These flows run concurrently and handle data, beginning at the source and ending at the destination. The PreemptivelyNotifyBenefits data flow, created for Pega's healthcare products, informs healthcare customers about benefit issues ahead of time.
Steps in the PreemptivelyNotifyBenefits data flow
- The Benefit issues data set: The BenefitIssues data set rule is used to retrieve data from the pr_PegaCPMHC_Data_BenefitIssue database table, which is in the PEGADATA schema. The data set uses the MemberID property (of PegaHC-Data) as the key to query the data.
- Calculate fields related to the benefit data transform: Used to calculate a plan end duration and percentage of benefits consumed for a benefit by a member, as these properties are used in filter conditions for the BenefitIssues event strategy. It is marked as an extension to set other property values that are to be passed to the BenefitIssues event strategy.
- Benefit issues event strategy: Event strategies provide a mechanism to simplify complex event processing operations. The sequencing in event strategies is established through a set of instructions and execution points, from real-time data to the final emit instruction. Between real-time data, emit, filter, window, aggregate, and static data instructions can be applied.
This strategy receives real-time data from the previous steps of the data flow. Then it filters the data based on the configured criteria.
For example, the above filter filters the data based on the member age, percentage of benefit limit consumed, and the plan end duration in days. The last emit step produces the filtered data that is used in the next step of the data flow.
4. Outbound email: The last step sends out a correspondence email, using the default Interaction Outbound-Email case type, to the members listed in the filtered data set by setting the appropriate properties.
Triggering the data flow
The data flow can be triggered from an activity by using a DataFlow-Execute method that appropriately sets the parameters (NextRunID) in the previous step. The GetDataFlowRuns report definition is helpful to retrieve the last run ID, and then the next run ID can be calculated.
The triggering process can be automated by tying the above activity to a job scheduler.
After these steps are completed, you can trigger this data manually or tie it to a scheduler for automated background processing.