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

From PegaWiki
Jump to navigation Jump to search
(asked questions, reworded some phrases)
Tag: Visual edit
(updated application name and industry)
Tag: Visual edit
 
(17 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 ==
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 are '''in play ?? what does this mean? affects?? f'''or all 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.  
+
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.   '''DD: What does this mean?? The implementation team needs to have a clear understanding of the options available to extract data from PCS in order to ??? create client 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 four  available options to extract data from PCS:  
+
There are five available options to extract data from PCS:  
 
* Clipboard
 
* Clipboard
 
* Business Intelligence Exchange (BIX)
 
* Business Intelligence Exchange (BIX)
 
* Data extract reports
 
* Data extract reports
* Flattened data structures
+
* Flattened data structures (FDS)
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.
+
* 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). 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 the BenefitSetTree to''' load all required data:  '''what does this mean??'''
+
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?? '''what is benefit proper?'''
+
* 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
 
 
 
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. what does this mean?  What is File?  One of the final forms?'''
 
 
 
The Clipboard option is not recommended because of the significant effort and maintenance for the implementation teams.
 
 
 
'''<big>BIX</big>'''
 
 
 
'''For transactional reporting needs of the organization for product repository, what does product repository mean here?  awkward sentence?  Is it? 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. what does this mean?  Only the delta changes to a 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.  '''??? do we know or not know???  8.1 user guide says yes.'''
+
The Clipboard option is not recommended because of the significant effort and maintenance.
  
'''<big>Data extract reports</big>'''  
+
=== '''<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.
  
The benefit coding QA team needs a 360 view across the product repository in order to review the configurations across multiple products and plans. '''terminology...title says QC and this talks about QA'''
+
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.  
  
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''' '''what does this mean?? a great tool for visual inspection as well as in automated scripts??''' 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 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.  
  
There are two types of reports
+
'''Note:''' The use of BIX might require an additional license. 
  
-       High level - Summary report
+
=== '''<big>Data extract reports</big>''' ===
 +
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. 
  
-       Detailed - Cost share detail 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.
  
'''How can we show these reports better?  These are too wide'''
+
There are two types of reports:  
[[File:Summary report.png|thumb|1270x1270px|Sample PCS Summary report]]
 
[[File:Cost share detail report.png|thumb|1270x1270px|Sample PCS Cost share detail report]]
 
  
The implementation team can write complex queries on the data that is produced by these reports. 
+
* High level - Summary report
  
'''<big>Flattened data structures (FDS)  ??? i don't think that this is a real acronyn---couldn't find anything??? Is it????Just Pega's?</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 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.  
+
=== '''<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 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 what does that mean??''' in the 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 in ''Generating a flattened structure for plan and product data'' in the implementation guide''.'' [[https://community.pega.com/knowledgebase/articles/pega-product-composer-healthcare/generate-flattened-structure-plan-and-product-data how to generate a flattened product or plan.]]  '''This information is now in the implementation guide (as of 8.5 GA).'''
+
As a result of these advantages, FDS is the recommended method for integration and data extraction from PCS.
  
Flattened data structures contain all the information to determine '''how ???''' 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.