Business rule engines have had a long and storied relationship with the insurance industry. The nature of insurance business processes tends to require large sets of calculations and comparisons across several steps in the business lifecycle, including eligibility, rating, underwriting, and claims.
Across these various steps in the insurance business cycle, the claims processing, or “claims adjudication” step tends to require the most complex set of rule calculations. The claims adjudication step often needs the highest number of permutations of business logic as rules are applied across lines of business, geographic locations, various providers, clients, and policy benefits.
Some firms have opted to solve these calculation intensive problems with rigid application code or even spreadsheets. However, these approaches are cumbersome over the long term, since the business logic must be permuted and subtly changed to accommodate all the possible business cases. Additionally, as the business ages, rules often need to change over time, but old versions of rules still need to be available for re-execution. These requirements can force developers to write ugly source code that eventually becomes unmaintainable or for IT to keep hundreds or even thousands of copies of old spreadsheets lying around.
Many firms have opted to use business rule technology– Business Rule Engines (BREs) or Business Rule Management Systems (BRMSs)–to help tackle the complexity of managing large sets of claims business logic calculations. The main advantages a BRMS offers over more traditional approaches:
- Providing authoring tools that allow subject matter experts (SMEs) to edit rules without having to change application code
- Offering management and reporting tools that give visibility into the business logic that drives claims processing (business logic reporting)
- Allowing SMEs to test business logic changes instead of developers
- Providing SMEs with simple approaches to integrate business logic with disparate back-end systems. It is a major benefit to integrate with live, transactional data versus one-off copies that may be trapped in spreadsheets or one-off application databases
- Allowing overrides and multiple versions of rules to be available over time, with simple approaches for finding and executing old versions of rules
Below is a list of technical points to consider when looking for a BRE tool to solve the claims adjudication problem.
Handling claim data schemas and hierarchical collections
Although most firms have custom approaches for storing and expressing policy data, claims processing almost always requires a schema that links together a set of collections for matching and aggregation. These collections will contain business entities such as current claim service lines, claim history, benefits, providers, as well as individuals and assets covered on the policy.
The rule engine must easily handle the complexity of traversing these various collections while aggregating claims, locating appropriate benefit limits, and writing out eligibility and coverage results.
Options for looking back through the claims history
When considering eligibility or coverage for a claim, the system may have to look back over the history of a policy, a group, or an individual. Depending on the scenario, this history may be significant, and it may not be practical to load the entire claim history into memory for comparison with new claims.
Fully featured BREs, such as InRule, provide features that allow the rule engine to work with a claim history in-memory, or to keep the history within a relational database or behind a service layer. These features allow the firm to always use the “best tool for the job” when efficiently matching data between groups of benefits, claims, and individuals.
Overriding benefit limits at multiple levels
Many policy offerings may start with a base set of benefit limits, but then require that a small subset of the benefit limitations are adjusted per client, group, or geographic location.
Once a base set of coverage rules have been established for a line of business, the SME’s should be able to easily override a small sub-set of the benefits without having to completely re-author the entire set of base rules.
Filtering collections with complex criteria
When comparing collections of data for claims processing, there are often several sets of parameters that must be considered all at once. These can produce complex “where clauses” that must combine fields such date ranges, procedure IDs, benefit IDs, locations IDs, etc. all into a single set of match criteria. A fully featured BRE, such as InRule, contains built-in capabilities for creating rules that can pull fields from multiple locations in a complex object model, and then apply matching criteria to several sets of collections in a single operation.
Containing complexity with vocabulary
Once a set of queries has been developed, those queries should be applied using terminology that makes sense to the business. Business users such as SMEs and managers should be able to edit and read matching rules without struggling with confusing filter clauses and nested object models.
The InRule Business Language Editor allows SMEs to author and report on rules using domain specific language. Rules often read in plain English, and can then be exported to HTML reports.
Handling logic changes over time
One thing that is certain in claims handling is change. The adjudication rules will need to be modified over time, and the system will need to be flexible enough to allow the business to override benefit limits for special cases.
A fully-featured BRE, such as InRule, will support change management features for rules. This “source control for rules” allows SMEs to version rules over time while maintaining a history of past rule sets. Developers can easily surface features that can re-execute past versions of rules based on date ranges or text labels.