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
|Happy Birthday Linux||Aug 25, 2016|
|ContainerCon Vendors Offer Flexible Solutions for Managing All Your New Micro-VMs||Aug 24, 2016|
|Updates from LinuxCon and ContainerCon, Toronto, August 2016||Aug 23, 2016|
|NVMe over Fabrics Support Coming to the Linux 4.8 Kernel||Aug 22, 2016|
|What I Wish I’d Known When I Was an Embedded Linux Newbie||Aug 18, 2016|
|Pandas||Aug 17, 2016|
- Happy Birthday Linux
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- ContainerCon Vendors Offer Flexible Solutions for Managing All Your New Micro-VMs
- What I Wish I’d Known When I Was an Embedded Linux Newbie
- Updates from LinuxCon and ContainerCon, Toronto, August 2016
- Returning Values from Bash Functions
- NVMe over Fabrics Support Coming to the Linux 4.8 Kernel
- New Version of GParted
- All about printf
- Tech Tip: Really Simple HTTP Server with Python
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide