Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

View Benefits Microjourney

Updated on October 13, 2020

The View Benefits Microjourney™ answers questions about a member's coverage. Agents can quickly access critical, personalized information, and focus on the customer's needs. For example, it might be a simple eligibility check or a complex scenario that requires multiple types of coverage information, such as cost share responsibilities, claims, and limits.

Business value

Healthcare organizations can use this Microjourney to easily and consistently address the high volume of plan benefit questions that they receive. Successful resolution of these inquiries is critical to high customer satisfaction and first-call resolution rates. Agents can easily access needed information, whether it is a simple eligibility check or a complex scenario touching multiple types of coverage information, such as cost share responsibilities, claims, and limits.

This Microjourney has been designed to enable healthcare organizations to quickly realize value from their deployment. Many settings can be configured by using Pega’s low-code development tools. Pega data integration tools make connecting to your data sources efficient and easy. The Microjourney also includes numerous extension points, which are documented in this article. 

Personas, channels, and use cases

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

Persona Channel Use Case
Member services representativeAgent-assisted

A member services representative assists health plan members in understanding and using their benefits, for example whether an authorization is required for a procedure, whether members are covered for a benefit, whether they have visits remaining in the benefit year, or a member’s cost-share responsibilities for an upcoming service.

Provider services representativeAgent-assisted
  • A provider checks whether an authorization is required for a procedure.
  • A provider checks whether a member is covered for a benefit or whether they have visits remaining in the benefit year.
  • A provider checks a member’s cost-share responsibilities for an upcoming service, for example, whether a deductible applies and how much the doctor's office should collect as a copayment.
Health plan member 
  • Members try to understand the cost impact of their provider selection, for example, in-network versus out-of-network, or if their network is tiered.
  • Members want to know whether they are covered for a benefit or whether they have visits remaining in the benefit year.
  • Members check their cost-share responsibilities for an upcoming service, for example, whether a deductible applies and how much the doctor's office should collect as a copayment.

Example

Thomas has visited the chiropractor several times and will continue these regular visits. Thomas wants to know “Am I still covered? How many visits do I have left under my insurance plan for this year?" The View Benefits Microjourney enables agents to access the full slate of coverage information in a way that is not overwhelming. By providing quick access and full context, agents can handle calls quickly, answer questions, and anticipate Thomas' needs.

With the available information that is shown in his profile, the agent lets Thomas know that he has already used two visits and has 16 remaining chiropractic visits. Thomas also asks about any outstanding claims, which the agent can access by clicking View ClaimsAll of the information that was discussed with Thomas can automatically be emailed to him. 

Stages and steps

The View Benefit Microjourney stages consists of the following stages: 

  1. The Verify stage can be extended to filter which customers can be serviced by the View Benefits Microjourney. It is skipped by default. To extend it, see Extending the Microjourney.
    Note that this stage is named “Eligibility” in the case template and on the Settings tab, but the stage is re-named in this Microjourney to distinguish it from the concept of benefit eligibility.
  2. The Intake stage collects any information that is needed prior to benefit selection. By default, this information is used in provider services interactions only to identify the member and plan. Member services interactions skip this stage by default.
  3. The Process stage delivers the benefit information that customers request and includes the benefit selection, coverage information, related claims, and a review.
  4. The Resolve stage completes the inquiry and emails the information that was reviewed during the interaction to the customer. This stage can be extended to include other channels, such as mail.

The project team can modify and extend many elements of this Microjourney in App Studio, such as display preferences and step settings, thereby allowing business users to Build for Change®.

Data model

Use the Data model page in App Studio to quickly view and understand the relationship between all data objects in the application. You can add, update, and delete data objects without exiting the visual data model. For information about the Data model page, see Data modeling. For information about connecting to external data entities, see Managing data and integrations with the Integration Designer.

The following figure shows the entity relationship diagram (ERD) for this Microjourney. For each data object, the ERD shows only the properties that apply to this Microjourney.

 

Extending the Microjourney 

In App Studio, open the View Benefits Microjourney (Case types > View Benefits). Certain rules require switching to Dev Studio in order to update them. App Studio indicates when this is required.

Stage 1 - Verify 

By default, Stage 1 - Verify is set to “skip stage”.

