Capitation Calculation

The user can start a calculation for either a single contract, or for a set of contracts that meet the specified criteria. Starting a calculation for a set of contracts is primarily a feature that provides convenience towards the user; it is the equivalent of starting an individual calculation for each contract in the set.

The scope of the calculation can be controlled by selecting values for the following parameters:

Table 1. Capitation Calculation
Name	Description
Organization	If specified, the calculation only selects contracts that have a reference to the organization.
Calculation Input Date	Based on the mandatory calculation input date, the applicable contract calculation period is selected for each contract. The calculation automatically includes earlier periods that need to be (re)calculated.
Look Back Date	The mandatory look back date prevents the system from recalculating capitation for contract calculation periods before this date.
Financial Transaction Function	This function facilitates the modification of financial transaction details and financial transaction and financial transaction process data attributes of the financial transaction. Only dynamic logic functions with signature Financial Transaction are allowed.
Dynamic Field (1)	Field usage name of the first dynamic field that is used as a filter. Only single value, non time valid fields on contracts are allowed. If specified - together with the value - then only contracts having a dynamic field with that value, are selected.
Value (1)	Alphanumerical value for the first dynamic field that is used as a filter.
Dynamic Field (2)	Field usage name of the second dynamic field that is used as a filter. Only single value, non time valid fields on contracts are allowed. If specified - together with the value - then only contracts having a dynamic field with that value, are selected.
Value (2)	Alphanumerical value for the second dynamic field that is used as a filter.
Disable Grouping on Reversal Indicator for Invoice Lines?	The default behavior is that invoice lines are grouped on (among others) the reversal indicator; as a consequence credit and debit invoice lines can never result in a single zero result invoice line. Setting the parameter to 'Y' disables this default behavior.

The following messages can occur during this activity:

Table 2. Messages
Code	Severity	Message Text
CPN-VL-CPNC-001	Fatal	Organization code {code} is unknown
CPN-VL-CPNC-002	Fatal	Financial transaction function dynamic logic code {code} is unknown or has an invalid signature
CPN-VL-CPNC-003	Fatal	Dynamic field usage name {field usage name} is unknown
CPN-VL-CPNC-004	Fatal	The dynamic field usage must be single value and non time valid
CPN-VL-CPNC-005	Fatal	The dynamic field usage may not refer to a dynamic record definition or flex code set
CPN-VL-CPNC-006	Fatal	Both dynamic field and value must be specified
CPN-VL-CPNC-007	Fatal	The look back date must be on or before the calculation input date

The output of this activity is a list of contracts that meet the (optional) input parameters of organization and the two dynamic fields. The only purpose of this activity is to split up the calculation load over various contracts. Finding the right contract calculation periods happens in the activities per contract.

Capitation Calculation Per Contract

The capitation calculation per contract activity can either be the result of the capitation calculation spread across contracts (the activity described above) or it can be started directly within the context of a contract. This activity has the following parameters:

Table 3. Capitation Calculation Per Contract
Name	Description
Calculation Input Date	Based on the mandatory calculation input date, the applicable contract calculation period is selected. The calculation automatically includes earlier periods that need to be (re)calculated.
Look Back Date	The mandatory look back date prevents the system from recalculating capitation for contract calculation periods that end before this date.
Financial Transaction Function	This function facilitates the modification of financial transaction details and financial transaction and financial transaction process data attributes of the financial transaction. Only dynamic logic functions with signature Financial Transaction are allowed.
Disable Grouping on Reversal Indicator for Invoice Lines?	The default behavior is that invoice lines are grouped on (among others) the reversal indicator; as a consequence credit and debit invoice lines can never result in a single zero result invoice line. Setting the parameter to 'Y' disables this default behavior.

The following messages can occur during this activity:

Table 4. Messages During Activity
Code	Severity	Message Text
CPN-VL-CPNC-002	Fatal	Financial transaction function dynamic logic code {code} is unknown or has an invalid signature
CPN-VL-CPNC-007	Fatal	The look back date must be on or before the calculation input date
CPN-VL-CPNC-008	Fatal	Capitation contract code {code} is unknown

The high level flow is depicted in the following picture:

Level 1 Calculate Capitation per Contract

