Local Area
All claim pages, except enter claim page, use the same layout, with small differences to suit the function of that specific page. The local area is divided 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.
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 |
|
Entity formatted name gender date of birth current address description date |
claim.serviced<Object>.code[2] claim.servicedPerson.(formatted name) (Only for serviced entity type Person) claim.servicedPerson.gender (Only for serviced entity type Person) claim.servicedPerson.dateOfBirth (Only for serviced entity type Person) derived (Only for serviced entity type Person) claim.serviced<Object>.description (Only for serviced entity type other
than Person)[2] claim.serviced<Object>.date (Only for serviced entity type other than Person)[2]
2. <Object> represents the chosen serviced entity type and is a configurable name like Car, Houseboat, etc.
|
Entity Ref |
claim.providerEntityReference |
Servicing Provider (formatted) name |
claim.serviceProvider.code claim.serviceProvider.(formatted)name |
Service Facility (formatted) name |
claim.locationProvider.code claim.locationProvider.(formatted)name |
Service Specialty description |
claim.serviceSpecialty.code claim.serviceSpecialty.description |
Referring Provider (formatted) name |
claim.referralProvider.code claim.referralProvider.(formatted)name |
Billing Provider[3] (formatted) name |
claim.claimantProvider.code claim.claimantProvider.(formatted)name |
Billing Relation[3] (formatted) name |
claim.claimantRelation.code claim.claimantRelation.(formatted)name |
Pay To Provider[3] (formatted) name |
claim.paymentReceiverProvider.code claim.paymentReceiverProvider.(formatted)name |
Pay To Relation[3] |
claim.paymentReceiverRelation.code claim.paymentReceiverRelation.(formatted)name |
Specification To Provider[3] (formatted) name |
claim.paymentSpecificationReceiverProvider.code claim.paymentSpecificationReceiverProvider.(formatted)name |
Specification To Relation[3] (formatted) name |
claim.paymentSpecificationReceiverRelation.code claim.paymentSpecificationReceiverRelation.(formatted)name |
Beneficiary Provider[3] (formatted) name |
claim.paymentBeneficiaryProvider.code claim.paymentBeneficiaryProvider.(formatted)name |
Beneficiary Relation[3] |
claim.paymentBeneficiaryRelation.code claim.paymentBeneficiaryRelation.(formatted)name |
Location Type description |
claim.locationType.code 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 |
Section 2: Claim Details
For each claim detail, a list of records is displayed. These lists show a selection of key fields per detail records, for example, 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. Click this icon to open a dialog that shows all information available for that claim detail. In some pages, such as the Change Claim page, these details are editable. In this case an edit icon will be 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 will not be 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 |
Un-finalize 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):
-
Click the Authorizations deep link to open the View Authorizations page (in another tab) showing all authorizations for the person or object that are specified on the claim header
-
Click the Claim Lines deep link to open the Claim Lines Search Results page (in another tab) showing all claim lines for the person or object that are 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 are 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 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. It discards the existing tagged results for that claim and ends by setting the skip tag action to Redo. For example, if 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. Choose the Undo action normally as a first step to apply other changes to the claim and only then submit.
First sort pend reasons on priority, then on code. Sort un-finalize reasons and messages on code. Sort diagnoses on sequence. Sort status history on date. The most recent status transition will be listed first.
Financial Holds are sorted first on hold type, then on hold date. The most recent financial hold will be listed first. The edit or 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 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 will not be 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.
Show routing slips 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 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 originating 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 almost 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 is 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 a URL as 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 and behavior applies when modifying external claims data:
(1) Only the records or 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 automatically attaches 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) Click OK in the external claims data dialog to close the dialog but not commit the changes;
(2) Click the save button on the claims page to save changes;
(3) Click Cancel in the external claims data dialog to close the dialog and roll 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. Since the dialog is opened via the working copy claim, only the external claims data attached to the working copy claim can be modified.
Dynamic fields can be edited almost the same way. The dialog only 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 Create Read Update Delete (CRUD) configuration on external claims data. 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 (for example, manual benefits page) then that user can still update the external claims data.
If URL dynamic logic is specified for a flex code field usage of a dynamic record, then that field will have a link icon displayed next to its value. Click the link icon to open a new browser window with a URL as the outcome of the dynamic logic function. 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 gets extended with validated dynamic record values. These record values display in the same manner as external claims data dynamic record values, that is, as detail summary items that can be manipulated through a dialog. 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) description |
claimLine.(procedure).code claimLine.(procedure).description |
(Procedure 2 display name) description |
claimLine.(procedure2).code claimLine.(procedure2).description |
(Procedure 3 display name) description |
claimLine.(procedure3).code 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 (Number of Units) |
claimLine.allowedNumberOfUnits |
Covered (Amount and Currency) |
claimLine.coveredAmount.amount and claimLine.coveredAmount.displayCode |
Covered (Number of Units) |
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 gets 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, that is, 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 for 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 |
|
Entity formatted name description |
claimLine.serviced<Object>.code[5] claimLine.servicedPerson.(formatted name) (Only for serviced entity type
Person) claimLine.serviced<Object>.description (Only for serviced entity type other than Person)[5]
5. <Object> represents the chosen serviced entity type and is a configurable name like Car, House Boat, etc.
|
Entity Ref |
claimLine.providerEntityReference |
Servicing Provider |
claimLine.serviceProvider.code claimLine.serviceProvider.(formatted)name |
Service Specialty |
claimLine.serviceSpecialty.code claimLine.serviceSpecialty.description |
Service Facility (formatted) name |
claimLine.locationProvider.code claimLine.locationProvider.(formatted)name |
Referring Provider (formatted) name |
claimLine.referralProvider.code claimLine.referralProvider.(formatted)name |
Pay To Provider[6] (formatted) name |
claimLine.paymentReceiverProvider.code claimLine.paymentReceiverProvider.(formatted)name |
Pay To Relation[6] (formatted) name |
claimLine.paymentReceiverRelation.code 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 description |
claimLine.locationType.code claimLine.locationType.description |
Reservation Code |
claimLine.reservationCode |
Reservation Line Code |
claimLine.reservationLineCode |
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. Since 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, for example, 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. Click this icon to open a dialog that shows all information available for that claim line detail. In some 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 will not be displayed (nor is it possible to open the underlying dialog box). An exception is the view icon for Applied benefit rules, which is displayed 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). For example: 50 $ on network family deductible
|
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). For example: 150 $ on network deductible
|
Process Fields |
claimLine.priceIndProvider.code claimLine.priceOrgProvider.code claimLine.priceInputDate claimLine.priceInputNumberOfUnits claimLine.indPricePrincipalProcedure1 [7] claimLine.indPricePrincipalProcedure2 [7] claimLine.indPricePrincipalProcedure3 [7] claimLine.benefitsProvider.code claimLine.benefitsInputAmount.amount and claimLine.benefitsInputAmount.displayCode claimLine.benefitsInputDate claimLine.benefitsAgeInputDate claimLine.waitingPeriodInputDate
7. 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 For 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 |
For 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 (reversed limit consumptions are not displayed). The page opens 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 or 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 displayed 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 displayed 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 will be displayed the same manner as external claims data dynamic record values on the claim header, that is, as detail summary items that can be manipulated through a dialog.Dynamic record validation attached to the line can only be edited if the claim is in the CHANGE status.