To extend this stage to meet your organization's business needs:

  1. Use the DetermineEligibilityToRun decision table to specify individuals who call on behalf of a member, for example, an office manager from the provider service, to launch a case. 
  2. In App Studio, set the Allow user to bypass verification switch (Tools > Verification) and configure the steps in the stage to include an additional verification step. 

Stage 2 - Intake 

The Intake stage handles the member searches upon provider request. The D_Search_Member data page retrieves the member information and related plan information. To retrieve data from your own implementation-layer classes for member, subscriber, and plan tables, override the LoadMembersBasedOnSearchCriteria report definition, save the rule into your implementation-layer member class, and update the subscriber, policy, and plan data classes in the Data Access tab of the LoadMembersBasedOnSearchCriteria rule. For more information, see Learning about report definitions

NoteBy default, there is nothing in Stage 2 that applies to member services. This stage is related to provider services only. 

Stage 3 – Process request

This stage includes steps to select a benefit to review, display coverage information, display related claims, and review the information with the customer. The steps in this stage can be re-run so that agents can discuss multiple benefits within one interaction.

Benefit selection

The Benefit search step includes both a search and a list common benefits, which are bookmarked to save agents time. Operators with the role of CS:ExpressMgrTools can define these bookmarks in the Interaction portal by clicking Application Tools > View Benefits > Configure

Both the Benefit search and the common benefits configuration tool use a type-ahead search that is populated by the D_BenefitNamesByPlanPurposeAndName data page. Update the data source to point to your plan benefits system of record.

The Benefit search step retrieves the benefits that are bookmarked in the configuration tool by using the read-only D_GetCommonBenefits data page.

Display of coverage information

This step displays rich coverage information to enable highly personalized interactions:

  • Plan benefit coverage by network or tier: Information about the selected benefit, such as whether a deductible applies or copay amount, is retrieved by using the D_BenefitsByPlanAndPurpose data page. 
  • Benefit usage: Usage accumulators, such as how many times a benefit has been used in a benefit year, are retrieved by the D_Getaccumulatorheader data page.
  • Plan level cost shares: Also displays the member’s plan-level cost shares and statuses, such as what types of deductibles are in a plan and how much has been accumulated to date.
    This information is retrieved by using the D_GetPlanAccumulators data page, which in turn uses the GetPlanLevelAccumulators report definition. If you add other properties, then you must update this report definition and the MapAccumulatorsData data transform.

Claims

Claims are retrieved by using the D_FetchClaimsUsingSearchCriteria data page, which should point to an organization’s claims system of record.

Review

If you maintain your history table for auditing the reviewed benefits, use the D_ReviewedBenefitsHistoryList data page to retrieve the benefit summary information that was captured in a given case or a specified time period. 

Stage 4 - Resolve 

This stage completes the inquiry and provides options to send information to the customer. Email is the default setting.

You can modify the IsDistributionMethodEmailcondition When rule in Dev Studio if your organization requires another communication channel. You can also use this stage to extend your workflow if your organization requires a post-inquiry follow-up. 

  1. Click the Is communication channel selected email step. 
  2. In the right pane, add a path, and then add the steps that are specific to your routing logic.

Reporting

To maintain application performance, when you create usage reports on this Microjourney, for example benefits most recently researched, use the following class and table so that you do not impact the application's work table.

  • The Reviewed Benefits Historylink class (PegaCPMHC-Link-ReviewedBenefitsHistory) combines data from the View Benefits case instances and the Coverage, Benefit Usage, and Claim data object instances.
  • The pegadata.pr_PegaCPMHC_Link_Review_018eb table has been included to store the results of running this Microjourney. Alternatively, another table can be mapped to the Reviewed Benefits Historylink class.

    By default, the following properties are recorded in the table. You can add more properties by saving the MapPropertiesToReviewedBenefitsHistory data transform (marked as an extension point) in the implementation layer, and then updating the rule.

Allowed Units

Are Benefit Claims Reviewed

Are Benefit Claims Reviewed

Benefit Alias Name

Claim ID

Claim Member Cost

Claim Service Date

Claim Service Provider

Claim Status

CoInsurance Amount

Copay Amount

Family Deductible Info

Individual Deductible Info

Is Benefit Coverage Reviewed,

Is Benefit Usage Reviewed

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us