Note that if in any of the steps described below a message is logged, the element id of the message is set to the contract code and contract calculation period start date (separated by a space) of the contract and contract calculation period that are in context. If a fatal error occurs, the activity can be restarted. This will result in only the parts that resulted in errors being processed again, so it is advisable to restart the activity rather than starting a new activity for the same contract.

Select Contract Calculation Periods

The first step of the process selects all contract calculation periods - based on the calculation input date and look back date that are specified as parameters - that potentially need to be (re) calculated and determines per selected period the information that is needed in the subsequent steps. This selection can include past periods, that is, periods that have not been calculated yet or have to be recalculated due to retroactive changes. Whether these periods are actually recalculated depends on the outcome of the next step in the process. This step only selects those periods that may require (re)calculation. The subsequent steps are iterated per selected period.

Select Calculation Periods

All contract calculation periods that have a start date that is on or before the calculation input date and an end date that is on or after the look back date are selected. If there is at least one non-reversed calculation result for a selected period, but there are no contract mutations that take effect before or on the last day of the period, the period is removed from the selection. This check makes sure that past calculations that are still valid are not recalculated. If no periods are selected, the system skips the steps that are performed per contract calculation period and goes directly to the 'Reverse Future Results' step.

Determine Reference Date and Time Periods

Per selected contract calculation period the reference date, contract time period and default time period are determined.

Based on the contract calculation period as input parameter, the function dynamic logic for reference date is executed for each selected period. If no dynamic logic is configured, then the reference date defaults to the start date of each contract calculation period.

The reference date drives the time period selection. The contract time period (if it exists) that includes the reference date of the contract calculation period becomes the contract time period to be used. The default time period that includes the start date of the contract time period or the reference date if no contract time period could be determined, becomes the default time period to be used. The default time period is used to retrieve rate schedule lines and adjustment schedule lines of generic adjustment schedules in the 'Calculate Rate' and 'Calculate Adjustments' steps. The contract time period is used to retrieve contract specific adjustment schedule lines in the 'Calculate Adjustments' step. If the default time period cannot be determined for a contract calculation period, the following message is logged:

Table 5. Determine Reference Date and Time Periods
Code	Severity	Message Text
CPN-FL-CPNC-001	Fatal	No default time period can be determined

Note that errors in executing dynamic logic (to determine the reference date) will also result in the logging of fatal error messages.

Select Contract Alignments and Maintain Attributions

In this step of the process the applicable contract alignments are selected, after which attributions are created. The selection of contract alignments depends on the existing attributions and contract mutations. If no attributions exist at all that reference the contract calculation period, the process of generating attributions is performed for all relevant contract alignments; the existence of contract mutations is irrelevant. This process is described in the No Attributions Present sub-section. If at least one attribution exists that references the contract calculation period, the system selects the applicable contract alignments based on the existing contract mutations. This process is described in the Attributions Present sub-section.

After the evaluation as specified in the sub-sections below is performed, all attributions are in place and not to be changed later in the process. If at this point no attributions exist at all for a contract calculation period, then the system stops the calculation process for the contract calculation period in context and picks up the next contract calculation period in the selection (if applicable). Note that errors in executing dynamic logic (on the provider filter rule) will result in the logging of fatal error messages.

No Attributions Present

All contract alignments where the time validity overlaps with the time validity of the contract calculation period, are selected. Each contract alignment is evaluated against the contract alignment filter condition - if any - that is specified on the contract. This condition has as input the contract alignment, the contract calculation period and the reference date. It typically holds restrictions on the member of the contract alignment, like not under the age of 18 at a certain date like the contract calculation period start date or the reference date. This results in the contract alignment under evaluation being kept or being discarded. Depending on the attribution type of the contract, the list of relevant contract alignments is further built up as specified below per attribution type.

Attribution Type 'Member and Provider': If the attribution type of the contract is 'Member and Provider', this means that attributions are generated with references to a member and a provider.

If provider filter rules exist, then they always specify a provider assignment type, with an optional provider group and/or condition dynamic logic. Provider filter rules are then evaluated against the contract alignment. If multiple provider filter rules exist, they are evaluated in order of sequence. A single filter rule is evaluated thus:

firstly the provider assignment type is used to establish if the member of the contract alignment has an assigned provider of the configured provider assignment type with an overlap in time validity of assigned provider, contract alignment and contract calculation period. If so, this leads to one or more candidate attributions. The candidate attribution references the member, the contract calculation period and the provider that was found as assigned provider and it has as time validity the overlapping time period between assigned provider, contract alignment and contract calculation period. This means that a change of assigned provider results in separate candidate attributions based on a single contract alignment. Each candidate attribution is now evaluated further.
secondly the provider group - if specified - is used to see if the assigned provider references a provider that is part of the specified provider group. The time validity of the provider group affiliation is checked against the time validity of the candidate attribution. If there is an overlap in time validity, the candidate attribution ends up with the overlapping time period; if not, then the candidate attribution is discarded. Note that it is possible that the candidate attribution is split up in multiple candidate attributions if there are multiple provider group affiliations (for the applicable provider) that have an overlap in time validity with the candidate attribution.
finally, the attribution filter condition dynamic logic on the provider filter rule - if specified - is evaluated. This condition is used to see if the candidate attribution evaluates to true. It has as input variables the attribution, the contract calculation period, the reference date and the provider filter rule itself (for parametrization purposes).

The candidate attributions are now made final. If the time validity of the final attributions does not span the complete overlapping time validity between the contract calculation period and the contract alignment, then the second provider filter rule is evaluated, trying to fill any time validity gaps with a new attribution - and so on. If, for example, the contract calculation period is for December 2017 and a member has two attributions, one for December 1st - December 10th and one for December 20th - December 31st, then the second provider filter rule is evaluated looking only at the period December 11th - December 19th.

If no provider filter rules exist, then the logic for filtering further and finding a provider cannot be executed so no attributions are created.

Attribution Type 'Member': If the attribution type of the contract is 'Member', this means that attributions are generated with only a reference to a member, so without a reference to a provider.

If provider filter rules exist, then provider assignment type, provider group and condition dynamic logic are all optional (with at least one needing to be specified). Provider filter rules are then evaluated against the contract alignment. If multiple provider filter rules exist, they are evaluated in order of sequence. A single filter rule is evaluated thus based on what is specified on it:

a provider assignment type is specified without a provider group being specified The provider assignment type is used to establish if the member of the contract alignment has an assigned provider of the configured provider assignment type with an overlap in time validity of assigned provider, contract alignment and contract calculation period. If so, this leads to one or more candidate attributions. The candidate attribution references the member and the contract calculation period and it has as time validity the overlapping time period between assigned provider, contract alignment and contract calculation period.
both a provider assignment type and a provider group are specified All provider group affiliations are checked against all assigned providers of the member with the specified provider assignment type to see if there is an overlap in time validity of assigned provider, contract alignment, contract calculation period and provider group affiliation (there might be multiple overlaps). If an overlap exists, this leads to one or more candidate attributions. The candidate attribution references the member and the contract calculation period and it has as time validity the overlapping time period between assigned provider, contract alignment, contract calculation period and provider group affiliation.
a provider group is specified without a provider assignment type being specified All provider group affiliations are checked against all assigned providers of the member to see if there is an overlap in time validity of assigned provider, contract alignment, contract calculation period and provider group affiliation (there might be multiple overlaps). If an overlap exists, this leads to one or more candidate attributions. The candidate attribution references the member and the contract calculation period and it has as time validity the overlapping time period between assigned provider, contract alignment, contract calculation period and provider group affiliation.

A change of assigned provider of a member can result in separate candidate attributions based on a single contract alignment. However, because the provider is not stored on the candidate attribution, candidate attributions with adjacent time validity can now be merged. An example to clarify: the member switches from PCP, having Provider A (assignment type 'PCP') until the 10th of the month and Provider B (also with assignment type 'PCP') starting on the eleventh of the month. For attribution type 'Member and Provider' a provider assignment type 'PCP' would lead to a candidate attribution to Provider A until the 10th of the month and a candidate attribution to Provider B starting on the eleventh of the month. For attribution type 'Member', no provider is stored on (candidate) attributions, so a provider assignment type 'PCP' now leads to one candidate attribution after merging. When a provider group is specified without a provider assignment type, merging is also performed when a provider occurs in several assigned providers with overlapping time validity but different provider assignment types.

