Data Model

An authorization is required when a payer requires the insured or provider to request permission before undergoing or rendering services. Such permission is usually required for a limited set of services or specific combinations of procedures, diagnoses and providers. For example, before a person can claim a wheelchair from a durable medical equipment provider, he or she needs to obtain an approved authorization from the health care payer.

Authorization

This entity represents the fact that a specific service type, procedure of health care, that requires pre-approval before it can be claimed, is approved or denied. The authorization has the following fields:

Field Description

Brand

The brand to which the authorization belongs to

Type

The authorization types include 1) Authorization 2) Notification 3) Referral

Form

The authorization form (category) of the authorization[1]


1. The authorization form for an authorization is mandatory in Oracle Health Insurance Authorizations. It is optional in Claims Adjudication.

Code

The code of the authorization

Version

The version of the authorization

Requested by Provider

The organization or provider requesting the authorization for services

Requested by Relation

The relation requesting the authorization for services.

Requested for Insurable Entity

The person or object for which the authorization is requested

Requester Reference

The number or code used by the requester to identify the authorization

Service Provider

The provider delivering the specific services to the person or object

Provider Group Scope

The scope with respect to provider groups (In, Out or Either)

Service Specialty

The specialty for which the authorization is requested

Location Provider

The location at which the services will be provided

Requested Renewal Reference

The requested renewal reference

Requested Renewal Period

The requested renewal period (must be specified in combination with requested renewal reference)

Requested Renewal Period Unit of Measure

The requested renewal period unit of measure (must be specified in combination with a requested renewal reference)

Renewal Reference

Specifies the as-of date that is used to determine which period applies for the authorization limit when a claim line is evaluated in Claims. The following as-of dates can be specified:

  • After Start of Calendar Year - in short: Calendar Year. The first period starts at January 1st of the year of the service.

  • After First Claim - in short: First Claim. The first time the period starts at the service date (claim line start date). Because claims need not come in the logical order (oldest first), the periods possibly need to be rearranged as more claims come in.

  • After First Claim (irregular periods) - in short: First Claim Irregular. Same as the First Claim reference, with the difference that the periods are irregular.

If no reference is specified, this means that the authorization limit has no fixed period.

Renewal Period

The length of the renewal period (must be specified in combination with a renewal reference)

Renewal Period Unit of Measure

The unit of measure (Day, Month or Year) for the renewal period length (must be specified in combination with a renewal reference)

Currency

The currency of all amount fields

Requested Amount

The total amount for which services are requested

Requested Amount Currency

The currency of the requested amount

Requested Units

The number of services for which the authorization is requested

Requested Service Days

The number of service days for which the authorization is requested

Authorized Amount

The total amount for which authorization is approved

Authorized Amount Currency

The currency of the authorized amount

Authorized Units

The number of units for which the authorization is approved

Authorized Service Days

The number of days for which the authorization is approved

Indicator Override Cover Limits

Should the adjudication cover stop limits be overridden if this authorization is applied in Claims?

Start Date

The start date of validity of the authorization

End Date

The end date of validity of the authorization

Remarks

Additional information for internal use

Status

The status of the authorization

  1. Entry

  2. In Process

  3. Pended

  4. Change

  5. Approved

  6. Denied

Unfinalize Reason

The reason for unfinalizing the authorization

Access Group

The data access group that controls the access to the authorization in the UI pages

Authorization Basket

An authorization can have zero, one or multiple baskets attached to it:

Field Description

Authorization

The authorization to which the basket belongs to

Basket

The basket that is the subject of the authorization

Start Date

The start date of the authorization basket

End Date

The end date of the authorization basket

Authorization Service Type

An authorization can have zero, one or multiple service types attached to it:

Field Description

Authorization

The authorization to which the service type belongs to

Service Type

The service type that is the subject of the authorization

Authorization Line

An authorization can have zero, one or multiple lines attached to it:

Field Description

Authorization

The authorization to which the line belongs to

Code

The identifying code of the authorization line (unique within an authorization)

Procedure

The procedure that is the subject of the authorization (cannot be specified in combination with a procedure group)

Procedure Group

The procedure group that is the subject of the authorization (cannot be specified in combination with a procedure)

Requested Renewal Reference

The requested renewal reference

Requested Renewal Period

The requested renewal period (must be specified in combination with a requested renewal reference)

Requested Renewal Period Unit of Measure

The requested renewal period unit of measure (must be specified in combination with a requested renewal reference)

Renewal Reference

Specifies the as-of date that is used to determine which period applies for the authorization line limit when a claim line is evaluated in Claims. The following as-of dates can be specified:

  • After Start of Calendar Year - in short: Calendar Year. The first period starts at January 1st of the year of the service.

  • After First Claim - in short: First Claim. The first time the period starts at the service date (claim line start date). Because claims need not come in the logical order (oldest first), the periods possibly need to be rearranged as more claims come in.

  • After First Claim (irregular periods) - in short: First Claim Irregular.

Same as the First Claim reference, with the difference that the periods are irregular.

If no reference is specified, this means that the authorization line limit has no fixed period.

Renewal Period

The length of the renewal period (must be specified in combination with a renewal reference)

Renewal Period Unit of Measure

The unit of measure (Day, Month or Year) for the renewal period length (must be specified in combination with a renewal reference)

Requested Amount

The total amount for which the authorization line is requested

Requested Amount Currency

The currency of the requested amount

Requested Units

The number of units for which authorization line is requested

Requested Service Days

The number of service days for which authorization line is requested

Authorized Amount

The total amount for which authorization line is approved.

Authorized Amount Currency

The currency of the authorized amount

Authorized Units

