According to a conventional insurance claim processing scenario, a variety of processing applications must generally be applied to each insurance claim received by a claims processor in order to determine what, if any, benefit the claimant is entitled to receive. This may include, for example, validating that the data entered by the claimant is accurate, determining whether the recipient is eligible under a particular policy, or determining whether the service provider was authorized to provide the particular service, to name a few.
As these processing applications are being run, certain situations may arise that might raise a cautionary flag or cause the party processing the insurance claim to, for example, automatically deny the claim or require the assistance of someone higher up in the company. An example of such a situation may be where the date of service precedes the effective date of the policy. Alternatively, or in addition, a flag may be raised where, for example, a dental insurance claim is received for the same date of service as a medical insurance claim that indicates that the patient was hospitalized during treatment.
In order to define the situations which dictate an automatic denial of benefits or at least further review, software is constructed to analyze the myriad of factors and to identify those claims of interest. As much of claims processing is performed in an automated fashion under the control of software, both the quantity and the complexity of the software can be extensive. Since the portion of the software dedicated to identifying claims of interest of the type described above is often scattered throughout code, it is sometimes difficult to readily identify any such portions of software in order to determine the conditions that are currently being evaluated for purposes of denying benefits or flagging for further review. Furthermore, it can prove challenging for many people who are not well versed in the software code to determine from the software itself, the conditions that are being evaluated. Moreover, it can be imposing to create and integrate new software that defines new or different conditions to be considered for purposes of denying benefits or flagging for further review; even for those who can explain in general terms the parameter(s) to be considered by the new or different conditions.
USPTO Backgrounds
USPTO Backgrounds