Originally Published IVDT July/August 2009
Laboratory Automation
Applying open source software to IVDs
Despite its advantages of decreased development costs and time to market, open source software presents unique challenges to IVD manufacturers.
By Carl Herrgesell
 |
Carl Herrgesell is new product development practice manager at RTEmd (Pittsford, NY). He can be reached at carl.herrgesell@rtemd.com.
|
Open source software is not a new concept. Its roots date back to early developments that eventually evolved into the Internet. Often based on a broadly accepted standard such as Unix, the programs are contributed by disparate, interested developers working collaboratively. The use of open source software is gaining popularity in many industries, and it is being implemented increasingly in medical applications such as electronic health records and electronic medical records.2 Several advantages make open source software attractive, including its low cost and ready availability. Collaborations among several to many developers add to the expectation of a robust and usable implementation. However, open source software is generally provided through licenses with few, if any, restrictions on further distribution.
But can open source software be used in IVD products? Since IVD manufacturers ultimately bear the responsibility for assuring a device’s safety and efficacy, what additional risks are they assuming by including software that is developed outside their control? What additional steps can be undertaken to mitigate the possibility of unknown risks? Aside from the regulatory issues, how do IVD manufacturers protect their intellectual property rights in an open source licensing environment? This article examines and proposes solutions to these issues.
The Evolution of Open Source
 |
