“I am a firm believer in the people. If given the truth, they can be depended upon to meet any national crisis. The great point is to bring them the real facts.”
This may bring a chuckle given our most recent political discourse, but it’s a welcome reminder that most likely we are not getting the facts that we need, and it still rings true. We can make the right decisions if we’re given real facts. It is true for health care, for prices, for data, for code, for physician ratings and innumerable other private, cloistered and opaque parts of our system. The problem is facts are often hard to come by, or heavily disguised in the noise, but there is a solution.
The quote from Lincoln above leads off the first chapter of a book that’s both freely available (appropriately for the subject matter) and a must-read for those who care about health care, innovation and fixing our broken civic systems. Code for America’s new book, Beyond Transparency, is not focused on health care per se, but on open data in general and what’s been done with it. As I mentioned in my post on Steven Brill’s Bitter Pill article on the lack of pricing transparency, you can’t have a functional marketplace, healthcare or otherwise, without it.
Transparency Changes Relationships
Data enables decisions. That’s why we collect personal health information, of course, to make health decisions, but there’s something else that happens in a transparent environment: people begin to understand why the choices are what they are, and why certain decisions are made.
In one example from Beyond Transparency, telling the story of how the Boston Public Schools successfully released registration information that allowed parents to use it to register for schools in a program called “DiscoverBPS.org”, Joel Mahoney, a former Code for America fellow who created the site, says the most important feedback on the program was unexpected. According to Mahoney, Superintendent Carol Johnson said that DiscoverBPS
“had changed the way [The School Department] relates to parents.”
Mahoney goes on to say that, “In thinking about the goals for Code for America — Improving citizen engagement by making services more open, efficient and participatory — I can’t think of much higher praise.”
In health care we also need better engagement, improved relationships between people and the system that is supposed to serve them, and more transparency.
Health Insurance Exchanges (HIX) as a Lesson in Transparency
Insurance exchanges (when working) represent a big push toward a functional marketplace enabled by transparency in health insurance pricing. Most folks will know how much coverage they can get and how much it will cost, at least they should. The idea is that this kind of mechanism will push down prices and improve quality, “It’s a free market!”, enabled by choice and information.
Ironically for a site dedicated to one kind of transparency, the launch of healthcare.gov has likely been hampered by a lack of transparency in the design process.
There’s no shortage of advice on fixing the exchanges. Everyone is talking about the problems with healthcare.gov, inevitably focusing on the design and the poor execution that has ensued. There’s plenty of armchair quarterbacking on the three-legged stool of price, scope and timeframe of the system (A good designer will always lean on reducing scope, with time and price usually being less flexible, but not so much in this case).
The lack of access and ability has, of course, strongly impacted citizens relationship with the system that was meant to serve them. News programs talk about the “lack of trust” now for the entire ACA. That may be overblown given the six-month enrollment period, but things will need to improve quickly to improve public confidence. In essence, the timeframe has now been extended, and I suspect the scope and price will now change as well. Remember when new Google products were in “beta” for years?
Software is usually an opaque process for the most part (but it doesn’t have to be). It’s not like building a skyscraper. Historically, in a closed environment, outside observers couldn’t watch it go up, or even see a model ahead of time. “Black Box” development: you don’t see what you have until it’s done. It’s also fundamentally less predictable and requirements evolve as the project moves forward.
The key to successful software projects now is to let your users see the process a little more closely, to open it up, to make it a little more transparent, to see the skyscraper being built, and that’s why UX and open source initiatives more often than not reduce the risk of projects. Users can direct what the finished project will look like and get a handle on what it’s supposed to do. It sure seems like this kind of testing wasn’t done on healthcare.gov.
Alternatives to healthcare.gov
Health 2.0 Co-Founder Matthew Holt suggests moving people over to private exchanges, there are at least a few well-designed options out there. Holt says,
“Quietly last summer two private online insurance brokers, eHealth which runs the eHealthInsurance.com site, and GetInsured, struck deals with HHS which allowed them to enroll individuals in plans that qualify for the mandate under the ACA, and more importantly, connect with the ‘Health Exchange Data Hub’ that figures out whether the enrollee qualifies for a subsidy (theoretically by connecting to the IRS).”
In fact, Healthcare.gov doesn’t have to work. There is already at least one working alternative available. It’s understandable that the government doesn’t “pick winners,” but there should at least be a link toward “private exchange options” on the government site. Do quick use testing. Do users want this information? If so, put it up and point to “what the people wanted.”
You have to wonder (but maybe not for very long) why the right isn’t talking about these private alternatives in all the red states that have been pushed onto the Federal Exchange.
JD Kleinke also believes Healthcare.com (rather than .gov) would have worked better, because they know how to design consumer-focused products, government contractors, not so much. According to Kleinke,
“If there is one product design principle known to anyone who has ever worked for an e-commerce company, people browse before they buy — and many if not most of them are just browsing. The electronic traffic jams created by this terrible little design flaw multiply logarithmically.”
Alternatives aside, the government site likely could have worked better if the design process were more open, and it would have been more consistent with the overall goal of the site: transparency!
Transparent by Design
Designing transparency may sound like an oxymoron, how can you design what is open? You can design the openness to be relevant to decision making, and keep the whole design process open, rather than trying to opaquely nudge people in one direction or another, or missing how they’ll make decisions altogether.
So, designing for transparency requires a few steps for a few types of openness: open information, open architecture/design and open processes.
- Open up data relevant to a decision.
- Design the flow of data, the choice architecture, and open it to users during development.
- Be transparent about how the data is presented and what choices were made to present it that way.
The national exchanges haven’t done a very good job of designing the system for a couple of reasons that this armchair quarterback can see.
- Pricing and plan information is not readily available nor usefully presented either inside or outside the Federal Exchange system, you must go in and do a lengthy registration process first, as Kleinke and other have pointed out. This gets directly in the way of usability and the reason people come to the site.
- This is a design flaw likely caused by not enough user testing done to see how real people might interact (or more appropriately, fail to interact) with the system. There could be many reasons for this, time, budget, political or philosophical, but user experience design has largely taught us that software based on user experience testing is less expensive, faster and more highly adopted than without such testing. Any experienced Web developer can tell you to do the quickest possible data entry to get folks registered if that’s the goal, then move on to give them the information they want. Once you have contact info, you can always continue the process at a more convenient time. Otherwise, you’ll lose them, even if they desperately want your product.
- Focus the interface on the decision and action to be done. What users want on the exchange is a decision on which plan to use, and that should be the fundamental focus of the site, helping people make that decision as quickly and effectively as possible. Ever been on a conference call that’s gone adrift, wondering, “why is this person talking about this, how do did we get here?” That’s the same problem IT systems have when they are not focused on getting to a decision and an action.
Opening up the process may be the easiest way to get the healthcare.gov there. Invite input, make it open. Openness affords the opportunity to build trust and improve the relationship with all parties.
According to Business Week (must-read article on how transparency could have saved the day, and worked in the early stages at healthcare.gov):
“The government has an advantage over typical open-source projects. People, including programmers, are intrinsically interested in what it’s doing, often because their lives are affected directly. If it wanted to, the U.S. could tap an army of interested coders ready to support official efforts.”
And let’s face it, some of the more popular things Uncle Sam has done, like data.gov, are based on the principles of openness and transparency. The programs that are the most upsetting and problematic are the ones bathed in secrecy, see NSA.
If we want popular programs for happy citizens, move toward transparency and openness. Civic transparency beats civic conspiracy.