Free EMR Newsletter Want to receive the latest news on EMR, Meaningful Use, ARRA and Healthcare IT sent straight to your email? Join thousands of healthcare pros who subscribe to EMR and EHR for FREE!

Communities Help Open Source Electronic Health Records Thrive (Part 2 of 3: OSEHRA)

Posted on December 9, 2014 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site (http://oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

The first article of this series tried to convince you that community is important, and perhaps even the secret weapon behind open source software. Some open source project leaders understand this better than others, so a range of approaches to community has been developed.

In this article I’ll jump right in on the most critical open source project in health care–the famous VistA electronic health record–while saving some other impressive, although less well known, projects for the final article in the series.

Many open source projects in health IT don’t try to build communities. They feel that they put out useful software and they hope people use it–but they don’t do the work that, for instance, attendees at Community Leadership Summits have put in to make sure they make community members full-fledged partners in their work.

Brady Mathis, a health IT developer, discovered this problem when he became an enthusiastic adopter of the Tolven EHR. He told me that the project leaders seemed to lack a focus on community–a lapse all too easy to observe across many health IT projects. Specifically, he observed little responsiveness on forums, and when his firm offered back code improvements, he found no plan for developer contributions and guarded interest from the project team. However, he remains an enthusiastic support of Tolven, as one can see in a recent article he wrote, and he hopes to help it develop more involvement by its community.

The most famous open source EHR is VistA, and it has been widely adopted around the world (notably in Norway and Jordan) but has not enjoyed the penetration one would expect from such a mature product in the United States. As we saw in my previous article, the state of community around VistA may be implicated.

VistA has one of the most unusual histories of any open source project. As documented in Phillip Longman’s book, Best Care Anywhere, its primeval development was a famously grass-roots efforts by doctors and IT experts in the Veterans Administrations (now the Department of Veterans Affairs). VistA ultimately was accepted by VA management and recognized as a public resource that should be shared. Citing its code as public domain, the VA “threw it over the wall” (a phrase I have heard from VistA supporters) and continued to maintain it internally while having minimal contact with people outside.

A number of projects grew up around VistA, hoping to turn its illustrious success within the VA into an open source miracle in the rest of the globe. And indeed, the true community effort was the WorldVistA project. Several companies also grew up around VistA, two of whom I interviewed for a previous article about open source EHR projects.

All of these projects have survived, but none have broken through to the kind of success that VistA would seem to deserve in the swelling EHR market created by Meaningful Use. There could be many reasons for this inherent in VistA software. But I can’t find a technical reason. A basis in MUMPS, which makes VistA harder to understand, has not stopped companies such as Epic and InterSystems from reaching big adoption. Furthermore, the functions that the VA didn’t see as necessary (such as support for pediatricians) could be added by others.

Roger Maduro of Open Health News told me that licensing was a hurdle to pulling together a VistA community. As mentioned already, VistA itself is in the public domain. The WorldVistA team put their version under the GNU Public License (GPL), which has worked well for Linux and many other free software projects. But other GPL projects use programming languages that allow commercial projects to be built on top of a free software base, but the MUMPS language underlying VistA does not allow that.

The ungainly relationship between the VA and the putative community thus becomes an obvious candidate for improvement. And in 2011, the VA took decisive action in that area.

The VA had observed the success of many open source communities, notably the Apache web server, a project created totally by a committed community. Web servers are some of the most important software in the world (being the means by which people read this article and millions of other sites), and Apache has been the leader in this area for many years.

It so happens that one of the Apache leaders, Brian Behlendorf, also led one of the key open source projects promoted by the US government in health care, the CONNECT project for health information exchange. The VA consulted with Brian and others to develop an audacious plan for creating a healthy open source community out of the disparate stakeholders in VistA. The result in 2011 was the Open Source Electronic Health Record Alliance (OSEHRA).

OSEHRA has learned the lessons of successful community-building from other open source projects and has pursued them doggedly. They solicit input from users as far afield as Jordan and India, major users of VistA software. So far, these foreign collaborators have not returned changes. Culture change is hard, especially across cultures!

In an interview with Seong K. Mun, President and CEO of OSEHRA, I learned that it uses regular summits to develop “two-way conversations.” One success is contributions to a fundamental module called Fileman. The current version (20.2) was developed by a community over two-year period, with up to 20 people participating in discussions. The WorldVistA team reportedly feels sidelined by OSEHRA, but a fresh approach was needed.

In particular, OSHERA knew they had to get rid of the proprietary variants created over time by the companies that market VistA software. They needed one, consummately unified version of VistA across the VA and all outside users. As suggested by my earlier article, they are inspiring vendors to contribute code back to this harmonizing project.

However, when VistA felt it needed to do a major refactoring of VistA, it did not ask the community to step up, but hired a consulting firm. The sense I got from VistA supporters was that this job was too big for the current community community to take on. I suspect that, in particular, it required MUMPS skills the community didn’t have.

It’s hard to decide whether technical upgrades or community upgrades are harder. OSEHRA is dealing with both, and with notable success. My next article will cover some other open source projects dealing with communities.

Open Source Electronic Health Records: Will They Support Clinical Data Needs of the Future? (Part 2 of 2)

Posted on November 18, 2014 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site (http://oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

The first part of this article provided a view of the current data needs in health care and asked whether open source electronic health records could solve those needs. I’ll pick up here with a look at how some open source products deal with the two main requirements I identified: interoperability and analytics.

Interoperability, in health care as in other areas of software, is supported better by open source products than by proprietary ones. The problem with interoperability is that it takes two to tango, and as long as standards remain in a fuzzy state, no one can promise in isolation to be interoperable.

The established standard for exchanging data is the C-CDA, but a careful examination of real-life C-CDA documents showed numerous incompatibilities, some left open by the ambiguous definition of the standard and others introduced by flawed implementations. Blue Button, invented by the Department of Veterans Affairs, is a simpler standard with much promise, but is also imperfectly specified.

Deanne Clark, vxVistA Program Manager at DSS, Inc., told me that VistA supports the C-CDA. The open source Mirth HIE software, which I have covered before, is used by vxVistA, OpenVista (the MedSphere VistA offering), and Tolven. Proprietary health exchange products are also used by many VistA customers.

Things may get better if vendors adopt an emerging HL7 standard called FHIR, as I suggested in an earlier article, which may also enable the incorporation of patient-generated data into EHRs. OpenMRS is one open source EHR that has started work on FHIR support.

Tolven illustrates how open source enables interoperability. According to lead developer Tom Jones, Tolven was always designed around care coordination, which is not the focus of proprietary EHRs. He sees no distinction between electronic health records and health information exchange (HIE), which most of the health IT field views as separate functions and products.

From its very start in 2006, Tolven was designed around helping to form a caring community. This proved useful four years later with the release of Meaningful Use requirements, which featured interoperability. APIs allow the easy development of third-party applications. Tovlen was also designed with the rights of the patient to control information flow in mind, although not all implementations respect this decision by putting data directly in the hands of the patient.

In addition to formats that other EHRs can recognize, data exchange is necessary for interoperability. One solution is an API such as FHIR. Another is a protocol for sending and receiving documents. Direct is the leading standard, and has been embraced by open source projects such as OpenEMR.

The second requirement I looked at, support for analytics, is best met by opening a platform to third parties. This assumes interoperability. To combine analytics from different organizations, a program must be able to access data through application programming interfaces (APIs). The open API is the natural complement of open source, handing power over data to outsiders who write programs accessing that data. (Normal access precautions can still be preserved through security keys.)

VistA appears to be the EHR with the most support for analytics, at least in the open source space. Edmund Billings, MD, CMO of MedSphere, pointed out that VistA’s internal interfaces (known as remote procedure calls, a slightly old-fashioned but common computer term for distributed programming) are totally exposed to other developers because the code is open source. VistA’s remote procedure calls are the basis for numerous current projects to create APIs for various languages. Some are RESTful, which supports the most popular current form of distributed programming, while others support older standards widely known as service-oriented architectures (SOA).

An example of the innovation provided by this software evolution is the mobile apps being built by Agilex on VistA. Seong K. Mun, President and CEO of OSEHRA, says that it now supports hundreds of mobile apps.

MedSphere builds commercial applications that plug into its version of Vista. These include multidisciplinary treatment planning tools, flow sheets, and mobile rounding tools so doctor can access information on the floor. MedSphere is also working with analytic groups to access both structured and unstructured information from the EHR.

DSS also adds value to VistA. Clark said that VistA’s native tools are useful for basic statistics, such as how many progress notes have not been signed in a timely fashion. An SQL interface has been in VistA for a long time, DSS’s enhancements include a graphical interface, a hook for Jaspersoft, which is an open source business intelligence tool, and a real-time search tool that spiders through text data throughout all elements of a patient’s chart and brings to the surface conditions that might otherwise be overlooked.

MedSphere and DSS also joined the historical OSEHRA effort to unify the code base across all VistA offerings, from both Veterans Affairs and commercial vendors. MedSphere has added major contributions to Fileman, a central part of VistA. DSS has contributed all its VistA changes to OSEHRA, including the search tool mentioned earlier.

OpenMRS contributor Suranga Kasthurirathne told me that an OpenMRS module exposes its data to DHIS 2, an open source analytics tool supporting visualizations and other powerful features.

I would suggest to the developers of open source health tools that they increase their emphasis on the information tools that industry observers predict are going to be central to healthcare. An open architecture can make it easy to solicit community contributions, and the advances made in these areas can be selling points along with the low cost and easy customizability of the software.