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:

Table 1. Authorization Data Model
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 Entry In Process Pended Change Approved 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:

Table 2. Authorization Basket Data Model
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:

Table 3. Authorization Service Type Data Model
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:

Table 4. Authorization Line Data Model
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:

Table 5. Authorization Diagnosis Data Model
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:

Table 6. Authorization Message Data Model
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:

Table 7. Authorization Pend Reason Data Model
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:

Table 8. Authorization Status History Data Model
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:

Table 9. Authorization Pend History Data Model
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.

Table 10. Authorization Callout History Data Model
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.

Table 11. Authorization Event History Data Model
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.

Table 12. Authorization Validation History Data Model
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:

The information is not present at the time the authorization is entered and thus not relevant for authorization processing.
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.

Table 13. Attached Authorization Data Model
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:

Table 14. Note Data Model
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