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 rule for 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 CSHCSelfService sample application that is included in the media.

For more information, see Coverage Inquiry Microjourney.

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_BenefitIssue database table with the aggregated data.
      The table is in the PEGADATA schema.
   4. Map data to fields in the Benefit Issue data 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 PreemptivelyNotifyBenefits data 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. 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 notification.
   1. In the header of 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 for when the Job Scheduler will run.
   5. Save the rule and check it in.
   6. In the header of Dev Studio, from 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 (RecordsSysAdminRequestor 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 PreemptivelyNotifyBenefits data flow sends notifications by email, using the default Interaction Outbound-Email case 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.
      This data transform is marked as an extension point.
   3. Save the NotifyBenefitIssue email correspondence rule into the implementation layer and update the content.
6. Configure the Coverage Inquiry case type.
   1. Save a version of the DataBasedOnBenefit decision table into the implementation layer.
      This decision table is marked as an extension point. The columns refer to areas of the screen 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 that will 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 by opening App Studio, open the Coverage Inquiry case type, and then save and run the case.

      Note that the key sections to update in the Review Issue step are RemainingBenefitDetails and RemainingBenefitInformation.

      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.