Sunday, July 20, 2008

Example of a rule analysis

I will try to do some specific rule analysis to illustrate some of the ABRD concepts. ABRD proposes to do the analysis activities as soon as possible and in parallel of the rule discovery, this helps to identify the issues, gaps, and clarify the rules under scope. So let imagine a claim processing application for a car accident. There are some injured persons who reported the accident claim and with some medical providers who send medical bills to the insurance company. One important step of the rule discovery is to clearly understand the business process. For this example we can outline the basic process for claim processing looks like the following diagram:

In brown the decision points that are rule rich, so will be mapped to a rule set. Taking one rule from the adjudication decision point we will build a domain model:

Ask for an expert audit if one of the treatments includes an emergency room treatment or an ambulance transfer done on a day after the accident.

Claims adjudication in insurance refers to the determination of a member's payment, or financial responsibility versus the company ones. So obviously the company wants to pay for what it commits too no more. Here the policy states that we do not want to pay for emergency visit or ambulance transportation which was not on the same day of the accident. For the emergency room we can have some exception, if the injured person came back two days later for headache, or pains that could be consequences of the accident, we need to get some complement of information. For ambulance there is mostly no reason to pay. So from this little analysis we need to develop two rules: one for the emergency room case and one for the ambulance as the actions are different. One action will trigger some audit request and the other action will set the reimbursement amount to zero.

The analysis process starts by looking to the business terms used by the rule. Here we can highlight: audit, treatment, day of accident (also referenced as day of loss) and type of treatment like emergency room, ambulance transfer. Let starts by the fact that the claim is related to a car accident, this means our object model should support a claim type with a day of loss concept attached to it. There is at least one injured person who needs medical treatment, and so the claim relates to the involved persons in the accident. Injured person has injury and related treatments. A medical bill includes the description of the medical treatment done on the patient. By discussing with the claim processor or google ‘medical procedure code’ we can understand that each treatment has a code that we can use to get the type of treatment. The medical bill in fact has some legal form like the UB92 or HCFA-1450. From those forms we can also build our data model.

The audit may include a list of reasons so that we can manage in one audit multiple questions or items to review. The claim and the medical bill will follow a life cycle which will be supported by a state machine. Part of the state machine management will be done by the rule, part by the application. For example when rules are finding issue on the claim they will change its status. So from these descriptions we can build the following UML class diagram

Once we have this UML diagram, let generate Java classes, load them in a java project within Eclipse and tune this model so it will be more efficient from writing rules, using a test driven development approach and refactoring. I encourage using Maven to package the project and to be able to efficiently manage jar dependencies in your project. Once we did so we can start JRules Rule Studio and create the Business Object Model entry. I will detail that in a next blog.

No comments: