Healthcare Reform – Rewrite or Refactor?

Few people disagree that the healthcare system in the US needs to be reformed. How many people would agree about the best way to successfully accomplish it?

The article Understanding Healthcare Reform lists just a few of the elements of healthcare with links to several sub-categories within each of the following elements:

• coverage
• payment systems and costs
• patient safety
• health information technology
• medical research

For me the article is a reminder of just how complicated the healthcare system is. When a solution is required of a large scale system like healthcare, one has to consider whether it should be completely overhauled - or refactored* piece by piece. Without the right approach to the problem, it is conceivable that the solution could create substantially bigger problems than the current system. Joel Spolsky, a contributor to Inc magazine and owner of a New York software company, summarized it best in Things You Should Never Do, Part I, in reference to re-writing a software program from scratch.

“It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. First of all, you probably don't even have the same programming team that worked on version one, so you don't actually have "more experience". You're just going to make most of the old mistakes again, and introduce some new problems that weren't in the original version.”

If healthcare is to be reformed without the risk of creating more problems related to care, coverage, or cost, the system will have to either be refactored fixing one broken piece at a time - or piloted in a smaller representative area or areas and refined and scaled out until the system proves it meets everyone’s expectations.

 

* definition from wikipedia: Code refactoring is the process of changing a computer program's internal structure without modifying its external functional behavior or existing functionality, in order to improve internal quality attributes of the software, for example to improve code readability, to simplify code structure, to change code to adhere to a given programming paradigm, to improve maintainability, to improve performance, or to improve extensibility.

Healthcare and software seem like completely different subjects, but there are many parallels between large complex software programs and other large complex systems from other industries like healthcare.

Public gets Visibility into Government IT Spending

The government recently released the beta version of the IT Dashboard. It provides a level of transparency to the public which could help the general population to become better informed about the performance of Federal IT investments. The system meets many of the recommendations for effective dashboards in my past post Dashboards - Not Just for Cars, but as noted in that post, the dashboard itself has little value without a well-defined supporting process. The process, in this case, probably falls into the category of providing transparency to the public, but is not intended to be used as a “sense and response” tool by the agencies and teams managing the investments and projects.

An interesting and often common side effect of this type of dashboard is that despite any pitfalls that come as a result of being designed for public transparency only (see my post about Information dashboards), the ease of use and graphical nature often provides a view into valuable data that was either:

1. non-existent before
2. available, but in existing systems that are too difficult to use to proactively manage exceptions in a timely manner

As a result, the projects are managed better than ever before - even with ill-fitting tools. This phenomenon can enlighten managers to what can be possible if the same approach to providing visibility is focused on the control process.

I hope the Federal agencies have a user-friendly internal system that already provides visibility to these investments/projects at a level of detail that provides for effective management. However, if the amount of red on the graphs is an indicator, I suspect the internal managers and leaders can get a lot of mileage out of the using the new system to drive improvements. It has to get pretty bad to show yellow or red. For example, the cost graph only goes red if the actual cost is 40% or more over budget. The schedule is yellow if the average number of days late is 30-89 days.

Dashboards can be Designed for Information, not just Control

Not all performance dashboards are used for feedback and control. Sometimes an information dashboard is designed to provide details about a process or environment to an individual or group that is interested in the data, but does not have the capability and/or desire to directly impact the results. Some examples being a group of investors, a Board of Directors, or maybe a Federal compliance agency, like UL (Underwriters Laboratory).

As with any dashboard, the general usability considerations outlined in my previous post Dashboards – Not just for Cars still apply. What makes an information dashboard different from a dashboard used for control and optimization can include the following:

• May not be updated as frequently. (minimize information overload)
• The criteria for “Normal”, “Caution”, and “Houston we have a problem!” are often more relaxed than a proactive control system.
• The criteria used is often at a level of abstraction that provides basic, easily understandable information, but may not be meaningful to try to act on the information directly. It may be an aggregation of many inputs “Y = a + b + c + d” that would require further investigation by people that are closer to the inputs.