Local Area

All claim pages, with exception of the enter clam page, use the same layout, with small differences to suit the function of that specific page. The local area is divided up into 4 sections; two for each level on the claim. The following is a description, per section, on the information that is displayed. Each claim page shows these fields.

Claim Page Layout

Section 1: Claim

Displays the attributes of a single claim in a form based layout. This section also contains dynamic fields that extend the claim table. This section holds the following fields:

The claim’s status is shown in the title of the local area. If the claim is finalized and settled (settlement reason specified on the external claims data) then " (Settled with reason {code})" is added after the status, so for example it displays Finalized (Settled with reason APPEAL) instead of Finalized.

Display label	Entity field
Process Type	claim.processType
Code	claim.code
Claim Ref	claim.providerReference
Claim Set	claim.claimSet.code
Entity Type	claim.serviced<Object>.type*
Entity	claim.serviced<Object>.code**
+ formatted name	claim.servicedPerson.(formatted name) (Only for serviced entity type Person)
+ gender	claim.servicedPerson.gender (Only for serviced entity type Person)
+ date of birth	claim.servicedPerson.dateOfBirth (Only for serviced entity type Person)
+ current address	derived (Only for serviced entity type Person)
+ description	claim.serviced<Object>.description (Only for serviced entity type other than Person) *
+ date	claim.serviced<Object>.date (Only for serviced entity type other than Person) *
Entity Ref	claim.providerEntityReference
Servicing Provider	claim.serviceProvider.code
+ (formatted) name	claim.serviceProvider.(formatted)name
Service Facility	claim.locationProvider.code
+ (formatted) name	claim.locationProvider.(formatted)name
Service Specialty	claim.serviceSpecialty.code
+ description	claim.serviceSpecialty.description
Referring Provider	claim.referralProvider.code
+ (formatted) name	claim.referralProvider.(formatted)name
Billing Provider**	claim.claimantProvider.code
+ (formatted) name	claim.claimantProvider.(formatted)name
Billing Relation**	claim.claimantRelation.code
+ (formatted) name	claim.claimantRelation.(formatted)name
Pay To Provider**	claim.paymentReceiverProvider.code
+ (formatted) name	claim.paymentReceiverProvider.(formatted)name
Pay To Relation**	claim.paymentReceiverRelation.code
+ (formatted) name	claim.paymentReceiverRelation.(formatted)name
Specification To Provider**	claim.paymentSpecificationReceiverProvider.code
+ (formatted) name	claim.paymentSpecificationReceiverProvider.(formatted)name
Specification To Relation**	claim.paymentSpecificationReceiverRelation.code
+ (formatted) name	claim.paymentSpecificationReceiverRelation.(formatted)name
Beneficiary Provider**	claim.paymentBeneficiaryProvider.code
+ (formatted) name	claim.paymentBeneficiaryProvider.(formatted)name
Beneficiary Relation**	claim.paymentBeneficiaryRelation.code
+ (formatted) name	claim.paymentBeneficiaryRelation.(formatted)name
Location Type	claim.locationType.code
+ description	claim.locationType.description
Total Charged	claim.totalClaimedAmount.amount and claim.totalClaimedAmount.displayCode
Total Allowed	claim.totalAllowedAmount.amount and claim.totalAllowedAmount.displayCode
Total Covered	claim.totalCoveredAmount.amount and claim.totalCoveredAmount.displayCode
Payer Code	claim.payerCode.code
Brand	claim.brand.code
Access Group	claim.dataAccessGroup.code
Form	claim.claimForm.code
Classification	claim.classification.code
Classification Scheme	claim.classificationScheme.code
Type	claim.type
Emergency?	claim.emergency
Manual?	claim.manual
Ignore History?	claim.ignoreHistory
Claimed on	claim.claimDate
Received on	claim.receiptDate
Priced on	claim.priceDate
Entered on	claim.entryDate
Expires on	claim.expirationDate
Authorization	claim.authorizationCode
Preceding Payer	claim.precedingPayerCode
Preceding Payer Paid on	claim.paidDate
Next Payer	claim.nextPayerCode