Open source software is increasingly finding its way into medical technology including IVD instruments.
|
The introduction of the term open source was soon followed by the formation of the Open Source Initiative (OSI) and coincided with Netscape announcing in 1998 that it would release the source code of its Web browser. OSI organizers “decided it was time to dump the moralizing and confrontational attitude that had been associated with free software in the past and sell the idea strictly on the same pragmatic, business-case grounds that had motivated Netscape.”4 OSI produced the open source definition (OSD), which defined the attributes of open source software.
According to the OSD, open source software’s attributes are the following: the source code is available to the general community; the software can be distributed freely or bundled with proprietary content and sold under license; and redistribution of modifications must be allowed.
In turn, the open source environment does the following: encourages collaborative development by academic and commercial interests; saves development resources by reusing existing code; and facilitates rapid improvement of software.
Linux, which is the open source version of the Unix operating system, is growing in popularity and is increasingly being implemented as the platform for many applications. For example, Motorola has embarked on a strategy to use Linux in future smartphones. The Open Handset Alliance, a group of 47 technology and mobile companies, has developed Android, the first complete, open, and free mobile platform.5 In addition, Oracle 11g was recently released on Linux before Microsoft Windows, an indication of the database vendor’s strategic focus on the open source operating system.
Of course, open source software encompasses much more than applications running on Linux or Linux itself. Open source toolkits, utilities, and libraries fulfilling various software needs can be used as development tools or included as components in IVD applications.
Issues for Using Open Source Software in IVDs
Given the successes demonstrated in other applications, could using open source speed up time to market and reduce development costs in IVD devices? On the surface, the answer to this question seems simple. However, IVD manufacturers must address two issues. First, recognizing a manufacturer’s responsibility to assure a devices’ safety and efficacy, how can such assurances be supported in a regulated environment? Second, IVD manufacturers must reconcile the need to assert and protect their intellectual property rights with the free distribution philosophy of open source software licensing.
Validation and Verification
A device’s safety and efficacy remain an IVD manufacturer’s exclusive responsibility. A critical aspect of fulfilling that responsibility is maintaining control over the entire development process. Consequently, introducing software from another source or even another development process is a matter of concern.
In the U.S. medical device market, IVD manufacturers turn to the quality system regulation (QSR) and FDA for guidance. Manufacturers are required to align their development processes with the QSR in order to maintain control over the process and demonstrate through documentation, review, and testing that each step’s output complies with the documented requirements. The development follows a controlled process, with designs flowing from the requirements and the software code from the design. Finally, testing demonstrates that the implementation has fulfilled the requirements.
Validation testing is conducted to substantiate that the software performs appropriately for the IVD device’s intended use. Validation of open source components is not an insurmountable issue since the validation can be accomplished by testing the overall system. RTEmd (Pittsford, NY) has validated applications that included open source components, for example, message parsing libraries.
However, verification requires IVD manufacturers to examine their records to substantiate that all software was developed in a compliant process. Such examinations include formally auditing documents and processes, including requirements trace matrices, minutes of design reviews, and documentation of tests. Obviously, such audits are not possible in an open source setting. However, some open source software (e.g., Linux) is so widely used that it is believed to have been effectively verified by virtue of the large community of developers and users. Furthermore, some open source vendors have focused on regulatory compliance. For example, FreeRTOS, an open source real-time kernel, is also available in a low-cost, commercially licensed version and in a fully tested, documented, 510(k)-certified version.6
While FDA prescribes documentation deliverables from the development process but does not prescribe an actual process, the agency’s position on software in regulated medical devices has been that full validation and verification of all components are required. This requirement includes third-party software, whether it is licensed commercially or obtained as open source.
Open source software, off-the-shelf (OTS) software, and software of unknown provenance can be construed to being developed without design controls. FDA has addressed OTS software; in September 1999, it released its “Guidance on Off-The-Shelf Software Use in Medical Devices.”
If open source were considered to be a special case of OTS software, this FDA guidance can be instructive. FDA requires IVD manufacturers to assure that the product development methodologies used by OTS software developers are appropriate and sufficient for the device’s intended use. FDA recommends that manufacturers should audit the OTS software developer’s design and development methods used in constructing the software. This audit should thoroughly assess the development and qualification documentation for the OTS software. However, if such an audit were not possible and, after hazard mitigation, the OTS software still represents a major level of concern, the use of such software may not be appropriate for the intended medical device application.
It might follow that open source software, although apparently suitable for the application, was not designed for the IVD’s intended use. The development process probably lacked the design controls that FDA requires. Moreover, an IVD manufacturer may not be able to audit the process that was employed for developing the software.
From a regulatory perspective, IVD manufacturers must answer several questions when software from any uncontrolled source is included in a product:
• How can IVD manufacturers meet design control requirements?
• What hazards or risks have been introduced by the uncontrolled software?
• How do manufacturers gain the necessary confidence in the software?
• What can manufacturers use to qualify the software?
• If a major issue occurred with an open source component, how will FDA and OIVD react?
IVD manufacturers must systematically examine the software, including open source components, for design flaws. Otherwise, they may expose themselves to FDA action or even claims by injured patients and providers who were assured of the device’s safety.
Licensing
According to Gernot Heiser, “There also remains an ownership question that many manufacturers are struggling with. A frequent concern about Linux is that it is distributed under the general public license (GPL), which requires that all derived code is subject to the same license and thus becomes open source. Some legal arguments claim that the license applies even to device drivers that are loaded into the kernel as binaries at run time.”7
In other words, does the work product that includes an open source component become open source as well, or does it remain proprietary intellectual property? Is the functionality that is added to an open source application considered an extension of that application and therefore available to the general community?
OSI specifies 10 criteria for OSI-certified licenses.8 These criteria address redistribution of the software (including its corresponding license), derivative works, and intended use. Two common open source licenses, GPL and the lesser general public license (LGPL), restrict the distribution of derivative works so that the original code and the derivatives from that code remain open. The GPL’s purpose is to keep any software licensed under it permanently open. An LGPL allows proprietary closed source programs to call open source software libraries, leaving the proprietary software unaffected by GPL requirements for openness.9
When determining whether to use an open source component, the first consideration regarding open source licensing is the type of license that accompanies the component. If the component were licensed under an LGPL, it can most likely accompany proprietary portions of an IVD application without issue.
For example, RTEmd developed two veterinary IVD applications that were built on an open source platform. In these cases, the client was comfortable with the approach, and the products are now on the market. However, the license language was sufficiently complex and confusing enough to raise questions of potential legal challenges in the future.
For another RTEmd project, the client rejected a proposed Linux operating system for a hematology application because of concerns with intellectual property protection. The project spent significant resources on Linux-based development before it was determined that the licensing issues were too risky. Regardless of whether the application was ultimately developed on an open source platform, the decision might have been much easier or made sooner if the guidance were more clear-cut.
If the open source component were distributed under a GPL, the issues are more complicated. It would not be appropriate to distribute the entire IVD application under a GPL simply to utilize one or more open source components that are released under a GPL. The specialized nature of IVD devices assures there would be limited interest in reusing or extending the application’s functionality beyond the device itself. However, the intellectual property issues are more important. IVD manufacturers must protect both their significant R&D investments and their resulting competitive advantages by asserting their intellectual property rights.
If an open source component were modified in any way to work with the proprietary software, the component becomes a derivative work, in which case the entire package could be subject to a GPL. There are situations in which proprietary software can exist alongside open source GPL components. The best candidates are components with well-defined and stable application program interfaces. The proprietary application should use dynamic linking to the component to avoid contaminating the proprietary software with the component.
 "Click to enlarge") |
