Change Event Rules

Some updates to contract related entities may require a reattribution or recalculation of capitation. For example:

• when updating the amount on a rate schedule line, a recalculation needs to be performed for the contracts that use the applicable rate schedule

• when updating the assigned providers of a person, a reattribution (including a recalculation) needs to be performed for the contracts that the person is aligned to (through contract alignments)

To streamline this process, it is important to detect:

• if a change to a contract related entity leads to a trigger and if so

• what this trigger looks like

To give flexibility in defining the if and the what, rules can be set up, the change event rules. These configurable change event rules structure the way modifications are translated into triggers. If all the conditions on the change event rule are met, then a trigger is automatically stored; this trigger will from now on be referred to as a contract event.

First, the if part of a change event rule is described. The system is able to track a restricted number of entities. These are the entities that can reasonably have an effect on reattribution or recalculation. As a possible subject to track a modification, this list qualifies:

• Person (PERS)

  • Person titles and bank account numbers are seen as part of a person

• Address (ADDR)

• Assigned Provider (APRV)

• Contract Alignment (CNAL)

• Provider (PROV)

  • Provider titles are seen as part of a provider

• Service Address (SRAD)

• Rendering Address (RNAD)

• Provider Specialty (PRSP)

• Provider Group Affiliation (PRGA)

• Contract (CONT)

• Contract Time Period (CTMP)

• Contract Calculation Period (CTCP)

• Contract Adjustment (CNAD)

• Contract Adjustment Override (CNAO)

• Contract Provider Filter Rule (CPFR)

• Contract Rate Split (CNRS)

• Contract Payment Receiver (CNPR)

• Rate Schedule Line (RSLN)

• Adjustment Schedule Line (ASLN)

• Schedule Dimension Value (SDVL)

Typically only a subset of fields on any of these entities could potentially impact calculation, that is, not all modifications qualify to trigger an event. For example, updating contact information on the member record would trigger the need for a recalculation. Therefore, a distinction is necessary for:

• Action: Create, Update or Delete

  • Note that updates on person details through the Relation integration point are handled as replacements of the existing details by the details specified in the request, so if updates on subjects address, assigned provider or contract alignment are to be tracked it is advisable to create a change event rule for the Update action as well as a change event rule for the Create action.

  • Note that updates on provider details through the Provider integration point are handled as replacements of the existing details by the details specified in the request, so if updates on subjects service address, rendering address, provider specialty or provider group affiliation are to be tracked it is advisable to create a change event rule for the Update action as well as a change event rule for the Create action.

• Field List: for an update, it is important to provide a list of all the fields (fixed and dynamic) on the entity that are worth monitoring. When this list is not provided, all the field on the entity are monitored for an update.

Now to the what part of a change event rule. The change event rule defines if the event eventually leads to reattribution or only recalculation. Note that reattribution always includes a recalculation. Refer to the Capitation Calculation page in the Operations Guide for more information on this subject.

Last, it is necessary to define from which date onward the modification has effect. For a time valid record like a calculation period this is likely to be the start date of the record. And if the modification is on the start date itself, then it is likely to be the earliest of the old and the new value for the start date. Because variations are possible, this is made configurable through function dynamic logic with signature Change Event Rule.

Summing up, a change event rule has the following fields:

Table 1. Change Event Rules

Field	Description
Code	The code of the change event rule
Subject	The subject of the modification (for example: PERS for Person)
Action	The change action (Create, Update or Delete) that needs to trigger an event (must be Update if the subject is person, provider or contract)
Field List	The list of fields that trigger an event on update (must and may only be specified if the action is Update)
Type	The type of the event (Reattribution or Recalculation) Must be Recalculation if the subject is contract timeperiod, contract adjustment, contract adjustment override, contract rate split,contract payment receiver, rate schedule line, adjustment schedule line or schedule dimension value Must be Reattribution if the subject is assigned provider,contract alignment, provider group affiliation or contract provider filter rule
Effective Date Function	The function dynamic logic that is used to generate the effective date of thecontract event

What automatically happens on a modification of one of the subjects, is that all the change event rules on the subject are evaluated, taken into account the trigger action and the field list. If all conditions are met, then a new contract event record is stored (described in Events and Mutations).