^* <Object> represents the chosen serviced entity type and is a configurable name like Car, House Boat, etc.

^** These fields are only displayed as separate fields in the Change Claim page. In other claim pages the fields are combined into one field (showing either the provider or the relation): Beneficiary, Billing Party, Pay To and Specification To.

Section 2: Claim Details

For each claim detail, a list of records is shown. These lists show a selection of key fields per detail records, e.g., if a claim has ten diagnoses then all ten are shown with only priority, type and code. In addition to detail records, this section also shows claim attributes that are expected to take up a lot of page real-estate (free form remarks, routing slips).

Nearly all summaries display a view icon. Clicking this icon will open a dialog that shows all information available for that claim detail. In some of the pages, such as the Change Claim page, these details are editable. In this case an edit icon is displayed rather than a view icon. In case no claim details of a certain kind exist and the detail is not editable in the claims page, then nothing is displayed. For example, if there are no claim messages and the user opens the View Claim page, then the detail summary header is not displayed (nor is it possible to open the underlying dialog box).

The subsections are listed in the same sequence as they appear (top to bottom) in section 2:

Displayed Header	Entity field
Quick Search	Authorizations (deep link) Claim Lines (deep link)
Skip Actions	claimTagActionList[].action claimTagActionList[].skipTag.displayName
Pend Reasons	claimPendReasonList[].indResolved claimPendReasonList[].pendReason.priority claimPendReasonList[].pendReason.code Edit/View icon
Unfinalize Reasons	claimUnfinalizeReasonList[].unfinalizeReason.code claimUnfinalizeReasonList[].sourceReference Edit/View icon
Financial Hold status and history	FinancialHoldList[].FinancialHoldType.code FinancialHoldList[].status FinancialHoldList[].expirationDateTime Edit/View icon
Messages	claimMessageList[].message.severity claimMessageList[].message.code Edit/View icon
Diagnoses	claimDiagnosisList[].sequence claimDiagnosisList[].diagnosisType.description claimDiagnosisList[].diagnosis.code Edit/View icon
Process Fields	claim.dueDate
Routing Slips	claim.sendOutForPreprocessing claim.sendOutForPricing claim.preprocessingDone claim.pricingDone claim.externalPricing claim.externalBenefits
Status, pend, event and callout history	claimStatusHistoryList[].dateTime claimStatusHistoryList[].status claimStatusHistoryList[].claimPendReasonHistoryList[].pendReason.code claimStatusHistoryList[].claimPendReasonHistoryList[].pendReason.descr claimStatusHistoryList[].claimEventHistoryList[].event claimEventHistoryList[].claimLineEventHistoryList[].claimLineCode claimStatusHistoryList[].claimCalloutHistoryList[].definitionCode claimStatusHistoryList[].claimCalloutHistoryList[].definitionDescription View icon
Internal remarks	claim.internalRemarks Edit/View icon
External remarks	claim.externalRemarks Edit/View icon

The Quick Search subsection provides deep links to other pages in the context of the person or object specified on the claim header (the links are only displayed if the person or object is specified on the header level):

• Clicking on the Authorizations deep link opens the View Authorizations page (in another tab) showing all authorizations for the person or object that is specified on the claim header

• Clicking on the Claim Lines deep link opens the Claim Lines Search Results page (in another tab) showing all claim lines for the person or object that is specified on the claim header

Skip actions are ordered alphabetically by the display name of the skip tag in ascending order. Skip actions that refer to a skip tag with indicator "Display in UI?" unchecked are not shown; these records can only be set through IPs and can not be viewed through the UI. The action is a dropdown list with values Redo, Skip, Hold and Undo (in that order) - the Force action cannot be chosen (because it can only be invoked though the IPs) but is still shown. The action dropdown is editable only in the Change page and read only in all other pages.

