Benefit design in PCS
Benefit design in PCS
|Description||Benefit design with PCS|
|Version as of||8.6|
|Application||Pega Product Composer for Healthcare|
|Capability/Industry Area||Healthcare and Life Sciences|
Benefit design with PCS
Goal of the design pattern is to share options and design considerations for configuring benefits in PCS.
Questionnaire for the design team
The below questionnaire would help implementation teams and the clients understand what PCS offers and how to approach the benefit design in PCS.
|1||What is the scope/purpose of benefits and plans configured in PCS. Possible options are 1) SOR and input for claim adjudication 2) Feeding the sales system as a product catalog 3) Generating documents 4) All of the above, or a combination of options||The primary purpose of the benefits and plans configured in PCS would have a large impact on the granularity of the details that are captured for the benefits. For example for adjudication purposed implementation, the benefit definition (mapping) along with cost share and other coverages play a key role. For an implementation that is primarily feeding the plans to the sales users or brokers and PCS is fulfilling the role as a product catalog - the focus would be on the coverages, and not so much on the benefit definition (mapping). For generating documents like SBCs - the focus would be on creating the benefits to then be able to map the benefits to the SBC templates. This understanding would give the implementation team a solid foundation for the benefit design and reuse. The answers to these questions would drive how and to what extent the benefits would be configured in the PCS application. It is also very important to take into consideration the annual (minimally) renewal process of plans, to determine how to best build the benefits to be as future-proof as possible.|
|2||How are the benefits being designed today? Where are they being stored? Can you share examples.||Explain how PCS allows the users to create benefits using standard codes and code groups. The users can use a combination of these codes to uniquely define each benefit. The process for entering new codes or custom codes should also be discussed. The format of currently stored benefits matters, because if they are in csv or Excel, they can be imported into PCS directly. It is also important to understand if they want to bring in the codes and code groups 'as is' or if there are improvements they want to make to their current benefit definitions to maximize the reusability of benefits in PCS. This can allow users to use common benefits across market segments and lines of business. Note: Code and code group benefit definitions (mapping) are usually only done if PCS is being used as an input for claim adjudication.|
|3||How are the benefit definitions updated? How frequently ? What is the process for that?||The impact of updating benefit definitions should be considered in the benefit design. Explain how PCS provides versioning for each benefit. Explain how benefits can be updated in PCS, including the stages and the built-in approval mechanism.|
|4||Explain the difference between benefit definition and coverage in PCS, and ask if that separation exists.||For many clients, there is no difference between coverage and benefit definition. Benefits are "grouped" based on their coverage data - for example all benefits with 10% coinsurance could be worked upon together. Or all benefits with $20 copay would be associated together. The important point here is to explain the difference between benefit definitions (which are independent and reusable) and coverage information which is only associated at the product and plan layers. This often requires thought leadership to help a client understand how rethinking their benefit structure and usage can dramatically reduce their time in configuring and maintaining plan data.|
|5||How does the coverage/cost shares affect the benefits?||Same as above. Goal here is to see how the benefits are handled in the system or the expectation from the business if the same benefit has different coverage information across plans.|
|6||Which line of business or market segment is being considered?||This will help with understanding the total number of plans in play for the current implementation. The number of plans (and customizations) are usually less for small/mid group, whereas the large group accounts have several customizations and often manage a very large number of plans. The expansion plan should also be kept in mind as the benefit and plans are being designed. Understanding the migration plan of their existing data will help in determining which lines of business or market segments to build first, so that subsequent build stages can reuse what has been built and not need to start from scratch.|
|7||Do you have any operational reporting requirements with regard to benefits?||Which are the most commonly reused benefits? Which benefits have the highest copay/coinsurance? Which benefits should always be available in certain plans? Which set of benefits should not appear along with each other? Having a clear understanding of the reporting requirements will allow you to design the benefit structures appropriately. In PCS, benefit is a standard case type.|
|8||Are effective dates managed at the benefit level? Or just at the plan level?||This would help you understand the scope of benefits, and the expectations from the business in terms of when to make a benefit not available.|
|9||On average, how many benefits are there per plan?||Another data point to help you make informed decisions for benefit design. We have seen plans with up to 1000 benefits. The main purpose of this is to understand the average size of the plan, give the end users idea about pagination, and come up with a plan for ordering the benefits in the benefit set (benefit ranking is very important if PCS is being used as an input for claims adjudication and should be thoroughly discussed with the client to understand how it will interact with their claim engine). The number of benefits can vary greatly, usually based on the main purpose PCS is serving. Having an understanding of the total number of benefits would help the design team calculate the load on the system as well, and hence could impact the cloud/on-prem hardware sizing.|
|10||How are duplicate benefits being checked for in the system? Do you have a process? When and using what criteria do you create a new benefit? How frequently does this happen?||These questions would help you understand the system expectations with regard to duplicate check. Also it will give you idea about the factors that determine when to create a new benefit. The details of the process are important to design the validations for benefits.|
|11||What automation exists today, as far as data entry and QA is concerned?||Discuss PCS import, and see how that can be leveraged. The existing data extract reports should be discussed along with QA expectations. Look for specific requirements which cannot be met with existing PCS features.|
|12||What granularity of benefits is expected in the sales catalog?||This would determine how to identify benefits to be represented to sales users. Having a common language between sales and operations will greatly simplify the integration and enable the sales brokers to understand what they are seeing. This is especially important for custom plans.|
|13||How are medical policies influencing the benefit design? Do you have mandatory benefits or validations to run on plans?||Get details about medical policies and see if they influence the benefit design. The validations to be run are easy to design, but you need to know the granularity to check for. Is it based on the benefit name or the cost share associated with certain benefits, etc.?|
All the necessary code sets and code groups that make up a benefit are defined in the Pega Foundation for Healthcare layer. You can also add additional custom code sets to uniquely define a benefit in PCS.
From the PCS configuration page, these code sets and code groups can be referenced and viewed. In PCS, a benefit is a combination of these code sets and code groups.
Any PCS implementation would need answers to these questions in order to design a robust and extensible architecture that supports all benefit and plan configurations. The business team would also feel more empowered as they get familiar with PCS features that support the benefit design.