That’s the question we recently asked Shahid N. Shah who, in addition to publishing Netspective Media and blogging at HealthcareGuy.com, serves as the Chairman of the Strategic Board of Advisors at the Open Source Electronic Health Record Alliance. Here’s what he shared.
The entire Internet runs on open source software (OSS), and if we used it more in healthcare and medical devices it would lead to reduced costs and increase the quality of our clinical workflows. If you ask some regulatory affairs folks in medical device companies or healthcare CIOs if they think OSS is too “dangerous” for use in safety critical systems, the most common excuse given by engineers is that the regulatory compliance folks wouldn’t allow OSS, or that the FDA would disapprove, or that there is “no support” for such software. There is plenty of evidence to the contrary, though, because the FDA hasn’t really rejected devices due solely to use of open source software. The lack of OSS use in medical device and healthcare IT circles in most cases likely stems from a lack of experience with open source in the senior executive and regulatory compliance ranks within companies. This is a summary of a quick 10 step process R&D groups could use to properly experiment with and include open source software in safety-critical systems.
1. Understand open source licensing, remove the fear of IP loss.
One common fear is that using open source will “leak” your own IP or cause IP loss. However, open source licenses allow for inclusion of open software in your device(s) without harming your own intellectual property (IP) rights or proprietary claims. There’s no need to fear that somehow if you include open source you’ll accidentally relinquish proprietary IP. If you’re not sure which licenses to use, start with the Apache Software License (ASL), Mozilla Public License (MPL) or LGPL, all of which are friendly enough to use in commercial software.
2. Understand where code is coming from and what test harnesses are included.
If you use the right license (e.g. ASL, MPL, LGPL) there’s no fear of IP loss but if you use the wrong license or library linking methodology you could accidentally end up getting into trouble. That’s why you need to keep track of precisely where you’re getting the OSS code from. Also, try and focus on incorporating OSS that already contains good test harnesses so you can prove to yourself, your QA teams, and your regulatory teams that the software works for its intended uses.
3. Connect with the developers of the OSS you’re using.
If you’re going to rely on some OSS, get in touch with the developers of those projects. Most OSS developers are quite community oriented and usually helpful; in case your senior executives, regulatory, or QA folks have questions you’ll be able to answer them easily if you’re in touch with the original developers. Also, if you need changes, some developers will likely be available for hire for making changes or helping with validation.
4. Monitor the revision control system of the open source project.
My general recommendation is that you not download binaries for OSS projects; instead, connect directly to the Subversion, Git, CVS, Mercurial, or other revision control system (RCS) the OSS project developers are using. You should get used to various RCS systems and not just the one you’re using in your own shop. It’s much easier to know precisely what lines of code, modules, etc. are changing when you’re directly connected to the RCS.
5. Create your own binaries so that your team trusts the builds.
As soon as you’re connected to the revision control system of the OSS project, build your own binaries using the existing make or build scripts. If there are no make or build scripts you should not use the OSS (if you have other choices) or you can create your own.
6. Create a process to securely sign the binaries.
When you create your own binaries you’ll want to make sure you digitally sign the binaries and ensure that your devices / gateways have firmware or other software that verifies the binaries.
7. Create your own deployment packages.
If you’re running on Windows you’ll want to create *.msi packages; on RedHat create RPMs, on Debian / Ubuntu create *.deb packages, etc. You will want to have a proper package management approach that your QA and regulatory folks can have confidence in and easily understand.
8. Create a process to test the binaries using code coverage tools.
This step could be done before or after step 6 but you’ll want to be sure you run the test harnesses with code coverage turned on; that way, you’ll know what test coverage you can achieve in the various OSS packages you’ll build. Try not to go to your regulatory folks and say “we can trust OSS package X” without some sort of real evidence – test harnesses and code coverage tools are good starts.
9. Keep an eye on changes coming in from the source and retest regularly.
Figure out how you’ll ensure that packages stay up to date and will be regularly tested (with code coverage); you might want to read an RSS feed, get regular e-mail notifications from forums, etc. Each time the code changes you probably don’t want to upgrade immediately but you’ll want to stay abreast of the updates.
10. Review your process with the compliance officers and get their buy in.
Share with your QA and regulatory folks your process early and often—they’ll have more confidence in your process when the process is documented, scripted, and easy to understand and follow.
If you do things “properly” and follow a good solid OSS integration process then business executives, technical executives, engineers, and especially compliance officers can (hopefully) be convinced that the code can be trusted. The more proprietary software we create in medical devices, the less interoperable they will be so it’s time we get our design teams folks on the OSS bandwagon.
If you enjoyed this post, be sure to request your copy of the 2016 Healthcare IT Market Report , which includes more insight from Shahid and other industry experts.