Updating the skip action to Redo, Skip or Hold just means what is says: it updates the claim tag action to the appropriate action. Updating the skip action to Undo and subsequently saving (or submitting) the claim has a different meaning however. It first discards the existing tagged results for that claim and ends by setting the skip tag action to Redo. So if, e.g., a skip action of Skip exists for iCes edits and Undo is chosen in the UI then the iCes edits tagged results are removed after which the skip tag action for iCes edits gets the value Redo. The Undo action is normally chosen as a first step to apply other changes to the claim and only then submitting.

Pend reasons are sorted first on priority, then on code. Unfinalize reasons and messages are sorted on code. Diagnoses are sorted on sequence. Status history is sorted on date. The most recent status transition is listed first.

Financial Holds are sorted first on hold type, then on hold date. The most recent financial hold is listed first. The edit/view icon is controlled by access restriction Financial hold. This section is always visible even if there are no financial holds applied to the claim. When the edit or view button is clicked, a detailed page is opened in the context of the selected claim that shows all financial holds that were entered for the claim. When the user has edit privileges for financial holds, new financial holds can be entered in this page and existing financial holds can be released. When the view icon is pressed, the page is opened in display-only mode.

The status history detail summary shows status, pend, event and callout history. The displayed history is restricted to the last iteration of the claim, meaning that only status history records up until (and excluding) the previous PRICING FINALIZED or FINALIZED record (if any) are displayed.

A single pend status may have been caused by multiple pend reasons, especially since each claim line keeps separate pend reasons. In order to avoid that the status history detail summary takes up a large portion of the available screen real estate (and thereby defeating the purpose of having concise detail summaries), pend reason history for pend reasons that have been attached at the claim line level are not displayed in the detail summary. Claim line pend reason history is displayed only in the dialog box.

The claim event history only shows records with a checked display in UI indicator; possible details (claim line event history) are shown in a single field by comma separating the claim line codes, like displaying modifiers elsewhere. Claim event history records are sorted on event (within claim status history of course).

The claim callout history also only shows records with a checked display in UI indicator. Claim callouts are sorted on "Request sent date", the most recent callout listed first.

Routing slips are shown as checkboxes, one under each other, in the order as specified above. The indicator "Preprocessing done?" is editable, the others are not editable.

Displaying External Claims Data

In addition to the listed "fixed" detail summaries, section 2 also displays external claims data including the indicator "Exempt from Purging?" which is shown as a checkbox. An external claims data entity serves as a container for dynamic fields and dynamic records that represent external information written to a claim or claim transaction in OHI Claims.

Each external claims data entity is linked to either a (working copy) claim or a claim transaction. When a claims page displays a working copy claim, it shows both the external claims data attached to the working copy and all external claims data attached to any claim transaction version that originated from that working copy. The View Claim Transaction page shows both the external claims data (excluding the "Exempt from Purging?" indicator) attached to the specific claim transaction version and the ones attached to the working copy.

External claims data is displayed as follows; each dynamic record usage and each dynamic field usage represent as a separate detail summary. The detail summary header is the display name as defined in the usage.

In the detail summary, dynamic records show three columns; the first is the version of the claim transaction to to which the record applies. The second and third column are the two fields of the record with the lowest display sequence. An edit icon is displayed, which provides access to a dialog that shows the full dynamic record(s). See the following image for clarification.

The records are sorted on version. External claims data attached to the working copy is shown first. Dynamic fields are displayed in the much the same way. Rather than three, dynamic fields show two columns; the first showing claim transaction version, the second showing the field value.

If URL dynamic logic was specified for a flex code field usage of a dynamic record, and that field is displayed in the summary, then that field will be displayed as a link. Clicking the link will open a new browser window with as URL the outcome of the dynamic logic function.

Editing External Claims Data

Changing external claims data is done much in the same way as editing any claim header detail summary item. However, because external claims data can be changed regardless of a claim’s status, and because external claims data can be bound to a specific claim transaction version except "Exempt from Purging?" indicator, there are some notable differences.

