A great deal of excitement is in the air, anticipating OSCON 2012.
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."
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.
"...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:
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.