Finally, the attribution filter condition dynamic logic on the provider filter rule - if specified - is evaluated, which has as input variables the attribution, the contract calculation period, the reference date and the provider filter rule itself (for parametrization purposes). If the provider filter rule consists of a condition dynamic logic plus a provider assignment type and/or a provider group, then the condition dynamic logic is applied to the candidate attribution. If the provider filter rule only consists of the condition dynamic logic, then first a candidate attribution is created based on the member and time validity of the contract alignment after which the condition dynamic logic is applied as before.

If no provider filter rules exist, then the logic for filtering further cannot be executed so attributions are created directly.

Attributions Present

If at least one attribution exists that references the contract calculation period, the contract mutations are examined:

if a contract mutation exists of type 'Reattribution' without a reference to a person and with an effective date before or on the last day of the contract calculation period, then all contract alignments are evaluated in the same way as described above in the section 'No Attributions Present'. The difference with the above scenario is that attributions may exist already so before creating new attributions all existing attributions pointing to the contract calculation period being evaluated, are removed and all existing calculation results pointing to the contract calculation period being evaluated, are reversed.
if no such contract mutation exists, then contract mutations with a reference to a person are evaluated. A contract mutation of type 'Reattribution' with an effective date before or on the last day of the contract calculation period that references a person, leads to the evaluation of contract alignments that refer to that person in the same way as described above in the section 'No Attributions Present'. The difference with the above scenario is that attributions may exist already so before creating new attributions all existing attributions pointing to the contract calculation period and the member being evaluated, are removed an all existing calculation results pointing to the contract calculation period and member being evaluated, are reversed.
if no contract mutations of type 'Reattribution' exist at all, this step is completed.

Finally, for every calculation result that is reversed (if any) in this step, a reversal financial transaction of the already existing financial transaction is created. The reversal financial transaction inherits values from the original financial transaction that it represents and therefore, no financial transaction dynamic logic function is executed during its creation. The system also creates a financial transaction with zero amount and no financial transaction details for every reversed (in this step) calculation result that belongs to an attribution that no longer exists (which means that it was removed based on the existence of contract mutations, but that it was not recreated when the contract alignments were reevaluated).

The financial transactions are further processed in the financial sub system to generate Financial Message(s) for the financial application connector that is being used. More information on the financial transaction and financial processing can be found in the Developer Guide for financial processing.

Evaluate Attribution Thresholds

On a contract, an attribution threshold can be set up. For a contract with attribution type 'Member and Provider', it specifies the minimum number of members that a provider must have in a certain contract calculation period before any payment will be made at all. For a contract with attribution type 'Member', it specifies the minimum number of members altogether. Once the threshold is reached, payment is made for all members.

For a contract with attribution type 'Member', this step is carried out whenever the previous step led to the creation or deletion of at least one attribution. The total number of attributions within the contract calculation period that have a distinct member, is calculated.

For a contract with attribution type 'Member and Provider', this step is carried out per provider whenever the previous step led to the creation or deletion of at least one attribution for that provider. Per provider the total number of attributions (referencing that provider) within the contract calculation period that have a distinct member, is calculated.

If the attribution threshold is met, the applicable attributions are calculated normally in the steps that are carried out per attribution. If it is not met, the 'Calculate Rate' and 'Calculate Adjustments' steps are skipped and a calculation result with a zero amount and without calculation result lines is created in the 'Write Calculation Result' step (which results in the creation of a zero amount financial transaction in the 'Write Financial Transaction’step) for the applicable attributions.

Select Attributions

The attributions that meet one or more of the following criteria are selected (this selection will always result in at least one attribution):

the attribution does not have a non-reversed calculation result
a contract mutation^[1]] of type 'Recalculation' exists without references to a person nor a provider
the attribution refers to a person for which a contract mutation^[1] of type 'Recalculation' exists with a reference to that person and without a reference to a provider
the attribution refers to a provider for which a contract mutation^[1] of type 'Recalculation' exists with a reference to that provider and without a reference to a person
the attribution refers to a person and a provider for which a contract mutation^[1] of type 'Recalculation' exists with references to that person and provider

