Multiple Reassessments during a Case's Lifetime

At this point it's worth pausing to recall what happens each time a case is reassessed:

the Engine invokes CER to calculate a new determination result for the case;
the Engine retrieves the existing determination result for the case from the database;
the Engine compares the new determination against the existing determination, and only if the new determination is "different":
- the Engine supersedes the existing determination result and stores the new determination result on the database;
- the Engine updates the case's financial schedule;
- the Engine identifies whether there have been any over- or under-payments and if so takes corrective action.

Bulk case reassessment is no different from online case lifecycle processing in this regard - i.e. processing can reassess a case any number of times, but it is only when the new assessment determination result differs from the existing assessment determination result that a new determination result is stored and potentially financial impacts are stored (such as changes to the financial schedule, and possibly the identification of over- or under-payments and corrective actions).

As such, a "needless" reassessment which results in no change to the existing assessment determination is not as expensive (in system terms) as a "necessary" reassessment which results in a change to the determination; but on the other hand performing a "needless" reassessment is more expensive than avoiding it. Needless reassessments have no business impact on the case, though. You should consider your performance requirements to determine to what extent needless reassessments are tolerable in your system and bear that in mind when choosing your approach to bulk reassessments.

There are a number of common processing points in the application which will cause a case to be reassessed:

case lifecycle events - e.g. if the case is closed, and then reopened, and then reactivated, the case will be reassessed at reactivation time;
when a case worker chooses to manually reassess the case;
when case-level reassessment occurs, e.g. in response to changes in evidence or personal details;
if the financials batch programs are configured to force a reassessment of each case prior to generating financials for the case; and
bulk case reassessment (the subject of this section).

Once system-wide changes to data have been made, then for any particular product delivery case, the first processing point to reassess the case (e.g. one of the events listed above) will calculate a new determination result which takes into account all the system-wide changes to data, and any subsequent processing point will calculate an identical determination result and take no further action (assuming that there have been no other data changes which affect the case in the meantime).

Important: Because the first processing point to reassess the case takes into account all system-wide changes to data, you must consider carefully:

when to publish the system-wide changes;
how long after publication the batch processing will run to identify and reassess affected cases;
whether case workers should be allowed to view and maintain¹cases during the lag between publication of the system-wide changes and completion of the batch processing; and
how your business processes will cope with any case that would have had a new determination stored by the batch processing, except that some online processing (e.g. a manual reassessment by a case worker) caused a new determination (taking into account the published system-wide changes) to be stored already.

This last point is especially important if you require to run additional business processing during your batch identification and reassessment of cases (e.g. to send out a particular type of correspondence), as online processes such as a manual reassessment by a case worker will not automatically include that additional processing. In such circumstances it may be important to schedule the publication of the system-wide changes and the full batch processing (to completion) during downtime when caseworkers do not have access to the system, and/or make your batch business processing tolerant to the situation that a case may have already been reassessed by an online action.

Assuming that you have no additional business processing that relies on being the first processing point to reassess a case after system-wide changes have been published, then in general it is safe to run bulk reassessment batch processing concurrently with the online system. You should note though that:

online users may experience a performance degradation while batch processing is ongoing; and
if an online user performs an action which leads to a case being reassessed, at the same time that the bulk reassessment batch processing is attempting to reassess the same case, then it is possible for either the online and/or batch transaction to fail:
- the online user's transaction may fail and the user advised to try again;
- a deferred transaction to reassess the case triggered from the online user's action may fail and will be retried a set number of times; and/or
- the batch "chunk" may fail and will be automatically retried.

¹ For example, you might have to carefully communicate to your case workers that a system-wide change has occurred, and to let them know that it will be some time until all affected cases have been reassessed, but that urgent cases can be manually reassessed in the meantime.

Depending on your business needs, this situation may be perfectly acceptable, or on the other hand be needlessly confusing for case workers.