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.
Tooling has been provided to assist with running the Dependency Manager batch suite, please see the 'Dependency Manager Batch Tooling' section of the 'Cúram Operations Guide' for more information.
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 choose1to 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 ApproachesApproach |
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 APIs2.
- 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
identify3, 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".
|
45 |
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.
3 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.
5 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.