The subsequent steps are iterated per selected attribution. Note that for contracts with attribution type 'Member', if the attribution threshold is not met, the 'Calculate Rate' and 'Calculate Adjustments' steps are skipped for all selected attributions. For contracts with attribution type 'Member and Provider', the 'Calculate Rate' and 'Calculate Adjustments' steps are skipped for attributions that refer to a provider for which the attribution threshold is not met.

Calculate Rate

This section describes how the rate is determined for a single attribution. From the attribution and earlier evaluation the contract, contract calculation period, contract alignment, default time period and reference date are all known.

Determine Rate Schedule Line

This step determines the rate schedule line and finds the applicable rate amount. The system has to find the matching rate schedule line to obtain the appropriate rate amount. The line that matches is the one in the default time period for which the attribution satisfies all specified line conditions. These configurable conditions are typically on the person’s demographics - such as age or gender - and /or on provider characteristics.

The system evaluates rate schedule lines by comparing the field values on the rate schedule line to the field values on (or applicable to) the attribution. The fields on the schedule lines are called schedule dimensions. The system looks for a rate schedule line that matches on all dimensions; when it finds it, the rate amount on that line or the result of the dynamic logic function found on that line is used for further calculation.

If multiple applicable rate schedule lines are found the following messages is logged:

Table 6. Determine Rate Schedule Line
Code	Severity	Message Text
CPN-FL-CPNC-002	Fatal	Multiple applicable rate schedule lines exist for member {code}

If no applicable rate schedule line is found and the indicator Fatal If No Line Found is 'No' the member will be ignored. If no applicable rate schedule line is found and the indicator Fatal If No Line Found is 'Yes' the following messages is logged:

Table 7. Message
Code	Severity	Message Text
CPN-FL-CPNC-003	Fatal	No applicable rate schedule line exists for member {code}

Note that errors in executing dynamic logic (to calculate the rate or to evaluate the generic dimensions) will also result in the logging of fatal error messages.

All dimensions are the result of configuration (see the Configuration Guide on Rates and Adjustments for details). There are two types of configurable schedule dimensions: dynamic field dimensions and generic dimensions. Each of these two types is evaluated differently. Note that a dimension is only evaluated if there is a value specified on the rate schedule line.

Dynamic Field Dimensions: Dynamic field dimensions are evaluated by comparing the value on the rate schedule line with the value of the dynamic field. A dynamic field dimension evaluates one specific dynamic field. These can be dynamic fields on any of the following entities:

Table 8. Dynamic Field Dimensions
Entity	Context Of
Provider	The provider of the attribution
Person	The person of the attribution
Contract	The contract in context
Contract Alignment	The contract alignment (that is valid on the reference date of the contract calculation period) of the applicable person and contract

If the evaluation of rate schedule lines tries to compare a dynamic field dimension on the rate schedule line with a dynamic field that is not configured on the entity in context, the rate schedule line is ignored. It is also possible that the dynamic field values are time-effective. In this case the reference date is used to retrieve the appropriate dynamic field value.

Consider a rate schedule definition that has the dynamic field dimension 'Grade'. The 'Grade' is a dynamic field on the provider record. This dynamic field is time valid. When the system determines the applicable rate schedule line, the value on the rate schedule line is evaluated for the provider of the attribution. The value of the 'Grade' field for this provider on the reference date is compared to the value on the rate schedule line.

Depending on the configuration of the schedule dimensions, the dynamic field value either has to be equal to the value on the rate schedule line, or the dynamic field value has to be within a range specified on the rate schedule line, in order for the rate schedule line to apply. If the line specifies a range, the dynamic field value has to be equal or greater than the range from field but no greater than the range to field. For multi-value dynamic fields at least one dynamic field value has to be equal to the value on the rate schedule line, or at least one dynamic field value has to be within a range specified on the rate schedule line (as described above).

