Aetna Facilitates Business Rules Development in Key Project

This interview originally appeared in the members only BPM Strategies Magazine.   Join today to receive your own copy. 

Aetna, Inc. is one of the nation's leading providers of health, dental, group, life, disability and long-term care benefits. More than 14 million people are covered through its health insurance plans; more than 12 million through its dental insurance programs; nine million people are enrolled in its pharmacy programs and 14 million in its group health insurance. Its healthcare network involves more than 672,000 healthcare professionals, including more than 400,000 primary care doctors and specialists working in 4084 hospitals.The company offers a broad range of insurance and employee benefits products including the first consumer-directed health plan provided by a national full-service health insurance provider. Aetna supports a wide array of programs and services that help control rising employee benefits costs while striving to improve the quality of healthcare, such as case management; disease management and patient safety programs, and integrated medical, dental, pharmaceutical, behavioral health and disability information.In 2002, the company initiated a project to develop a unified quotation system for the full range of Aetna 's products. The new system was to have several attributes. First, it would incorporate the products offered by other insurance providers that Aetna had bought or absorbed over time. Integrating those product offerings had proceeded slowly in the years prior to this project; this project was intended to move that effort forward.Secondly, the new quotation application would be Web-based. Aetna provides benefits through employers in all 50 states, with products and services targeted specifically to small, mid-sized and large multi-site national employers. Aetna also serves individuals and Medicare beneficiaries in certain markets. The advantages of a Web-based application were apparent.Creating the business rules for a new quotation application was a serious challenge. The answer was empowering business users to author them .Third, the idea was to make the user interface for the medical benefits section of the application completely driven by a rules engine. The medical benefits section is where clients tailor the insurance policy to specifically meet their needs. For example, they can choose what kind of co-payment they will make for each visit to a physician's office; they can determine their deductible level; and a wide range of additional choices can be made, as well. "The purpose of the application was to provide flexible medical plans," said John Semmel, an application technical specialist at Aetna , who played a pivotal role in the development of the process of developing and loading business rules for the application. "We wanted plan sponsors to be able to mix and match benefits without having a fixed plan. We could work with the sponsors to give them what they wanted. That is why we needed rules, to prevent us from going too far one way or another."The Rules Environment In this context, a rule is a constraint on data. "Rules are close to the kinds of things that you can do in a relational database in creating a domain," Semmel said. "But in our case it is more complex. There is not just one domain but multiple domains." Since Aetna operates in all 50 states, there are rules for each of the different states. Moreover, the rules change according to the size of the group to be insured and the services that Aetna provides. For example, Aetna often serves as the administrator for companies that are self-insured. One set of rules applies to them. Groups for which Aetna is the payer also have another set of rules. All in all, there are as many as a dozen major criteria that have an impact on which rules come into play and should be applied in a given situation.Defining the circumstances that determine which rules come into play is just the first step. The Aetna team developed more than 25 types of rules such as limiting rules that restrict the domain of a value; default rules that show values before a selection is made; cross-edit rules when one value drives another; non-display rules that turn off the display of a value; warning rules to produce messages for the end user and so on. Moreover, the rules often interact with each other. They can conflict. And they can overlap. Couple this with the fact that a single quotation can encompass more than 1200 data elements and the sheer enormity of the challenge in developing a coherent, effective collection of rules becomes clear.The First Try Aetna 's first attempt to develop the business rules for the new application followed a fairly traditional course. IT staff and business users worked together to draft the broad outlines and structures of the products involved and then worked down from the highest level of abstraction to the lowest level of values. They discussed how they wanted the user interface to operate and how the rules could ensure that the interface worked as anticipated. Ultimately, the teams developed Excel templates for each rule type, complete with documentation and some examples. What would happen next is this. A business analyst would develop a rule in English. A consultant would then translate the rule into an appropriate template and then the rule would be loaded into the database. The result was a disaster. First, the workload was intense, requiring long hours of overtime just to bulk load the data. Second, at each step of the process, errors were introduced. "Every time the data changed hands, something got dropped," Semmel said.Compounding the problem, there was no way to examine the data. "You could write queries but that wasn't good for the business people, who needed to inspect the data," Semmel observed. In short, the entire process was too slow, too complex and too error-prone.By the time the data reached the database, it frequently was in terrible shape. Required fields were often missing. Inconsequential data was often present. Codes and sequence numbers were improperly translated or transcribed. Rules were applied to plans that did not have the appropriate values. Rule descriptions and failure messages often had nothing to do with the actual content of the rules. And to top it off, the technical loading process would sometimes fail. As deadlines approached, the sheer number of rules needed to be written and tested seemed daunting.Management Suite Semmel knew that the project could not meet its objectives using the processes in place. He set about to develop a management suite to automate the rule-development process and to allow the business users to interact more directly with the database. "I knew that it would never be a smooth process until the users got closer to the database," he said.The first applications he developed were an inquiry tool and integrity checker. With the inquiry tool, users could view different sections of the database, which are rendered in a tree view control-like format. Since a lot of the data is hierarchical in nature, the tree-like structure makes it easier for users to understand the nature of the data. They can open up a product line and drill down to the lowest level of detail. The integrity checker checks the structure of the rules, data domains and referential integrity, precedence and logic.The next pieces were an overlap checker, a duplicate checker and a failure message generator. The overlaps checker could monitor rules that would be or could be triggered at the same time, resulting in a domain with no valid values. The duplicate checker searches for rule duplicates themselves; rules that are triggered at the same time against the same value; rules that are logically the same but triggered under different circumstances, and rules that are just very similar.The failure message generator addressed a major shortcoming with the initial process. Business users would write the failure messages that were displayed if a rule was violated. They were often inconsistent or wrong. And the message would not be changed when the rules changed. To address those problems, Semmel wrote a long stored procedure through which the database itself read the rules and generated the appropriate failure message, complete with documentation.The key tool, however, was a rule wizard. Earlier, an outside group had tried to develop a rule wizard but the project had not succeeded. Semmel built on that earlier work but he had a significant advantage. "By the time I began designing the rule wizard, I had a very strong notion about what the job entailed," he said. "I wasn't developing something because somebody said they needed something. I was developing something because I needed it." The rules wizard is a "smart" maintenance facility, fully integrated with the data inquiry application. Customized by business area, it embodies as many of the rules' "meta-rules" as possible and incorporates all of the checkers and failure message generators. In short, the rule wizard makes it very difficult to enter a rule with errors in it. It also allows for copying, deleting and maintaining existing rules.The final piece was creating a series of emulators that allowed business users to see the impact of a rule change before it is loaded to the database. "They can write a rule, test it and know that it is going to work before they get anywhere near the database," Semmel said. "To be able to interactively understand what the rules were doing was the piece that was missing for a long time."The Impact The impact of the management suite has been dramatic. Though not fully rolled out, the quotation application for new business products is in operation and the application for policy renewals is in development. There are nearly 230,000 rows on the plan table with information about almost 200 plans. There are over 46,000 rules in the database that translate into about 236,000 rules in the rules engine. More than 2400 rules may fire during a single benefit selection transaction. So far, more than 27,000 rules have been added, 46,000 deleted and 39,000 maintained using the rule wizard. In fact, 300 to 500 rules are created, modified or deleted daily. Work to be Done But there is a lot of work still to be done. Semmel estimates that the final product will entail about 200,000 rules in the database, which will translate into perhaps one million rules in the rules engine. Each of those rules has to be accurate and appropriate. Many are associated with filling in the default values on potential plans. Since four pages of data must be completed, many customers just accept the default values. "The defaults have to be good," Semmel said.Lessons Learned With the rule wizard in place, what had once been a very challenging environment has become an efficient and effective process. While enabling the business users to directly create the rules in their area of expertise was essential, that in and of itself was not sufficient. Business users had to learn how to write good rules, as well. "They didn't understand what a rule was in this context," Semmel said. "They had a tendency to recite pieces of legislation instead of trying to break it down into atomic rules so it can be rendered as a piece of logic." That skill, he noted, was perhaps the hardest to learn and most essential for success.Moreover, Semmel observed, in tackling projects like this for the first time, it is counter-productive to rush. Deadlines have to be realistic. Moreover, he suggests that teams start small and expand after the completion of a proof of concept. And, while automation tools are useful and appropriate, in the final analysis, the rule authors are the most important people in the process.Walt Jordan is a freelance writer who has written extensively about information management and new technology for more than 20 years. He is a regular contributor to Database Trends and Applications magazine and the 5 Minute Briefing family of newsletters.There are as many as a dozen major criteria that have an impact on which rules come into play and will be applied . The rule wizard makes it very difficult to enter a rule with errors in it and allows for copying, deleting and maintaining existing rulesThree hundred to 500 rules are created, modified or deleted daily.This interview originally appeared in the members only BPM Strategies Magazine.   Join today to receive your own copy.