External claims data detail summaries always show an edit icon, allowing the user to modify the external claims data. This means that all claims pages have a save button, even when fields on the (working copy) claim cannot be edited due to the claim’s status. The following restrictions an behavior applies when modifying external claims data: (1) Only the records/fields that belong to a claim (transaction version) currently displayed in the claims page can be removed or updated. (2) When creating a new record or field, it is automatically attached to the claim (transaction version) that is displayed in the claims; (3) The version column can never be changed.

Saving changes to external claims data works exactly like for other detail summaries: (1) Clicking "ok" in the external claims data dialog closes the dialog but does not commit the changes; (2) Changes are saved by clicking the save button on the claims page; (3) Clicking "cancel" in the external claims data dialog closes the dialog and rolls back the changes made in that dialog. Changes made before the dialog was opened remain open.

Example of a dialog for external claims data

The image above reflects a dialog for external claims data opened via the View Claims page. Because the dialog was opened via the working copy claim, only the external claims data attached to the working copy claim can be modified.

Dynamic fields are edited in the much the same way. Note that the dialog only ever has two columns: the first displays the version, the second holds the dynamic field value.

Access to external claims data is governed by separate access restriction. This means that the function access restriction of the page that shows the external claims data does not apply its CRUD configuration on external claims data. To clarify, when a user has update rights on the external claims data access restriction, but does not have update rights on the page that shows the external claims data (e.g. manual benefits page) then that user can still update the external claims data.

If URL dynamic logic was specified for a flex code field usage of a dynamic record, then that field will have a link icon displayed next to its value. Clicking the link icon will open a new browser window with as URL the outcome of the dynamic logic function. Note that when the dynamic logic function uses the contents of the dynamic record to determine the URL, and the contents of the dynamic record are changed, the new URL will only be available after clicking OK in the dialog to process the changes.

Displaying Dynamic Record Values

It is possible that the claim is extended with validated dynamic record values. These record values display in the same manner as external claims data dynamic record values, i.e., as detail summary items that can be manipulated through a dialog. Note that dynamic record validation attached to the claim can only be edited if the claim is in the CHANGE status.

Section 3: Claim Line

Displays the attributes of a claim line in a table based layout. The following fields are displayed in table columns:

Display label	Entity field
Action	Displays the possible actions (delete, duplicate and deny). Which actions (if any) are displayed, depends on the claim page. If the claim line is locked, a non-clickable Locked icon, indicating that the claim line is locked, is displayed instead of the action(s).
KP?	claimLine.indKeepPricing
KB?	claimLine.indKeepBenefits
Seq	claimLine.sequence
Start Date	claimLine.startDate
Qty	claimLine.claimedNumberOfUnits
(Procedure display name)	claimLine.(procedure).code
+ description	claimLine.(procedure).description
(Procedure 2 display name)	claimLine.(procedure2).code
+ description	claimLine.(procedure2).description
(Procedure 3 display name)	claimLine.(procedure3).code
+ description	claimLine.(procedure3).description
Modifiers	claimLine.modifier.code
Charged (Amount and Currency)	claimLine.claimedAmount.amount and claimLine.claimedAmount.displayCode
Allowed (Amount and Currency)	claimLine.allowedAmount.amount and claimLine.allowedAmount.displayCode
Allowed #	claimLine.allowedNumberOfUnits
Covered (Amount and Currency)	claimLine.coveredAmount.amount and claimLine.coveredAmount.displayCode
Covered #	claimLine.coveredNumberOfUnits
Encounter?	claimLine.indEncounter
Status	claimLine.status
Code	claimLine.code

The claims form configuration defines

• The number of procedure columns shown (0, 1, 2 or 3)

• The column header display names

• The procedure code object field names

• Against which flex code system the code is validated upon entry

Consider the following configuration for claims form 837I, where two procedure definitions have been set up:

This results in two procedure columns in section 3, for claims that belong to claim form 837I:

The "Rev Code" column only accepts procedures that belong to the definition REVENUE_CODES; the "CPT" column only accepts procedures that belong to the CPT_CODES definition. Only the columns specified under the claims form are shown, i.e., because no definition is specified for procedure 3, the 3rd procedure column is hidden.

The quick search on procedures works as follows: only one field is shown ('Procedure') and by providing a value, a search is performed on all three procedure fields. So as an example, searching on procedure 'A' returns all claim lines within the claim that have procedure 'A' stored as either the first, second or third procedure.

Section 3 has a fixed height. The following fields are available in the inline overflow area:

Field	Entity field
Line Ref	claimLine.providerReference
Authorization	claimLine.authorizationCode
Exception Type	claimLine.authorizationExceptionType
Emergency?	claimLine.indEmergency
Funding Arrangement	claimLine.fundingArrangement.code
Product Family	claimLine.productFamily.code
Product Line	claimLine.productLine.code
Process as IN?	claimLine.processAsIn
Family	claimLine.familyCode
Product (benefits)	claimLine.product.code
Coverage Regime	claimLine.claimLineOverrrde.coverageRegime.code
Coverage Regime (no auth)	claimLine.claimLineOverrrde.coverageRegimeNoAuth.code
Authorization Regime	claimLine.claimLineOverrrde.authorizationRegime.code
Waiting Period Regime	claimLine.claimLineOverrrde.waitingPeriodRegime.code
Post Benefit Regime	claimLine.claimLineOverrrde.postBenefitRegime.code
Coverage Specification	claimLine.claimLineOverrrde.coverageSpecification.code
End Date	claimLine.endDate
Payer Paid (Amount and Currency)	claimLine.precedingPayerPaidAmount.amount and claimLine.precedingPayerPaidAmount.displayCode
Entity Type	claimLine.serviced<Object>.type *
Entity	claimLine.serviced<Object>.code *
+ formatted name	claimLine.servicedPerson.(formatted name) (Only for serviced entity type Person)
+ description	claimLine.serviced<Object>.description (Only for serviced entity type other than Person) *
Entity Ref	claimLine.providerEntityReference
Servicing Provider	claimLine.serviceProvider.code
+ (formatted) name	claimLine.serviceProvider.(formatted)name
Service Specialty	claimLine.serviceSpecialty.code
+ description	claimLine.serviceSpecialty.description
Service Facility	claimLine.locationProvider.code
+ (formatted) name	claimLine.locationProvider.(formatted)name
Referring Provider	claimLine.referralProvider.code
+ (formatted) name	claimLine.referralProvider.(formatted)name
Pay To Provider**	claimLine.paymentReceiverProvider.code
+ (formatted) name	claimLine.paymentReceiverProvider.(formatted)name
Pay To Relation**	claimLine.paymentReceiverRelation.code
+ (formatted) name	claimLine.paymentReceiverRelation.(formatted)name
Subscription Date	claimLine.subscriptionDate
Classification	claimLine.classification.code
Classification Auth	claimLine.classificationAuthorization.code
Manual Pricing?	claimLine.indManualPricing
Manual Benefits?	claimLine.indManualBenefits
Location Type	claimLine.locationType.code
+ description	claimLine.locationType.description

^* <Object> represents the chosen serviced entity type and is a configurable name like Car, House Boat, etc.

^** These fields are only displayed as separate fields in the Change Claim page. In other claim pages the fields are combined into one field (showing either the provider or the relation): Pay To

Claim lines that are replaced are visible but grayed out. The modifiers are displayed in a table column cell, while they are modeled as claim details. Because it is possible for a claim to have multiple modifiers, but the domain of possible modifiers is limited, these are displayed and edited through a multi-select combo box.

Section 4: Claim Line Details

For each claim line detail, a list of records is shown. These lists show a selection of key fields per detail records, e.g., if a claim has ten diagnoses then all ten are shown with only priority, type and code. In addition to detail records, this section also shows claim attributes that are expected to take up a lot of page real-estate.

