Implementing Claims Inquiry for Pega Case Management Edition

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

Implementing Claims Inquiry for Pega Case Management Edition

Description Learn how to use Pega's case management capabilities in an external desktop.
Version as of 8.7
Application Pega Customer Service
Capability/Industry Area Healthcare and Life Sciences



Before you begin[edit]

For more information about different recommended design methodologies, prerequisites, troubleshooting common issues, and recommendations to leverage Pega Customer Service TM Case Management Edition, see Implementing case types using Digital Experience APIs for Pega Customer Service Case Management Edition.

Design methodology for Claims Inquiry implementation[edit]

For the Claims inquiry Microjourney, the Rebuild UX design methodology has been followed and tested by using the React starter pack. The rules that were created for this work are available in the PegaCSHC-Cases-CME ruleset, which is included with Pega CRM for Healthcare.  

Context for case type[edit]

To display the Claim Inquiry Microjourney in an external desktop or web applications, you need to set the customer context by passing the context parameters in the React starter pack to the Create Case API (DX v1 API).

The context parameters are dynamically passed from the application settings option, as shown in the following figure:

The following list shows the context in JSON format for different customer types in healthcare:

  • Member: HCCustomerType:"Member",MemberID:"MB20XXXXXX10",PlanID:"PLAN-XXXX",PolicyNumber:"PO201XXXXXX3",ContactId:"MB2XXXXX10"
  • Practitioner: HCCustomerType:"Provider",EntityTypeQualifier:"1",ProviderNumber:"PC201XXXXXXX"
  • Provider: HCCustomerType:"Provider",EntityTypeQualifier:"2",ProviderNumber:"PR201XXXXXX10",ParticipatingProvider:"PC20XXXXX2426",ContactId:"COXXXXXXXX"

Claims Inquiry Microjourney implementation[edit]

This section describes the design decisions that were made for the existing case type to render it in an external desktop:

  • Leveraged the DX v1 API capabilities while authoring the case type for the best user experience. The case type was simplified by splitting the intake process into three pages thereby allowing the user to focus on one task at a time.
    • You enter search criteria and submit to display claims results on the first page where you can then select a claim and submit it for more details on the second page.
    • On the second page, you can view the reviewed claim and provide the reason from the drop-down list for the action taken on the second page such as authorization, claim overpaid, and denied. You also provide any comments.
  • The Confirm page was re-built in the PegaCSHC-Cases-CME ruleset so that it appears as expected for all case types and for all appropriate channels as well.

Implementation details[edit]

This section describes the DX v1 API and React starter pack issues that were encountered while rendering the Claims Inquiry case type. It also includes the workarounds that were used.

Search claims page[edit]

Search fields differ based on the healthcare customer type.

In a member interaction, you can search the claims by claim dates, claim ID, member name, service provider NPI, facility NPI, and benefit.In a practitioner interaction, you can search the claims by claim dates, claim ID, member name, facility NPI, and billing provider as well as claims that are related to different unrelated members.In a provider interaction, you can search the claims by claim dates, claim ID, member name, service provider, facility NPI, and billing provider as well as claims that are related to different unrelated members.

Search results not displayed on the same page as that of search criteria[edit]

Claim search results are a pagelist of type "x-y-z" under the ClaimsInquiry work object (pyWorkPage). After a claim is selected and submitted, the DX API commits only the editable fields on pyWorkPage before the next assignment is displayed. Because the claim object is not edited (only a checkbox is selected), the selected claim cannot be identified on the next page so that you can view more details or select an action.

Workaround: Clicked Submit after entering the search criteria and performed the search in post-processing of the current flow action. This helped display the search results on the next page.

Date range control not supported by DX v1 API[edit]

The DX v1 API does not return the date range control metadata.

Workaround: Replaced the date range control with date controls. Custom validations such as end date added after the start date were handled at the flow-action level validations.

Auto-complete control and does not support search on multiple fields[edit]

Search by using multiple fields is not supported as of React starter pack version 1.4. Enabling search on multiple fields might be supported in future versions of the React starter pack.

Workaround: Made the most appropriate property the primary search field.

Select claims page[edit]

This page has been introduced to display the claim results for the search criteria provided on the Search claims page, shown above. Also, a provision to navigate to the previous Search claims page has been added (using a local action), so that you can revise the search criteria. Click the Actions menu to do this task.

Issue with the Master detail option in a Table layout[edit]

The Master detail option in a Table layout cannot be used to display additional details about the claim. Currently, DX v1 API does not support the Master detail option in a Table layout .

Workaround: Added checkboxes for each claim search result. The claim search results and their corresponding selection done on this page are persisted by DX v1 API when you submitt the current page.This faciliatates the display of more details of the selected claims on the next page.

Review claim page[edit]

This page displays the master details of the claims that were selected on the Select claims page. The details include claim lines, member cost, authorizations, provider, and history-related information in a stacked layout. If there are multiple claims, then the details for each claim appear one below the other. The following figure shows that two local actions, Search claims and Select claims, have been added to the Actions menu so that you can navigate back to previous pages:

Issue with the Master detail option in a Table layout[edit]

Additional details for a claim could not be displayed by using the Master detail option in a Table layout. Curently, the Master detail option in a table layout is not supported in version 1.4 of the React starter pack. Also a Tabbed layout is not supported.

Workaround: For each selected claim, used a Stacked layout to display more information such as claim lines, authorizations, provider details, and claim history.

