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
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- LiveCode Ltd.'s LiveCode
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