Extracting data for reporting, QC, and downstream integration
|Request to Publish|
|Description||Integrating and leveraging PCS data|
|Version as of||1.0|
|Application||Pega Product Composer for Healthcare|
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ Please Read Below ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
Enter your content below. Use the basic wiki template that is provided to organize your content. After making your edits, add a summary comment that briefly describes your work, and then click "SAVE". To edit your content later, select the page from your "Watchlist" summary. If you can not find your article, search the design pattern title.
When your content is ready for publishing, next to the "Request to Publish" field above, type "Yes". A Curator then reviews and publishes the content, which might take up to 48 hours.
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ The above text will be removed prior to being published ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
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 for the implementation team to extract data from PCS will allow 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, Organization Specific Data
- Benefit proper holds 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 , File depending to the most palatable intake form for the organization.
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, a 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. BIX can be tailored to export delta plan data changes - which would report only on 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\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
How can we show these reports better? These are too wide
The implementation team can write complex queries on the data that is produced by these reports.
Flattened data structures (FDS)
For a 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 or the normalized tables of BIX are not a good solution as both are difficult to parse and the results of the lookup are not optimal.
For such business scenarios, the flattened data structures are 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 are designed with 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 look up to the source is required. Each plan is split across several data instances
More information can be found in Generating a flattened structure for plan and product data in the implementation guide. [how to generate a flattened product or plan.]
Flattened data structures contain all the information to determine the benefit, all cost share data, all limit data, pricing information can be integrated. Enhanced and production-level Pega SCE adjudication performance is attained for multiple claim lines using Elastic Search and FDS, round trip using Post Claim REST requests. Ownership of updating the FDS with each release is on PCS product team – providing the holy grail of modularity and decoupling in the enterprise architecture to great extent.
FDS will keep pace with PCS data changes and FDS 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, Sales Automation.
FDS is the recommended source for all integration and data extraction from PCS.