Building Agile Processes with SOA and Business Rules

Vision Service Plan, VSP, presented on their use of business rules to build agile business processes in healthcare. VSP has some 55M customers in their plans and have been an IBM/ILOG customer since 2002. Every process in healthcare is governed by policies, regulations – every process has decisions that must be made following the rules implied by these policies and regulations. Everything from clinical decision-making to billing. Healthcare companies are dealing with siloed processes that make it hard to manage risk consistently and increase the time to make a change. The lack of transparency and an inability to do “what-if” analysis only make this worse while business users want more visibility and more control.

VSP have a ton of legacy systems built since 1955. Much of this is running on COBOL on the mainframe. Many systems were built for a particular department (claims, eligibility) and this has become an increasing burden. Many processes had manual steps and this too has become unacceptable. Every time they wanted to add a new product offering it would take 9-12 months. This reduced agility and even though this time included lots of testing there was still a risk of rules being…

Vision Service Plan, VSP, presented on their use of business rules to build agile business processes in healthcare. VSP has some 55M customers in their plans and have been an IBM/ILOG customer since 2002. Every process in healthcare is governed by policies, regulations – every process has decisions that must be made following the rules implied by these policies and regulations. Everything from clinical decision-making to billing. Healthcare companies are dealing with siloed processes that make it hard to manage risk consistently and increase the time to make a change. The lack of transparency and an inability to do “what-if” analysis only make this worse while business users want more visibility and more control.

VSP have a ton of legacy systems built since 1955. Much of this is running on COBOL on the mainframe. Many systems were built for a particular department (claims, eligibility) and this has become an increasing burden. Many processes had manual steps and this too has become unacceptable. Every time they wanted to add a new product offering it would take 9-12 months. This reduced agility and even though this time included lots of testing there was still a risk of rules being missed because they were hidden in the systems. Finally the IT department contains lots of tribal knowledge built up over the years. In 2002 adopted SOA, business rules and business process to start fixing this.

Key is to improve agility to bring new products to market. This would reduce costs but agility was critical. They wanted to improve reuse of services, rules and process steps while putting both business and IT people into the rule management process. Centralizing rules to make them easier to locate and manage and end-to-end process visilbity were likewise objectives. VSP realized this was not a once-and-done project but a way to create continuous improvement.

One of the first steps was to define a reference architecture. This had a presentation/requester layer, a business process service layer, business services layer and infrastructure services layer. Every layer very IBM-centric – WebSphere products used at every layer with a mainframe-centric infrastructure layer.  They are still adding support for a service registry and have their own service bus but other than that pretty much IBM down the line.

Having built the reference architecture they moved to some proof of concept projects and prototype services. One PoC was a patient options calculator for use in a doctor’s office. Needed most of the core components (web tier, couple of services, mainframe connection) but was fairly limited in scope. Learned some interesting things especially about the development process. For instance, they had started with a bottom-up, Java-centric approach but found this was too brittle and that a model/XSD-driven top-down approach would be more effective. In particular, this made it much easier to make the information available to the rules.

Next phase was a major roll out and widespread use of rules. Improved the external and customer service portals and claims pricing. 53 services developed with 42 in production and 6,500 hours of development saved so far. Some of these services are getting 80-100,000 hits/day.

Claims processing involves submission, validation, pricing and payment. Each of these decisions – is this a valid claim? How much of this claim should we pay? – were automated using business rules. Initially these were written as “code” in the rules engine but even then this improved the engagement of the business over traditional code. Also increased the rate straight through processing. Added lab routing service, built using rules, to this claims process. Subsequently exposed the rules using more business user friendly tools and this has increased agility and accuracy – the business user is now driving not just participating.  The improved accuracy and agility was dramatic when compared to the old system. 30% faster developing rules in ILOG v writing Java, business analysts are taking ownership of the rules and have about 4,000 rules. Now moving on to the rating engine and improving the pricing engine.

Another project was around business process – one example was around customer service letter processing. This process collects information from multiple mainframe and related sources and then pulls it together to generate the letter. Using WebSphere Process Server they were able to minimize the number of screens required to collect data and automate more of the information assembly. Now moving on to handle membership on-boarding – a process with lots of hand-offs and manual steps across multiple groups. Now using WebSphere to monitor processes to improve visibility as well as to integrate the various steps.

Some lessons learned:

• SOA Service Team – a Center of Excellence – drove momentum by working on different projects
• SOA Development Community to keep the teams engaged helped with the adoption of services
• SOA Governance was important and helps with sustaining the initiative
• Service versioning matters
• Manage testing – who tests versions, how to manage this, can you test only services or must you test applications
• Process changes involving humans are hard
• Continuous Improvement is the key

SOA is helping VSP gain business efficiencies and speed to market. SOA is not easy but being persistent and patient can generate a real pay off. They use a great phrase “commit and adapt” to reflect the constant need to change the approach while continuing to use it. SOA is not a one-size fits all approach so adapt it to work for you.

Link to original post