Use this job level rule to execute regional date processing (RDP) rules on forms. You create the RDP rules via Documaker Studio.
| Note | See the Documaker Studio User Guide for more information on creating RDP rules. |
In the U.S. insurance industry, certain forms must comply with a regional authority (usually a state) to be approved for use within that area. The process of getting approval to use forms in each location is often referred to as submitting for state compliance.
Because of the various jurisdictions involved, you may have a form which is accepted by some states, but not by others. Alternatively, the form might be accepted by multiple states, but as of different dates. And to add another layer of complexity, states specify which document date must be used when activating this form.
To understand this last point, consider that almost all insurance policies have a date when coverage becomes effective – typically referred to as the policy effective date. Likewise, a policy usually has a written date that identifies when the document was actually drawn up. It is not unusual for the written date to be different from the policy effective date. For instance, you might buy your hurricane insurance today (the written date), but the policy does not become effective for 30 (or more) days. Each regional authority specifies which date determines the compliance of a given form.
This necessity to only activate the use of a form in a given region after a specific date complicates the creation of trigger conditions. Not only do you have to consider the typical transaction information that would cause you to include the form, you also have to calculate the various details to comply with the regional authorities described above.
To help you more easily manage this process, Studio lets you define regional date processing (RDP) rules that you can assign to each form. Part of the support is accomplished in Studio by defining the appropriate regional tests for each form. The remaining part occurs during the batch transactional process via the RegionalDateProcess rule.
RegionalDateProcess;;;
There are no parameters for this rule.
Place this rule before any rule that calls the base triggering functionality, such as the RunSetRcpTbl rule. RDP rules operate as a filter that aids the normal triggering process by eliminating forms which do not meet the necessary criteria.
RDP rules are defined in group form files and assigned to individual forms. RDP rules are optional and only those forms containing one or more such rules are subject to this filtering process.
If a form has one or more RDP rules defined, these are evaluated during execution of this rule. The execution proceeds like this:
First, the system locates and evaluates the date search token associated with the rule. The resulting date value obtained from the transaction data is compared against the date range provided in the rule. If the date value is out of range, the form is flagged for possible elimination and execution moves to the next RDP rule.
If the date value is within the valid range, the next step is to iterate through the region search tokens associated with the rule and evaluate each. Each region search token might yield multiple hits. The system cross-references this list of values against the inclusion and exclusion list provided in the rule. If there is an intersection between the two lists, the rule is considered satisfied and the system moves to the next RPD rule. If the search token results in no matches for the list, then the system continues with the next search token until all search tokens are exhausted.
If the rule completes execution of the regional search tokens without finding any matches for the defined set, the form is flagged for possible elimination.
Each RDP rule executes in this manner which means that at the point where one rule considers the form eligible, no further RDP rules are execute on that form. Instead, RDP processing will immediately move to the next form.
If all RDP rules for a given form consider the form ineligible, then the form remains flagged with this state and is skipped during the subsequent triggering job rule process.
You can enter Yes for the RegionalDateProcess option to turn on debugging if you run into problems. Here is an example:
< Debug_Switches >
Here's an example trace file produced by setting the RegionalDateProcess option to Yes:
1. Thu Sep 11 14:38:14.678 2008 pid=00029776 RDP Form <PREMIUM
CONFIRMATION> IS excluded.
2. Thu Sep 11 14:38:14.678 2008 pid=00029776 RDP Form <PREMIUM
CONFIRMATION 06152008> IS excluded.
3. Thu Sep 11 14:38:14.866 2008 pid=00029776 RDP Form <PREMIUM
CONFIRMATION> IS excluded.
4. Thu Sep 11 14:38:14.866 2008 pid=00029776 RDP Form <PREMIUM
CONFIRMATION 06152008> IS excluded.
5. Thu Sep 11 14:38:14.975 2008 pid=00029776 RDP Form <PREMIUM
CONFIRMATION> IS excluded.
6. Thu Sep 11 14:38:14.975 2008 pid=00029776 RDP Form <PREMIUM
CONFIRMATION 06152008> IS excluded.
7. Thu Sep 11 14:38:14.991 2008 pid=00029776 RDP Form <MEDICAL
HISTORY USING MEDBODY1> IS excluded.
Here is an example of how you would use this rule:
<Base Form Set Rules>
;NoGenTrnTransactionProc;2; single step;
;ResetOvFlw;2;;
;BuildFormList;2;;
;RegionalDateProcess;2;;
;RunSetRcpTbl;2;;
;WriteOutput;2;;
;WriteNaFile;2;;
;BatchingByRecipINI;2;;
;PaginateAndPropagate;2;;
© Copyright 2014, Oracle and/or its affiliates. All rights reserved. Legal notices.