Member data type in Pega Customer Service for Healthcare

From PegaWiki
Using the Member data type in Pega Customer Service for Healthcare / This is the approved revision of this page, as well as being the most recent.
Jump to navigation Jump to search

Member data type in Pega Customer Service for Healthcare

Description Learn how you can capture consumer data in Pega Customer Service for Healthcare with the Member data type
Version as of 8.5
Application Pega Customer Service
Capability/Industry Area Healthcare

The Member data type can be used for all healthcare consumers, such as health plan members, patients, and their representatives.

Data model

Pega Customer Service for Healthcare includes a rich data model out-of-the-box. Project teams should use and extend these default data types whenever possible to avoid unnecessary complexity and to make implementations faster.

This rich data model includes a data type for healthcare consumers - PegaCPMHC-Party-Member. The type includes properties and data pages for demographic, contact, coverage, and other common information, such as the consumer’s primary care provider.

While consumers of healthcare and life science services have different relationships with organizations across the healthcare system, much of the information about them is the same, regardless of whether they are health plan or provider members, or life science patients. Accordingly, this data type is intended for all healthcare and life science organizations.

The application data model includes many data types in Pega Foundation for Healthcare, on which Pega Customer Service for Healthcare is built. Where foundation data types have been extended in Pega Customer Service for Healthcare, implementation project teams should inherit from the extended data type to make use of all available properties and data pages. This approach applies to PegaCPMHC-Party-Member.

Project teams should review the available properties and add new ones into the implementation layer data type to address any gaps. Likewise, project teams should review the available data pages before creating new ones, because redundant data pages create unnecessary complexity. This method is especially important when deploying, extending, or building new microjourneys; it is likely that the same data is used elsewhere in the application and that existing rules can be reused.


Pega Customer Service for Healthcare interactions focus on a contact, using the PegaCA-Interface-Contact data type. The first step in any interaction type is to identify the customer. This might be searched for and selected by an agent or passed into the application by an interactive voice response (IVR) system. For consumer interactions, information in the PegaCPMHC-Party-Member class is retrieved and then declared the interaction contact.

Pega Customer Service for Healthcare includes the ability for authorized representatives to interact on behalf of consumers, for example, a patient’s healthcare proxy. When a customer identifies that they are interacting on behalf of a consumer, agents can select that person from a list of authorized representatives. Project teams need to extend the interactions to include their clients’ specific needs, such as whether agents can immediately create and interact with a new representative. That authorized representative is also declared in the interaction as a contact, while the consumer’s information remains in focus during the interaction (also as a contact).

In many scenarios, Pega Customer Service for Healthcare is not the system of record for consumer information. For example, healthcare providers retrieve patient information from an electronic health record (EHR). When using Microjourneys that are included out-of-the-box, it is assumed that any updated consumer information is verified before a system of record is updated.