Figure 1. Comparison of open source and commercial software licensing protection. (click image to enlarge) |
FDA and Open Source
Last January, the Obama administration received a report from the Government Accountability Office asserting that FDA’s process for reviewing and approving medical devices was severely flawed and calling for immediate steps to fix the problems. This report was punctuated by letters from nine senior scientists at FDA’s device division to President Obama “seeking significant changes at the agency.”10
Some people have speculated that improvements to FDA’s medical device review and approval process will consider new solutions and that open source might play a role in the future. According to Scott McNealy, cofounder of Sun Microsystems, “The government ought to mandate open source products based on open source reference implementations to improve security, get higher quality software, lower costs, higher reliability—all the benefits that come with open software.”11 Perhaps FDA could emulate the Department of Defense’s approach of publishing an approved list of acceptable open source packages for its programs.
But will FDA embrace open source software immediately? In a presentation by FDA’s Center for Devices and Radiological Health, “The FDA Perspective on Open Source Software,” the tongue-in-cheek opening slide stated, “FDA does not have a perspective on open-source software.” However, that same presentation concluded with a more pragmatic note: “FDA doesn’t prescribe the specific design processes appropriate for software design (or any other technology, for that matter). In making judgments about the adequacy of design and development processes, FDA applies generally accepted principles of good design practice, as dictated by the software engineering discipline.”12
However, any movement toward the use of open source software in IVD products, especially in light of the future review and approval process changes noted above, will probably include increased scrutiny by FDA. In fact, FDA is already using static analysis tools to uncover software flaws in devices under review.13 This shift illustrates an emphasis beyond the software development process to include software quality.
Conclusion
According to Steve Langer, “Open source projects succeed best where a body of knowledge is commonly known, the solution requirements have broad consensus, and effort can be shared among users to commoditize that solution into community infrastructure (i.e., the intellectual commons).”14
The value added by an open source component is significant because it does the following: prevents reinventing the wheel; leads to better quality code (more eyes, more testing); leads to more stable and persistent code (if the code is in the intellectual commons, no one vendor can discontinue it); and frees talented developers to work on more challenging problems.
Alternatively, if a vendor has solved a problem that gives it a significant competitive advantage, the vendor may be less willing to share it before the protection expires. However, the balance will shift over time as more software products offer open source alternatives and as licensing issues become clearer, enabling companies to become more comfortable that their intellectual property rights can be protected by open source licensing.
Given the growing popularity of open source software and the potential advantages of cost and time to market, IVD manufacturers could be expected to press FDA to prescribe a mechanism for use and control of open source software in diagnostic devices. But until that time, the determination to include open source software in IVD products will not be easy. Including open source software requires thorough technical and legal analysis and, in many cases, will depend on the manufacturer’s risk tolerance.
References
1. D Cornett, “The CIO’s Dilemma,” presentation at the CIO 08 conference, Coronado, CA, October 28-30, 2007.
2. I Valdes, “Free and Open Source Software in Healthcare 1.0,” presentation at the American Medical Informatics Association annual symposium, Washington, DC, November 15-19, 2008.
3. S Crocker, “How the Internet Got Its Rules,” April 6, 2009.
4. “History of the OSI,” Open Source Initiative Web site (Redwood City, CA [cited 4 June 2009]); available from Internet: www.opensource.org/history.
5. “Google and the Open Handset Alliance Announce Android Open Source Availability,” Open Handset Alliance Web site, 9 December 2008 (cited 4 June 2009); available from Internet: www.openhandsetalliance.com/press_102108.html.
6. “The FreeRTOS.org Project,” FreeRTOS Web site (cited 4 June 2009); available from Internet: www.freertos.org/.
7. G Heiser, “Virtualizing Embedded Linux,” Embedded.com Web site, 18 February 2008 (cited 4 June 2009); available from Internet: www.embedded.com/design/opensource/205918954?_requestid=220981.
8. “The Open Source Definition,” Open Source Initiative Web site (Redwood City, CA [cited 4 June 2009]); available from Internet: www.opensource.org/docs/osd.
9. F Deek and J McHugh, (Cambridge, UK: Cambridge University Press, 2008), 250-258.
10. G Harris, “Report Criticizes FDA on Device Testing,” , January 16, 2009.
11. M Schiels, “Calls for Open Source Government,” BBC News Web site, 21 January 2009 (London [cited 4 June 2009]); available from Internet: news.bbc.co.uk/2/hi/technology/7841486.stm.
12. “The FDA Perspective on Open Source Software,” presentation at MCIM 2007 workshop, St. Louis, April 30–May 3, 2007.
13. R Jetley, and P Anderson, “Using Static Analysis to Evaluate Software in Medical Devices,” Embedded.com Web site, 14 April 2008 (cited 4 June 2009); available from Internet: www.embedded.com/design/testissue/207000574?_requestid=226464.
14. S Langer, “A Radiology Open Source FAQ,” SIIM Web site, July 2006 (Leesburg, VA [cited 4 June 2009]); available from Internet: www.scarnet.org/index.cfm?id=716&terms=Langer+A+Radiology+Open+Source+FAQ&searchtype=1&fragment=False.
Copyright ©2009 IVD Technology
