Claims Model
The range of Electronic Data Interchange (EDI) standards used to exchange health care claims between payers and providers is diverse. Each market uses a different standard and commonly knows multiple variations.
In order to process a claim, it needs to be stored in a generic data model. This chapter describes that data model, that is, the fixed structure and fields. In addition to the fields in the fixed data model, the claim record can be extended by user defined properties (dynamic fields).
A claim represents one or more services that have been provided for an insurable person or object. The word 'claim' is commonly used to refer to the claim including its details, that is, including claim lines, messages, pend reasons, and so on. For example, when the text says that a 'claim' is processed, it means that all the constituent parts of the claim are processed. The term 'claim header' is used to refer to the claim record without its constituent parts.
Some scenarios require the provider to obtain pre-approval for a specific service. This approval request (referred to as a reservation from now on) has the same level of specificity as an actual claim, and is processed exactly like an actual claim. A reservation does not result in payment, but it can lead to general ledger entries. The finalized reservation represents an approval or denial for when the actual claim is processed.
In addition to representing an approval for the actual claim, a reservation also reserves limit consumption. This means the reservation 'protects' part of the limit from other claims and other reservations, to the effect that it can only be used by the claims that correspond to the reservation.
When the corresponding claim is processed, the system matches its lines to the reservation (lines) and uses the reserved consumption during the benefit calculation. It is possible that the reservation claim and the actual claim are slightly different, that is, another procedure code or another provider.
In some scenarios a member might like to check the cost for a specific service. That is ask for a "quote". A quote also has same level of specificity as an actual claim and is processed exactly like an actual claim with an exception that it does not update accumulators, no limits are consumed. Also, a quote does not result in payment. It is possible to generate ledger entries.
Since quote and reservation claims follow the same specificity of a claim, they can potentially participate in the claim flows that look across claims, for example, medical cases, episodes, combination adjustment rules etc. Note that the configured rules in the application apply to quotes and reservations as well. For example, a quote line becoming a triggering line for an episode (which is intended for an actual claim). The if the application needs to treat quotes and reservations differently from actual claims, this behavior has to be part of that rule’s configuration.
For simplicity’s sake, in the text the word claim will encompass both the reservation claim, quote claim and the actual claim; whenever the text only applies to an actual claim, a reservation claim or quote claim, it will be specified.
Design Choices
Storing Non-Matched Data Elements
A claim can have any number of data elements, such as the serviced person or object, the rendered procedure and the servicing provider. When the claim is loaded the data elements in the XML claim file are cross-checked against the providers, persons or objects, procedures etc. stored in the database.
It is possible that no match is found and that no reference can be made to for example the provider record. This typically happens when the provider records in the application are not up to date. When this happens, the claim is loaded as normal, but the 'unmatched' data element in the XML file is stored on the claim record as a character string. This character string is visible in the user interface, so that a claims processor can manually edit and correct the claim.
The claim record stores multiple character strings per unmatched data element. For example, to capture a serviced person or object, the claims model includes the following fields:
-
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
These fields will only have values if the person or object was unmatched. The insurable person or object is not the only data element that can be unmatched. The following list are the data elements that can be stored on the claim record in case there was no match:
-
Relations
-
Providers
-
Specialty
-
Procedures
-
Diagnoses
-
Modifiers
-
Messages
-
Location Type
Not all data elements are stored on the claim in case of a non match. For example dynamic fields and payer codes are not. If any of these fail to match, the claim will fail to load. The XML response will contain an explanatory message.
Cascading Field Values
Any claim refers to a serviced persons or objects. The actual level on which that field is positioned in the claim structure can vary per standard. More specifically, some claim forms store the person or object on the claim header, other forms can specify a different person or object per claim line.
Some forms may even allow you to specify the data element on multiple levels in a claim, given that a value on a specific level overrides the value on the header level. For example, if the serviced person or object is provided on both the claim header and on the claim line, the value on the line overrides the value on the header.
The claim has three levels that stored data elements. From high-level-to-specific these are: the claim header, the bill and the claim line. A data element value on the more specific level always overrides whatever value is specified at a higher level. If no value is specified on the specific level, the higher level value is inherited.
Model
The following image reflects the hierarchy of the concepts discussed in this section and aims to provide the reader with a sense of how the entities tie together. It does not contain the level of detail of a full fledged entity relation diagram. White entities reflect information that is imported into Claims. Black entities represent entities that are the result of processing the claim in Claims.
Claim Header
The claim header stores the following fields:
Field | Description |
---|---|
Authorization Code |
This field stores the authorization code as supplied on the incoming claim. |
Brand |
The brand used in context of user access restrictions on this claim. |
Claim Date |
The date that the claimant created the claim. |
Claim Set |
The set, sent in by the provider, that contains the claim |
Claimant Provider |
The provider that created the claim. |
Claimant Relation |
The relation that created the claim. |
Classification |
This field stores the classification of the claim (automatically determined during claims classification). |
Classification Scheme |
This field stores the scheme that was used to classify the claim. |
Code |
Mandatory. 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 was entered in Claims. |
Expiration Date |
The date after which the reservation consumption expires. |
External Remarks |
Free text remark field. |
Form |
Mandatory. Specifies the form of the claim, for example, EDI versus paper. |
Data Access Group |
The code used in context of user access restrictions on this claim. |
Ind Changed in UI |
If checked, the claim has been changed in the UI after it has been unfinalized. |
Ind Emergency |
If checked, the services on this claim is/are qualified as emergency services. |
Ind External Benefits |
If checked, Claims will send out the claim for determining benefits. |
Ind External Pricing |
If checked, Claims will send out the claim when it needs (re)pricing. |
Ind High Priority |
If checked, the claim will be picked up for processing with high priority |
Ind Ignore History |
If checked, across claims rules will ignore claims in history. |
Ind Manual |
If checked, the claim entered the system through manual entry. |
Ind Preprocessing Done |
If checked, indicates that the claim has been through preprocessing. |
Ind Pricing Done |
If checked, indicates that the claim has been through a pricer. |
Ind Send out for Preprocessing |
If checked, indicates that the claim may be sent out through the Prefinalized Out IP for Preprocessing |
Ind Send out for Pricing |
If checked, indicates that the claim may be sent out through the Prefinalized Out IP for Pricing |
Internal Remarks |
Free text remark field. |
Location Provider |
The location where the services was/were rendered. |
Location Type |
The type of location where the services was/were rendered. |
Next Payer Code |
The payer where the claim must be sent once it is finalized. |
Paid Date |
The date that the preceding payer finalized this claim. |
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 will receive the payment for this claim. |
Payment Receiver Relation |
The relation that will receive the payment for this claim. |
Payment Specification Receiver Provider |
The provider that will receive the payment specification. |
Payment Specification Receiver Relation |
The relation that will receive the payment specification. |
Preceding PayerCode |
The payer that processed this claim before it was received by the current payer. |
Price Date |
The date that this claim was priced. |
Process Type |
The type of the process to follow, either C(laim) or R(eservation) or Q(uote) |
Provider Entity Reference |
A free text external reference to the serviced person or object 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 person or objectin 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 Type |
The type of the entity for which the claim is entered (person or object). |
Serviced Entity |
The person or object that has undergone the services specified on this claim. |
Start Date |
The first (earliest) claim line start date |
Status |
Reflects the current state of the claim in the processing flow. Possible values are: ENTRY, INITIAL, SENT OUT FOR PREPROCESSING, SENT OUT FOR PRICING, MANUAL PRICING, PRICING DONE, MANUAL PRICING ADJUDICATION, PRICING ADJUDICATION DONE, PRICING FINALIZED, MANUAL BENEFITS, BENEFITS DONE, MANUAL ADJUDICATION, ADJUDICATION DONE, FINALIZED and CHANGE. |
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. Restitution or Provider claim? |
Claim Messages
A claim message represents a piece of information within the context of that claim’s traversal through the process. Claim messages service two important purposes. First, claim messages provide context as to why a claim processed the way it did. Second, messages 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 are used to maintain a proper record of history of claims. Furthermore, the document discussions, conversations, actions carried out and advice given to claimants can be recorded in the form of notes.
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 a piece of information within the context of the person’s or object’s state of being when the service was provided, or the reason why the service was provided. This information may affect the applicable benefits.
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 specific diagnosis type. The claim diagnosis with the lowest sequence number is interpreted as the primary diagnosis on the claim. The primary diagnosis is the diagnosis that Claims uses to evaluate benefit specifications. See the implementation guide on Product Definition for further elaboration.
Claim Unfinalize Reasons
A claim that is fully processed within Claims attains the status "finalized". It’s possible that a claim needs to be corrected after it has been finalized. In Claims 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 one or more reasons explaining why the claim has been unfinalized.
Every time a claim is unfinalized, any existing unfinalize 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
A claim may pend for external intervention, usually because a human operator needs to work the claim before it can continue to be processed. Whenever a claim pends, one or more reasons are attached to that claim, explaining why the claim pended. Both the conditions under which a claim pends and which pend reasons apply is driven by configuration.
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 pend reasons store only the current pend reasons, that is, they are discarded once the claim is resubmitted. The full history of pend reasons is stored in separate entity named "Claim Pend Reason History".
Claim Status History and Claim Pend Reason History
The position of a claim in the processing flow is reflected by a claim’s status. 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 certain steps within the process. 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. Even when Claims receives a new copy of the same claim through the claims in integration point, the status history is kept intact and continued. A number of claim statuses reflect that the claim has pended. The reasons why a claim 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. |
Bill Provider Reference |
Provider reference of the bill. Only filled for bill pend reasons, given that the provider reference was specified. |
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. |
For example, a typical claim status history for a claim that pended for manual adjudication:
Claim | Status | Datetime | Remark |
---|---|---|---|
1234 |
INITIAL |
2010-04-21 15:00.000 |
First version enters Claims |
1234 |
PRICING DONE |
2010-04-21 15:10.000 |
|
1234 |
PRICING ADJUDICATION DONE |
2010-04-21 15:10.050 |
|
1234 |
BENEFITS DONE |
2010-04-21 15:10.100 |
|
1234 |
MANUAL ADJUDICATION |
2010-04-21 15:10.200 |
Need for external intervention detected |
1234 |
ADJUDICATION DONE |
2010-04-22 12:00.000 |
External intervention completed |
1234 |
FINALIZED |
2010-04-22 12:01.000 |
Processing complete |
The claim was pended for manual adjudication because a plastic surgery procedure was detected for claim line 3. The pend reason for plastic surgery is attached to both the claim and claim line level. The claim pend reason history contains the following information:
Claim status history (entry) | Line Code | Bill Reference | Pend reason |
---|---|---|---|
Claim 1234, MANUAL ADJUDICATION on 2010-04-21 15:10.200 |
Plastic surgery |
||
Claim 1234, MANUAL ADJUDICATION on 2010-04-21 15:10.200 |
3 |
Plastic surgery |
Claim Event History and Claim Line Event History
There could be several reasons why the claim events that have been sent out, need to be stored:
-
to make these events visible in the UI
-
to use these logged events to prevent that the same event is reraised
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. |
For events especially of level 'Claim Line' and 'Claim with Lines' the claim lines for which the event was fired are stored in the claim line event history, with the following fields:
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. |
Claim Callout History
There could be several reasons why claim callouts need to be stored:
-
to make these callouts visible in the UI
-
to track and audit execution of callouts to external components
Note that the existence of Claim Callout History does not preclude a callout from executing again when the callout rule is triggered again (for example upon reprocessing of 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 defined for a particular claim per distinct configured skip tag the action to be taken, for example for skip tag iCES action REDO would mean that the results from a previous callout to iCES should be discarded and the callout should be made again.
A claim can have zero, one or multiple tag acions 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 represents an actual health care service. A claim consists of one or multiple claim lines:
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. |
Bill |
The bill to which this claim line belongs. See the section on Bills for further clarification. |
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 in the Appendices part of the Claims Flow 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) [1] |
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 person or object on this claim line. |
Provider Reference |
A free text external reference to this claim line. |
Referral Provider |
The provider that referred the serviced person or object in 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 Type |
The type of the entity for which the claim line is entered (person or object). |
Serviced Entity |
The person or object 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 information retrieved 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 person or object. 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 |
Subscription 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
Identical to its counter part on the claim, a claim line message represents a piece of information within the context 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
Identical to its counter part on the claim, a claim line diagnosis represents a piece of information on the context of the performed health care service. A claim line can have zero, one or multiple diagnoses attached to it:
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 for a specific diagnosis type. The claim line diagnosis with the lowest sequence number is interpreted as the primary diagnosis on the claim line. The primary diagnosis is the diagnosis that Claims uses to evaluate benefit specifications. See the implementation guide on Product Definition for further elaboration.
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 for the coverage regime used to calculate the claim line’s benefits. This feature is typically used in the special 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 are used to override, at the claim line level, the maximum height of a limit used to calculate the claim line’s benefits. This feature is typically used in the special circumstance where a limit maximum should be stretched beyond the maximum for the plan for a specific claim line or serviced person or object.
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 full history of pend reasons is stored separate entity.
Replaced Lines
It is possible that a claim contains lines that have been replaced by other lines within that same claim. A claim line that is replaced is referred to as an 'original' line. A claim line that replaces an original line is referred to as a 'replacement' line.
A replacement line must be associated with one or more original lines. Likewise, an original line is associated with one or more replacement lines. Original lines are ignored during claims processing, that is, the replacement line is processed instead. To clarify, consider the following scenario.
A provider sends in a claim with two claim lines for the same serviced person or object: the first line refers to procedure A, the second line refers to procedure B. Because procedure A and B commonly go together, the payer has introduced procedure C, which represents the combination of procedure A and B. The payer has set up all pricing and benefit rules within the context of procedure C.
Consequently, before the claim is processed, the claim lines containing procedure A and B are replaced by a single claim line, containing procedure C. This process is known as bundling. However, once the claim is processed, the explanation of benefits has to correspond to the way the claim was originally submitted, that is, it has to refer to procedure A and B. For this reason the claim lines containing procedure A and B must be retained, even though they are not used when the claim is processed.
Note that this example describes a situation where multiple lines are replaced by one line. The opposite is also possible, that is, one line is replaced by multiple lines. This process is referred to as unbundling. The claims data model can capture both transformations without loss of information. Also note that many-to-many replacement cannot be captured by the model, for example, a situation where procedure A and B are replaced by procedure C, D and E.
In the claims data model the link between original lines and replacement lines is captured by three fields on the claim line:
-
An optional reference to a line that is replaced by this line
-
An optional reference to a line that replaces this line
-
An indicator that whether or not this line is replaced (and should be processed or not)
In a situation where one original line is replaced by multiple replacement lines, the replacement lines contain a reference to the original line, that is, the reference specified in the first bullet.
In a situation where multiple original lines are replaced by a single replacement line, all the original lines contain a reference to the single replacement line, that is, the reference specified in the second bullet.
In addition, for each original line that is replaced, the indicator is set to indicate that the line is replaced. Although the indicator stores redundant information (the reference between the original and replacement line implies the line’s replacement), it is included for processing purposes: when the claim line is processed, there is no need to check all other claim lines to see whether or not it has been replaced in the situation where one original line is replaced by many replacement lines.
Coordination of benefits details
In some specific situations, a claim that has already been partially paid by a primary payer is re-processed by a second payer so that (a part of) the amount not paid by the primary payer may be paid by the second payer. For this reason a claim line accommodates the following information:
-
Preceding payer code
-
Amount paid by preceding payer
-
Date on which the preceding payer paid
-
Next payer code
The purpose of the preceding payer code is to (be able to) validate that the processed claim has been adjudicated by the correct payer in a COB situation where the processing payer is not the primary payer. The implementation of this validation is to be determined as a part of claims processing.
The purpose of the next payer code is to be able to determine the next destination payer in a COB situation. This information does not directly affect the processing of the claim, but may be required in resulting claim output. Note that neither the preceding payer code, nor the next payer code are stored as a reference to the Claims Payer Code entity; both are implemented as character fields.
The claims data model does not store amounts such as the deductible amounts and limit amounts applied by a preceding payer. These amounts can be added as dynamic fields.
Claim sub lines
A single claim line may encompass one or more sub lines. A sub line only stores procedure information, that is, the procedure code, the pertaining code definition and the quantity. Procedures captured in a sub line reflect a sub component of the procedure captured in the pertaining claim line. For example, the procedure code in the claim line specifies a custom pharmaceutical recipe, while the procedure codes in the sub lines specify the actual ingredients and quantities.
The information in the sub line may be used to process the pertaining claim line correctly, but are not processed independently. Any processing results are stored at the main line level. For example, in order to determine the allowed amount for the custom pharmaceutical recipe, Claims is set up to use a specific calculation. The input for this calculation is the list of all the ingredients and their corresponding quantities and the result is the allowed amount. The actual allowed amount is then stored in the main line.
A claim line can have up to 99 claim sub lines. 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 |
Claim Line Rule Coverages
A claim line can have one or more claim line rule coverages. A claim line rule coverage consists of 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 |
The claim line rule coverage pinpoints the exact cover withhold rule that led to a piece of coverage or withhold. After that, claim line rule coverages are aggregated into claim line coverages with the same label. For examples, see the Coverage Regime Model.
Claim Line Coverages
A claim line can have one or more claim line coverages. A claim line coverage consists of 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 |
The coverage label specifies what the amount or number represents such as the "copay" or "deducted" amount. The amount or number of units specifies how much is specified under that label. The sequence specifies the order in which the labels are displayed in the user interface. Note that this sequence has nothing to do with the sequence in which the benefit rules are applied.
Claim Line Benefit Specifications
A claim line can have one or more claim line benefit specifications. A claim line benefit specification consists of 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 |
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 used 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
A claim line can have one or more claim line provider pricing clauses. A claim line provider pricing clause consists of the following f ields:
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 |
Bills
A bill represents a provider’s invoice for a serviced person or object. Since a person can submit multiple invoices as a single claim, the bill is modeled is a subgroup of claim lines within a claim. A claim can be composed of one or more bills, each of those bills composed of one or more lines. Bills are only allowed in claims of the type "restitution claim".
For example, suppose a person sends in both the doctors bill and a dentist bill in a single request for reimbursement. The single request translates into a single claim. In the example, the claim contain two bills, each consisting of one or more lines.
If a claim consists of bills, all claim lines in that claim must belong to a bill. Claim lines are sequenced within the context of the claim, regardless of whether or not a claim contains the bill-level. A claim can consist of zero, one or multiple bills:
Field | Description |
---|---|
Authorization Code |
This field stores the authorization code as supplied on the incoming bill. |
Bill Date |
The date on which the physical bill was created. |
Claim |
The claim to which this bill belongs. |
Ind Emergency |
If checked, the services on this bill is/are qualified as emergency services. |
Location Provider |
The location where the services was/were rendered. |
Location Type |
The type of location where the services was/were rendered. |
Payment Receiver Provider |
The provider that will receive the payment. |
Payment Receiver Relation |
The relation that will receive the payment. |
Provider Entity Reference |
An free text external reference to the serviced person or object on this bill. |
Provider Reference |
An external reference to this bill. |
Referral Provider |
The provider that referred the serviced person or object in context of the services specified on this bill. |
Service Provider |
The provider that rendered the services specified on this bill. |
Service Specialty |
The specialty under which the services specified on this bill were rendered. |
Serviced Entity Type |
The entity type for which the bill is created (person or object).. |
Serviced Entity |
The person or object that has undergone the services specified on this bill. |
Bill Messages
A bill can have multiple messages attached to it:
Field | Description |
---|---|
Bill |
The bill 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 BENEFITS, PRE PRICING, RESERVATION, PRICING, PRICING LIMIT, PRICING NO RECALCULATION and SANITY CHECKS |
Bill Diagnoses
A bill can have multiple diagnoses attached to it:
Field | Description |
---|---|
Bill |
The bill to which the diagnosis belongs. |
Diagnosis |
The diagnosis that is specified on the bill. |
Type |
The type of the diagnosis (for example principal, admitting, e-code). |
Sequence |
Specifies the relative importance of this diagnosis on this bill. |
Within a bill, a specific diagnosis can only be present once for a specific diagnosis type. The bill diagnosis with the lowest sequence number is interpreted as the primary diagnosis on the bill. The primary diagnosis is the diagnosis that Claims uses to evaluate benefit specifications. See the implementation guide on Product Definition for further elaboration.
Bill Pend Reasons
A bill can have multiple pend reasons attached to it:
Field | Description |
---|---|
Bill |
The bill to which the pend reason belongs. |
Pend Reason |
The pend reason |
A bill pend reason represents the current active pend reasons. Once a pend reason is no longer active, it is copied to the pend reason history and discarded. The full history of pend reasons is stored in a separate entity.
Providers and relation overview
Claims contain information about the people and organizations relevant to that particular claim. These people and/or organizations all represent a role within the context of the claim. The claims model distinguishes two types of people/organizations:
-
Providers - All individuals and organizations on the claim that represent health care providers within the context of the claim.
-
Relations - All persons and organizations on the claim that do not represent health care providers within the context of the claim.
A claim has references to individual and organization providers representing the following roles:
-
The servicing provider
-
The servicing location
-
The referring provider
-
The price individual provider - individual provider only
-
The price organization provider - organization provider only
-
The benefits provider
-
The payment receiver
-
The payment specification receiver
-
The payment beneficiary
-
The claimant
A claim has references to persons and organizations representing the following roles:
-
The payment receiver
-
The payment specification receiver
-
The payment beneficiary
-
The claimant
-
The serviced person or objject
Note that some roles on the claim can be represented by a provider or a relation, for example, on a provider claim, the claimant is likely to be a provider and on a restitution claim the claimant is likely to be a relation.
Process fields
The processing results of a claim depend both on the information provided on the claim and the way that Claims is set up. Which specific piece of information on the claim is actually used to determine the processing results differs per country. Consider the following example:
In country A the provider contract is always derived from the servicing location, while in country B the provider contract is always derived from the provider that generated the claim, that is, the claimant. The concept of having a contracted provider is consistent in both countries; the actual provider that fulfills this role is different.
Because the derivation of the contracted provider is country dependent, it is not a 'hard coded' derivation in Claims' processing flow. Consequently the claims data model (and the canonical claims message) not only captures information that was provided on the original claim: they also capture derived information that is used to process the claim. These fields are referred to as process fields.
The process fields are the following:
-
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)
These fields can be set in two ways: either their values are sent in through the claims in integration point or claims update integration point, or the values are derived by derivation rules configured within Claims. In addition, the price principal procedure indicators can also be changed through the Change Claims page.