Driving the Identification of Affected Cases

After system-wide changes to data have been made, you must run batch processing to identify the cases affected, and reassess each case.

The algorithm(s) that you choose to identify cases will depend on your business requirements. In general there are these types of case-identification algorithm to choose from (or possibly combine):

Bottom-up
Identify cases that are known by the system to be affected by the change, i.e. use the dependency records stored in the Dependency Manager; and/or
Top-down
Identify cases by some facet of the case, e.g. all active cases for a particular product, or all cases for claimants in a particular range of social security numbers.

The application includes an implementation of the bottom-up algorithm in the form of the batch suite provided by the Dependency Manager (see the Cúram Express Rules Reference Manual). The batch suite uses the dependency records to identify cases potentially affected by system-wide changes in data and reassesses them.

CAUTION:

The Dependency Manager batch suite has the capability to reassess cases, but it also has the capability to recalculate other types of dependents, such as Advice.

If you choose not to use the Dependency Manager batch suite to reassess cases, you must still use the batch suite to recalculate other types of dependents.

The application also includes a sample implementation of a top-down algorithm in the form of the CREOLEBulkCaseChunkReassessmentByProduct batch process (see the Cúram Operations Guide), and instructions for writing your own batch process to implement your own top-down algorithm are included below (see Writing your own Bulk Reassessment Batch Process).

When scheduling batch processing to reassess cases affected by your published system-wide changes, you can choose¹to schedule one or both of:

an implementation of a top-down algorithm, either that included with the application or your own custom batch process; and/or
the bottom-up algorithm included in the Dependency Manager batch suite.

The benefits and limitations in the choices of approach are outlined in the table below:

Table 1. Benefits and Limitations to Bulk Reassessment Approaches
Approach	Benefits	Limitations
Use the Dependency Manager batch suite only	The implementation is included with the application - no custom processing needs to be implemented. The Dependency Manager batch suite provides robust identification of all cases potentially affected by system-wide changes made through the application's APIs². The Dependency Manager batch suite must be run anyway to recalculate other dependents such as Advice.	You cannot control the order in which the Dependency Manager reassesses cases. You cannot perform any additional business processing at the point at which the Dependency Manager batch suite reassesses the case. If you have requirements to perform specific business processing for all the cases that were identified and reassessed by the Dependency Manager and/or those for which new determinations were recorded, you must satisfy yourself that you can identify these cases in some way after the Dependency Manager batch suite has completed and implement your own custom batch program to perform the required post-reassessment business processing.
Use an implementation of a top-down case identification/reassessment algorithm, followed by a run of the Dependency Manager batch suite	You get to "prioritize" the processing of certain cases (those identified by your top-down algorithm) ahead of any other cases and any other dependent types (such as Advice). You control the order in which cases are reassessed. For cases reassessed by your top-down case reassessment implementation, you can perform additional business processing at the point of reassessment. Any case that your top-down algorithm fails to identify³, but which is affected by the system-wide change, will still be identified and reassessed by the Dependency Manager batch suite, so by the end of the batch run all affected cases will have been identified and reassessed; You can schedule this "clean-up" run of the Dependency Manager batch suite quite some time after the run of the top-down batch processing which identified and reassessed your "priority" cases. For example, you might wish to schedule the "priority" (top-down) case processing to run overnight starting on the evening when the system-wide changes were published, but defer the "clean-up" (bottom-up) case processing until the next weekend. The Dependency Manager batch suite must be run anyway to recalculate other dependents such as Advice.	You will have additional development activity to implement and test your custom case identification algorithm and/or post-reassessment business processing (unless you are using the `CREOLEBulkCaseChunkReassessmentByProduct` batch process included with the application). Some cases identified by the Dependency Manager batch suite will have already been identified and reassessed by your top-down case identification/reassessment algorithm, so some of the reassessments performed by the Dependency Manager may turn out to be needless. If a case is missed by your top-down algorithm and is instead identified and reassessed by the Dependency Manager batch suite, then the Dependency Manager batch suite cannot perform any additional processing that your top-down algorithm might have done at the point where it would have reassessed the case. If you have requirements to perform specific business processing for the cases that were cleaned-up by the run of the Dependency Manager batch suite, then you must satisfy yourself that you can identify these cases in some way after the Dependency Manager batch suite has completed and implement your own custom batch program to perform the required post-reassessment business processing.
Use an implementation of a top-down case identification/reassessment algorithm only	You get to "prioritize" the processing of certain cases (those identified by your top-down algorithm) ahead of any other cases and any other dependent types (such as Advice). You control the order in which cases are reassessed. For cases reassessed by your top-down case reassessment implementation, you can perform additional business processing at the point of reassessment.	You will have additional development activity to implement and test your custom case identification algorithm and/or post-reassessment business processing (unless you are using the `CREOLEBulkCaseChunkReassessmentByProduct` batch process included with the application). You take sole responsibility for the accurate and complete identification of cases affected by the system-wide data change. Any case that your algorithm fails to identify will not be reassessed by the batch processing run, and its stored determination will not be consistent with the system-wide data change until such time as the case is reassessed for some other reason. The Dependency Manager batch suite must be run anyway to recalculate other dependents such as Advice. Your system operators must be instructed explicitly not to run the Dependency Manager batch suite for dependents of type "case assessment determination".
⁴ ⁵

Note that it is always possible for the Dependency Manager to identify a case for reassessment, but having reassessed that case the Engine finds out that the reassessment turned out to be needless, due to the granularity at which dependency records are stored for case determination dependents. Examples where such a needless reassessment might occur are:

a change to column value on an entity row, where other unchanged columns for that entity row have been used as the input to determination calculations;
a change to a common CER rule set which is used to calculate determinations, and also for some other purpose such as Advice, but the changed rules are not accessed during determination calculations;
a change to a rate (such as for income thresholds) which does not affect the overall determination result for a case.

Note: There are only two options regarding a reassessment which turns out to be needless:

either the system performs the reassessment, and only once a new determination is calculated can the system discover that the reassessment turned out to be needless, at the risk of using up processing time; or
a human outside the system uses his or her business knowledge to implement processing to identify cases in such as way as to eliminate or minimize needless reassessments, at the risk of human error (i.e. that needless reassessments still occur for some cases, or, more seriously, that some necessary reassessments were not identified.

You should weigh up these unavoidable risks as part of your decision as to which approach to use for bulk reassessment processing.

¹ You can choose the most appropriate approach each time you publish one or more system-wide changes, or you can choose to use the same approach each time.

Any custom batch processing you require to support bulk case reassessment will need to be implemented and deployed to your production environment, of course.

² If system-wide changes to data are made outside of the application's APIs, e.g. by an SQL script, then the Dependency Manager cannot automatically identify affected cases.

³ There may be edge cases not obvious during the design of your case identification algorithm.

For example, a rate table may be primarily used in the determination calculations for a particular product, and thus it would be possible to drive the identification of cases to reassess by finding all active cases for that product.

If, unbeknownst to the administrator, a rules designer has reused that rate table in way that it is used by a handful of unusual cases for another product, then these cases will not be identified by the naive "all active cases for a product" algorithm run against the main product which uses the rates.

⁴ If system-wide changes to data are made outside of the application's APIs, e.g. by an SQL script, then the Dependency Manager cannot automatically identify affected cases.

⁵ There may be edge cases not obvious during the design of your case identification algorithm.