Requirements for using Open Source Software in Medical Devices - IVD Medical Device

W

willem biggelaar

Hi,

We are developing an IVD medical device. What are the regulatory requirements for using open source software in our product?

I have read the article of Matthias Klumper title "Navigating the new EU rules for MD software". That states: "the software should not contain any software of unkown provenance (SOUP), typical examp are open source components".

But
a) it does not answer my question what if we DO use them
b) the scope of the article is about MD not about IVD MD

Can someone enlighten me?
 

Marcelo

Inactive Registered Visitor
Re: Requirements for using Open Source Software in Medical Devices - IVD Medical Devi

Although the IVD directive hasn´t changed, and thus do not have the updated essential requirement for software, i would treat it the same way as the updated MDD (you can see this point due to the fact that EN 62304:2006 Medical device software - Software life-cycle processes is already harmonized to the IVMDD).

Regarding SOUP (which includes open source), the way regulations see it (and also EN 62304) is that this kind of software is potentially dangerous because it has not been proven safe. In the software case, this means that it´s development and validation have not used controlled procedures - to facilitate comprehension, let´s say it have not followed EN 62304 requirements and also it´s validation (which is outside the scope of EN 62304) was not done (note that the main problem here is that the software development and validation have to take into account the whole medical device).

So what do you do? Well, the only real thing to do is to "retrofit" safe into the software. If you use SOUP as a component of the medical device software, EN 62304 has requirements for those (including risk management). So, if you follow EN 62304, and validate you medical device with software, it would also deal with the SOUP problem.

Please note that it´s not as simple as it sounds, and it gets worse if your device is already built.
 
Last edited:
W

willem biggelaar

Re: Requirements for using Open Source Software in Medical Devices - IVD Medical Devi

Thanks Marcelo, for the quick response.

And as I already suspected, this will not be easy.

Thanks again!
 
J

Juan Dude

Re: Requirements for using Open Source Software in Medical Devices - IVD Medical Devi

I have read the article of Matthias Klumper title "Navigating the new EU rules for MD software". That states: "the software should not contain any software of unkown provenance (SOUP), typical examp are open source components".

This statement is illogic and goes against everything open source stands for. One argument for open source has always been that you have inherently more security because anyone can examine the underlying program code and verify it does what it ought to be doing.

Check this out:

http://en.wikipedia.org/wiki/List_of_open_source_healthcare_software

http://medicalconnectivity.com/2009/04/16/medical-device-open-source-frameworks/
 

Marcelo

Inactive Registered Visitor
Re: Requirements for using Open Source Software in Medical Devices - IVD Medical Devi

This statement is illogic and goes against everything open source stands for. One argument for open source has always been that you have inherently more security because anyone can examine the underlying program code and verify it does what it ought to be doing.

From a medical device regulatory point, open source software is a nightmare. This is becuse software safety can only be demonstrated by showing that the software was developed folowing a very strict and controlled process in which risk management plays a proeminent role. Open source generally does not follow any regulation because it´s made for a wide range of uses. That´s why regulations put severe restrictions in the use of these.
 
J

Juan Dude

Re: Requirements for using Open Source Software in Medical Devices - IVD Medical Devi

Open source generally does not follow any regulation because it´s made for a wide range of uses. That´s why regulations put severe restrictions in the use of these.

Can you cite some of these restrictions?
 
J

Juan Dude

Re: Requirements for using Open Source Software in Medical Devices - IVD Medical Devi

William check out this article, it's a great reference for how to overcome some challenges posed by using open source software on Medical Devices.


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.

According to Dion Cornett, vice president, North America sales at Red Hat (Raleigh, NC), “Today, the chief information officer (CIO) faces challenges that cannot be overcome by technical features alone: reduce costs, drive business innovation, enable competitive advantage, improve customer satisfaction, grow revenue. Every CIO faces a dilemma: How can I do more with less? The answer may lie in the use of open source applications and tools.”1

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

Since the 1960s and continuing to the present day with Linux, the creation of Unix shaped the open source community’s identity and proved that open source is a viable software development model. At the same time, researchers developing early telecommunication networks adopted a collaborative process called request for comments (RFC). RFCs encouraged the sharing of information and soon became the formal method to publishing Internet standards. RFCs were crucial to the Internet’s development (the RFC process recently marked its 40th anniversary) and promoted what were to become the open source movement’s defining principles.3

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.


Open source license issues are complex and subtly nuanced. IVD manufacturers should not decide to include open source components along with their proprietary applications without conducting a thorough legal review (see Figure 1).

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.

Source: http://www.devicelink.com/ivdt/archive/09/07/008.html
 

Marcelo

Inactive Registered Visitor
Re: Requirements for using Open Source Software in Medical Devices - IVD Medical Devi

Can you cite some of these restrictions?

I was creating an answer when you posted the article information. I think it summarizes the concerns i mentioned in the questions:

• 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?

This all has to do with risk management. Software risks can only be controlled by controlling, thru risk management, it´s development lifecycle. If you do not control your develpment lifecycle (and when i say control, i mean the design controls of the medical device regulations, which off-the-shelf sofware developers do not use) then you need to treat the software as a blackbox, and apply controls to gain confidence in it´s use.
 
Last edited:

Peter Selvey

Leader
Super Moderator
Re: Requirements for using Open Source Software in Medical Devices - IVD Medical Devi

After 10 years of regulatory auditing, now turning my hand to design of test equipment involving hardware, microprocessor level software and PC software, I have been wondering what is all the fuss about software -sure software has a lot of problems, but what is special about software that gets all the attention?

The conclusion I have is that there is nothing intrinsic about software that makes it different to any other area of design - there are for example exactly the same types of problems in both hardware and software.

The difference seems to come from hardware tending to be a system of off the shelf components, whereas in software we tend to write much of the material fresh for the device.

And therein lies the key danger - the amount of fresh new material that has not be subjected to test of time or wide application.

An off the shelf ADC (analogue to digital converter) has exactly the same potential problems as off the shelf software. The ADC has many complicated and critical aspects, and its failure may directly result in critical problems in the end medical device. But a medical device manufacturer is allowed to trust the ADC manufacturer's specification sheet without any special provisions, despite that the design of the ADC is outside of the manufacturer's control. Don't be fooled: end product verification testing does not fully test hardware circuits - it is no different to software in that it is impossible to test all permutations - and as such a huge amount of trust is being placed in the the component manufacturers.

Why? In truth we trust the ADC manufacturer largely because it is a well established component, sold by the millions in both medical and non-medical equipment.

And of course, if the failure of the ADC can lead to a serious event, such as death, then the manufacturer should put into place protection that operates independent of the ADC.

On the other hand, a manufacturer that uses some off the shelf software, suddenly the world comes down on them. Does this make sense? No. In the article above about IVD and open source software, every argument raised about OTS software can be equally applied to an OTS ADC.

I believe the original problem - fresh software - is being overlooked and as is typical, regulation has grabbed a subject and then ran with it far beyond the point where we can expect reasonable gains in safety for resources invested. Those resources get taken away from other more critical areas.

Whether open source or not, the reliability of most OTS software is bound to be several times higher than anything written by the medical device manufacturer, simply because of its wider application. Thus, we should be encouraging the use of OTS software rather than discouraging: it would be safer in the long run.

And again, a medical device should never be designed where the failure of a line of code can cause a serious event: there should be independent protection in place that at least ensures a fail safe situation.
 
Top Bottom