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
PCS application is a healthcare application that is built on Pega Healthcare Foundation. Product and plan data in PCS is highly nested. Many layers of inheritance in play for all the coverage information in PCS. Only incremental changes are being stored at each layer in product and plan for the coverage information. Getting complete view of the cost shares associated with a plan requires complex navigation of the clipboard. All data is XML and Pega blob based – 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 4 available options to extract data from PCS. Implementation team needs to carefully study the pros and cons of each and have a clear understanding on the client needs before finalizing the architecture. The details below would 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). So having a solid understanding of the clipboard structure is imperative for all implementation teams. PCS Data can be exported from the clipboard. After Plan or Product is Approved in Production, iterate the BenefitSetTree to load all required data:
- UnionData and Benefit proper objects.
- UnionData: CostShare, Accumulator, Policy, Claim Instructions, Metadata, Notes, Organization Specific Data
- Benefit proper holds Benefit Mapping
Next step for the implementation team would be to transform the data in final form. Options are DB Table, Connect to Service (SOAP, REST,XML) APIs , File depending to the most palatable intake form for the organization.
This option involves significant effort and maintenance for the implementation teams and is not recommended.
For transactional reporting needs of the organization for product repository, the data configured in PCS needs to be exported out 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 the user specify export rules to define specific data element to export to: a normalized DB table, or CSV file, or XML. This helps to transform Pega blob to user defined extract format. BIX runs as a series of batch utilities via a Linux scheduler, or an Agent in PRPC, or as shell script files. BIX can decrypt a PRPC Blob and export data as a normalized SQL DB table into a data repository. BIX can be tailored to export delta plan data changes.
Clear advantage over using clipboard directly as there is no inheritance look up or clipboard mapping involved. Implementation team would be responsible for configuring the BIX and updating the scripts as changes are made to the base PCS. This could have impact to the upgrade cycles and BIX may require additional license.
Data extract reports
The benefit coding 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. Data extract 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 single view of all the plans and benefits along with the associated cost shares. The data output can be Excel or Database. Using the built-in extensions, these reports can be extended to include client implementation properties.
There are two types of reports
- High level - Summary report
- Detailed - Cost share detail report
Implementation team can write complex queries on the data produced by these reports.
Flattened data structures (FDS)
For a highly performant claims adjudication system 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 would not be a good solution as both would be difficult to parse and the results of the look up would not be 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 creates multiple data instances which have all the benefit and cost share data associated with the plan. FDS can be turned on using the options on the 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 Flattened Data Model. Each plan is split across several data instances
More information can be found at []
Flattened data structure contains all 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.