Overview
In this section, various processing scenarios are discussed through sample configurations of the process steps.
The system is supposed to have the following process steps (with each step focusing on various aspects of the configuration capabilities):
Process Step | Rule Step |
---|---|
Sanity Checks |
Validation Rule |
Age and Gender Check |
Duplication Check |
Validation Rule |
Duplication Check |
Pend Rule |
Potential Duplicate |
Medical Review |
Validation Rule |
Combination Check |
Callout Rule |
Fetch Documentation Details |
Event Rule |
Request to submit Diagnostic Documentation |
Pend Rule |
Missing Diagnostic Documentation |
Pricing Check |
Validation Rule |
Service Type - Allowed Units Check |
Benefits Check |
Validation Rule |
Sanity Checks
This step demonstrates the usage of the validation rules to perform checks on the data. The validation rules can be defined to check the completeness and correctness of the data on the authorization, for example:
-
If a certain service type is defined, then a location must be specified.
-
If a combination of the procedures requested on the authorization is a feasible one, for example both RENT and PURCHASE of a DME (Durable Medical Equipment) cannot be authorized at the same time.
The result of a validation condition evaluating to true is that the function dynamic logic is executed and a message is attached to the authorization. The function dynamic logic can be used to modify the request information as appropriate. The message can be used to pend or deny the authorization.
In this example, the age and sex of the person are matched against the age and sex of the procedure. If the age or sex is not in accordance with the configuration on the procedure a fatal message is attached. Therefore failing this check results in the denial of the authorization.
Duplication Check
This example step makes use of a validation rule and then explains how an authorization can be pended based on a validation message.
Here, the system checks for the uniqueness of the request by implementing a validation rule. If there is a potential overlap with an existing authorization then the system attaches an informative message indicating that a potential match has been found and the authorization is pended for manual intervention through a pend rule. The 'Pend Event' (through Outbound Restful Service Invocation) is also triggered when the authorization pends. All this is achieved by using various settings on the pend reason and pend rule as described in this example.
Medical Review
This step introduces the usage of the event rule and callout rule.
Through a validation rule, the system checks if certain diagnoses are specified for a given procedure or not. The authorization is denied if the diagnostic details are not found.
It is also required that the diagnostic reports must be available. This information is gathered by triggering a callout rule to a document management system. If the reports are absent or incomplete, an 'Event Rule based Event' (through Outbound Restful Service Invocation) is triggered to notify the requester to provide a copy of the missing document(s). The authorization is then pended for manual intervention.
Pricing Checks
This example shows the use of reference sheets. A validation rule using reference sheets is used to determine the allowed number of units for the requested service type. Here, the system refers to three reference sheets. The first reference sheet is used in the validation condition to establish if for a given service type the number of units should be looked up or not. If the condition evaluates to true, then the system uses the second reference sheet to identify the rate card. The service type and service provider group scope determine the rate card that should be applied. The third reference sheet is the rate card and defines the maximum number of units that should be allowed for a given service type. The number of units that the service type is authorized for (the authorized number of units) is adjusted as per the outcome of the third reference sheet.