Google Health

This recent post from the official google blog entitled, Heath care information matters immediately caused me to reflect on my own experiences and realize a flood of ideas about how the Internet may someday help people deal with health care in some unexpected ways..

About a year and a half ago my then two-year-old son was nearly killed in an accident. We spent 8 days in the pediatric ICU and a total of a month in the hospital. Fortunately, our story ended up more positive than Adam's, but we still had our share of hiccups along the way.

Now that I think about it, I'm sure I used Google to help me look up terms like "noncommunicating hydrocephalus" at 3:00AM. I would have been completely in the dark on those nights if it wasn't for Google.

Our information problem was much more acute after we were safe and sound back at home. With nearly $200,000 in medical bills, from a dozen different providers, there was a lot of paperwork in the year following the accident.

If you've never had to deal with this kind of situation, here's how it goes:

• When you first get home from the hospital, you don't really care about bills, so you just put them in a pile. Over time, the pile grows.
  
• You get a bunch of different bills from a lot of different providers. We received bills from the hospital that had a single line item for $130,000, with a friendly note at the bottom that said, "if you'd like to pay by credit card.." We'd then receive itemized bills from the hospital contracted providers (read, the doctors themselves) that included some portion of that $130,000 worth of services, but of course there was no way to correlate them to each other.
  
• There are a whole pile of different providers involved here. Radiologists, intensivists, ambulance services, respiratory therapists, trauma surgeons, the hospital itself, infectious disease specialists, physical therapists, neurologists, etc. The doctors work in shifts, around the clock, and fortunately many of them are associated with each other such that their bills are combined. But some are not, so you may get different bills from different doctors for the same types of services on the same date!
  
• The providers bill you even before they've heard back from your insurance. Of course, the insurance company doesn't just pay off $100,000 bills immediately, so the providers keep sending you bills (that at some point begin to be labeled "overdue") even while the insurance payments are still pending.
  
• Your stay at the hospital spanned one or more of the provider's billing cycles, so you receive some bills that reflect services rendered early in your stay, and other bills that reflect services from later in your stay.
  
• The insurance company tries to figure out if there's some reason they can avoid paying up. They send you various questionnaires to determine if there's some other insurance that should pay some portion of the bills or if there's somebody they can sue. You get lots of these, and you always answer them the same way, and they send you more. Surprisingly, you get tired of continuously explain what happened over and over again.
  
• The insurance company starts sending you lots of "Explanation of Benefits (EOB)" notices. These look a lot like a bill, but they're not, and the insurance company cleverly marks them with "this is not a bill." These are supposed to explain to you what they're going to pay to the providers. Unfortunately, there's no deterministic way to correlate the EOBs to the provider statements. And by now you have multiple statements from multiple providers not all of which have the same charges, some of which overlap, and none of which are formatted or described consistently.
  
• You'd like to correlate bills to insurance payouts based on amounts and dates. But guess what, the insurance company doesn't pay the same amount you're being billed. Instead, they pay an insurance negotiated rate. They don't pay entire bills at once, so you get more bills from the providers that now have different amounts on them!
  
• Guess what? Not all of the providers have your insurance information! The ambulance company never got your insurance information--so they just bill you and you need to contact them to give them your insurance. The first hospital you went to for trauma service used your wife's old insurance card--which is no longer valid. The children's hospital you eventually ended up at distributed a lot of your more accurate insurance information to most of the providers, but not quite all of them..
  
• Eventually the insurance begins to pay the bills. But of course they get their wires crossed, and decide that some charges "weren't necessary." You're responsible for them anyway, and by the way, nobody asked you at 2:00AM if you would like to authorize a certain procedure, did they?
  
• In the end you end up paying only about $5000 out of your own pocket. This is about $2500 more than the insurance company said you'd need to pay, but in the chaos described above, how are you supposed to figure out why? You count your blessings and try to move on with life.
  

The Internet is a very loosely coupled collection of sites and services that does some things remarkably well. Go ahead and search for "noncommunicating hydrocephalus" on Google, and in a few minutes you'll learn more about the topic than you would in 8 hours of medical school. The individual information systems used by the above parties are anachronistic systems managing highly structured data that don't talk to each other except through a few dinosaur interfaces such as EDI. Somewhere in between the internet's model and the current state-of-the-art in health information management systems, there's probably an opportunity for Google or some future company like Google. I wish them the best. I just hope I never have to deal with it all again..

