Duplication Check

The authorization processing might be required to be suspended for manual intervention. Pend rules help to achieve this. An authorization is pended with a pend reason when a pend rule evaluates to true. This example shows how a pend rule can be configured so that processing can be suspended when certain conditions are met.

The process step is configured as:

Process Step	Rule Step
Duplication Check	Validation Rule	Duplication Check
	Pend Rule	Potential Duplicate

The validation rule is configured as:

Field	Value
Code	VAL_DUPECHECK
Description	Check if there are potentially matching requests
Dynamic Logic Condition	DYLO_VAL_DUPECHECK
Dynamic Logic Function	-
Message	MSG_VAL_DUPECHECK_FAILED
Inherit?	N
Enabled?	Y

The dynamic logic DYLO_VAL_DUPECHECK uses predefined search methods to find potentially duplicate authorizations. If this validation evaluates to true then the message MSG_VAL_DUPECHECK will be added to the authorization.

Now, it is desired that when MSG_VAL_DUPECHECK is attached, then the authorization must pend. To achieve this, a pend rule is configured as:

Field	Value
Code	PEND_DUPECHECK
Description	Pend for duplicate check
Authorization Type	-
Authorization Form	-
Brand	-
Message	MSG_VAL_DUPECHECK
Message Group	-
Service Type	-
Procedure Group	-
Diagnosis Group	-
Condition	-
Pend Reason	DUPE_CHECK
Suppress When Fatal?	Y
Enabled?	Y

Here the pend rule has only one fixed criterion i.e. the message on the authorization should be 'MSG_VAL_DUPECHECK' for the pend rule to apply.

Note

The presence of a fatal message on the authorization will not trigger the rule as the indicator Suppress When Fatal is set to 'Y'.

The system also needs to notify the workflow system if such a pend occurs; for this, the pend reason must have the indicator publish set to 'Y'. The pend reason is configured as:

Field	Value
Code	DUPE_CHECK
Description	Potential duplicate authorization request
External Code	DUPE_CHECK
Publish Message?	Y
Reattach?	N
Authorization Fields	-

Should this authorization be reprocessed at any later stage, it might not be of interest to be notified that the authorization is a potential match with an existing authorization as such this situation has been already reported once. Therefore, the 'Reattach' indicator is set to 'N'.

What if?

Many different configurations could lead to a similar outcome when a request is processed for the first time. However, a configuration may result into a different outcome during reprocessing. Consider that instead of the validation rule, the pend rule condition is implemented to check for duplicates. The authorization request will pend if it is a potential duplicate and a workflow message will also be sent out. However, if such a request is reprocessed, even if the pend rule condition detects that the authorization is a potential match, the authorization will not pend (as the reattach indicator is set to 'N') and there will be no visible indication or warning. If such a warning is desired then it is necessary to implement the check through a validation rule.

Here, by implementing a validation rule; message MSG_VAL_DUPECHECK will always be attached to the authorization whenever the system detects it to be a potential duplicate. For the first time it will result into a pend and for the second time it will not (as reattach is 'N').