Open source electronic health records for all

No readers like this yet.
open source button on keyboard
Image by:

Opensource.com

A great deal of excitement is in the air, anticipating OSCON 2012.

At the healthcare track, this year we will be sharing the latest news and upcoming plans for OSEHRA, the Open Source Electronic Health Records Agent.

This young organization was set up last year by the US Department of Veterans Affairs (VA) as:

"...an important milestone on its joint path with the Department of Defense (DoD) to create a single electronic health record [EHR] system for service members and veterans."

OSEHRA's mission is to:

"facilitate, through the use of the best practices in open source software development, the improvement and maintenance of EHR information systems. These systems will be freely available for all medical beneficiaries"

In our talk, OSEHRA - Building an Open Source EHR for All, we will summarize the many things that have happened in the first year of this endeavor, and will also describe plans for the second year of activities.

One of the most exciting events of OSEHRA's first year was the VA's contribution of:  "...its current EHR, known as VistA (Veterans Integrated System Technology Architecture), to seed the effort. OSEHRA will oversee the community of EHR users, developers, and service providers that will deploy, use, and enhance the EHR software."

More about VistA can be found in the VistA Monograph, and recent opensource.com post.

In our OSCON talk, we will also discuss the concept of critical mass in open source communities and the importance of growing the community size to the level where it becomes self-sustaining.

Our estimation, based on our observation of several large scale software projects, in particular the Linux Kernel, is that an open source project should have about one developer per every one thousand lines of code, to ensure that all the needs of the project are taken care of.

This builds on the observation that Clay Shirky makes in his book Cognitive Surplus:

"...with a large enough crowd,
unpredictable events becomes predictable"

We apply this dictum to open source software communities as:

Given a large enough community:

All bugs will be found,
All found bugs will be fixed,
All needed features will be implemented, and
All this will happen on a regular schedule.

An our corollary is also that:

If there is uncertainty in an open source community,
(if we don't know where the bugs are,
or we don't know who would fix them)
that is probably an indication that the community
is not large enough for the project yet,
and that the current community members
are underpowered, and overworked.

The solution is of course:

Recruiting new members

Which also implies:

  • Working hard on training materials
  • Reducing barriers of entry
  • Hosting events such as hackathons that welcome newcomers
  • Simplifying the software deployment and development infrastructure

Along these lines, in our OSCON presentation we will be talking about our initiatives to:

  • Teach M to the next generation of developers
  • Raise awareness about the powerful NoSQL nature of M as a language for healthcare applications
  • Facilitate widespread access to M and VistA by including it in popular Linux distributions

Please join us at OSCON. Bring your suggestions on how to better pursue these goals.

Because when one is Building an open source EHR for all, one also needs everybody.

Tags
Health
Databases
OSCON
Luis Ibanez
User profile image.
Luis Ibáñez works as Senior Software Engineer at Google Inc in Chicago.
More about me

5 Comments

Avatar
Greg P | July 13, 2012
No readers like this yet.

Speaking as someone in medicine, not in the VA system, but having reviewed records from the VA system, I don't see anything magical about the Vista implementation. On the receiving end it's more than a bit disorganized.

The important feature which EHR need to have is portability. To that end, what is most needed is an open format for the transmission of information, yet at the same time there needs to be a high level of privacy protection.

It's very important that health care data remain in the form of data. So much of what is out there is transformed into some image (e.g. a fax) which blocks the incorporation of its information so that it can be collated, organized, and searched like data. Most of what we have about our patients begins as data: text, numerical, images, but for various reasons it is transformed to an opaque image of itself.

Avatar
Chris T. | July 17, 2012
No readers like this yet.

Not to be snarky about it, but maybe all the out of work COBOL programmers could be retrained to learn M?

Seriously, though. This is an exciting event and important step toward an open source EHR. However, I can't help but feel its going to struggle sorely on the manpower front. Based on related posts, it seems M might be well known inside health institutions but it is not clear to me it's well known OUTSIDE of them.

Is it worth educating new developers on M (who will no doubt write poor code for several years)? Or, perhaps it's a more worthy goal to rewrite the code base into a more OSS mainstream language. (and no, I won't define that for you :)

