Implementing Patient Assistance for Pega Care Management Edition

From PegaWiki
Implementing Patient Assistance for Pega Case Management Edition / This is the approved revision of this page, as well as being the most recent.
Jump to navigation Jump to search

Implementing Patient Assistance for Pega Care Management Edition

Description Learn how to implement the Patient Assistance case type in an external desktop by using Pega's Digital Experience APIs
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 the Patient Assistance implementation[edit]

For the Patient Assistance case type, the parallel flows design methodology has been followed and tested by using the React starter pack. A parallel process (Capture case details in the external desktop) in the Intake stage has been added to support the case in the external desktop. The IsThisExternalDesktop when rule was used to check if the process supporting the external desktop should be run. This checks if the requestor session is through APIs and if the active channel is ExternalDesktop. The Change stage shape with the .CleanUpProcesses parameter set to true has been added in the external desktop process to support the omni-channel experience.

pyDefault case type rule

When the CSR launches the case in the Interaction portal, both tasks are displayed. After one of them is completed, the case moves to the next stage.

Context for the case type[edit]

For an external desktop agent to launch the Patieince Assistance case type, the customer and policy context are required.  

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

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

Patient Assistance Microjourney implementation[edit]

The following are design decisions that were made for this existing case type to render it in an external desktop.:

  • Leveraged the DX v1 API capabilities while authoring the case for the best user experience. The patient details collection functionality was split across two pages. This means hat the first page displayed the patient’s insurance details, medications, primary care provider, and financial details. The next page displayed the address information because the facility address depends on the primary care provider that was selected on the first page.
  • In the practitioner interaction, the member search and selection logic were also split across two pages. The first page captured the member’s last name and first name. The next page showed the search results and the provision to select a member.
  • The manager approval is outside the scope of the external desktop.This is a backend process and can be implemented according to the customer needs.
  • The Confirm harness was re-built in the PegaCSHC-Cases-CME ruleset so that it appears as expected for all service cases 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 Patient Assistance case type for member and provider interactions. It also includes workarounds that were used.

Member interaction[edit]

This section describes issues that were found during a member interaction.

Collect details from patient page[edit]

This is the first page that displays when the case is launched for a member. This page shows member’s insurance details followed by sections to capture treatment details, provider details, and financial details.

Adding or deleting a row in the Treatment details section erases entered data[edit]

The DX API refreshed and reloaded the complete page thereby erasing the unsaved data.

Workaround: Moved the Treatment details section above the Provider details section so that it becomes the first one to capture the data. After the treatment details were entered, then the other details were filled in.

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

Search using multiple fields is not supported as of React starter pack version 1.4.

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

Auto-complete control does not have uniform width[edit]

React starter pack version 1.4 does not support the width customization of the auto-complete control.

Workaround: Modified the React starter pack code for the dropdown control.

Select shipment address[edit]

This page was introduced because the facility address is dynamic and changes based on the provider were selected on the previous page. Only one address can be selected, and the required validation has been added to the flow action.

The address selection sections could not be displayed on the previous page[edit]

DX v1 APIs do not support refreshing other sections.

Workaround: Separated the address selection section on this page. After the provider was selected on the previous page, the facility address can be displayed on this page.

Get treatment details from provider[edit]

After the initial details are collected from patient, the payer needs to get confirmation about the medication for which the assistance is sought. The case gets routed to the patient assistance work queue and can be opened from the operator dashboard. This involves initiating an interaction with the provider that was selected during the intake process and will be handled by the customer. After the interaction is launched, the following page displays the patient and treatment details. Then the CSR confirms the treatment details with the provider or makes changes to the treatment as instructed by the provider.

Auto-complete control does not have uniform width[edit]

React starter pack version 1.4 does not support the width customization of the auto-complete control.

Workaround: This can be addressed by modifying the React starter pack code for the dropdown control.

Approval process[edit]

Patient assistance approval is a back-office process which the customers can implement in their own way. If the request needs a manager approval, the case can be opened from the Patient assistance:Manager approval work queue and can be processed further. After the case was manager-approved or auto-approved, it was resolved.

Provider interaction[edit]

Search patient[edit]

The Patient assistance in a provider interaction begins from this page where the CSR helps the provider search for a patient. The CSR needs to enter the patient's last name or first name or both and submit it to see the search results on the next page.

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

Patient search results are a PageList of type "x-y-z" under the Members work object (pyWorkPage). After a member is selected and submitted, the DX API commits only the editable fields on pyWorkPage before the next assignment is displayed. As the member object is not edited (only a checkbox is selected), the selected member could not be identified on the next page for viewing more details or selecting an action.

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

Select patient[edit]

This page displays the search results based on the last and first name entered on the previous page. A checkbox for selecting a patient has been added next to each row.

The read-only grids display Add and Delete buttons[edit]

This behavior is the same on all the pages that have read-only grids because there is an issue in React starter pack version 1.4.

Workaround: There is no functionality attached or required with these buttons for the read-only grid. You can remove these buttons by deleting the <Table.Footer> element from the PegaForm.js file during the React starter pack installation.  

Get treatment details from provider[edit]

This page is used to collect the treatment details from the provider.

Uneven width and alignment of the fields in treatment details grid[edit]

There is an issue in React starter pack version 1.4.

Workaround: Added the required styling to the grid.

Collect details from patient[edit]

This page is used to confirm the medication details and get the financial details from the patient after the initial request is submitted by a provider.

The read-only grids display Add and Delete buttons[edit]

This behavior is the same on all the pages that have read-only grids because there is an issue in React starter pack version 1.4.

Workaround: There is no functionality attached or required with these buttons for a read-only grid. You can remove these buttons by deleting the <Table.Footer> element from the PegaForm.js file during the React starter pack installation.  

Confirm pages[edit]

When the request is submitted by a CSR in a patient interaction, a confirmation is displayed as shown in the following figure:

When the request is submitted by a CSR in a provider interaction, a confirmation is displayed as shown in the following figure:

When the request is awaiting approval, a confirmation is displayed as shown in the following figure:

Accessing work queues[edit]

The Patient Assistance case type routes to different work queues. The React starter pack does not display all the work queues configured at the work group to which user belongs.

Because the React starter pack is getting the queues directly from the operator record, the following workaround is suggested to access work queues,

Workaround: Added the queues to the operator record.

In the Pega Interaction Portal, when the cases are opened from the Patient assistance work queues, the CSR is required to establish an interaction. By using the DX v1 API, the cases run independently of the Pega interaction. 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 into external desktops by leveraging the DX v1 APIs and making reasonable changes in the UX. This requires little effort and results in great benefits.