Generic Dimensions: Generic dimensions are meant to configure customized comparisons that cannot be achieved by dynamic field dimensions. A generic dimension is shown as rate schedule column, but the difference is that there is no embedded evaluation logic. Instead, the user can configure this evaluation logic by setting up a dynamic logic condition and attaching it to the schedule definition. This condition has access to the fields on the attribution, rate schedule line and contract calculation period and has the reference date as input as well. Note that if there is no evaluation condition configured for the rate schedule, then generic dimensions are ignored when determining the matching rate schedule line.

Calculate Rate Amount

At this point the system has established the applicable rate amount. The next step is to determine how the rate amount maps to the contract calculation period. For example, if the rate amount applies to a full calendar year, and the contract calculation period only spans a month, the rate amount needs to be reduced to the amount appropriate for the contract calculation period. The amount interpretation of the rate schedule drives how the rate amount is interpreted:

Per contract calculation period
- This means that the rate amount is applied to a contract calculation period, regardless of how many days it spans. If the attribution period is not equal to the contract calculation period, then the outcome is multiplied by the number of days in the attribution divided by the number of days in the contract calculation period.
Per calendar year
- This means that a daily rate is derived from the rate amount and then applied to the number of days in the attribution.

Calculate Adjustments

This section describes the calculation process for the adjustments. Adjustment schedules come in three flavors:

of adjustment type 'Generic' with generic adjustment evaluation 'On Rate' Adjustments of this kind are applied on the rate amount
of adjustment type 'Contract' Adjustments of this type are applied in order of the sequence of configured contract adjustments. The input for the first contract adjustment is the outcome of the rate amount evaluation.
of adjustment type 'Generic' with generic adjustment evaluation 'After Contract Adjustments' Adjustments of this type are applied on the outcome of the previous step (rate plus contract adjustments)

These three flavors are evaluated in order of appearance and described in more detail below.

If multiple applicable adjustment schedule lines are found in an adjustment schedule (regardless of the type), fatal message CPN-FL-CPNC-004 (see below) is logged.

If at any time, the currency of an adjustment amount differs from the currency of the rate amount, fatal message CPN-FL-CPNC-005 (see below) is logged.

If within an adjustment schedule no adjustment schedule line is found and the schedule definition has indicator Fatal If No Line Found set to Yes, fatal message CPN-FL-CPNC-006 (see below) is logged. If within an adjustment schedule no adjustment schedule line is found and the schedule definition has indicator Fatal If No Line Found set to No, the adjustment is ignored.

Table 9. Logged Messages
Code	Severity	Message Text
CPN-FL-CPNC-004	Fatal	Multiple applicable adjustment schedule lines exist for adjustment schedule {code} and member {code}
CPN-FL-CPNC-005	Fatal	Multiple currencies are found in calculation for member {code}
CPN-FL-CPNC-006	Fatal	Adjustment rule is not specified for the adjustment schedule {code} and member {code}

Note that errors in executing dynamic logic (to calculate the adjustment or to evaluate the generic dimensions) will also result in the logging of fatal error messages.

Generic Adjustments on Rate

All enabled adjustment schedules of adjustment type 'Generic' and generic adjustment evaluation 'On Rate' are applied. Because all generic adjustments apply to the rate, the sequence in which the adjustment schedules are evaluated does not affect the outcome. All of the selected adjustment schedules are evaluated consecutively.

Determine Adjustment Schedule Line: For each adjustment schedule, the dimensions of the adjustment schedules lines as well as a condition (if specified) on the schedule definition are evaluated in exactly the same way as rate schedule lines were evaluated. If within an adjustment schedule multiple adjustment schedule lines are found that return a different adjustment value, message CPN-FL-CPNC-004 is logged. If within an adjustment schedule no adjustment schedule line is found and the schedule definition has indicator Fatal If No Line Found set to Yes, message CPN-FL-CPNC-006 is logged
Determine Adjustment Value: The adjustment schedule line holds either an amount, a percentage or a dynamic logic function. The amount and percentage can be positive - meaning that the adjustment value is added to the rate value - or negative - meaning that the adjustment value is subtracted from the rate value. If the adjustment value is a percentage, it is applied directly on the rate amount. If the adjustment value is an amount, the system uses the same pattern that has been used for rates. It uses the amount interpretation of the adjustment schedule. If the amount interpretation is calendar year, then the adjustment value is multiplied by the number of days in the attribution divided by the number of days in the calendar year; if the amount interpretation is contract calculation period, then the adjustment value is multiplied by the number of days in the attribution divided by the number of days in the contract calculation period.

