Not "just a website"

Julian days and Healthcare.gov

By Tom Sgouros in Rhode Island’s Future - See more at: http://www.rifuture.org/julian-days-and-healthcare-gov.html#sthash.5z5hrnfN.dpuf

There is a great deal of gnashing of teeth going on about healthcare.gov, the Obamacare portal for people who live in a state that refused to create its own exchange.  I’m sure that some of the well-reported woes of the web site are deserved, but it seems fairly obvious that a large number of the commenters, and the complainers, have little idea what they are talking about.

I have no direct knowledge of the software behind healthcare.gov, neither of the team behind it, or the technologies they are using.  But I do have some expertise in web sites, software, and data management, acquired over 28 years consulting in the software industry at many different companies, and there are some things that are being said that are just plain wrong.

To begin with, the health care exchange is not “just” a web site.  


It is a system that has to communicate data between lots of different insurance company databases very quickly. You can’t get a quote from a dozen different insurance companies to appear in any other way. This means that a dozen different insurance company databases have to be equipped to provide that kind of real-time response to a query.

To anyone who has spent time thinking about data, this is already the knell of trouble.  To anyone who is counting how many insurance companies in how many states this system must deal with, this sounds much worse.

First, a tale.  Back in the early days of working with data, I ran across a measure of time you frequently see in science data, the “Julian” day.  The idea here is that dealing with months and years is kind of a pain when you want to draw a graph, so let’s just number the days from the first year and ignore the months and years, and things will be much simpler.  It’s not a terrible idea, until you want to exchange your data with someone else.

At that point, you discover that you were counting days from January 1, in the year 1, and they were counting them from the year zero.  You point out that there wasn’t a year zero, but they say it makes the math work out better. Or you discover that you were using the days as a measure, so that day 2.5 means noon of the third day, whereas they said that day 2 was the second day and day 2.5 is nonsense.  

Or you discover that though it says Julian days, they were counting leap years on the Gregorian calendar so your counts are two weeks off theirs.  Or you discover that you were using local time, and they were using Greenwich Time. Or you find yourself looking at satellite data, where measurements can be taken from two or three different days within any 24-hour period.

I ran across this issue because for a number of years I contributed to a science data project, meant to normalize access to a whole lot of oceanographic and other earth science data.  Even beyond questions of data units, there were structural problems with interoperability, too.

There were two widely-used data sources in that project that, given the constraints involved, turned out to be impossible to reconcile.  Which is astonishing, since they were data measuring more or less the same things about the oceans.  But one of them had been created by scientists who believed the data ought to be accessed a small bite at a time while the other had been created by scientists who believed you should get big chunks at a time.  

For more cartoons by Bob Englehart, click here.

These guys had made design decisions early on that made working together utterly impossible, and with the best will in the world, the two could not be reconciled to work in real time without one team essentially scrapping its original design and putting in a lot of work while the other team sat around and waited for them.  Try as they might, there was no middle ground because neither one wanted to give up their design.

These are some of the lessons I learned:

1. In data, even when people are talking about the same thing, they’re not necessarily talking about the same thing.
2. Even when people want to work together, design decisions made in the distant past might make it difficult.  
3. When two teams have to choose between their approaches, there is very seldom middle ground.  One team gets to do all the work to convert to the other’s approach, while the other team sits around and makes snide comments.
4. No engineer thinks another engineer’s approach to a problem is worth a dime. 

Now think about trying to resolve problems like this among a few hundred databases run by insurance companies who are not necessarily going to be the most cooperative folks out there.  Think about it: you’re an insurance company IT executive and the healthcare.gov folks ask you if you might change the format of your data reporting to coordinate with the other companies in your state.  Your immediate response?  Why should we change and not them?  That’s more work for us and besides our system was designed better.

So not only are the healthcare.gov folks working against a few hundred different design decisions, but they’re also counting on having been able to anticipate all the data entry errors that might be lurking in hundreds of databases out there, and hoping that everyone has decent support staff, too.  

On top of that, healthcare.gov also has to interact with a handful of databases from other government departments, so there are similar problems on that end.  For those who sneer that the private sector would have gotten it right, let me tell you another time about my work on the airline reservation system that never got built, or the credit card database whose books didn’t balance, or the speech recognition system that couldn’t distinguish between “pizza” and “tractor.” 

In other words, big systems are complicated.  It is a scandal that the federal exchange isn’t ready yet, but no one should underestimate the social, technical, and management challenges faced by the team putting it together.  When you hear someone who says healthcare.gov is “just” a web site, you are hearing someone who does not care to understand the problem.

The good news is that there is little reason to doubt that most of the problems will find workarounds soon.  The issues are difficult, but the need is there to resolve them, and they will be resolved.  By this time next year, the glitches will be a memory, and it often seems that is what some of the critics fear most.

Tom Sgouros is a freelance engineer, policy analyst, and writer, easing back into blogging after a leave to work on a book about finance (stay tuned!). Reach him at ripr@whatcheer.net.