Adding new properties to PCS entities
Adding new properties to PCS entities
| Description | Adding new properties to PCS entities |
|---|---|
| Version as of | 8.7 |
| Application | Pega Product Composer for Healthcare |
| Capability/Industry Area | Healthcare and Life Sciences |
Extension - Adding new properties to PCS entities
During Implementation, there would generally be a need to add new functional attributes/properties to any application case types to meet the implementation layer needs. These can arise due to various specialization needs like geographical, business unit specific or lines of business etc.
Especially in Product Composer System (PCS) application, there could be a need to add attributes to the implementation layer case types to accommodate business specializations like small group, large group, commercial, Medicare etc. In PCS these case types can be as simple as a Benefit, Network etc. or as complex as Product Template, Product or Plan.
Though in general addition of few attributes to any case type is straight forward, In PCS there is an important concept called, inheritance, that should be kept in mind while adding these properties. This concept determines how and where these properties flow/get inherited seamlessly across entities, most importantly from Product to Plan. Introducing additional properties should not impact the existing inheritance or copy of the data between the entities.
Both, addition of new attributes and inheritance, can be achieved by leveraging the extension points provided in PCS.
Some of the example scenarios, where new properties can be added to PCS entities:
- If a new attribute to mark a plan as “ready to sell” is required when the plan reaches a production ready state, it can be added to the meta data extension section of the plan case type.
- Another example is to add a “Max allowed amount” attribute in the existing co-pay cost share structure. This can be added to the extension section provided for this purpose.
How to add new properties to the metadata of benefits, product templates, products, plans etc.:
For example, if you want to add the above mentioned “ready to sell” attribute to the meta data of ‘product’, first create the new property in the relevant class and add it to the extension section “PProductClientConfiguration” provided out of the box in PCS and save it to the implementation layer rule set. Ensure that the ‘Client Configuration’ setting is enabled in PCS Configuration page of the implementation layer, under ‘Application settings’ tab. This will make this section visible in the meta data UI screen. Similarly make the configurations for other entities as well, if required. More details and steps can be found at “Extending the Pega Product Composer for Healthcare application” section at:
https://community.pega.com/knowledgebase/articles/pega-product-composer-healthcare-implementation-guide/85/extending-pega-product-composer-healthcare-application
For example, if you want to add the above mentioned “Max allowed amount” to the co-pay cost share, create this property in the relevant class and add it to the section “CostShareAssemblyDetails_EXT” [of applies to class “Embed-HC-PCS-CostSharesAssembly” ] provided out of the box in PCS and save it to the implementation layer rule set.
The decision whether a property is to be added to the meta data or cost shares depends on the business need. For example, “Ready to sell” is a plan level global property which doesn’t apply to any other component of the plan like cost shares, networks etc. So, it can be a global indicator which drives further down stream processes. For example, only “Ready to sell” plans are eligible to be published in exchange. So, this property is a good candidate to be added to meta data.
On the other hand, a property can be added to a benefit/grouper cost shares when it drives the benefit/grouper level cost shares processing/logic. For example, a “Max allowed amount” property on the co-pay cost share is very specific to a benefit co-pay and it restricts the amount of money that is reimbursed for an Ambulance benefit. The extension section provided out of the box to extend the union data structure [CostShareAssemblyDetails_EXT], and the logic built in PCS processing, will take care of the inheritance of these newly added attributes to the cost shares.
Union data is an external structure maintained outside of the product template, product, and plan in PCS. These store the cost share data of the entire product template, product, or plan. Each node in PCS (plan high level, networks, groupers, benefits) will have a dedicated union data record if overridden, else it will be inherited from the appropriate parent union data. So, if you add a new attribute to a cost share, it must be reflected/stored in the union data too and extended. For more details, refer to the section “Extending union data” at:
https://community.pega.com/knowledgebase/articles/pega-product-composer-healthcare-implementation-guide/86/extending-union-data
Please note that if any of these new properties must be made available for the down stream systems by way of the PCS out of the box flattening structure, review the section “Generating a flattened structure for plan and product data” at:
https://community.pega.com/knowledgebase/articles/pega-product-composer-healthcare-implementation-guide/86/generating-flattened-structure-plan-and-product-data