Section 4 becomes scrollable when the accumulated height of all displayed records exceeds that of section 3.

Nearly all summaries also display a view icon. Clicking this icon will open a dialog that shows all information available for that claim line detail. In some of the pages, such as the Change Claim page, these details are editable. In this case an edit icon is displayed rather than a view icon. In case no claim line details of a certain kind exist and the detail is not editable in the claims page, then nothing is displayed. For example, if there are no claim line pend reasons and the user opens the View Claim page, then the detail summary header is not displayed (nor is it possible to open the underlying dialog box). An exception is the view icon for Applied benefit rules, which is shown if at least one of applied benefit specifications, applied parameters, coverages, applied limits and limit consumptions exists. Another exception is the Messages detail summary, which also displays fatal claim messages (fatal claim messages are displayed in the summary even if there are no claim line messages).

The subsections are listed in the same sequence as they appear (top to bottom) in section 4:

Displayed Header	Remark
Pend Reasons	claimLinePendReasonList[].indResolved claimLinePendReasonList[].pendReason.priority claimLinePendReasonList[].pendReason.code Edit/View icon
Messages	claimMessageList[].message.severity (only fatal claim messages are displayed) claimMessageList[].message.code (only fatal claim messages are displayed) claimLineMessageList[].message.severity claimLineMessageList[].message.code Edit/View icon
Diagnoses	claimLineDiagnosisList[].sequence claimLineDiagnosisList[].diagnosisType.description claimLineDiagnosisList[].diagnosis.code Edit/View icon
Coverages	claimLineCoverageList[].amount.amount and claimLineCoverageList[].amount.displayCode claimLineCoverageList[].action claimLineCoverageList[].displayName Displayed as natural text (with boilerplate text after the value, dependent on the action). See example below the table. Note that only coverages with an amount greater than 0 are displayed.
Limit Consumptions	limitConsumptionList[].amount.amount and limitConsumptionList[].amount.displayCode limitConsumptionList[].numberOfUnits limitConsumptionList[].serviceDays limitConsumptionList[].displayName Displayed as natural text (with boilerplate text after the value, dependent on the limit type). See example below the table. When a consumption is taken from the 'Reserved Consumption'; the offsetting negative consumption is qualified by text ' (Res. Offset)' ( setup as the boilerplate text). Example: 50 $ on network family deductible 50 $ on network family deductible (Res. Offset)
Provider Limit Consumptions	providerLimitConsumptionList[].amount.amount and providerLimitConsumptionList[].amount.displayCode providerLimitConsumptionList[].numberOfUnits providerLimitConsumptionList[].serviceDays providerLimitConsumptionList[].providerLimitCounter.providerLimitRule.code Displayed as natural text (with boilerplate text after the value, dependent on the limit type) 50 $ on AMOUNT LIMIT 5 unit(s) on UNITS LIMIT 1 day on SERVICE DAYS LIMIT When a consumption is taken from the 'Reserved Consumption'; the offsetting negative consumption is qualified by text '(Res. Offset)' ( setup as the boilerplate text). Example: 150 $ on network deductible 150 $ on network deductible (Res. Offset)
Process Fields	claimLine.priceIndProvider.code claimLine.priceOrgProvider.code claimLine.priceInputDate claimLine.priceInputNumberOfUnits claimLine.indPricePrincipalProcedure1 (*) claimLine.indPricePrincipalProcedure2 (*) claimLine.indPricePrincipalProcedure3 (*) claimLine.benefitsProvider.code claimLine.benefitsInputAmount.amount and claimLine.benefitsInputAmount.displayCode claimLine.benefitsInputDate claimLine.benefitsAgeInputDate claimLine.waitingPeriodInputDate (*) The price principal procedure indicators are shown as one label 'Price Principal Procedure' followed by the procedure codes beneath each other plus a mark whether they are principal or not. If the indicator to keep principal procedures is set to Y, then the label 'Override' is shown beneath the label 'Price Principal Procedure'; If the indicator to keep principal procedures is set to N, then the label 'Override' is not shown. As an example, if procedure1 'A' is marked as principal, procedure2 'B' is not marked as principal and the indicator to keep principal procedures is set to Y, then this subsection would be shown as: Price Principal Procedure x A Override o B with x a checked checkbox and o an unchecked checkbox; null procedures are not shown.
Parameters	claimLineParameterList[].amount.amount and claimLineParameterList[].amount.displayCode OR claimLineParameterList[].percentage claimLineParameterList[].coverWithholdCategory.code claimLineParameterList[].product.code Edit/View icon Displayed as natural text: 10 % COINSURANCE applied for BASE PRODUCT 20 $ COPAY applied
Limits	claimLineLimitList[].maximumAmount.amount and claimLineLimitList[].maximumAmount.displayCode OR claimLineLimitList[].maximumAmount.maximumNumber OR claimLineLimitList[].maximumAmount.maximumServiceDays claimLineLimitList[].limit.code claimLineLimitList[].product.code Edit/View icon Displayed as natural text (with boilerplate text after the value, dependent on the limit type) 100 $ DEDUCTIBLE applied for BASE PRODUCT 10 units VICODIN LIMIT applied for BASE PRODUCT 2 days PT VISIT LIMIT applied
Sublines	claimSubLineList[].sequence claimSubLineList[].numberOfClaimedUnits claimSubLineList[].procedure.code Edit/View icon
Contract References	claimLine.contractReferenceList[].code Edit/View icon
Replaced	derived from claimLine.indReplaced and claimLine.replacedBy, displayed as natural text, referring to the code of the line(s)
Replaces	derived from claimLine.replaces, displayed as natural text, referring to the code of the line(s)
Reservation	derived from claimLine.claimLine Example: Code : RES0001; with a deep link to the claims page. This page is opened within the context of the reservation code. Line Code : RESLN01

