Design inputs for extracting data for reporting, QC, and downstream integration

From PegaWiki
Extracting data for reporting, QC, and downstream integration / This is the approved revision of this page, as well as being the most recent.
Jump to navigation Jump to search

Design inputs for extracting data for reporting, QC, and downstream integration

Description Design inputs for extracting data for reporting, QC, and downstream integration
Version as of 8.5
Application Pega Product Composer for Healthcare
Capability/Industry Area Healthcare and Life Sciences

Integrating and leveraging PCS data[edit]

Pega Product Composer for Healthcare (PCS) is a healthcare application that is built on Pega Foundation for Healthcare. Product and plan data in PCS is nested. Many layers of inheritance affect the coverage information in PCS. Only incremental changes for coverage information are stored at each layer in products and plans. Obtaining a complete view of the cost shares that are associated with a plan requires complex navigation of the clipboard. All data is XML and Pega blob-based, which is consistent with any Pega-based application.

Having a clear understanding of the options available to extract data from PCS allows for the creation of strong and resilient system architecture.

Options to extract data from PCS[edit]

There are five available options to extract data from PCS:

  • Clipboard
  • Business Intelligence Exchange (BIX)
  • Data extract reports
  • Flattened data structures (FDS)
  • API

You need to carefully study the advantages and disadvantages of each option and clearly understand the client needs before finalizing the client architecture. The details below can assist you in making an informed architecture decision.


The data on the clipboard is used to populate all the UX screens in PCS (or any Pega application). Having a solid understanding of the clipboard structure is imperative. You can export PCS data from the clipboard. After the plan or product is approved in production, iterate (loop through) the BenefitSetTree to load all required data:

  • UnionData and Benefit proper objects (benefit definition-specific data)
  • UnionData: CostShare, accumulator, policy, claim Instructions, metadata, notes, and organization-specific data
  • Benefit proper holds the benefit mapping

The next step is to transform the data into the final form. Options are database table, Connect to Service (SOAP, REST,XML) APIs, or flat file. The final output option that you select depends on the organization's architecture.

The Clipboard option is not recommended because of the significant effort and maintenance.


For the transactional reporting needs of a product repository for an organization, the data configured in PCS needs to be exported to relational tables. Like all Pega applications, the rules are stored in a proprietary, encrypted, blob format in PCS.

BIX is a Pega-developed data export utility that lets you specify export rules to define specific data elements to export to a normalized database table, CSV file, or XML format. This helps to transform the Pega blob to a user-defined extract format. BIX runs as a series of batch utilities by using a Linux scheduler, Pega Platform agent, or shell script files. BIX can decrypt a Pega Platform blob and export the data as a normalized SQL database table into a data repository. You can tailor BIX to export delta plan data changes, which reports only the changes made to the plan.

There is a clear advantage over using the clipboard directly as there is no inheritance lookup or clipboard-mapping involved. You are responsible for configuring BIX and updating the scripts as changes are made to the base PCS. This could impact the update cycles.

Note: The use of BIX might require an additional license.

Data extract reports[edit]

The benefit coding QC,QA team needs a 360-view across the product repository in order to review the configurations across multiple products and plans.

To serve such QA requirements, PCS provides data extract reports. These reports provide a quick view of all the products and plans configured in the system and can be a great tool for visual or automated QA across the product repository. They provide a single view of all the plans and benefits and the associated cost shares. The data output can be Microsoft Excel or database. By using the built-in extensions, you can extend these reports to include client-implementation properties.

There are two types of reports:

  • High level - Summary report
  • Detailed - Cost share detail report
Sample PCS Summary report

Cost share detail report.png

You can write complex queries on the data that is produced by these reports. For more information, see the Report Definition Query tab.


For highly performing claims adjudication systems, which rely on the product repository as the source of truth for benefit determination, the ability to get to the right benefit and associated cost shares in a timely manner is critical. The nested structures of PCS and the normalized tables of BIX are not a good solution because both are difficult to parse and the results of the lookup are not optimal.

For such business scenarios, FDS is an out-of-the-box PCS feature which takes a product or plan and transforms them into multiple data instances which have all the benefit and cost share data associated with the plan. You can enable FDS by using the options on the Product Composer System Configuration page. FDS is designed with the performance needs of an adjudication system where millions of claims are being adjudicated in a single day. PCS inheritance is completely resolved in the flattened data model, which means that all cost shares are associated with each benefit and no lookup to the source is required. Each plan is split across several data instances:

  • PegaHC-Data-Plan (Benefit plan)
  • PegaHC-Data-Benefit-Definition (Benefit definition)
  • PegaHC-Data-Benefit-Coverage (Benefit coverage)
  • PegaHC-Data-BenefitSummary(Benefit summary)
  • PegaHC-Data-BenefitCategory (Benefit category)
  • PegaHC-Data-PlanBenefitCategoryAssociation (Association between plan and benefit category)
  • PegaHC-Data-Grouper-Definition(Grouper definition)
  • PegaHC-Data-Grouper-Coverage (Grouper coverage

For more information, see Generating a flattened structure for plan and product data.

Flattened data structures contain all the information to determine the benefit, all cost share data, all limit data, and pricing information. FDS is updated with each release of PCS to reflect any changes in the PCS entities data model. All PCS APIs use FDS as the source for integration with other Pega Healthcare products (Pega Customer Service for Healthcare, Pega Smart Claims Engine, and Pega Sales Automation for Healthcare).

As a result of these advantages, FDS is the recommended method for integration and data extraction from PCS.


Out-of-the-box, the PCS application provides the following APIs that allow you to access the PCS data:

Get Plan Catalog[edit]

The ability to expose the plan catalog allows the sales team to offer the right plans to customers (the request allows the invoking system to filter the plan catalog as needed). Also, having a predefined integration to access the plan catalog provides the basis for supporting a plan customization request workflow (for example, as part of the large group sales process).

Get Plan Detail[edit]

Get complete plan details through the flattening extract. The complete plan details for the requested plan are returned as the response.