Creating new, extending existing and bypassing modules
Creating new, extending existing and bypassing modules
| Description | Optimizing modules for the Smart Claims Engine for Healthcare |
|---|---|
| Version as of | 8.5 |
| Application | Pega Smart Claims Engine for Healthcare |
| Capability/Industry Area | Healthcare and Life Sciences |
Description
This design pattern will help implementers of the Smart Claims Engine (SCE) for Healthcare develop new modules or extend existing modules to enable new capability to be added to the orchestration. In addition, a best practice for coding a conditional bypass of a module will also be covered.
Definition
The module in the smart claims engine is designed to be a discrete piece of business or technical functionality to complete a complex task or a series of like tasks. Examples of modules include member match, where the SCE searches for an appropriate member in the system utilizing data on the claim to find a match or business audits, where the SCE utilizes historical claims information, along with the current claim to validate business policy edits. Modules implemented in the SCE can be seen in the visualization screen when a claim is adjudicated.
Before you begin
Before you decide to create a new module or extend an existing one, you need to identify the process that is being implemented:
- Is it in support of an existing flow?
- For example, do you want to add some new validations to verify specific data in your membership data against the claim? In this situation, extending the existing member validation module makes sense.
- Is the execution of this module conditional on specific data?
- For example, you need to integrate to a system providing prospective utilization review for pharmacy claims? In this situation, creating a new module would be appropriate.
There are also nuances that might define the need to create a new module vs extending an existing one, but care should be made not to create too many fine grained modules.
Process/Steps to achieve objective
Creating a new module
Creating a new module is relatively easy. On the module configuration tab in the claims engine configuration page in developer studio, the lists of existing modules are found, along with the button to add a new one. A module can reference any collection rule form in the Pega stack. The collection rule is used as this provides a higher level of processing performance than a flow rule. Modules need a name, an identifier, the process rule and a process type. The process type is a quick way to identify an internal SCE process vs an externally managed process and it's just used for display in the grid. When creating a new module, a bypass decision table should also be created. The name for the decision table should match the name of the primary rule of the module to ensure that it can be easily found. If no bypass table is listed, the module will not have a configurable bypass capability. Once a new module is created, you can add it to a sequence so that it can be part of an orchestration. Information on adding modules to an orchestration can be found in the implementation guide.
Extending existing modules
The SCE provides two capabilities to extend existing modules. The first can be to add the new logic to be executed before the current logic and the second is to add the new rules to be executed after the current logic. Decisions on where to extend can be easily defined. For example, if the new logic requires data to be sourced differently from the current implementation, then introducing the rule in the module initialization step is the appropriate place. If the logic to be implemented is to add new edits or event codes, or to finalize a business problem, then the finalization step is the location for this.
Bypassing modules
The SCE provides the ability to bypass modules based on a decision table. The table can be extended to add new columns specific to your implementation or to add data on the existing columns. When adding elements to the table to bypass the module, you need to consider key characteristics. For example you might want to bypass the ClaimsXten module for all dental claims, or the benefit determination module for all claims that have not matched to a member. Utilizing the bypass efficiently for claims that might need to recycle due to data latency or key operational requirements will improve the overall performance of the SCE. That said, if possible, you want to ensure all applicable logic can be applied. For example, if a claim meets the event code criteria for an invalid data field configured for recycle and an event code configured for denial, you would want to make sure the claim wasn't bypassing the denial criteria due to the invalid data field event code.
Key considerations
Modules should be encapsulated as much as possible for re-use, but not too granular that performance may be impacted by having too many fine grained modules in the orchestration. Each module can log information into the audit trail, but care should also be taken not to log too much data that doesn’t provide value for an operator viewing the processing steps. Examples of items to log, include any data replacements or matches, why an event code has been fired or a key financial calculation.