Do It Yourself Healthcare Reform

Voters tell Congress what they want in the upcoming bill. It’s as simple as that. Here are a few proposals. Voters will be presented with a list of Proposals Only , no implementation. Voters choose the proposals they want via a ratification process.

Here's what the proposals look like.

Simple! Voters pick what they like.

Only after voters chose what they want, do we let Congress decide how to implement the voter ratified healthcare reform proposals. This will then be submitted to voters in a referendum.

Voters are in control during the entire process.
Long and complicated. Yes. It’s too important to do any other way.

For more information on this approach of presenting political proposals, please check out Healthcare Reform via Use Cases

If you’re interested in adding more reform proposals, please submit other relevant proposals to this blog. I’ll convert it to appropriate Use Case Diagrams.

Healthcare Reform via Use Cases

One of the greatest things about an open society is the ability to learn, learn, learn. Learning is certainly so exhilarating as we can literally discover the world. Learning also gives us the opportunity to explore how other people solve a problem similar to ours but in a different context. Probably most out-of-the-box solutions that we hear about really stem from an in-the-box solution in its native context.

Speaking of native, maybe the Native Americans from the Standing Rock Sioux Reservation in the Dakotas (which, by the way, means friend) can teach us something about standing up on our hind legs. You see the Standing Rock Sioux Reservation is a sovereign nation, but every now and then they have to assert their rights lest they be trampled upon. In 1997, the SRSR did just that, suing the county and state for motor vehicle tax collection and winning.

This blog is about Healthcare Reform and we will appeal to the Software world to help us corral healthcare issues. As it turns out, by turning our view outward, we will be able apply a super-effective “out-of-the-box” solution to what ails healthcare reform.

Let’s first summarize the problems with Healthcare Reform efforts to date: 1) the inability of previous administrations to bring reform to fruition, and 2) the total disconnect between the public on the one hand and the administration and Congress on the other. Let us also be clear that the second problem drives the first. This disconnect has been apparent in the Town Hall meetings with angry citizens venting at our politicians, yet these pols don’t get it.

Now is the time for change, real change - “out-of-the-box” change.
Let’s briefly describe a problem in the Software Development arena that is similar to the recent experience with healthcare reform… In a nutshell, many large software projects failed miserably. They went over budget, over schedule, didn’t deliver what users wanted, and, in many cases, were despised by users and management alike. Even though these projects were well funded and were staffed by the best and the brightest, they failed anyway. This experience was repeated over, and over again, independently of organization, independently of location, etc. This was a huge problem that went on for many years, eventually to be resolved by the top computer scientists in the world. Why were projects failing so often and so painfully?

The answer was as remarkable as it was simple. The root cause of all the failures in the software industry was the absolute neglect of stakeholders by software architects and the like. The architects and developers built terrific systems that no one wanted or could use. They built systems in a vacuum. Let’s be clear about what this means… Like our members of Congress, the architects and developers were simply paying lip service to stakeholders’ needs and desires.

What are stakeholders? In a word, these are the people who care most about the system. They are the ones with the most to gain and, conversely, the most to lose. This begs the question then, why did competent architects and developers miss the mark by not considering stakeholders’ needs? The explanation actually lies in human nature itself. Like most of us, these professionals thought, no, were sure, that they knew exactly what their clients, the stakeholders, really needed. This wasn’t malicious or egotistical; it was just human nature. Furthermore, it wasn’t the professionals who were flawed. It was the development process itself that was the problem. It didn’t include a methodology to properly court the stakeholders and incorporate their needs into the development process. It sure sounds a lot like what Congress and the administration are doing with Healthcare Reform.

Use Cases A spectacular discovery, Use Cases, revolutionized Computer Science with a most compelling and natural way to capture and convey information. As we just explored, the problem with software development was that stakeholders were not controlling what went into software systems. To deal with these issues, the Use Case methodology provides the means for stakeholder control. The beauty of the Use Case methodology is that no special training is needed to benefit from it. Some examples are worth thousands of words…















The “Use Case” approach is not new to the world of strategic healthcare planning. The Department of Health and Human Services (HHS) used this very approach in some of its efforts.What’s new here is having citizens vote on which Use Cases to include in Healthcare revision legislation.

Fortunately, the Software Development Community has resolved all these problems, mainly by institutionalizing stakeholder involvement as part of the development process. My next post will describe how to bring this experience to public policy.

The whole point of the Use Case approach is to let the stakeholders get their rightful say in what gets implemented.