Coverage Inquiry preemptively notifies health plan members about potential coverage issues and tees up next steps to prevent care interruptions. This microjourney^TM includes Pega decisioning capabilities that identify opportunities for action as well as a mobile self-service case type.

• Business value
• Use case
• Applications required
• Personnas, channels, and usage
• Event Strategy Manager rules
• Stages and steps
• Data model
• Enabling the microjourney
• FAQs

Business value

Complex coverage issues are the root cause behind many calls into health plan contact centers. Health plans can use this microjourney to save members from dissatisfying hassles through preemptive outreach. Doing so will positively affect call volume, average handle time, and customer satisfaction.

Use case

Health plans can deploy this microjourney to preemptively help members avoid difficult benefit issues, often before members know that they have a problem. Potentially confusing events can be spotted ahead of time and trigger outbound communications in low-cost channels that inform members how to avoid a potential problem.

Examples of issues that can be handled by this microjourney are:

• Informing members about approaching benefit limits on recurring, repeatable medical services, such as chiropractor visits, physical therapy, or occupational or speech therapy. Next steps can include coordination with providers to determine whether additional visits can be authorized.
• Out-of-pocket expenses that are incurred for diagnostic procedures when the member expected a preventive visit to have no out-of-pocket expense, such as colonoscopies, dermatology visits, and mammograms. The member might be unaware of why the unexpected expenses are incurred. Preemptive outreach to that member might avoid a phone call after the member receives a bill from their provider.
• Changes to cost shares due to plan changes. Members regularly see providers, but their cost shares for that medical service might change from year-to-year. Preemptively reminding members avoids surprises at the providers’ front desk and phone calls to the health plan contact center.
• Resubmitted claims due to billing errors or other changes. The member might have visibility into the original claim that was denied, but the claims codes that explain whether a member is responsible for costs are often arcane or hard to understand. Preemptively notifying members why a claim was resubmitted might avoid phone calls.

Applications required

• Pega Customer Service™for Healthcare
• A license for Pega Customer Decision Hub™ is required in order to use Event Strategy Manager

Personas, channels, and usage

The following table shows the personas and channels for each use case in this microjourney.

A self-service channel is a secure channel where personal health information can be presented and where healthcare organizations can determine next steps.

Health plans can leverage their investment in member portals and mobile apps to increase engagement and avoid calls. An agent-assisted channel is a channel where agents interact with customers and perform work, such as answering questions or finding information.

Event Strategy Manager rules

A license for Pega Customer Decision Hub is required to use Event Strategy Manager.

The Coverage Inquiry microjourney uses the Event Strategy Manager, case types, and a data type. This section describes the Event Strategy Manager rules. The Pega Customer Service for Healthcare Implementation Guide describes how to configure and extend the entire microjourney.

The PreemptivelyNotifyBenefits data flow rule creates the actionable events and is marked as an extension point.

For more information about data flows, see Creating a data flow.

The PreemptivelyNotifyBenefits data flow uses the BenefitIssues data set rule to retrieve the 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.

For more information about data sets, see About Data Set rules.

The BenefitIssues event strategy rule creates the events that trigger the preemptive notifications.

For more information about event strategy rules, see About Event strategy rule.

The last step of the PreemptivelyNotifyBenefits data flow rule emails members about the benefit issue.

Stages and steps

This microjourney uses the Event Strategy Manager, case types, and a data type. This section describes the Coverage Inquiry case type. The Pega Customer Service for Healthcare Implementation Guide describes how to configure and extend the entire microjourney.

TheCoverage Inquirycase type includes a life cycle to assist members after they respond to the notification that was created by Event Strategy Manager. The life cycle includes these stages:

• Member Input –Member outreach
• Notify provider–Extendible provider outreach and internal routing
• Resolve – Close issue with member

Data model

This microjourney uses the Event Strategy Manager, case types, and a data type. This section describes the data type. The Pega Customer Service for Healthcare Implementation Guide describes how to configure and extend the entire microjourney.

The Benefit Issues data type holds the coverage issues and related information that is used by the preemptive notifications and subsequent follow-up activity.  Implementations will likely require fields to be added to this data type. 

For more information about data types, see Creating a data type in Dev Studio.

The Coverage Inquiry case type uses the D_BenefitIssue data page of this data type to retrieve the recorded data.

For more information about data pages, see Data pages.

Enabling the microjourney

This microjourney uses Event Strategy Manager to identify actionable events from your data and then act on them by using an extendable case type. In addition to the Event Strategy Manager and case type rules, this microjourney also includes a data type, database table, and associated rules.

Pega recommends that you use or extend the ClaritySkin skin rule for the Coverage Inquiry case type. It is purpose-built for self-service, both web and mobile. To use the ClaritySkin rulefor self-service case types while using a different skin for case types that run in the Interaction portal (agent desktop), create a distinct self-service application that is built on the primary implementation application. For an example, see the CSHCSelfServicesample application that is included in the media.

1. Connect the microjourney to your data.
   1. Identify the data that is required to support the benefit issues.
   2. Create a report by using reporting tools to aggregate the required data.
      For example, the benefit limit issue requires data such as the benefit name, member name, accumulated visits, benefit limit, and benefit year-end date.
   3. Populate the pr_PegaCPMHC_Data_BenefitIssuedatabase table with the aggregated data.
      The table is in the PEGADATA schema.
   4. Map data to fields in the Benefit Issuedata type.
      You can add fields to the data type.
      For more information about data types, see Creating a data type in Dev Studio.
