Claims

The range of Electronic Data Interchange (EDI) standards used to exchange health care claims between payers and providers is diverse. Each country tends to have its own standard and commonly knows multiple variations on that standard, e.g., different structures for different types of health care.

In order to process a claim, it needs to be stored in a generic data model. This chapter describes that data model, i.e., 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, i.e., including claim lines, messages, pend reasons etc. 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 used by the claim(s) 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, i.e., 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, an quote does not results in payment, but however 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. System will not exclude quotes or reservations from participating, for example, a quote line becoming a triggering line for an episode (which is intend for an actual claim). The configurations should be aware of the possibility of an quote or a reservation being possible for a given scenario.

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 e.g. 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 OHI Claims. Black entities represent entities that are the result of processing the claim in OHI 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 OHI 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, e.g., 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 service(s) on this claim is/are qualified as emergency service(s).
Ind External Benefits	If checked, OHI Claims will send out the claim for determining benefits.
Ind External Pricing	If checked, OHI 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 service(s) was/were rendered.
Location Type	The type of location where the service(s) 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 service(s) specified on this claim.
Service Provider	The provider that rendered the service(s) specified on this claim.
Service Specialty	The specialty under which the service(s) 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 service(s) 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?

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 OHI 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, e.g., 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 service(s) on this claim is/are qualified as emergency service(s).

Ind External Benefits

If checked, OHI Claims will send out the claim for determining benefits.

Ind External Pricing

If checked, OHI 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 service(s) was/were rendered.

Location Type

The type of location where the service(s) 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 service(s) specified on this claim.

Service Provider

The provider that rendered the service(s) specified on this claim.

Service Specialty

The specialty under which the service(s) 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 service(s) 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.

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

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 (e.g. principal, admitting, e-code).
Sequence	The relative importance of this diagnosis on this claim.

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 (e.g. 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 OHI 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 OHI Claims attains the status "finalized". It’s possible that a claim needs to be corrected after it has been finalized. In OHI 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.

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

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, i.e., 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.

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 OHI 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.

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 OHI 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

Claim

Status

Datetime

Remark

1234

INITIAL

2010-04-21 15:00.000

First version enters OHI 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 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

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.

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.

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 (e.g. 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?

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, e.g. 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.

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 OHI Claims
Covered Amount Currency	The currency of the covered amount
Covered Number of Units	The covered number of units as calculated by OHI 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: It will be automatically checked when an unfinalize reason with a checked Lock Claim Lines indicator is used to unfinalize the claim that the claim line belongs to It will be automatically checked when the claim that the claim line belongs to or the specific claim line is pended by an external intervention rule with a checked Lock Claim Lines indicator Locked claim lines can be unlocked (indicator unchecked) by the Unlock Line(s) action in the Change Claim page or through the Claims In and Claims Update integration points 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)*	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. If unchecked, the benefits provider is evaluated as normal.
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.
Sequence	Mandatory. Order (for UI and processing) of this claim line in context of the claim to which it belongs. A claim can have up to 999.999 lines.
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 service(s) 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.

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 OHI Claims

Covered Amount Currency

The currency of the covered amount

Covered Number of Units

The covered number of units as calculated by OHI 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:

It will be automatically checked when an unfinalize reason with a checked Lock Claim Lines indicator is used to unfinalize the claim that the claim line belongs to
It will be automatically checked when the claim that the claim line belongs to or the specific claim line is pended by an external intervention rule with a checked Lock Claim Lines indicator
Locked claim lines can be unlocked (indicator unchecked) by the Unlock Line(s) action in the Change Claim page or through the Claims In and Claims Update integration points

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)*

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.

If unchecked, the benefits provider is evaluated as normal.

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.

Sequence

Mandatory. Order (for UI and processing) of this claim line in context of the claim to which it belongs. A claim can have up to 999.999 lines.

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 service(s) 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.

^* the usage names of the procedures are configurable under the claims form.

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.

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.

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 (e.g. principal, admitting, e-code).
Sequence	The relative importance of this diagnosis on this claim line.

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 (e.g. 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 OHI 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.

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

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)

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.

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

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, i.e., 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, i.e., 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, i.e., 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, e.g., 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, i.e., 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, i.e., 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 OHI 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, i.e., 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, OHI 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

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 (e.g. 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

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 (e.g. 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 (e.g. 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

Field

Description

Claim Line

The claim line to which the coverage belongs

Coverage Label

The label that specifies the nature of the amount (e.g. 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.

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 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. E.g 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

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. E.g 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. Limit consumption are described in the Adjudication Limits section of the Benefit Rules implementation guide.

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 service(s) on this bill is/are qualified as emergency service(s).
Location Provider	The location where the service(s) was/were rendered.
Location Type	The type of location where the service(s) 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 service(s) specified on this bill.
Service Provider	The provider that rendered the service(s) specified on this bill.
Service Specialty	The specialty under which the service(s) 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 service(s) specified on this bill.

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 service(s) on this bill is/are qualified as emergency service(s).

Location Provider

The location where the service(s) was/were rendered.

Location Type

The type of location where the service(s) 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 service(s) specified on this bill.

Service Provider

The provider that rendered the service(s) specified on this bill.

Service Specialty

The specialty under which the service(s) 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 service(s) 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

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 (e.g. principal, admitting, e-code).
Sequence	Specifies the relative importance of this diagnosis on this bill.

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 (e.g. 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 OHI 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

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, e.g., 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 OHI 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, i.e., 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 OHI 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 OHI Claims. In addition, the price principal procedure indicators can also be changed through the Change Claims page.