Case Study: Health Insurance
Case Study: Curing Complexity in New Zealand
By Roger Sessions, ObjectWatch
If you are a gardener, hoses are essential to your work. Hoses allow water to move freely from one place to another. If you get a knot in a hose, the water slows to a trickle. You must stop what you are doing, untangle the knot, and straighten out your hose.
Software systems can also get knots. These knots are not caused by tangled hoses, they are caused by tangled logic. When a software system gets a knot, work slows to a trickle. Like the gardener, you must stop what you are doing, untangle the knot, and straighten out the logic.
A good example of a software knot was the one in the hose connecting two players in the New Zealand Health Care System. Like so many software knots, this was caused not by faulty code, but by faulty decisions at the IT architecture level. But which decisions were faulty? And how should they be changed? These questions seemed unanswerable, and were costing the New Zealand tax payers millions of dollars.
The solution came in a methodology known as Simple Iterative Partitions (SIP). SIP brings a mathematical precision to locating complexity knots and driving the best possible solution for knot elimination. But before I can explain how SIP was used in New Zealand, I need to give some background.
New Zealand has a public health care system. Most health care is provided by the government including subsidies for most drugs. The drug subsidies are managed by two governmental agencies, PHARMAC and HealthPAC. These two agencies are politically autonomous but technically interdependent. PHARMAC is responsible for the rules that govern which drugs are to be subsidized under which conditions. HealthPAC is responsible for paying the claims for those drugs.
In 2008, the work flow went as follows.
• On a monthly basis, PHARMAC would come up with a new version of the rules for pharmaceutical subsidies.
• PHARMAC would codify these rules as a “Schedule”.
• The Schedule would be made available in two forms, as a printed document and as an XML document.
• The XML document would be transmitted to HealthPAC.
• HealthPAC would read the XML document into their databases and use the information to determine which claims were eligible for how much subsidies.
The printed version of The Schedule ran over 200 pages. The rules for subsidy eligibility could get very complex. Here, for example, is part of the section defining eligibility for Adalimumab, a drug in the family known as TNF inhibitors:
Approvals valid for 6 months for applications meeting the following criteria:
All of the following:
1 Patient is an adult who has had severe and active erosive Rheumatoid Arthritis for six months duration or longer; and
2 Treatment is to be used as an adjunct to methotrexate therapy or monotherapy where use of methotrexate is limited by toxicity or intolerance; and
3 Patient has tried and not responded to at least three months of oral or parenteral methotrexate at a dose of at least 20 mg weekly or a maximum tolerated dose; and
4 Patient has tried and not responded to at least three months of oral or parenteral methotrexate in combination with at least two of the following (triple therapy): sulphasalazine, prednisone at a dose of at least 7.5 mg per day, azathioprine, intramuscular gold, or hydroxychloroquine sulphate (at maximum tolerated doses); and
5.1 Patient has tried and not responded to at least three months therapy at the maximum tolerated dose of Cyclosporin alone or in combination with another agent; or
5.2 Patient has tried and not responded to at least three months therapy at the maximum tolerated dose of Leflunomide alone or in combination with another agent; and
6.1 Patient has persistent symptoms of poorly-controlled and active disease in at least 20 active, swollen, tender joints;
6.2 Patient has persistent symptoms of poorly-controlled and active disease in at least four active joints from the following: wrist, elbow, knee, ankle, and either shoulder or hip; and
7.1 Patient has a C-reactive protein level greater than 15 mg/L measured no more than one month prior to the date of this application; or
7.2 C-reactive protein levels not measured as patient is currently receiving prednisone therapy at a dose of greater than
5 mg per day and has done so for more than three months; and …
This is only a part of the eligibility requirement for only one specific drug. You get the idea. The rules are very complex. And as you can imagine, the codification of these rules as an XML document that could be read into a database and be used to drive eligibility analysis was also very complex.
What should have happened is that once a month PHARMAC would send HealthPAC a new XML document that would automatically update the HealthPAC database with new data to drive the eligibility algorithms. What actually happened is that once a month PHARMAC and HealthPAC would spend hundreds of hours trying to understand why the latest XML document was unreadable.
HealthPAC would blame PHARMAC for creating a bad XML document. PHARMAC would blame HealthPAC for its inability to read a valid XML document. Hundreds of personnel hours would be spent trying to sort out the mess. And this drama would be repeated on a monthly basis. There was a knot in the hose, and nobody could figure out whose end of the hose was at fault.
A Cry For Help
In the hope of trying to sort out this problem once and for all, 2008 PHARMAC issued an RFP calling for “respected experts in systems architecture and agile systems development, for a review of processes depending on the Pharmaceutical Schedule.” ObjectWatch teamed up with its New Zealand partner, Fronde, to offer the SIP methodology to address the problem. As they wrote in their response,
To deliver this review, we are uniquely positioned to offer PHARMAC a highly effective approach focused directly on addressing the complexity of IT systems and related processes. Our approach, quickly and cost effectively, focuses on identifying issues with processes and systems architecture that are directly related to effective system partitioning. Effective partitioning is essential not only for managing complexity, but for enabling key architectural requirements such as security, reliability, and scalability. Failures in any of these areas of system partitioning, we can get a good reading on a wide range of architectural capabilities.
PHARMAC accepted the joint ObjectWatch/Fronde proposal, and work commenced.
The SIP Approach to Complexity
The SIP methodology is based entirely on complexity analysis. The foundational preposition is that given a choice between two architectural approaches that both solve a given problem, the lease complex solution is the best.
The approach used by SIP to analyze the causes of complexity in existing software systems is synergistic partitioning analysis. Synergistic partitioning analysis says that two business functions should be colocated within the same sub system if and only if the two business functions share the property of synergy. Two systems are said to share synergy if and only if, from the perspective of the business, neither function has value without the other. A full exploration of the topic of synergy is beyond this case study, but is discussed in depth in the White Paper, The Mathematics of IT Simplification, available at the ObjectWatch web site.
While the theoretical definition of synergy analysis may be difficult to follow, the pragmatic results are easy to understand.
The ObjectWatch/Fronde Analysis
There are three tests to check for effective synergistic partitioning. These are as follows:
• Function exclusivity, that is, functions live in only one place.
• Function synergy, that is, like functions live with like functions.
• Data partitioning, that is, that partitioning of the system at the function level is projected through at the data level.
It did not take long to find violations of all three of these principles in the area of Schedule Validation. Looking at function exclusivity, for example, we found
The monthly process [of schedule validation] is an intensive process that takes two people several days to complete... Yet despite this, this effort is duplicated in many other parts of the ecosystem.
Functional Synergy was also violated. Again, from the Final Recommendations:
The validation by HealthPAC and vendor systems also represents a violation of the Functional Synergy Rule. The function of validation is most synergistic (that is, it is most closely related), to the function of publication. The function of publication is, by all accounts, in the PHARMAC area of responsibility. There is no function in the HealthPAC area of responsibility that would normally be thought of as synergistic with validation. To the contrary, all of the HealthPAC functions are autonomous with respect to Schedule validation.
Finally, we looked at data ownership. Again, we found widespread violations. From the Final Recommendations:
Multiple groups within the Schedule ecosystem maintain their own writable versions of the Schedule. For example, when an important issue with the Schedule is detected, individual users of the Schedule may be requested to make direct modifications to their copies of the schedule. This, again, is a violation of partitioning.
As if the monthly XML problems weren’t enough, we found many other problems that were directly attributed to the complexity caused by poor partitioning. Again, from the Final Report:
The first and most obvious of the missing architectural capabilities is flexibility, that is, the ability to modify the system to meet new needs… complex systems are very difficult to modify, because changes in one part of the system have unpredictable effects on other parts of the system… It is clear that HealthPAC system fits the classic definition of an inflexible system; that this inflexibility is due to complexity, and that the high cost is born by all in the ecosystem.
We also found major problems in data security. While for confidentiality reasons, I won’t detail those problems here, I will quote from the final report on the cure:
Confidentiality is hard to build into a complex system. There are too many entry points, most of which are poorly understood and poorly documented. The best approach to improving confidentiality is to reduce the complexity of the system.
The Recommended Solution
We were asked to evaluate the problems in transmitting Schedule information from PHARMAC to HealthPAC. What we found, using partitioning analysis, was that the Schedule transmission problems had nothing to do with Schedule transmission per se. The problem didn’t even have to do with how the claims were being validated. The real problem had to do with who was doing the claims validation.
We showed that from a partitioning perspective, there was no justification for HealthPAC validating claims. Validating claims was synergistic with the PHARMAC business functions, not the HealthPAC functions. If claims validation was moved from the HealthPAC side to the PHARMAC side, the whole problem of Schedule transmission disappeared overnight. (Well, not quite overnight, there were a few technical changes to be made! But not many.) Any a number of other complexity related problems would be solved as well.
As we stated in our Final Recommendations,
We recommend a single implementation of Validate Subsidy Eligibility that is owned, implemented, and managed by PHARMAC and used by HealthPAC… These changes will ensure a single point for updates by PHARMAC and eliminate the complexity of attempting to transmit rules between the two organizations in [XML] data structures. The amount of complexity this will reduce from the existing PHARMAC/HealthPAC relationship promises a good return on investment. From a system implementation point of view, there is a large opportunity for code reusability and the required investment is not large. We believe the implementation of … these recommendations will result in a huge reduction of the complexity of the PHARMAC/HealthPAC ecosystem. These simpler systems will be easier to maintain, more agile, and less costly. Everybody involved in the ecosystem will feel the benefit. And the New Zealand taxpayers will be getting greater value for their investment.
We estimated that moving claims validation from HealthPAC to PHARMAC would directly or indirectly result in the following annual savings:
• Elimination of human validation of XML at HealthPAC: $240K
• Elimination of human validation at other partners: $500K
• Elimination of maintenance costs for validation program at HealthPAC: $200K
• Elimination of maintenance costs for validation program at other partners: $350K
• Elimination of manual reentry of pharmacy data and transportation costs: $600K
• Reduction of printing costs for Schedules that would no longer be needed: $50K
• Additional cost of simpler validation program at PHARMAC amortized over 5 years: ($100K)
Total Savings: $1.94M (NZD) - $100K (NZD) = $1.84M (NZD)
The SIP analysis occurred over about 6 weeks and cost a total of about $40,000 (NZD).
As the PHARMAC/HealthPAC system showed, when you have a knot in a hose, sometimes the solution isn’t to eliminate the knot. Sometimes the solution is to eliminate the hose.