Modal dialog box not supported[edit]

Cost share details for Member cost could not be displayed by using a modal dialog box. The modal dialog box is not supported by the React starter pack. As a result, the cost breakdown cannot be displayed when hovering over the Member cost data.

Workaround: Used a Stacked layout to display cost share details with other details of a claim such as claim lines, authorizations, provider details, and claim history.

Issue with read-only grids[edit]

An issue in the React starter pack v 1.4 means that the read-only grids display the Add and Delete buttons. This behavior is the same wherever read-only grids are used.

Workaround: There is no functionality attached or required with these buttons for read-only grids. Removed the buttons by deleting the <Table.Footer> element from the PegaForm.js file in the React starter pack installation as shown in the following figure:

Selected claims page[edit]

This page displays the claims that were selected for action on the Review claims page after going through details of a claim such as claim lines, authorizations, provider details, and claim history. It allows you to select a reason for each claim that you are acting on. When you submit the claim, the child cases are spawned for each applicable claim and are available in their respective work queues for further processing.

Text area does not work in the Grid layout[edit]

Using a text area to enter comments for each selected claim in a modal dialog box is not possible in the Grid layout. Modal dialog boxes which would be able to accommodate a bigger text area to enter comments are not supported in DX v1 API.

Workaround: Introduced an editable comments cell in each row to capture notes.

Confirm page[edit]

The following figure shows the Confirm page:

Lack of support for circumstanced rules[edit]

The Confirm harness is rendered in DX v1 API due to lack of support for circumstanced rules. The new Confirm harness is a circumstanced rule.

Workaround: The Confirm harness has been customized for Pega Case Management Edition in the PegaCSHC-Cases-CME ruleset so that it displays as expected for all case types and for all appropriate channels.

Launching sub-cases from work queues[edit]

You can create a claims inquiry for a member, provider, or practitioner. The child cases that are spawned as part of this case are routed to the appropriate work queues. These sub-cases are processed by users who have access to those work queues. In the React starter pack, you can access the work queues from the dashboard, as shown in the following figure:

Configured work queues are not working[edit]

All the work queues that were configured at the work group to which user belongs are not available for the user. The React starter pack is getting the queues directly from the operator record.

Workaround: Added the queues to the operator record as shown in the following figure:

Research page[edit]

This section describes the user interface when you open the child cases from the work queues. To do this, select the required work queue, and then click the row that shows the sub-case that you want to open.

When you select a claim for research, the Claims Inquiry case type spawns a Claims Research sub-case which is routed to the Member claims to research or Provider claims to research work queues based on whether the Claims Inquiry case type is for a member, provide, or practitioner. An agent from the Claims Research department typically acts on the sub-case. When launched from one of the above work queues, the following page displays the reason for researching this claim with other details of the claim. You can enter the comments and notes pertaining to the research in the Add notes text box.

Text box not working in Grid layout[edit]

Using a text area to enter research notes for each claim in a modal dialog box is not possible in the Grid layout. Modal dialog boxes, which can accommodate a bigger text area to enter comments, are not supported in the DX v1 API.

Workaround: Introduced an editable comments cell in each row to capture notes.

Provider follow-up page[edit]

When you select a claim for provider follow-up, the Claims Inquiry case type spawns a ProviderFollowUp sub-case which is routed to the Provider follow-up for members work queue. When the sub-case is launched from the work queue, it displays the claims details. The agent can enter comments and notes that the provider provides as part of this follow-up in the Comments text box.

Text box not working in Grid layout[edit]

Using a text area to enter research notes for each claim in a modal dialog box is not possible in the Grid layout. Modal dialog boxes, which can accommodate a bigger text area to enter comments, are not supported in the DX v1 API.

Workaround: Introduced an editable comments cell in each row to capture notes.

Claims adjustment page[edit]

In a provider or practitioner interaction, when a claim is selected for adjustment, the Claims Inquiry case type spawns an AdjustmentReview sub-case which is routed to the Claims adjustment requests for Providers work queue. When launched from the work queue, the sub-case displays the claims details, shown in the following figure, where a back-office agent can enter comments and notes related to the Claim adjustment request in the Comments text box:

Text box not working in Grid layout[edit]

Using a text area to enter research notes for each claim in a modal dialog box is not possible in the Grid layout. Modal dialog boxes, which can accommodate a bigger text area to enter comments, are not supported in the DX v1 API.

Workaround: Introduced an editable comments cell in each row to capture notes.

Completed claims inquiry page[edit]

This page displays when you open the Claims Inquiry case type from the Completed claims inquiry for member/provider work queue. The following figure shows the parent cases for which all the child cases have been resolved:

Text box not working in Grid layout[edit]

Using a text area to enter research notes for each claim in a modal dialog box is not possible in the Grid layout. Modal dialog boxes, which can accommodate a bigger text area to enter comments, are not supported in the DX v1 API.

Workaround: Introduced an editable comments cell in each row to capture notes.

In the Pega Interaction Portal, when the cases are opened from work queues, the CSR is required to establish an interaction which navigates the CSR to a part of the user interface based on the sub-case launched. But by using the DX v1 API, the cases run independent of Pega interactions. A customer can run these Pega case types with minimal UX updates from an external desktop which might be using a different technology or product than Pega.

Conclusion[edit]

You can embed Pega’s out-of-the-box case types in external desktops by leveraging the DX v1 APIs and making reasonable changes in the UX. Although the effort is low, great benefits result.