Do you feel your electronic health record (EHR) is heaven or hell? The vast majority of clinicians–and many patients, too, who interact with the EHR through a web portal–see it as the latter. In this article, I’ll describe an EHR heaven and how free and open source software can contribute to it. But first an old joke (which I have adapted slightly).
A salesman for an EHR vendor dies and goes before the Pearly Gates. Saint Peter asks him, “Would you like to go to heaven or hell?”
Surprised, the salesman says, “I didn’t know I had a choice.”
Saint Peter suggests, “How about this. We’ll show you heaven and hell, and then you can decide.”
“Sounds fair,” says the EHR salesman.
First they take him to heaven. People wearing white robes are strumming harps and singing hymns, and it goes on for a long time, till they take him away.
Next they take him to hell. And it’s really cool! People are clinking wine glasses together and chatting about amusing topics around the pool.
When the EHR salesman gets back to the Pearly Gates, he says to Saint Peter, “You know, this sounds really strange, but I choose hell.”
Immediately comes a clap of thunder. The salesman is in a fiery pit being prodded with pitchforks by dreadful demons.
“Wait!” he cries out. “This is not the hell I saw!”
One of the demons answers, “They must have shown you the demo.”
Most hospitals and clinicians are currently in EHR hell–one they have freely chosen, and one paid for partly by government Meaningful Use reimbursements. So we all know what EHR hell look like. What would EHR heaven be? And how does free and open source software enable it? The following sections of this article list the traits I think clinicians would like to see.
Interfaces could be easily replaced and customized
The greatest achievement of the open source movement, in my opinion, has been to strike an ideal balance between “let a hundred flowers bloom” experimentation and choosing the best option to advance the field. A healthy open source project encourages branching, which lets any individual or team with the required expertise change a product to their heart’s content. Users can then try out different versions, and a central committee vets the changes to decide which version is most robust.
Furthermore, modularization on various levels (programming modules, hooks, compile-time options, configuration tools) allows multiple versions to co-exist, each user choosing the options right for their environment. Open source software tends to be modular for several reasons, notably because it is developed by many different individuals and teams who want control over their small parts of the system.
With easy customization, a hospital or clinic can mandate that certain items be highlighted and that safe workflow rules be followed when entering or retrieving data. But the institution can also offer leeway for individual clinicians and patients to arrange a dashboard, color scheme, or other aspect of the environment to their liking.
Many of the enablers for this kind of agile, user-friendly programming are technical. Modularity is built into programming languages, while branching is standard in version control systems. So why can’t proprietary vendors do what open source communities routinely do? A few actually do, but most are constrained in ways that prevent such flexibility, especially in electronic health records:
- Most vendors are dragging out the lifetime of nearly 40-year old technology, with brittle languages and tools that put insurmountable barriers in the way of agile work styles. They are also stuck with monolithic systems instead of modular ones.
- The vendors’ business model depends on this monolithic control. To unbundle components, allow mix-and-match installations, and allow third parties to plug in new features would challenge the prices they charge.
- The vendors are fundamentally unprepared for empowered users. They may vet features with clinically trained consultants and do market research, but handling power over the system to users is not in their DNA.
Data could be exchanged in a standard format without complex transformations
Data sharing is the lifeblood of modern computing; you can’t get much done on a single computer anymore. Data sharing lies behind new technologies ranging from the Internet of Things to real-time ad generation (the reason you’ll see a link to an article about “Fourteen celebrities who passed out drunk in public” when you’re trying to read a serious article about health IT). But it’s so rare in health care–where it’s uniquely known as “interoperability”–that every year, reformers call it the most critical goal for health IT, and the Office of the National Coordinator has repeatedly narrowed its Meaningful Use and related criteria to emphasize interoperability.
Open source software can share data with other systems as a matter of course. Data formats are simple, often text-based, and defined in the code in easy-to-find ways. Open source programmers, freed from the pressures on proprietary developers to reinvent wheels and set themselves apart from competitors, like to copy existing data formats. As a stark example of open source’s advantages, consider the most recent version of the Open Document Format, used by LibreOffice and other office suites. It defines an entire office suite in 104 pages. How big is the standards document for the Microsoft OOXML format, offering roughly equivalent functionality? Currently, 6,755 pages–and many observers say even that is incomplete. In short, open source is consistently the right choice for data exchange.
What would the adoption of open source do to improve health care, given that it would solve the interoperability problem? Records could be stored in the cloud–hopefully under patient control–and released to any facility treating the patient. Research would blossom, and researchers could share data as allowed by patients. Analytical services could be plugged in to produce new insights about disease and treatment from the records of millions of people. Perhaps interoperability could also contribute to solving the notorious patient matching problem–but that’s a complicated issue that I have discussed elsewhere, touching on privacy issues and user control outside the scope of this article.
The next segment of this article will list three more benefits of free and open source software, along with an assessment of its current and future prospects.