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||Product Composer for Healthcare|
Integrating and leveraging PCS data
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 affects 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 will allow for the creation of strong and resilient system architecture.
Options to extract data from PCS
There are four available options to extract data from PCS:
- Business Intelligence Exchange (BIX)
- Data extract reports
- Flattened data structures
The implementation team needs 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 the implementation teams 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 for all implementation teams. 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 for the implementation team 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 architecture of the client team.
The Clipboard option is not recommended because of the significant effort and maintenance for the implementation teams.
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 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 would report 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. The implementation team is responsible for configuring BIX and updating the scripts as changes are made to the base PCS. This could have impact to the upgrade cycles. BIX might require an additional license.
Data extract reports
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. 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
The implementation team 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, Flattened data structures (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. FDS can be turned on 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 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, pricing information. Enhanced and production-level Pega SCE adjudication performance is attained for multiple claim lines using Elastic Search and FDS. Ownership of updating the FDS with each release is the PCS product team, resulting in providing the holy grail of modularity and decoupling in the enterprise architecture to a great extent.
FDS will keep pace with PCS data changes and it avoids any inheritance processing. All PCS APIs use FDS as the source and it allows integration with other Pega Healthcare products: Customer Service, Smart Claims, and Sales Automation.
FDS is the recommended source for all integration and data extraction from PCS.