Example:

Pend reasons are sorted first on priority, then on code. Messages are sorted on code. Diagnoses are sorted on sequence. Limit consumptions are sorted on display name. Coverages are sorted based on the display sequence of the coverage label. Sublines are sorted on sequence. Contract references are sorted on code.

In the Limit Consumptions detail summary the limit consumption display name is a deep link to the Adjudication Limit Counters page (note that reversed limit consumptions are not displayed). That page will open in the context of the claim line serviced person or object and that particular limit. The same holds true for the Provider Limit Consumptions detail summary where the provider limit rule code is a deep link to the Provider Limit Counters page. There are exceptions:

• If only preliminary (provider) limit consumption exists, no deep link is available. The reason is that the Adjudication Limit Counters and Provider Limit Counters pages do not show preliminary consumption.

• If limit consumption is related to a case or claim, no deep link is available. The reason is that the Adjudication Limit Counters page does not display case or claim related limit counters.

• If provider limit consumption exists within a claim with the ignore history indicator checked, no deep link is available. The reason is that the Provider Limit Counters page does not display counters that reference a specific claim (which originate from a checked ignore history indicator).

Applied benefit rules / Applied reimbursement method and pricing rules

Both 'Applied benefit rules' and 'Applied reimbursement method and pricing rules' are detail dialogs. In section 4, a button is shown to reach the detail dialog 'Applied benefit rules' only if at least one record exists in (one of the blocks of) that detail dialog. Likewise, a second button is shown to reach 'Applied reimbursement method and pricing rules' only if at least one record exists in that detail dialog. For both 'Applied benefit rules' and 'Applied reimbursement method and pricing rules' , no other information is shown in section 4.

Displaying Dynamic Record Values

It is possible that the line is extended with validated dynamic record values. These record values display in the same manner as external claims data dynamic record values on the claim header, i.e., as detail summary items that can be manipulated through a dialog. Note that dynamic record validation attached to the line can only be edited if the claim is in the CHANGE status.