Pre-Pricing Checks

Once the hard coded sanity checks have been executed, the claim goes through the user configured checks and rules that have been set up to trigger in the pre pricing step. These are the pre pricing dynamic checks and pre pricing derivation rules.

This step is not performed for locked claim lines and replaced claim lines.

The flow is schematically depicted by the following figure:

Pre pricing Checks

Remove Existing Messages

The messages attached to the claim, claim line and bills that were attached in a previous pre pricing step are removed. Also removed are the classification scheme plus classifications and classification authorizations that were previously attached.

Claim Scheme Classification

The evaluation of the model for claim classification (for details on the "Claims Classification Model", see the Pricing Components chapter of the Configuration Guide) is split into two parts:

  • determining which classification scheme is used (executed in the pre pricing checks)

  • applying the classification scheme to all claim lines (done after the call out for the DRG grouper)

Why isn’t the evaluation done wholesale? The reason is the in between step for call out to the DRG grouper. The call out rules themselves can be dependent on the classification scheme, so that information needs to be present. On the other hand can the call out change the claim, for example, by updating a dynamic field, so the line by line classification needs to be performed after the call out to the DRG grouper has been made.

The first step is not executed if a fatal message (of origin MANUAL, EXTERNAL or SANITY CHECKS) exists that is attached to the claim. It is done by comparing the claim to all classification schemes (regardless of their details). All the classification schemes are evaluated with respect to

  • location type group
    If specified in combination with location type group usage 'In': one of the location types in the location type group should match the location type of the claim.

    If specified in combination with location type group usage 'Not In': none of the location types in the location type group should match the location type of the claim.

  • classification scheme claim forms
    If specified, the claim form should match one of the specified classification scheme claim forms.

  • condition dynamic logic
    Claim level dynamic logic condition to validate that the classification scheme is applicable.

If more than one classification scheme is applicable, then the following fatal message is attached to the claim:

Code Sev Text

CLA-FL-PPRI-019

Fatal

No more than one classification scheme may be applicable

Otherwise, if one classification scheme is found, the code of the classification scheme is stored on the claim header. It is, of course, also possible that the evaluation does not result in a classification scheme being matched.

Derivation Rules

A derivation rule sets the value of certain fields on a claim, bill or claim line. There are two types of derivation rules:

  • process field derivation rules are used during the pre pricing checks to set the value of the following fields:

    • claim.externalPricing

    • claim.externalBenefits

    • claimLine.priceIndividualProvider

    • claimLine.priceOrganizationProvider

    • claimLine.priceInputDate

    • claimLine.priceInputNumberOfUnits

    • claimLine.pricePrincipalProcedure1 (set through process field pricePrincipalProcedure)

    • claimLine.pricePrincipalProcedure2 (set through process field pricePrincipalProcedure)

    • claimLine.pricePrincipalProcedure3 (set through process field pricePrincipalProcedure)

    • claimLine.benefitsProvider

  • derivation rules can set the value of a dynamic or native field on either the claim, the bill or the claim line.

At this point in the flow, only derivation rules are executed for which the "step" field has the value "pre pricing".

Derivation rules are not evaluated if a fatal message (of origin MANUAL, EXTERNAL or SANITY CHECKS) exists that is attached to the same (or higher) level as specified by the derivation rule.

The pre pricing derivation rules are evaluated in the following order:

  1. Process Field Derivation Rule on the claim determining the claim.externalPricing

  2. Derivation Rules on the claim; if multiple derivation rules exist, they are executed in order of the configured sequence (sequence null is evaluated last)

  3. Derivation Rules on the bill; if multiple derivation rules exist, they are executed in order of the configured sequence (sequence null is evaluated last)

  4. Derivation Rules on the claim line; if multiple derivation rules exist, they are executed in order of the configured sequence (sequence null is evaluated last)

  5. Process Field Derivation Rules on the claim line in the following order:

    1. claimLine.priceIndividualProvider [1]

    2. claimLine.priceOrganizationProvider [1]

    3. claimLine.priceInputDate[1]

    4. claimLine.priceInputNumberOfUnits [1]

    5. claimLine.pricePrincipalProcedure1, claimLine.pricePrincipalProcedure2 and claimLine.pricePrincipalProcedure3 (all set through process field pricePrincipalProcedure)footnote:fn1 [2]

    6. claimLine.benefitsProvider[3]

  6. Process Field Derivation Rule on the claim determining the claim.externalBenefits

If an as-of-date is needed, the price input date is used for all but the benefits provider, where the claim line start date is used. As is apparent however, the price input date is not the first process field to be determined so it’s possible that the price date is not at hand during the evaluation of the price providers (in the situation that the price input date is not sent in on the claims in); in that situation, the claim line start date is used. If the price input date is still not specified directly after the step 'price date derivation rule' then the following product independent fatal message is attached to the claim line:

Code Sev Text

CLA-FL-PPRI-014

Fatal

The pricing of this line requires the price input date to be specified

If more than one process field derivation rule is found for a certain process field, the list is ordered by the process derivation priority of the process field derivation rule. The lower the priority field value, the higher the priority. If a process field derivation rule has no priority value, then this is interpreted as the lowest possible priority. This way, only a single process field derivation rule should have the highest priority for a certain process field. If not, the following product independent fatal message is attached to the claim or claim line:

Code Sev Text

CLA-FL-PPRI-013

Fatal

Multiple process field derivation rules with the same priority have been found for process field {process field name}

Send Out for Preprocessing?

A claim can be sent out for preprocessing, which means that upstream information needs to be added to a claim. It is sent out if the following conditions are met:

  • The claim routing slip "Ind Preprocessing Done" is unchecked

  • The claim routing slip "Ind Send Out For Preprocessing" is checked

When a claim is to be sent out for preprocessing the following happens:

  • The claim gets the status SENT OUT FOR PREPROCESSING

  • The pre-finalized claim out integration point sends out a notification message that the claim is ready to be retrieved.

Dynamic Checks

A dynamic check represents a (user configured) condition. If the claim or claim line fails to meet that condition, a message is attached. A dynamic check is executed on one of two points in the flow. The first moment is during the pre-pricing checks, as described here. The second moment is during the pre-benefits checks. At which of the two points a check executes depends on the way the check is configured.

Pre-pricing dynamic checks can be either on the claim, or the claim line level. Claim level dynamic checks are executed first. Dynamic checks are not evaluated if a fatal message (of origin SANITY CHECKS) exists that is attached to the same (or higher) level as specified by the dynamic check.

Dynamic checks that do not require enrollment or payment status data are typically configured as pre pricing checks. For example checking the consistency of dynamic field values: a "dischargeDate" cannot be before an "admissionDate".

1. Only evaluated if both pricingDone and externalPricing indicators are set to false.
2. Only evaluated if keepPricePrincipalProcs indicator is set to false
3. Always evaluated