2. Refer to your data.

   1. Open the PreemptivelyNotifyBenefitsdata flow rule.
      The first step in the data flow rule is the BenefitIssues data set, which points to the database table pr_PegaCPMHC_Data_BenefitIssue that is referenced above.

   2. Use the extension point in the second step, the CalculateFieldsRelatedToBenefit data transform, for any calculations that are needed on your uploaded data. Save this data transform into your implementation layer.

   3. Use a Pega Job Scheduler to schedule when to execute the data flow rule.
      For more information about data flows, see Creating a data flow. For more information about Job Scheduler, see Job Scheduler rules.
3. Configure the event strategy rule.
   1. Update the BenefitIssues rule, which creates the events that trigger the preemptive notifications, by saving it into your implementation layer.
   2. To open the filter, right-click the filter step, and then click Properties.
   3. Update the filters to set the conditions for sending preemptive notifications.
      By default, the rule includes two sample filters. For example, you can set these conditions:
      • When to allow these preemptive notifications during the benefit year
      • The percentage of a benefit consumed to trigger a preemptive notification year
   4. If needed, set the Emit step to Only once, which emits the event as it happens, but only once during the specified time interval.
      By default, the Emit step is set to As it happens.
      For more information about event strategy rules, see Event Strategy rule.
4. Schedule automatic email notifications.
   1. In Dev Studio, enter TriggerPreemptiveJourney and press Enter.
   2. Click the Job Scheduler rule.
   3. On the Job Scheduler page, on the Definition tab, turn on the Enable Job Scheduler switch.
   4. In the Schedule section, enter values to schedule the time when the Job Scheduler will run.
   5. Save the rule and check it in.
   6. In the header of Dev Studio, in the application menu, click Definition.
   7. Expand the Advanced tab.
   8. Select the Include in background processing check box, and then click Save.
   9. Open the pega BATCH requestor (Records > SysAdmin > Requestor Type), add the access group for your implementation application, and set it as the default by clicking the radio button next to the access group.
5. Send preemptive notifications.
   1. To change your notification channel, replace the final step of the data flow with a different interaction case type.
      By default, the PreemptivelyNotifyBenefitsdata flow sends notifications by email, using the default Interaction Outbound-Emailcase type (PegaCPMHC-Work-Interaction-Outbound-Email) to send outbound emails.
   2. Save the SetOutboundEmailPreRequisites data transform into your implementation layer and update the values that you pass into your outbound emails.
      It is marked as an extension point.
   3. Save the NotifyBenefitIssue email correspondence rule into the implementation layer and update the content.
6. Configure the Resolve Benefit Issuecase type.
   1. Save a version of the DataBasedOnBenefitdecision table into the implementation layer.
      This is marked as an extension point. The columns refer to areas of the screen that are presented to members in the “Review Issue” step of the “Member Input” stage. The values in the table refer to rules that define the information that is presented.
   2. Save, update, or create rules to be referred to in the version of DataBasedOnBenefit in the implementation layer.
   3. Save the correspondence rules into the implementation layer and add your content to them:
      • NotifyBenefitInformation:Notify a member about a benefit issue and direct them to a portal to learn more.
      • NotifyProvider: Contact a provider to follow up on behalf of the member.
      • BenefitIssueApproved:Notify a member that a request related to the benefit issue has been approved.
      • BenefitIssueNotApproved: Notify a member that a request related to the benefit issue has not been approved.
   4. Review the member-facing self-service screens and update as needed. These screens have been designed as mobile-first. They are responsive to different screen resolutions. These screens are dynamic based on the benefit issue information that is passed to the screens.
      1. Open App Studio.
      2. Open the Resolve Benefit Issue case type.
      3. Save and run the case.
         Note that the key sections to update in the Review Issue step are RemainingBenefitDetailsand RemainingBenefitInformation.

FAQs

1. Can multiple uses cases be implemented concurrently?
   Yes. This microjourney can be used to concurrently outreach to member-facing, confusing, out-of-pocket expense issues and upcoming benefit limits, for example. Each use case requires its own data flow and event strategy rule.
2. Can this microjourney handle large volumes of data?
   Yes. Pega data sets can handle large volumes of data – in the hundreds of thousands for example.
3. Will the self-service component of this case type work in both mobile and web?
   The member screens are designed specifically for mobile self-service, but can be easily configured for the web channel.
4. How do I update the member-facing screens included in the Resolve Benefit Issue case type?
   All of the member-facing screens are found in the first stage of the case type. Update the “Review Issue” and “Review additional Details” steps in the “Member Input” stage.
5. Are there additional ways to update the business process defined by the Resolve Benefit Issue case life cycle?
   Yes. Extend theRouteFollowupWork flow to add process steps to the case life cycle. Extend the Resolution flow to add actions prior to resolution of a case instance.
6. Instead of notifying members by email, can I call them instead or let Pega Customer Decision Hub decide?
   Replace the last step of the data flow rule with an outbound call interaction type or with an activity that refers to a Customer Decision Hub strategy.
   The final step of the PreemptivelyNotifyBenefits data flow can be branched so that certain events are communicated in one channel and other events use a different channel.