When you come to implement a change in legislation, there are many factors which you should bear in mind when choosing which approach is better for your change. Sometimes the competing factors will mean that there is no overall clear-cut answer, and you will need to make an informed decision based on the details of the change that you need to make.
Over time, a product may undergo several legislation changes, and each legislation change must be taken on its merits when deciding which approach to take; in other words, a long-lived product may have had several historical legislation changes implemented using branching logic, and also other historical legislation changes implemented using multiple product periods. Indeed, it is possible (but rare) that a single legislation change may be implemented using a combination of the "branching logic" and "multiple product periods" approaches.
This table describes some important consequences to keep in mind when making your choice.
| Factor | Consequences under the "branching logic" approach | Consequences under the "multiple product periods" approach |
|---|---|---|
| Testing | For existing unit test that test attributes which now contain branching logic, the tests need to be updated to test the output of rule attributes taking into account eras of old legislation and new legislation; these tests will need to deal with both versions of the legislation. | The full bank of unit tests for a cloned rule set must also be cloned and maintained in line with the cloned rule set; in particular, tests for cloned attributes which are updated in line with the legislation change must be updated to test the behavior of the changed attribute. Each test only needs to deal with one version of the legislation, however. |
| Refactoring | Typically (depending on the complexity of the legislation change) no refactoring will be required to make logic common, as existing common logic should already have been factored to normalize common logic. | The cloning of rule sets may present an opportunity to refactor rule sets so that common logic unaffected by the legislation change can be refactored to exist only once - but this refactoring will take implementation and retesting effort. |
| Maintenance | The number of rule classes and rule attributes will typically be unchanged; however, the implementation of some rule attributes will become more complex, as those attributes have to deal with legislation change. Future bug fixes to the rule set (which span legislation eras) will typically require implementation in one rule set only. | The number of rule classes and rule attributes will increase due to cloning; however, the implementation of rule attributes should remain at the existing level of complexity. Future bug fixes to the rule set (which span legislation eras) may require implementation in more than one rule set, depending on whether logic common across rule sets has been refactored. |
| Complexity | This approach is suited to legislation changes which affect a small number of rule attributes, where the human-readability of the overall rule set is not overly-compromised by the limited introduction of branching logic. | This approach is suited to legislation changes which affect a large number of rule attributes, where the human-readability of the overall rule set would be overly-compromised by the wide-ranging introduction of branching logic. |
| Guarantees regarding stability of decisions under older legislation | You must test that your implementation of branching logic has correct dates for eras, and does not accidentally affect past periods already determined for cases. | Existing periods of determinations for the old product period (now with an end date) are guaranteed not to be affected by the legislation change introduced by the new product period. |
| Existing display categories | You must test that the existing dynamic UIM screens for display categories should continue to work with your updated rule sets. | You must test that the existing dynamic UIM screens for display categories work with the different rule sets configured for your different product periods. Either update the existing dynamic UIM screens (if necessary), or if the display output for an existing rule set category is sufficiently different after the legislation change, you may need to clone the display category so that there are different tabs (and thus different dynamic UIM screens) for before/after the legislation change. If you clone a display category, then case workers will need to click on one of two display categories, depending on which one is implemented for the coverage period displayed. |
| New display categories | If a new display category is introduced for the legislation change, then your existing rules must create appropriate "no output" values for older eras of legislation. | Your cloned rule sets and new product period can introduce support for a new display category which is not supported by older product periods. |
| Whether the legislation change affects all cases on the same date | Each attribute which is updated to contain legislation change logic can have an implementation which uses different era dates from other attributes (and can even use dates which vary according to circumstances of the case). | The cloned version of the rule sets affects all cases on the same date - namely the date of the new product period. The date cannot vary across cases. |
| Whether the legislation change date is important enough to flag to case workers on each determination | If the date of legislation change is important in its own right, consider implementing a key decision factor which shows the date that legislation changed. | If the date of legislation change is important in its own right, consider implementing a key decision factor which shows the date that legislation changed. Note that if the format of the decision details data is different between your old product period and your new product period, then when a case worker views a determination which spans these periods, then the Engine will split the determination into different coverage periods anyway (due to the change in decision details across the product periods). |
Typically, the choice of approach does not significantly affect performance and/or data storage. The multiple product period approach will lead to more rule objects being created in memory during the calculation of a determination result; but these rule objects are not stored on the database. They are included in rule object snapshots, however, but if common logic has been normalized, then when CER is requested to create a rule object with common logic, CER will re-use a similarly-created rule object that has the same initialization/specified values, and thus the common rule object will appear only once in the rule object snapshot, regardless of which approach is used.
Some types of legislation change require that newly-registered cases are treated differently from cases which already existed at the time that the legislation change came into effect, even if those newly-registered cases are recorded to retrospectively start before the legislation change (i.e. if the case was registered "late" and its start date is back-dated). Under these circumstances, regardless of which approach is chosen, the case's registration date will become an important piece of evidence in its own right, as it will govern how the case is treated. If you are considering the "multiple product period" approach, then you might implement and test the changes to branch logic based on the case registration date before cloning your rule sets, as the branching logic may be common to the determination results for both eras of legislation.
Some types of legislation change introduce "transitional" periods whereby claims are treated different. You may need to include branching logic for several dates, or create more than one new product period, to cater for how cases are treated before/during/after any transitional periods.
If a start date of a case is incorrectly recorded, then when it is corrected, there may be a change to the product periods which contribute to that case, and thus the case may now be affected by a legislation change whereas previously it was not, or vice versa. This kind of retrospective correction to case start dates behaves as you would expect and is automatically handled by the Engine.
Legislation changes can be future-only or contain an element of retrospective change, depending on whether the effective date of the legislation change is in the future or the past; indeed, sometimes a legislation change targeted at a future date might, due to lags introduced by legal/policy departments, end up being in the past by the time it is implemented. The implementation of legislation changes will typically affect a large number of cases, which will undergo changes in their determination results. For future-dated changes, the periods of the determinations affected will be in the future, typically for periods not yet processed by financial processing, and thus there will be no corrective under- or over-payments issued on foot of the change. For retrospective legislation changes though, it is possible to affect determinations for periods already delivered, typically leading to corrective under- or over-payment processing on a number of cases, as is to be expected.