The number of units for which the authorization line is approved

Authorized Service Days

The number of service days for which the authorization line is approved

Start Date

The start date of the authorization line

End Date

The end date of the authorization line

Authorization Diagnosis

An authorization can have zero, one or multiple diagnoses attached to it:

Field Description

Authorization

The authorization to which the diagnosis belongs to

Diagnosis

The diagnosis that is the subject of the authorization

Authorization Message

An authorization message represents a piece of information within the context of that authorization’s traversal through the process. The authorization messages provide context as to why a authorization processed the way it did.

An authorization can have zero, one or multiple messages attached to it:

Field Description

Authorization

The authorization to which the message belongs to

Indicator Inherit

Indicates if the claim line should inherit the message or not

Indicator Processing

Indicates if the message has been added as part of processing

Value 0 …​9

Value for message placeholders {0} to {9}

Message

The message

Authorization Pend Reason

An authorization may pend for external intervention, usually because a human operator needs to work the authorization before it can continue to be processed. Whenever a authorization pends, one or more reasons are attached to that authorization, explaining why the authorization pended.

An authorization can have zero, one or multiple pend reasons attached to it:

Field Description

Authorization

The authorization to which the pend reason belongs to

Pend Reason

The pend reason

Process Step

The process step in which the pend reason was attached to the authorization

Authorization pend reasons store only the current pend reasons, that is, they are discarded once the authorization is submitted after resolving pends. The full history of pend reasons is stored in separate entity named "Authorization Pend History". It is not allowed to have multiple authorization pend reasons for the same authorization with the same pend reason.

Authorization Status History

The position of the authorization in the processing flow is reflected by a authorization’s status. The authorization status history keeps track of all status transitions, so that it is possible to trace back how an authorization flowed through the processes and how long it took to complete certain steps within the process. The authorization status history entity has the following fields:

Field Description

Code

The code of the authorization the history is for

Authorization

The authorization version the history is for

Status

The status of the authorization

Status Reached Date Time

Date and time when the authorization entered the status

Authorization Pend History

The reasons why an authorization pended are stored as a detail of a authorization status history that logs a pend status. The authorization pend history entity has the following fields:

Field Description

Authorization Status History

The authorization status history under which the pend reason was active

Pend Reason Code

The code of the pend reason

Pend Reason Description

The description of the pend reason

Process Step Display Name

The display name of the process step in which the rule was executed

Process Step Sequence

The sequence of the process step

Resolved by

The user who resolved the pend reason

Resolved Date Time

The date and time when the pend reason was resolved

Authorization Callout History

The processing of authorization callout rules is tracked in the authorization callout history. An authorization callout history record is created when a callout rule is executed. A callout history record is then linked to the Authorization’s most recent status history record at that point in time.

Field Description

Authorization Status History

The most recent authorization status history when the callout rule was executed

Definition Code

The code of the callout definition

Definition Description

The description of the callout definition

Indicator Display in UI

Indicates if the authorization callout history be shown in the UI or not

Process Step Display Name

The display name of the process step in which the rule was executed

Process Sequence

The combination of the sequence of the process step and the sequence within the process step in which the rule is executed

Request Sent Date Time

The timestamp the request was sent

Response Received Date Time

The timestamp the response was received

Authorization Event History

The processing of authorization event rules is tracked in the authorization event history. An authorization event history record is created when an event rule is executed. An authorization event history record is then linked to the Authorization’s most recent status history record at that point in time.

Field Description

Authorization Status History

The most recent authorization status history when the authorization event was triggered

Event

The event on the event rule

Topic

The topic on the event rule

Indicator Display in UI

Indicates if the authorization event history be shown in the UI or not

Process Step Display Name

The display name of the process step in which the rule was executed

Process Sequence

The combination of the sequence of the process step and the sequence within the process step in which the rule is executed

Authorization Validation History

The processing of authorization validation rules is tracked in the authorization validation history. An authorization validation history record is created when a validation rule is executed. An authorization validation history record is then linked to the Authorization’s most recent status history record at that point in time.

Field Description

Authorization Status History

The most recent authorization status history when the authorization validation rule was triggered

Validation Code

The code of the validation rule

Validation Description

The description of the validation rule

Process Step Display Name

The display name of the process step in which the rule was executed

Process Sequence

The combination of the sequence of the process step and the sequence within the process step in which the rule is executed

Attached Authorization Data

Attached authorization data provides the ability to write additional information to the authorization without affecting the authorization status. Without the existence of attached authorization data, adding information to an approved authorization would lead to the creation of a new authorization version and the need for reprocessing.

The information that is written to attached authorization data has the following characteristics:

  1. The information is not present at the time the authorization is entered and thus not relevant for authorization processing.

  2. The information cannot readily be added to an authorization afterwards because the authorization is in a status- typically Approved or Denied - that changes are no longer permitted unless it is unfinalized and there is no need to reprocess the authorization after adding this information.

Attached authorization data is a completely configurable entity and can be can be extended with dynamic records and fields.

Fields Description

Code

The code of the authorization to which the attached authorization data belongs to.

Dynamic Fields and Records

The dynamic fields and records defined to capture additional information about the authorization

The attached auth data record is created automatically along with the authorization. The attached auth data can be entered through the Attached Data IP or from the View and Edit Authorization page. Attached auth data is also accessible from the dynamic logic (through object authorization).

Note

Notes are used to maintain a proper record of history of authorizations. Furthermore, the document discussions, conversations, actions carried out and advice given to claimants can be recorded in the form of notes.

An authorization can have zero, one or multiple notes attached to it:

Field Description

Authorization Code

The code of the authorization that the note belongs to

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