Solving the Right Problem

Some recent project work reminded me of an old theory of mine about software development: sometimes the hardest thing in designing a system is to understand what problem you are really trying to solve. In particular, the difference between a good system and a bad system is often the way the problem to be solved was framed and articulated to the team.

It's all too easy to race directly to the immediate issue or goal that a project is trying to accomplish; it's much harder to take a step back and get a more abstracted view of the overall problem.

In this case, we were designing a system to manage the process of filing insurance product information with state Exchanges. As we talked through the objectives, everyone was very focused on what we had to do in a few months: file a bunch of specific templates full of data with three different state Exchanges. We had a list of the 12 documents that were going to be required by one of the Exchanges, and while we hadn't received any definite information yet from the other two Exchanges we assumed their filings would be very similar.

The high-level business requirements were simple: rather than having the people doing the filings store their documents on their local PC file systems and email them around to each other, create a simple document management and workflow solution (using COTS packages, fortunately, not coding stuff from scratch.) It needed to allow users to upload the filings documents to a secure, version-controlled, and auditable location, track the state of the documents from initial draft to final submission, and route them to other users for steps in the process like data validation and approval.

When the first screen prototypes came back from the team, they showed a user interface with one tab for each of the documents to be submitted--prescription drug template, service area template, etc. On each tab were specific controls  to let you upload the associated document and drop downs to change its state. You could create additional "certification filings", but each one would have the same hardwired set of tabs.

"Let's back up a minute," I said. The design would have worked fine for the first filing for that one particular Exchange, but it wouldn't work for the other Exchanges unless they had the exact same documents required to be submitted. And, if next year one of the Exchanges decided they needed to remove one type of document and instead have insurance companies submit, say, a new report on drug utilization statistics, well, we'd have to spin up a new project and have developers go in and revise the system.

What we really needed to create was not a system to manage product filings for three specific Exchanges but rather a submission management system that allows users to manage a definable and changing set of documents to any sort of external agency. We talked through it and got everyone in agreement and off the team went.

The end design was for a very flexible system that allow end users to define "submission packages" and create within them any number of documents. An Exchange could change their submission requirements all they want  in the future and the same system can be used to manage the filings without needing a single modification, and it could be used to manage any number of other regulatory filings, too.

In the end, it all came down to the way the problem was framed. Once we stopped talking about the immediate need--filing those 12 documents with this particular state Exchange--and instead discussed the solution in terms of the bigger picture need--a system to manage a wide range of document filings with regulators--we got the proper results.

If you have good design and development teams, they can generally figure out how to solve any problem you throw there way. You just have to make sure you turn their talents loose on the right problem.

The Affordable Care Act? Is That Still a Thing?

Two weeks ago, the Kaiser Family Foundation published poll results that provide bracing lessons for anyone currently working to roll out Health Insurance Exchange and other Affordable Care Act (ACA) related business changes. That theme is simple: don't assume any of your constituents understand the changes that are coming down the pike.

The most telling statistic for me: 42% of respondents were not even aware of the current status of the ACA law, which means they probably don't even know that there are significant changes in the health insurance world coming up this fall when open enrollment begins.

It immediately suggests a couple of key principles for how insurance companies, brokers, and employers move forward into their post-ACA business.

1. Education. Education. Education. View every constituent contact as an opportunity to engage and educate as to what's coming down the road.

2. Explain everything. When you've been in the trenches of implementing healthcare reform changes, the alphabet soup of acronyms becomes an insiders shorthand: EHB, APTC, CSR, even ACA itself. In any external communications, spell it out and explain what it is in the simple language possible. The changes themselves are hard enough to make sense of: don't let language make it harder.

3. Keep it simple. When trying to decide between different possible approaches or designs, always start with this question: what will make this easiest on our brokers, our employers, and our members? 

4. Provide continuity: There is a temptation when contemplating changes as broad as the ones that ACA-features like Exchanges and member-level rating to take that opportunity to overhaul the whole way you do business. But, there's a danger in changing too much too fast. If you can keep your interactions, your communications, and processes as similar as possible to the way they currently function, that will help ease your constituents into the new post-ACA way of doing things. 

And, don't forget the network effect. The largest single source that Kaiser's poll respondents cited as to where they get their information about health care reform law is from conversations with friends and family. If you can effectively reach those people you do make contact with, they'll help spread the word to everyone else.