Contract Adjustments

Contract adjustment schedules are adjustment schedules specifically configured for a contract. Alternatively, a contract adjustment schedule can be used by a number of contracts; if one or more specific contracts have deviation values, this can be configured through contract specific overrides. Note that contract adjustments are not evaluated if no contract time period was determined for the applicable contract calculation period in the Select Contract Calculation Periods step.

Determine Contract Adjustments: All contract adjustments for the contract time period in question that refer to an enabled adjustment schedule are selected. The sequence number on the contract adjustment determines in which order the adjustment schedules are applied to the rate. The order matters because adjustment schedule lines can have as value nominal amounts as well as percentages. Lower sequence numbers apply before higher sequence numbers, for example a contract adjustment with sequence '1' applies before a contract adjustment with sequence '2'. This means that the calculation of the contract adjustment with sequence '2' is based on the outcome of the calculation of the contract adjustment '1' (which is based on the rate). This is especially relevant if the contract adjustment with sequence '2' is specified as a percentage. Contract adjustments that have the same sequence number are applied simultaneously, that is, they ignore each other’s calculations and the calculated adjustment amounts are aggregated and applied at the same time.
Determine Adjustment Schedule Line: For each adjustment schedule, the dimensions of the adjustment schedules lines as well as a condition (if specified) on the schedule definition are evaluated in exactly the same way as earlier adjustment schedule lines - and rate schedule lines - were evaluated.
Determine Contract Adjustment Override: If a contract adjustment override exists that points to the adjustment schedule line found and to the contract time period, then this record acts as an override.
Determine Adjustment Amount: The outcome up till now is either a contract adjustment override or - if no override is found - an adjustment schedule line. This result holds either an amount, a percentage or a dynamic logic function. The amount and percentage can be positive - meaning that the adjustment value is added to the calculation - or negative - meaning that the adjustment value is subtracted from the calculation. If the adjustment value is a percentage, it is applied directly on the outcome of the previous calculation. If the adjustment value is an amount, the system uses the same pattern that has been used for rates. It uses the amount interpretation of the adjustment schedule. If the amount interpretation is calendar year, then the adjustment value is multiplied by the number of days in the attribution divided by the number of days in the calendar year; if the amount interpretation is contract calculation period, then the adjustment value is multiplied by the number of days in the attribution divided by the number of days in the contract calculation period.

Generic Adjustments after Contract Adjustments

The steps to calculate the generic adjustments after contract adjustment are identical to the steps described in the section 'Generic Adjustments on Rate' with two differences:

the first is that now all enabled adjustment schedules of adjustment type 'Generic' and generic adjustment evaluation 'After Contract Adjustments' are applied
the second is that adjustment values that are specified as a percentage are calculated using the rate including all contract adjustments rather than the rate alone

Write Calculation Result

If the attribution has an associated non-reversed calculation result, this result is first reversed. Afterwards all parts of the outcome of the calculation are written to the calculation result and calculation result lines. This happens after all preceding steps have been executed for the attribution. The calculation result record is a snapshot of the calculation end results. It stores the outcome of a capitation calculation within the context of a single attribution. The calculation result lines for rate and adjustments are all linked to the calculation result record. The result of each calculation step (rate and adjustments) is stored in a calculation result line record. This record keeps track of both the input amounts and settings as well as the outcome. A detailed description can be found in the Calculation Data Model section.

Rounding: The results of calculation are stored. The scale (the maximum number of decimals allowed) in the database restricts how accurate these money data can be stored. More scale allows for more preciseness on a detail level (for example adjustment on a rate); this way a downstream system could do final rounding only after aggregation (for example, on a provider within a contract).

All amount columns in calculation results and calculation result lines allow for 12 decimals. A system property can be set to specify the number to which each of the number(22,12) columns will be rounded: default is 2, maximum is 12.

Before storing each of those columns into the database, the system property for rounding is checked and applied. For example a value of 0.123456789012 with the system property set to 4 will result in a value of 0.1235 (identical to 0.123500000000) written to the database.

