Difference between revisions of "Extracting data for reporting, QC, and downstream integration"

From PegaWiki
Jump to navigation Jump to search
m
Tag: Visual edit
(updated application name and industry)
Tag: Visual edit
 
(21 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{New request
+
{{Design pattern|Title=Extracting data for reporting, QC, and downstream integration|Description=Design inputs for extracting data for reporting, QC, and downstream integration|Version=8.5|Applications=Pega Product Composer for Healthcare|Capability Area=Healthcare and Life Sciences|Owner=shahp@pegasystems.com}}
|Request to Publish=
 
|Curator Assigned=
 
|Description=Integrating and leveraging PCS data
 
|Applications=Pega Product Composer for Healthcare
 
|Capability Area=Healthcare
 
|Version=1.0
 
}}
 
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓  '''<big>Please Read Below</big>'''  ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
 
 
 
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.
 
 
 
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ '''<big>The above text will be removed prior to being published</big>''' ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
 
  
 
== Integrating and leveraging PCS data ==
 
== 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.  
+
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 for the implementation team to extract data from PCS will allow creation of strong and resilient system architecture.
+
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 ==
 
== 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.
+
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.
  
'''<big>Clipboard</big>'''
+
=== '''<big>Clipboard</big>''' ===
 
[[File:PCS clipboard page.png|thumb|337x337px|PCS clipboard page]]
 
[[File:PCS clipboard page.png|thumb|337x337px|PCS clipboard page]]
  
''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:  
+
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 and Benefit proper objects.
+
* UnionData: CostShare, accumulator, policy, claim Instructions, metadata, notes, and organization-specific data
 
+
* Benefit proper holds the benefit mapping
-       UnionData: CostShare, Accumulator, Policy, Claim Instructions, Metadata, Notes, Organization Specific Data
+
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.  
 
 
-       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.
 
 
 
'''<big>BIX</big>'''
 
  
''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.''
+
The Clipboard option is not recommended because of the significant effort and maintenance.
  
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.
+
=== '''<big>BIX</big>''' ===
 +
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.  
  
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.
+
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.  
  
'''<big>Data extract reports</big>'''
+
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 upgrade cycles. 
  
''The benefit coding QA team needs a 360 view across the product repository in order to review the configurations across multiple products and plans.''
+
'''Note:''' The use of BIX might require an additional license.
  
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.
+
=== '''<big>Data extract reports</big>''' ===
[[File:Summary report.png|thumb|1270x1270px|Sample PCS Summary report]]
+
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.  
[[File:Cost share detail report.png|thumb|1270x1270px|Sample PCS Cost share detail report]]
 
There are two types of reports
 
  
-       High level - Summary report
+
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.
  
-       Detailed - Cost share detail report
+
There are two types of reports:
  
Implementation team can write complex queries on the data produced by these reports.
+
* High level - Summary report
  
'''<big>Flattened data structures (FDS)</big>'''
+
* Detailed - Cost share detail report
 +
 +
[[File:Summary report.png|1170x1170px|Sample PCS Summary report|left]][[File:Cost_share_detail_report.png|frameless|1170x1170px]]
 +
You can write complex queries on the data that is produced by these reports. For more information, see the [https://community.pega.com/sites/default/files/help_v85/index.htm#oxy_ex-1/platform-helpsystem/rule-/rule-obj-/rule-obj-report-/rule-obj-report-definition/query.htm Report Definition Query tab]. 
  
''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.''
+
=== '''<big>FDS</big>''' ===
 +
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 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  
+
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
  
•       PegaHC-Data-BenefitDefinition
+
For more information, see [https://community.pega.com/knowledgebase/articles/pega-product-composer-healthcare-implementation-guide/85/generating-flattened-structure-plan-and-product-data Generating a flattened structure for plan and product data].
  
•       PegaHC-Data-BenefitCoverage
+
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).
  
More information can be found at [[https://community.pega.com/knowledgebase/articles/pega-product-composer-healthcare/generate-flattened-structure-plan-and-product-data]]
+
As a result of these advantages, FDS is the recommended method for integration and data extraction from PCS.
  
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.
+
=== '''API''' ===
 +
Out-of-the-box, the PCS application provides the following APIs that allow you to access the PCS data:
  
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.
+
==== Get Plan Catalog ====
 +
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).  
  
FDS is the recommended source for all integration and data extraction from PCS.
+
==== Get Plan Detail ====
 +
Get complete plan details through the flattening extract. The complete plan details for the requested plan are returned as the response.

Latest revision as of 20:26, 7 June 2021

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.

Clipboard[edit]

PCS clipboard page

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.

BIX[edit]

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 upgrade 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.

FDS[edit]

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.

API[edit]

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.