Claims
To process claims, the application stores all incoming claims in a canonical data model. This page describes the native claim model and its constituent parts.
Payers and providers exchange healthcare claims using many standards and formats. The canonical claim model is highly extensible to support the need for flexibility, enabling you to add additional data elements to what is described on this page.
Claim Process Type
A claim represents a number of healthcare services provided to a patient. In this context, the patient (referred to as the member from now) is a natural person that is insured by one of the health plans administered by the payer.
There are three types of claims. Each type uses the same canonical claim model, but is different in how it is processed.
Actual Claims
Actual claims are priced and adjudicated as normal. They evaluate, consume, and potentially exhaust the benefits afforded to the member through their health plan. Actual claims can result in a payment to whomever submitted the claim.
Reservation / Pre-Determination Claims
Some scenarios require the provider to obtain pre-approval for a healthcare service. Such a reservation claim is submitted as if it were an actual claim. Reservation claims are processed exactly like actual claims, with the following differences:
-
Reservation claims do not result in payment. [1]
-
Reservation claims block the benefit, so that it can’t be exhausted by other claims. Only the actual claim or claims that match up with the reservation can use the reserved benefit.
Reservation claims have an expiration date. This prevents a reserved benefit from being blocked indefinitely in the event that the matching actual claim is never received.
Quote Claims
Some scenarios require the member or provider to obtain an indication for the cost of a healthcare service. Such a quote claim is submitted as if it were an actual claim. Quote claims are processed exactly like actual claims with the following differences:
-
Quote claims do not result in payment. [1]
-
While quote claims use the member’s current accumulators and counters to come up with an accurate indication of the expected reimbursement, the quote claim does not update those counters and accumulators. In other words, there is no lasting effect.
Model
The following section describes the available data elements on a claim. This includes both the data elements that are submitted on the claim as received, as well as the data elements that are set during the pricing and adjudication of the claim.
Those data elements that are required by the application are marked as mandatory. All other data elements are optional.
Claim
This entity represents the claim header and stores the following fields:
Field | Description |
---|---|
Authorization Code |
The authorization code as supplied on the incoming claim. |
Brand |
The brand of the health plan under which this claim is to be adjudicated. |
Claim Date |
The date that the claimant created the claim. |
Claim Set |
The set to which this claim belongs. |
Claimant Provider |
The billing provider submitted the claim. |
Claimant Relation |
The relation that created the claim. |
Classification |
The classification of the claim as determined by the application |
Classification Scheme |
The scheme that the application used to classify the claim. |
Code |
Mandatory. The assigned identifier for this claim. |
Due Date |
The date that the claim is due for payment. |
End Date |
The last (latest) claim line of end date. |
Entry Date |
The date the claim first entered the application. |
Expiration Date |
The date after which the reservation consumption expires. |
External Remarks |
Free text remark field. |
Form |
Mandatory. Specifies the form of the claim. |
Data Access Group |
The code used in the context of user access restrictions on this claim. |
Ind Changed in UI |
Checked by the application if the claim is changed after being unfinalized. |
Ind Emergency |
If checked, claim is considered to specify an emergency service. |
Ind External Benefits |
If checked, the application skips the benefit adjudication step for this claim. |
Ind External Pricing |
If checked, the application skips the pricing step for this claim. |
Ind High Priority |
If checked, this claim is picked up by the automated pricing and adjudication process before any non-priority claims. |
Ind Ignore History |
If checked, this claim skips rules that involve evaluating other claims, such as duplicate claim rules. |
Ind Manual |
Checked by the application if the claim was keyed in manually. |
Ind Preprocessing Done |
Checked if the claim has been preprocessed. |
Ind Pricing Done |
Checked by the application once the claim is priced. |
Ind Send out for Preprocessing |
If checked, the application sends the claim out for preprocessing. |
Ind Send out for Pricing |
If checked, the application sends the claim out for repricing. |
Internal Remarks |
Free text remark field. |
Location Provider |
The provider location where the service was rendered. |
Location Type |
The type of location where the service was rendered. |
Next Payer Code |
The subsequent receiver of this claim, applicable within the context of coordination of benefits. |
Paid Date |
The date that the preceding payer paid this claim, applicable within the context of coordination of benefits. |
Payer Code |
The payer code used in context of user access restrictions on this claim. |
Payment Beneficiary Provider |
The provider to which the payment for this claim is due. |
Payment Beneficiary Relation |
The relation to which the payment for this claim is due. |
Payment Receiver Provider |
The provider that is to receive the payment for this claim. |
Payment Receiver Relation |
The relation that is to receive the payment for this claim. |
Payment Specification Receiver Provider |
The provider that is to receive the payment specification. |
Payment Specification Receiver Relation |
The relation that is to receive the payment specification. |
Preceding PayerCode |
The payer that has to adjudicate this claim prior to being processed by the application. This is applicable within the context of coordination of benefits. |
Price Date |
The date that this claim was priced. |
Process Type |
The type of the process to follow. The possible values are:
|
Provider Entity Reference |
An alternative reference to the serviced member on this claim. |
Provider Reference |
An external reference to this claim. |
Receipt Date |
The date that the payer received the claim. |
Referral Provider |
The provider that referred the serviced member in context of the services specified on this claim. |
Service Provider |
The provider that rendered the services specified on this claim. |
Service Specialty |
The specialty under which the services specified on this claim were rendered. |
Serviced Entity |
The member that has undergone the services specified on this claim. |
Start Date |
The first (earliest) claim line start date. |
Status |
The current state of the claim in the processing flow. Possible values are:
|
Total Allowed Amount |
The allowed amount accumulated over all claim lines. |
Total Allowed Amount Currency |
The currency of the total allowed amount. |
Total Claimed Amount |
The claimed amount as specified when the claim was entered. |
Total Claimed Amount Currency |
The currency of the total claimed amount. |
Total Covered Amount |
The covered amount accumulated over all claim lines. |
Total Covered Amount Currency |
The currency of the total covered amount. |
Type |
Mandatory. Member Restitution or Provider claim? |
Claim Messages
A claim message conveys information regarding the pricing and adjudication of that claim. Claim messages serve the following purposes.
-
Provide context on how the claim has been processed.
-
Serve as hooks to pend a claim for manual inspection and intervention.
A claim can have zero, one, or multiple messages attached to it:
Field | Description |
---|---|
Claim |
The claim to which the message belongs. |
Value0 through value9 |
The parts of the message text that are determined at run time. |
Message |
The message that specifies severity and the static part of the message text. |
Origin |
The origin of the message that specifies in what interval of the claims processing flow the message was added. Possible values are: ADJUDICATION, PRE BENEFITS, BENEFITS, COVERAGE, ENROLLMENT, EXTERNAL, MANUAL, PAYMENT STATUS, PRE PRICING, PRICING, PRICING LIMIT, PRICING NO RECALCULATION, RESERVATION and SANITY CHECKS |
Skip Tag |
The skip tag which was added though the callout. |
Overturned Indicator |
Indicates whether a claim message is overturned. An overturned message acts like an informative message. Only Deny messages can be overturned. |
Overturned By |
The user who overturned the claim message. |
Notes
Notes can be used to store free format instructions, clarifications, or comments within the context of the claim.
A claim can have zero, one, or multiple notes attached to it:
Field | Description |
---|---|
Claim |
The claim to which the note belongs. |
Version |
The version of the note (when an existing note is updated a new version of that note containing the updates is created; existing records of notes are never updated). |
Note Text |
The text of the note. |
Claim Diagnoses
A claim diagnosis represents information about the member’s state of being when the service was provided or the reason why the service was provided.
A claim can have zero, one, or multiple diagnoses attached to it:
Field | Description |
---|---|
Claim |
The claim to which the diagnosis belongs. |
Diagnosis |
The diagnosis that is specified on the claim. |
Type |
The type of the diagnosis (for example principal, admitting, e-code). |
Sequence |
The relative importance of this diagnosis on this claim. |
Within a claim, a specific diagnosis can only be present once for a particular diagnosis type. The claim diagnosis with the lowest sequence number is interpreted as the primary diagnosis of the claim. The primary diagnosis is the diagnosis that Claims uses to evaluate benefit specifications. See the Configuration Guide on Product Definition for more information.
Claim Un-finalize Reasons
A claim that is fully processed within Claims attains the status "finalized." A claim may need to be corrected after it has been finalized and this is supported by a mechanism that "unfinalizes" a claim. After unfinalizing a claim, the claim can be changed and reprocessed. When a claim is unfinalized, the claims operator or integration point that unfinalized the claim is required to specify a reason explaining why the claim has been unfinalized.
Whenever a claim is unfinalized, any existing unfinalized reasons are discarded before the new reasons are attached. Unfinalize reasons attached to a claim only apply to the most recent unfinalization. A claim can have zero, one, or multiple unfinalize reasons attached to it:
Field | Description |
---|---|
Claim |
The claim that is unfinalized. |
Unfinalize Reason |
The reason that leads to the unfinalize. |
Source Reference |
The reference to the source document that triggered the unfinalize. |
Whether or not the sourceReference field is mandatory depends on the configuration of the unfinalize reason.
Claim Pend Reasons
The application includes configurable business rules that detect when a claim requires manual intervention. If this happens, the applicable rule attaches a pend reason to the claim that explains why the claim is pended.
After a pend reason is resolved, or when the claim is reprocessed, claim pend reasons are discarded by the application. The history of pend reasons is stored in a separate entity named "Claim Pend Reason History."
A claim can have zero, one, or multiple pend reasons attached to it:
Field | Description |
---|---|
Claim |
The claim to which the pend reason belongs. |
Pend Reason |
The pend reason. |
Claim History
The following entities describe the track history of how the claim is processed.
A claim’s status reflects the position of a claim in the processing flow. The claim status history keeps track of all status transitions so that it is possible to trace back how a claim flowed through the processes and how long it took to complete specific steps. The claim status history entity has the following fields:
Field | Description |
---|---|
Claim |
The claim the history is for. |
Status |
The status of the claim at date time. |
Datetime |
Date and time when the claim entered the status. |
The claim status history keeps all statuses of a claim up to and including the current status. A number of claim statuses reflect that the claim has pended. The reasons why a claim is pended are also stored as a detail of a claim status history that logs a pend status. A claim pend reason history entity has the following fields:
Field | Description |
---|---|
Claim Status History |
The claim status history entry under which the pend reason was active. Only the claim status history entries for the statuses MANUAL PRICING, MANUAL BENEFITS and MANUAL ADJUDICATION are eligible. |
Code |
Code of the claim line. Only filled for claim line pend reasons. |
Pend Reason |
The pend reason. |
Resolved by |
The user who resolved the pend reason. |
Resolved Datetime |
The date and time when the pend reason was resolved. |
The application enables you to configure business rules that emit events to external components in certain situations. The claim event history entity has the following fields:
Field | Description |
---|---|
Claim Status History |
The claim status history record to which the claim event history record is attached. |
Event |
The event of the claim event rule, published in the message. |
Ind Display in UI |
Should the claim events fired by this rule be shown in the UI? |
Level |
The level of the event that was sent (Claim, Claim with Lines or Claim Line). |
Topic |
The topic of the claim event rule, published in the message. |
The following entity tracks which claim line or lines triggered the event:
Field | Description |
---|---|
Claim Event History |
The claim event history record to which the claim line event history record is attached. |
Claim Line Code |
The identification of the claim line for which the event was fired. |
The application enables you to configure business rules that call out to an external component to retrieve additional information required to adjudicate the claim. The claim callout history entity has the following fields:
Field | Description |
---|---|
Claim Status History |
The claim status history record to which the claim callout history record is attached. |
Definition Code |
The code of the callout definition used to execute the callout. |
Definition Descr |
The description of the callout definition used to execute the callout. |
Request Sent Datetime |
The date and time when the request message was sent. |
Response Received Datetime |
The date and time when the response message was received. |
Ind Display in UI |
Should the claim events fired by this rule be shown in the UI? |
Claim Tag Actions
Claim tag actions enable you to skip certain steps in the pricing and adjudication process. This applies, in particular, to callout rules that should only be invoked once, even if the claim is reprocessed several times.
A claim can have zero, one, or multiple tag actions attached to it:
Field | Description |
---|---|
Claim |
The claim to which the tag action belongs. |
Skip Tag |
The skip tag. |
Action |
The action to be taken. |
Claim Lines
A claim line specifies a healthcare service provided to the serviced member. A claim has at least one claim line.
Field | Description |
---|---|
Allowed Amount |
The allowed amount. |
Allowed Amount Currency |
The currency of the allowed amount. |
Allowed Number of Units |
The allowed number of units provided by an external application, manual pricing or internal pricing engine. |
Authorization Code |
This field stores the authorization code as supplied on the incoming claim line. |
Authorization Exception Type |
Specifies the type of authorization (authorization, notification or referral) for which this claim line is exempt from any authorization requirement. |
Benefits Age Input Date |
The date used for age determination in benefits selection. |
Benefits Provider |
The provider that is used in context of the evaluation of benefit rules. |
Benefits Input Amount |
The amount based on which the benefits are calculated. |
Benefits Input Amount Currency |
The currency of the benefits input amount. |
Benefits Input Date |
The date used for benefits selection. |
Claim |
The claim to which this claim line belongs. |
Claim Line |
The reservation line that is matched against the actual claim line for consumption. The only allowed reference from claim line to claim line is the one from a line belonging to a claim with process type C(laim) to a line belonging to a claim with process type R(eservation). |
Claimed Amount |
The charged amount as specified by the claimant. |
Claimed Amount Currency |
The currency of the claimed amount. |
Claimed Number of Units |
Mandatory. The charged number of units as specified by the claimant. |
Classification |
This field stores the classification of the claim line (automatically determined during claims classification). |
Classification Authorization |
This field stores the authorization that was used as grounds for the classification of the claim line. |
Code |
Mandatory. Identifier for this claim line, unique within the claim. |
Covered Amount |
The covered amount as calculated by Claims. |
Covered Amount Currency |
The currency of the covered amount. |
Covered Number of Units |
The covered number of units as calculated by Claims. |
End Date |
Service end date. |
Ind Encounter |
If checked, this claim line is an encounter claim line. |
Ind Emergency |
If checked, the service on this claim line is qualified as an emergency service. |
Ind Keep Benefits |
If checked, this line remains untouched when the claim is reprocessed for benefits, nor does it trigger external intervention rules for manual benefits. |
Ind Keep Pricing |
If checked, this line remains untouched when the claim is repriced, nor does it trigger external intervention rules for manual pricing. |
Ind Keep Price Principal Procs |
If checked, then the principal price procedure indicators remain untouched by derivation rules. |
Ind Manual Benefits |
If checked, the coverage for this claim line has been manually altered. |
Ind Manual Pricing |
If checked, the allowed amount for this claim line have been manually altered. |
Ind Price Principal Procedure1 |
If checked, then procedure1 is marked as principal for pricing purposes. |
Ind Price Principal Procedure2 |
If checked, then procedure2 is marked as principal for pricing purposes. |
Ind Price Principal Procedure3 |
If checked, then procedure3 is marked as principal for pricing purposes. |
Ind Replaced |
If checked, then this claim line is replaced by another claim line. |
Ind Locked |
If checked, then this claim line is locked for any changes. This means that the claim line cannot be updated and that it will not be again processed when the claim that it belongs to is reprocessed (all results on the claim line will be kept). This indicator cannot be directly set:
See "Claim Line Locking Scenarios" section in the Appendices part of the Operations Guide for more information. |
Location Provider |
The location where the service was rendered. |
Location Type |
The type of location where the service was rendered. |
Payment Receiver Provider |
The provider that will receive the payment for this claim line. |
Payment Receiver Relation |
The relation that will receive the payment for this claim line. |
Preceding Payer Paid Amount |
The accumulated amount that has been paid to the claimant by the all preceding payers. |
Preceding Payer Paid Amount Currency |
The currency of the preceding payer paid amount. |
Price Individual Provider |
The individual provider that is used for pricing. |
Price Organization Provider |
The organization provider that is used for pricing. |
Price Input Date |
The date that is used for pricing. |
Price Input Number of Units |
The number of units that is used as input to pricing. |
(procedure 1) [2] |
Specifies the service rendered. |
(procedure 2) |
Specifies the service rendered. |
(procedure 3) |
Specifies the service rendered. |
Process as In |
If checked, this claim line is processed as though the benefits provider is
in one of the product provider groups on the claim line start date. |
Provider Entity Reference |
A free text external reference to the serviced member on this claim line. |
Provider Reference |
A free text external reference to this claim line. |
Referral Provider |
The provider that referred the serviced member in the context of the service specified on this claim line. |
Reservation Code |
Used for matching reservation matching. |
Reservation Line Code |
Used for matching reservation matching. |
Sequence |
Mandatory. Order (for UI and processing) of this claim line in context of the claim to which it belongs. |
Service Provider |
The provider that rendered the service specified on this claim. |
Service Specialty |
The specialty under which the service specified on this claim is rendered. |
Serviced Entity |
The member that has undergone the services specified on this claim line. |
Skip Tag |
The skip tag which was added through the callout. |
Skip Tag Allowed |
The skip tag which was added through the callout or replacement rule that led to update of allowed amount or units. |
Start Date |
Mandatory. Service start date. |
Status |
Indicates the status of the claim line: APPROVED or DENIED. If the claim line has not yet been or is being processed, the status is blank. |
Replaced by Line |
Specifies the claim line by which this line is replaced. |
Replaces Line |
Specifies the claim line that replaces this claim line. |
Waiting Period Input Date |
The date used for determining the waiting period. |
Claim Line Overrides
A claim line override holds values that override the retrieved information in the claims flow.
Field | Description |
---|---|
Authorization Regime |
The authorization regime that applies to this line. This overrides the information retrieved in the claims flow. |
Coverage Specification |
The coverage benefit specification to be used in this line. This overrides the information retrieved in the claims flow. |
Coverage Regime |
The regime that specifies the coverage that should apply to this line. This overrides the information passed back through the enrollment interface. |
Coverage Regime No Auth |
The regime that specifies the coverage that should apply to this line in case no authorization is found. This overrides the information passed back through the enrollment interface. |
Family Code |
The unique identifier for the family of the serviced member. This overrides the information passed back through the enrollment interface. |
Funding Arrangement |
The funding arrangement to be used to determine the product category. |
Post Benefit Regime |
The post benefit regime that applies to this line. This overrides the information retrieved in the claims flow. |
Product |
The product to be used for benefits. This overrides the information passed back through the enrollment interface. |
Product Family |
The product family to be used to determine the product category. |
Product Line |
The product line to be used to determine the product category |
contract start date |
The date that specifies the start of the policy contract. This overrides the information passed back through the enrollment interface. |
Waiting Period Regime |
The waiting period regime that applies to this line. This overrides the information retrieved in the claims flow. |
Claim Line Messages
A claim line message is identical to its counterpart on the claim and represents the information of that claim’s traversal through the calculation/adjudication process.
A claim line can have zero, one, or multiple messages attached to it:
Field | Description |
---|---|
Claim Line |
The claim line to which the message belongs. |
Value0 through value9 |
The parts of the message text that are determined at run time. |
Message |
The message that specifies severity and the static part of the message text. |
Origin |
The origin of the message that specifies in what interval of the claims processing flow the message was added. Possible values are: ADJUDICATION, PRE BENEFITS, BENEFITS, COVERAGE, ENROLLMENT, EXTERNAL, MANUAL, PAYMENT STATUS, PRE PRICING, RESERVATION, PRICING, PRICING LIMIT, PRICING NO RECALCULATION and SANITY CHECKS. |
Product |
The product to which the messages applies. |
Skip Tag |
The skip tag which was added through the callout. |
Overturned Indicator |
Indicates whether a claim line message is overturned. An overturned message acts like an informative message. Only Deny messages can be overturned. |
Overturned By |
The user who overturned the claim line message. |
Claim Line Diagnoses
A claim line diagnosis is identical to its counterpart on the claim and represents the information of the performed healthcare service.
Field | Description |
---|---|
Claim Line |
The claim line to which the diagnosis belongs. |
Diagnosis |
The diagnosis that is specified on the claim line. |
Type |
The type of the diagnosis (for example principal, admitting, e-code). |
Sequence |
The relative importance of this diagnosis on this claim line. |
Within a claim line, a specific diagnosis can only be present once in a particular diagnosis type. The claim line diagnosis with the lowest sequence number is considered the primary diagnosis on the claim line. The primary diagnosis is the diagnosis that Claims uses to evaluate benefit specifications. See the Configuration Guide on Product Definition for more information.
Claim Line Modifiers
A claim line can have multiple modifiers attached to it:
Field | Description |
---|---|
Claim Line |
The claim line to which the modifier belongs. |
Modifier |
The modifier that is specified on this claim line. |
Claim Line Parameters
Claim line parameters are used to override at the claim line level. The parameter values of the coverage regime are used to calculate the claim line’s benefits. This feature is typically used in an exceptional circumstance where a copay or coinsurance should be ignored for a specific claim line, even though it would normally apply.
Field | Description |
---|---|
Claim Line |
The claim line to which the parameter belongs. |
Cover Withhold Category |
The cover withhold category of which the percentage or amount should be overwritten. |
Percentage |
The percentage of the amount of the rendered procedure that is either covered or withheld. |
Amount per Unit |
The nominal amount per unit of the rendered procedure that is either covered or withheld. |
Currency |
The currency of the amount per unit. |
Product |
If specified, the value in this record only applied to regimes adjudicated under the specified product |
Claim Line Limits
Claim line limits override the behavior for a specific limit within the context of benefits adjudication. For example, this enables you to increase the maximum for a specific benefit limit in the context of this claim line only.
Field | Description |
---|---|
Claim Line |
The claim line to which the parameter belongs. |
Limit |
The limit towards which should be counted; identifies the counter to be used. |
Cover Withhold Category |
The cover withhold category of which the percentage or amount should be overwritten. |
Maximum Amount |
The maximum amount to be applied. |
Currency |
The currency of the maximum amount. |
Maximum Number |
The maximum number of units to be applied. |
Maximum Service Days |
The maximum number of service days to be applied. |
Product |
If specified, the value in this record is only applied to regimes adjudicated under the specified product. |
Reached Action |
The action when the limit is reached (stop or continue). |
Claim Line Contract References
A claim line can have multiple contract references.
Field | Description |
---|---|
Claim Line |
The claim line to which the contract reference applies. |
Contract Reference |
The contract reference that applies to this claim line. |
Claim Line Pend Reasons
A claim line can have multiple pend reasons attached to it:
Field | Description |
---|---|
Claim Line |
The claim line to which the pend reason belongs. |
Pend Reason |
The pend reason. |
Claim line pend reasons store only the current pend reasons. The entire history of pend reasons is stored separate entity.
Claim Sub Lines
A claim line can have one or more sub lines. This feature is intended to support claim lines with a service code that represents a composite of several other service codes. For example, consider a claim line that specifies a service code that represents a custom pharmaceutical recipe, and the sub lines specify the actual ingredients and quantities.
A sub line has a sequence number within the context of the parent claim line:
Field | Description |
---|---|
Claim Line |
The claim line to which this sub line belongs. |
Claimed Number of Units |
The number of claimed procedure units. |
Procedure |
The service or goods provided. |
Sequence |
Identifier of this sub line in context of the claim line. |
A claim line can have up to 99 claim sub lines.
Claim Line Rule Coverages
The application creates claim line rule coverages to store the intermediate results of the benefit calculation process. A claim line can have one or more claim line rule coverages.
A claim line rule coverage has the following fields:
Field | Description |
---|---|
Claim Line |
The claim line to which the coverage belongs. |
Cover Withhold Rule |
The cover withhold rule that resulted in this rule coverage. |
Post Cover Withhold Rule |
The post cover withhold rule that resulted in this rule coverage. |
Coverage Label |
The label that specifies the nature of the amount (for example copay or deductible). |
Amount |
The covered or withheld amount. |
Currency |
The currency of the amount. |
Number of Units |
The covered or withheld number of units. |
Action |
Indicates whether the amount is a covered amount or a withheld amount. |
Product |
The product to which the applied benefit belongs. |
Claim Line Coverages
The application creates claim line coverages to store the final results of the benefit calculation process. A claim line can have one or more claim line coverages.
A claim line coverage has the following fields:
Field | Description |
---|---|
Claim Line |
The claim line to which the coverage belongs. |
Coverage Label |
The label that specifies the nature of the amount (for example copay or deductible). |
Amount |
The covered or withheld amount. |
Currency |
The currency of the amount. |
Number of Units |
The covered or withheld number of units. |
Action |
Indicates whether the amount is a covered amount or a withheld amount. |
Product |
The product to which the applied benefit belongs. |
Claim Line Benefit Specifications
The application creates claim line benefit specifications as a result of the benefits selection process. A claim line can have one or more claim line benefit specifications.
A claim line benefit specification has the following fields:
Field | Description |
---|---|
Claim Line |
The claim line for which the regime is evaluated. |
Benefit Specification |
The benefit specification that is evaluated. |
Coverage Regime |
The coverage regime that is evaluated. |
Authorization Regime |
The authorization regime that is evaluated. |
Reservation Regime |
The reservation regime that is evaluated. |
Waiting Period Regime |
The waiting period regime that is evaluated. |
Post Benefits Regime |
The post benefits regime that is evaluated. |
Evaluation Result |
The outcome of the regime evaluation. Possible values:
|
Product |
The product to which the applied benefit belongs. |
Product Benefit Specification |
The combination of product and benefit specification that was used to calculate benefits for the claim line. |
Product Provider Group Status |
IN if the benefits provider is in at least one of the product provider groups. OUT otherwise. |
Product Provider Group |
The product provider group used to verify that the productProviderGroupStatus is IN. Unspecified in case the productProviderGroupStatus is OUT. |
Specific Provider Group Status |
IN if the benefits provider is in at least one of the benefit specification provider groups. OUT otherwise. |
Specific Provider Group |
The benefit specification provider group used to verify that the specificProviderGroupStatus is IN. Unspecified in case the specificProviderGroupStatus is OUT. |
Inherited Provider Group Status |
The provider group status that the line inherited through being part of a medical case. |
Processed as In |
If claimLine.processAsIn = 'Y' and no overriding coverage regime is specified, then this value is set to 'Y'; in this situation the processAsIn indicator is directly responsible for the claim line being processed as if in network. |
When the claim line uses an overriding regime, the benefit specification, product benefit specification, and the six fields that track the provider network status are left empty.
Claim Line Provider Pricing Clauses
The application creates claim line provider pricing clauses as a result of the pricing process. A claim line can have one or more claim line provider pricing clauses. A claim line provider pricing clause has the following fields:
Field | Description |
---|---|
Claim Line |
The claim line for which provider pricing clause is applied. |
Provider Pricing Clause |
The provider pricing clause that is applied. |
Fee Schedule Line |
The fee schedule line that is applied (only filled when a fee schedule is applied). |
Sequence |
The order in which the provider pricing clause is applied. |
Mark |
The way a claim line is marked with respect to the pricing rule. For example, the claim line can be primary or secondary in a combination adjustment rule. |
Amount |
The amount (plus, minus or zero) that shows the difference to the last outcome. |
Currency |
The currency of the amount. |
Limit Consumptions
A claim line may have one or more limit consumptions. These represent increments to a specific limit that resulted from the adjudication of the claim line. See the "Limit consumptions" section described in the Adjudication Limits.
Model Features
Non-Matched Data Elements
A claim has many data elements that rely on reference tables, such as service codes, providers, and members. When the claim is loaded, these data elements in the payload are matched against the records that are stored in the application.
If the application fails to find the matching reference data for any data element, the claim is still loaded. An error message is attached to the claim.
In addition, application stores whatever information it received regarding the data element that it failed to find, so that claim can be manually remediated.
A claim stores multiple text fields for each unmatched data element. For example, when the application fails to recognize the serviced member, it stores the following information instead, provided the information was included in the claim payload:
-
Non matched entity type
-
Non matched alternate key
-
Non matched name
-
Non matched address
-
Non matched entity date
-
Non matched dynamic field name
-
Non matched dynamic field value
This feature applies only to a restricted set of entities. These are:
-
Persons
-
Organizations
-
Providers
-
Specialty
-
Procedures
-
Diagnoses
-
Modifiers
-
Messages
-
Location Type
If the application fails to find a matching record for an entity that is not on this list, the claim is not loaded. When this happens, the application returns an error message specifying which data element is unrecognized.
Inherited Field Values
A claim has two levels: a claim header and any number of claim lines. Several data elements can be specified on both levels.
For example, the serviced member can be specified on the claim header, applying to all lines. Alternatively, for multi member claims, the serviced member is specified on the line level, with no member specified on the header level.
For pricing and adjudication purposes, the application always uses the following logic:
-
Use the value specified on the claim line, if specified.
-
Otherwise, use the value specified on the claim header.
Process Fields
A claim can contain hundreds of data elements. Only a subset of those data elements influences how claims are priced and adjudicated. You can set up business rules to identify those data elements.
This is especially relevant when there is a level of ambiguity. For example, the claim can specify multiple providers as well as a provider location. The logic that derives which of those providers is used to determine the network participation status during the benefit selection is subject to a payer specific business rules. The result of such business rules is stored in process fields.
The following are process fields:
-
The due date (claim).
-
The price organization provider (claim line).
-
The price individual provider (claim line).
-
The price input date (claim line).
-
The price input units (claim line).
-
The price principal procedure indicators (claim line).
-
The benefits provider (claim line).
-
The benefits input amount including the currency (claim line).
-
The benefits age input date (claim line).
-
The benefits input date (claim line).
Process fields can be set by the application through the configuration of business rules. Alternatively, process field values can be submitted with the claim.
Bundled and Replacement Lines
Claim lines can be replaced by other lines within the same claim. This feature is intended to support edits made to a claim by external claim editors. The model supports the following scenarios:
-
A single line is replaced by one or more replacement lines.
-
Multiple lines are bundled into a single replacement line.
The application
-
Accepts bundled and replacement lines as specified when a claim is submitted.
-
Tracks which lines are replaced as well as which lines are considered its replacement.
-
Ignores all replaced lines during pricing and benefits adjudication.
-
Provides the ability to restore all replaced lines, discarding all replacement lines.
Coordination of Benefits
When a member is insured by more than one healthcare payer, those payers may agree to adjudicate the claims for that member in a coordinated fashion, each payer reimbursing some part of that claim, until either the claim is fully reimbursed or all payers have processed the claim. This process is commonly referred to as the Coordination of Benefits (COB).
The coordination of benefits requires an agreed sequence in which the payers adjudicate that member’s claim. To support this scenario, the claim line has the following data elements:
-
Preceding payer code.
-
Amount paid by preceding payer.
-
Date on which the preceding payer paid.
-
Next payer code.
Additional data elements that are required to support the coordination of benefits can be added through extensibility.