Attribution Thresholds

For contracts with attribution type 'Member', if the attribution threshold is not met, a calculation result with a zero amount and without calculation result lines is created.

For contracts with attribution type 'Member and Provider', if the attribution references a provider that did not meet the attribution threshold, a calculation result with a zero amount and without calculation result lines is created.

Write Financial Transaction

The calculation results are converted to data structures in the financial subsystem to generate invoices and accounting data. These data structures are referred to as 'Financial Transactions'.

The financial transaction represents the calculation outcome for the attribution. For every calculation result that the system creates (including calculation results with a zero amount and without calculation result lines), it also creates corresponding financial transactions. Financial transactions reside under the base financial object, which is the combination of member, contract, calculation period, provider (optional) and attribution start date. A financial transaction has financial transaction details. These financial transaction details correspond to the calculation result lines (if any).

The amount columns (total amount in Financial Transaction and amount in Financial Transaction Detail) allow for the same precision and scale as the calculation amounts - number(22,12) - and follow the rounding that has been applied to the calculation amounts (as described in the previous section).

For a financial transaction, the system checks if an amount has to be split into several payment receivers. The rate splits are defined on the contract. A contract rate split can have as level Rate, Adjustment or All. Rate splits of level Adjustment can also reference a specific adjustment schedule. This means the following options are possible in increasing order of specificity:

all means the rate split applies to all calculation result lines
rate means the rate split applies to the calculation result line for the rate schedule
adjustment (no adjustment schedule specified) means the rate split applies to all calculation result lines for an adjustment schedule
adjustment (adjustment schedule specified) means the rate split applies to the calculation result line for the specified adjustment schedule

If multiple rate splits are configured the more specific ones take precedence. For example configuring a rate split of level adjustment and a rate split of level adjustment referencing a specific adjustment schedule leads to the last one being applied to the calculation result line for that adjustment schedule and the first one being applied to all calculation lines referencing another adjustment schedule while the calculation result line for the rate is not split.

For each contract rate split, one or more contract payment receivers can be defined through dynamic logic while simultaneously specifying the percentage of the split. Each calculation result line is now evaluated to see if a contract rate split is appropriate. If so, then a financial transaction detail is created per contract payment receiver. If not, a single financial transaction detail is created for each calculation result line.

The financial transaction can be customized by the 'Financial Transaction' dynamic logic function that can be specified as input parameter on the global and contract activity. This function is executed per calculation result. The mapping of the fields between calculation result lines and financial transaction details can also be customized by it.

If the attribution is the subject of recalculation, then the system creates a reversal financial transaction which is the reversal of the financial transaction corresponding to the version previous to the latest recalculated version of the calculation result. The reversal financial transaction inherits values from the original financial transaction that it represents and therefore, no dynamic logic function is executed during its creation.

Reverse Future Results

In this step existing results that belong to contract calculation periods that start after the calculation input date, are reversed (as specified below) and the attributions for those contract calculation periods are removed. If for example November 2017 and December 2017 have already been calculated for a certain contract and now the calculation is run again for November 2017 (with the calculation input date being in November 2017), then the calculation results for December 2017 will be reversed and the attributions for December 2017 are removed.

The applicable non-reversed calculation results are first reversed. Afterwards a financial transaction with zero amount and no financial transaction details is created for every reversed (in this step) calculation result (note that the financial transaction dynamic logic function is not executed). The system also creates a reversal financial transaction of the already existing financial transaction for every reversed (in this step) calculation result. The reversal financial transaction inherits values from the original financial transaction that it represents and therefore, no financial transaction dynamic logic function is executed during its creation.

Clean Up Contract Mutations

All the preceding steps after 'Select Contract Calculation Periods' (except the 'Reverse Future Results' step) are executed per contract calculation period. After the iteration over all contract calculation periods is finished and the future results are reversed, all contract mutations that were present for the contract at hand at the start of the activity are cleaned up; this is done for type 'Reattribution' as well as 'Recalculation'. Note that this includes contract mutations that take effect on a date that lies further into the past than the specified look back date.

1. that has an effective date before or on the last day of the attribution