Top 10 Computer Books from 2006

Referenced from Andy Hunt's blog, a list of Amazon's top ten technical books from 2006. At least I have one of these (the Rails book). I'm ordering #10, on Software Estimation immediately as it is a hot topic right now on some of the SDLC project management tools we're building.

EyeOS

Speaking of taking your desktop anywhere, take a look at EyeOS

Traffic Rules

I live in a geographic area with lots of relatively low cost real estate. Thus, our streets are wide, and our intersections are well marked and orderly. I've lived in this area most of my life since I was old enough to drive.

Many years ago (for some reason I forget), I found myself driving to San Fransisco often and driving around in the "big city" where real estate was not so cheap, and the roads had much tighter physical constraints. I noticed something back then--the closer one got to the "chaos" of the inner city, the less the traffic rules constrained you, and the more one simply did whatever worked to get from point A to point B. One-way-streets aside, in heavy downtown areas, the rules pretty much go out the car window, and people tend to do what works to get where they need to go. I found the attitude towards the rules, comforting, and seemed to think that traffic moves as smooth as can be expected given the number of cars in such a tight space.

No doubt, others have had different down-town experiences, but this article on experiments eliminating traffic rules seems to validate my anecdotal evidence.

Goodby Java, Hello Mono

Regarding Infoworld's "Goodby Mono, hello Java?". It's weird that anybody would assume the reason Java hasn't been more successful as a stand-alone application framework is because of its licensing restrictions. The thought's never crossed my mind. Lots of vendors distribute Java based software and simply require that the consumer install a JRE or they bundle one with their application.

The real reason Mono's been so successful and Java's floundered is because of the chaos within the Java framework, and the lack of "turn-key" IDE/RAD environments that are on par with Visual Studio. I know that I can use the latest JDK and Eclipse to create a great application--and I can package and deploy it without much hardship to the consumer. But I've had to earn that ability over the past 10 years--and the knowledge and experience is not available to a majority of the world's developers. The Visual Studio crowd is vast, and they're armed with some pretty sophisticated tools. They've got a large community of tools, information, and support. And while I happen to find those tools repulsive, there are countless thousands of developers that are pretty darned productive with them. And Mono allows them to be just as productive while quickly and easily deploying to Linux as well as Windows.

Desktop Anywhere

One of the reasons I use a lot of Google's stuff is because it gives me a consistent view of the world, and allows me to pick up right where I left off, regardless of the computer I happen to be using.

If I'm at work, using one of several laptop computers at home, or one of my desktop machines, I can always check email, scan RSS feeds, in the same way and within the same context. I characterize this as the evolution of the ubiquitous computing concept that's been around for many years.

It's sad that the evolution of ubiquitous computing is taking so long. About 10 years ago, the state-of-the-art was actually farther along than it is today. I think of the 1990's as the "golden years" of Unix, when there were multiple vendors of both hardware and UNIX operating systems. We regularly NFS mounted our "home" directory from whatever physical workstation we happened to be using at the time, then used rc scripts to adjust for different desktop needs. The end result was that one could tune one's desktop to look and work the same, regardless of what workstation you happened to be logged in on. Your personal data was always there for you, it was just the box (and sometimes the applications installed on that box) that were different. Why in today's world of virtual desktops we can't realize a similar vision is beyond me. Even the modern Linux user seems content to VNC from one machine into another and plow through the differences in his desktop on each.


Anyway, back to Google.. Looking at the new Google Desktop 5, I see that the evolution continues. Google Desktop has an option (maybe it's been there for a long time, I don't know) to "Save my gadget content and settings so I can access them from any computer." As more of the functionality I expect from my computer migrates to on-line, web accessible, and (for right now) Google based applications, these kind of features should allow me to enjoy the same desktop--regardless of the computer.

In related news, I see that the W3C just started a draft of a Widget Specification This might further the evolution to ubiquitous computing by providing standards for widget implementations--regardless of the platform.

Catching up on Digg

When Digg first came along I found all kinds of cool things. But then Digg got too big, and one couldn't keep up with the stream of Digg posts via RSS. So I unsubscribed. Last night I decided to "catch up" by going through the Digg top posts for the year. This revealed a couple of gems. One of which is this demonstration of a physics modeling tool that combines gesture drawing, on-line whiteboard tools and the modeling software itself. Personally I could have hours of fun with this system and my kids creating our own toys..