AND, as Greg mentioned, ensure portable data standards, etc.

Avatar
Luis Ibanez | July 21, 2012
No readers like this yet.

Chris,

I share your concern regarding the need for gathering the large number of developers that are needed in this community. The M language is not well known outside of healthcare, and we are working towards changing that balance through education and training initiatives.

For developers who are looking for meaningful and motivating work, the option of writing open source software for being used in hospitals is quite appealing. As open source developers we gravitate towards projects that matter and that have a deeper impact. Young developers should become aware that in addition to the option of writing yet-another-mobile-app, they can also put their time, effort and passion on writing code that helps millions of patients in hundreds of hospitals.

The fact that new developers would write sub-optimal code in their first years of training is not a reason for not training them. Such situation will happen with any language,... and with any skill for that matter. You may have read "Outliers" by Malcolm Gladwell, and the argument that one needs 10,000 hours of practice to become expert at anything (from Karate, to Jockey, to Football, to programming). The way to address this concern is to generate opportunities for learning, for example by building up a system of mentorships combined with online code reviews, where expert developers guide younger developers. Along those lines, we have been using Gerrit (originally from the Android project) for performing code reviews, and are very satisfied with how it transforms the dynamics of the community, as far as training goes.

Regarding the popularization of M, we are now working on including GT.M (the open source M platform) for the Debian and Fedora Linux distributions, so it is easily available at the fingertips of any curious bystander. The next step is to make available online tutorials (such as this one: http://www.opensourcesoftwarepractice.org/M-Tutorial/) that give new developers a quick view of the language.

It is worth pointing out that M is focused on the database side of a healthcare information system. We will still need many other languages and technologies to deal with the ancillary services, such as web access and mobile devices. That said, M is not going anywhere any time soon. It is still the standard language of healthcare databases, and the only one that was designed and implemented for that specific purpose. The majority of large healthcare information systems are written in M, this includes the proprietary offering such as Epic, Meditech and GE Healthcare/Centricity, as well as the open ones such as VistA at the VA, CHCS at the Department of Defense, and RPMS at the Indian Health Service. This is millions of lines of code, servicing millions of patients,... an enormous job market in a sector of the economy where we invest 18% of GDP today.

Avatar
Chris T. | July 17, 2012
No readers like this yet.

Not to be snarky about it, but maybe all the out of work COBOL programmers could be retrained to learn M?

Seriously, though. This is an exciting event and important step toward an open source EHR. However, I can't help but feel its going to struggle sorely on the manpower front. Based on related posts, it seems M might be well known inside health institutions but it is not clear to me it's well known OUTSIDE of them.

Is it worth educating new developers on M (who will no doubt write poor code for several years)? Or, perhaps it's a more worthy goal to rewrite the code base into a more OSS mainstream language. (and no, I won't define that for you :)

AND, as Greg mentioned, ensure portable data standards, etc.

Avatar
maguro_01 | July 19, 2012
No readers like this yet.

It was, if memory serves, a Cleveland Clinic study that showed that family trees with health histories were a better predictor of a person's health future than present state of the art DNA techniques. That may be true for a long time since the histories contain environmental information that DNA cannot.

Universal electronic health records probably contain the SS#'s of parents and a new child easily permitting the construction of such trees. They might be made over time as any new contact with the medical care system is made, especially through obstetrics or a pediatrician's care. If insurance companies are installing computer centers and Case Management software for US operations offshore then any privacy or data mining enforcement will be problematic. If insurance companies could set rates to largely escape the insurance business naturally they would.

Personally I don't see a solution but Single Payer but that question is outside the scope of your project of course. Net, the project is a fine contribution. Anything that aids the medical system in communications is very positive - a surprising number of people die every year from incompatible medications provided by different doctors and organizations.

Related Content

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.