EOF - Why We Need Hackers to Fix Health Care
My mother died five years ago of a stroke following an endoscopic procedure to remove a gallstone. The procedure perforated her duodenum, and digestive fluids leaked into her abdomen. She spent the next week in the Intensive Care Unit, fighting for her life. She was tough and lived through it, but the stroke got her a few days later.
The stroke probably was due to a blood clot, which probably formed because she was off her blood thinners. That was a medical error that might have been prevented had her gastroenterologist and her cardiologist been communicating with each other. My sister and I blame ourselves for not making sure those guys were talking. But, I also blame the hospital's IT system, which failed to keep both doctors in their shared patient's loop.
I also should have suspected the IT system of suckiness, because I brought it down myself one day while visiting Mom by using a browser on one of the nursing workstations there. I was surfing for about ten seconds when every screen in sight went blue. Shocked and concerned, I asked a nurse if this happened often. “Happens all the time”, she said. “It's a new system.” Of course, it ran on Windows.
This year, I had my own encounter with sucky systems. It started in April after I had a pulmonary embolism (a blood clot) in my right lung. While looking for the clot's possible sources, a CAT scan showed a cystic lesion on my pancreas. My gastroenterologist ordered an MRI, which showed more cysts. Radiologists said it wasn't clear if one of the cysts was communicating with the pancreatic duct, so my gastroenterologist recommended an endoscopic procedure to look up the duct and see what was going on—the same procedure that put Mom in the hospital.
The doctor told me before the procedure that there was only a 5% chance of getting pancreatitis from it. I said okay, and we went ahead with it. The next morning pancreatitis struck, and I spent the next nine days in the hospital taking no food or water while massive quantities of fluids were dripped into my veins. Pain was addressed with enough Demerol, Morphine and Dilaudid to satiate a junkie.
As I write this, I'm still recovering—and still in a state of mystery about my pancreas. The procedure did not see a cyst communicating with the duct. Neither did a second team of radiologists that viewed the same MRI. That team said I didn't need the procedure. But the word came too late, when I was already in the hospital.
One reason we couldn't get the MRI CD to the second team earlier was that we couldn't find a machine to read it. It wouldn't load on my gastroenterologist's Windows machine or on either of my Linux or my Mac machines. All I could see was a pile of Windows binaries and files.
So, although it was our error to hasten a procedure I didn't need, I also blame a system in which too much tech doesn't work, doesn't communicate with other tech, or doesn't use standard image and text file formats that any machine can read.
Among the many doctors I met in the hospital, one stood out, because he alone addressed the problems of bad data and bad communications. He said that the whole medical system is corrupted by collusion between equipment makers, software suppliers and institutional customers. The result is many closed systems, all lousy at communicating with each other. He said we need open systems, with data built around patients rather than locked inside closed silos. He liked Google Health, because at least it was trying to solve the problem from the patient's side, by making the patient the point of integration for health-care data from many different sources. (Microsoft also seems to be doing something similar with HealthVault.)
The whole matter of Personal Health Records (PHRs) is a complicated one. There are many open-oriented efforts going on there, and I hope one or more of them succeeds. Meanwhile, countless thousands of people die every year in the US alone from bad data and poor communications among health-care providers. This problem cannot be fixed from the top down, no matter how open its code.
It has to be fixed from the bottom up—by hackers and patients. Hackers need to build (or help health-care software companies build) new systems using free software and open-source code, so those systems can be improved and made more compatible on an ongoing basis. Plenty of money can be made selling systems and servicing them. You don't need closed code for that. Patients need to become platforms. Each of us needs to be able to gather, control and share our own health-care data, on our own terms—quickly, easily and securely. So services can be based on what makes each of us unique.
When I suggested this in a post on the Linux Journal Web site, some skeptical comments followed, especially from veterans of The System. But, their arguments were the same kind I heard 30 years ago against personal computing and open networking—that they were a cool idea, but that the Big Boys would never let it happen.
We know how that story turned out. I'd like the health-care story to turn out the same way. We need open-source hackers to make that happen. Preferably while I'm still alive.
Doc Searls is Senior Editor of Linux Journal and a fellow with both Berkman Center for Internet and Society at Harvard University and the Center for Information Technology and Society at the University of California, Santa Barbara.
Doc Searls is Senior Editor of Linux Journal
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Validate an E-Mail Address with PHP, the Right Way
- Technical Support Rep
- Senior Perl Developer
- UX Designer
- Introduction to MapReduce with Hadoop on Linux
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?