Pend Rules

A pend rule can halt an authorization process for manual intervention. When an authorization is pended the user needs to manually decide to either resolve the pend reasons (that is resolving them after modifying or without modifying the authorization) or deny the authorization.

The pend rule describes the circumstance in which an authorization pends. The pend reason describes why the authorization has pended. Each pend rule must specify the pend reason that is attached to the authorization, should that rule trigger.

The pend reason has the following fields:

Table 1. Pend Rules

Field	Description
Code	Identifying code of the pend reason
Description	The description of the pend reason
External Code	The external code sent to the workflow system
Publish Message?	If checked, the pend reason is included in the Workflow IP. The workflow IP is triggered if there is at least one pend reason with this indicator checked at the end of evaluation of the pend rules for a process step
Reattach?	Should the pend reason be reattached? If unchecked, this reason will not be reattached, that is, will not cause the authorization to pend if the authorization pend history shows that the same pend reason has been resolved in the past on the authorization (regardless of the version).
Authorization Fields	Dynamic function producing a list of name value pairs that are included in the workflow message (Workflow IP)

A pend rule configuration consists of three different sort of fields. Some identify the rule, some are used to describe the circumstance under which an authorization pends and some drive what happens when the authorization actually pends. These fields are:

Field	Description
Code	The code of the pend rule
Description	The description of the pend rule
Authorization Type	The authorization type to which the pend rule applies Authorization Notification and Referral
Authorization Form	The authorization form to which the pend rule applies
Brand	If specified, this should match the brand of the authorization
Message	If specified, this should match one of the authorization messages
Message Group	If specified, one of the authorization messages should match one of the messages in the group
Service Type	If specified, one of the service types on the authorization should match this service type.
Procedure Group	If specified, one of the procedures of the authorization should match one of the procedures in the group. The criterion is met if one of the authorization lines procedures is part of the procedure group on the authorization line start date
Diagnosis Group	If specified, one of the diagnoses on the authorization should match one of the diagnoses in the group. The criterion is met if any diagnosis on the authorization is part of the diagnosis group on the authorization start date
Condition	The dynamic logic condition that is used to check the authorization. If specified, then along with the other fixed criteria, the condition must also evaluate to true for the authorization to pend
Pend Reason	The pend reason that is attached to the authorization
Suppress When Fatal?	If checked, then this rule is suppressed when the authorization has a fatal message
Enabled?	Is the pend rule enabled for execution?

A rule can specify multiple fields of the authorization to be checked, for example, a single rule can check for the diagnoses, the procedure, and the messages. If a single rule configures multiple fields to be checked, then the authorization needs to match all of them in order for that rule to trigger.