Example

Let's say that a user creates a new rule set (MyRuleSet) with a MyPerson rule class. The user adds some rule attributes to the rule class named after some columns on the Person database table:

The user creates a new configuration to propagate Person database rows to the new MyRuleSet.MyPerson rule class. There also continues to be an existing configuration (provided by the application) to propagate Person database rows to the ParticipantEntitiesRuleSet.Person rule class.

After a new row is inserted into the Person database table, then if a MyRuleSet.MyPerson rule object is requested for that person row during CER calculations, then the Entity Rule Object Converter will create a rule object in memory from the data on that row. The MyRuleSet.MyPerson rule object has its values for concernRoleID, dateOfBirth and dateOfBirthVerInd populated from the database row. It does not have any value for dateOfDeath because there is no such rule attribute on the MyPerson rule class.

By contrast, if a ParticipantEntitiesRuleSet.Person rule object is requested for that person row during CER calculations, then the Entity Rule Object Converter will populate the ParticipantEntitiesRuleSet.Person rule object from the same underlying database row. ParticipantEntitiesRuleSet.Person does have an attribute for dateOfDeath but not for dateOfBirthVerInd. Both rule classes have a concernRoleID rule attribute, which is required because concernRoleID is the primary key of the Person database table.

If the person row is subsequently modified on the database, then the Entity Rule Object Propagator notifies the Dependency Manager that the row has changed, and the Dependency Manager identifies all case determination results that depend on that row and requests that those cases be reassessed.

Let's say there are rules which require access to a claimant's personal details, and also requires access to details of other people related to the claimant, such as spouses and relatives. The rules would:

Claimant Joe (concernRoleID 392) has relationships to wife Mary (concernRoleID 393) and brother Frank (concernRoleID 394) stored as concern role relationships (concernRoleRelationshipIDs 773 and 774 respectively). These details are retrieved during the eligibility/entitlement calculation for Joe's case (caseID 453).

The Engine invokes the CER utility to identify these dependencies (which are stored using the Dependency Manager):

Table 1. Example Dependency Storage for Entity Rule Objects
Dependent   Precedent
Case 453's Entitlement depends on Entity row from table 'Person' where attribute 'concernRoleID' has value '392'
Case 453's Entitlement depends on <readall>/<match> expression against rule attribute 'ParticipantEntitiesRuleSet.ConcernRoleRelationship.concernRoleID', matching value 392
Case 453's Entitlement depends on Entity row from table 'ConcernRoleRelationship' where attribute 'concernRoleRelationshipID' has value '773'
Case 453's Entitlement depends on Entity row from table 'Person' where attribute 'concernRoleID' has value '393'
Case 453's Entitlement depends on Entity row from table 'ConcernRoleRelationship' where attribute 'concernRoleRelationshipID' has value '774'
Case 453's Entitlement depends on Entity row from table 'Person' where attribute 'concernRoleID' has value '394'
Case 453's Entitlement depends on Data configuration for conversion of Entity rule objects