Martin Mc Hugh

A recent revision to the European Medical Device Directive (MDD) 2007/47/EC made fourteen amendments to the original directive (93/42/EEC). A number of these changes directly affect the de-velopment of software for use in healthcare. The most significant change in relation to medical device software development is that standalone software is now seen as an active medical device and should be developed following state of the art medical device software development processes. State of the art medical device software processes is understood within the industry as developing software in accordance with IEC 62304 and standards that are aligned with it. This paper identifies how changes to the MDD affect medical device software development companies and recommen-dations are made as to how medical device software development companies can conform to the latest regulatory requirements. Additionally, the paper provides an overview of how Medi SPICE is currently being developed to provide organisations with a single point of reference for the practices that should be implemented in order to produce regulatory compliant medical device software.

Since 2010, two significant international regulations regarding medical device development have come into force, the amendment to the European Union (EU) Medical Device Directive (MDD) 2007/47/EC and the United States (US) Food and Drug Administration (FDA) Final rule on Medical Device Data Systems (MDDS). Adherence to these regulations is mandatory to be able to market a medical device in the respective region. The ability to understand these regulations and apply them to a development project can be difficult. The MDDS final rule changes the safety classification of a number of devices from Class III-high risk to Class I-low risk. The aim of this regulation is to make the process of achieving regulatory approval for manufacturers easier. The MDD aims to provide guidance for the development of medical devices to be marketed for use within the EU. It also provides defined pathways which manufacturers can follow in order to achieve regulatory approval. However, changes made as part of amendment to the directive have a direct impact on the development of medical devices. One of the most significant changes as part of this amendment is for software to potentially be considered as a medical device in its own right and potentially the only element in a medical device subject to regulatory conformance. These regulations have created confusion surrounding specific areas such as the use of mobile device applications for healthcare purposes. This article describes the key points of these latest regulatory changes that medical device manufacturers need to be aware of.

The popularity of Agile software development is growing rapidly with an increasing number of projects being developed following Agile methodologies such as Scrum and XP [1]. Research has revealed that following Agile practices when developing software can have a significantly positive impact in reducing development time, reducing cost and increasing overall quality [2-4]. Whilst Agile practices can have a positive impact on a development project there are incompatibilities between Agile methodologies and the plan driven approaches followed when developing safety critical software [5, 6]. However, it has been recognised that “formal techniques may be used in an agile way” [5]. Case studies have been performed in organisations developing safety critical software which validate this statement [7-9]. This Ph.D. is focusing on the area of medical device software development and integrating Agile software development principles into traditional plan driven lifecycles for use in developing medical device software

Agile methodologies such as XP and Scrum are founded upon the four values and twelve principles of agile software development. A software development project is only considered to be truly agile if these values and principles are followed. However, software developed for use in medical devices must be regulatory compliant and this can make the process of following a single agile methodology such as XP difficult to achieve. This paper outlines how we identified the barriers to agile adoption in the medical device software domain through performing a survey. These barriers include: lack of documentation; maintaining traceability; regulatory compliance; lack of up front planning and the process of managing multiple releases.  Based on this research recommendations are also made as to how these barriers can be overcome.

The rate at which agile software development practices are being adopted is growing rapidly. Agile software development practices and methodologies appear to offer the silver bullet which can solve the problems associated with following plan driven software development lifecycles. Agile software development practices offer the possibility of achieving lower development costs, increased efficiency and improved software quality. However, there is currently a low rate of publicly available information that suggests there is widespread adoption of agile practices within the medical device software domain. This is largely due to the fact that software developed for medical devices includes challenges not faced when developing non safety critical software. As a result of these challenges, medical device software is typically developed using plan driven software development lifecycles. However, such lifecycles are quite rigid and cannot accommodate changes easily. Previous research has revealed that medical device software development projects can benefit from adopting agile practices whilst still maintaining the discipline associated with following plan driven development lifecycles. This paper outlines the challenges faced by developers when developing medical device software and how shortcomings in both agile and plan driven approaches can be resolved by following a mixed method approach to medical device software development.

Non-safety critical software developers have been reaping the benefits of adopting agile practices for a number of years. However, developers of safety critical software often have concerns about adopting Agile practices. Through a literature review this research identified the perceived barriers to following agile practices when developing medical device software. A questionnaire based survey was also conducted with medical device software developers in Ireland to determine what the actual barriers are to adopting agile practices. In addition a comparison is performed between the perceived and actual barriers and the results are reported.

A recent revision to the European Medical Device Directive (MDD 2007/47/EC) made fourteen amendments to the original directive (93/42/EEC). A number of these changes directly affect the de-velopment of software for use in healthcare. The most significant change in relation to medical device software development is that standalone software is now seen as an active medical device. Prior to this amendment medical device software was developed in accordance with the IEC 62304 standard. However, IEC 62304 is not sufficiently comprehensive to provide guidance in the development of standalone software as an active medical device. Medi SPICE is currently being developed to fill the gaps left by IEC 62304 in developing standalone software as an active medical device and to provide medical device software developers a single point of reference for developing software for use in healthcare.

On 16 April 2011, the US Food and Drug Administration’s (FDA’s) final rule on medical device data systems (MDDSs) came into force. This rule attempts to remove the uncertainty surrounding the safety classification of certain information technology systems used in healthcare. Devices that now meet the criteria of being an MDDS are classified as Class I (general controls). However, this final ruling explicitly precludes specific software applications that meet the definition of an MDDS, such as electronic health record applications and computerised physician order entry applications, as being beyond the scope of an MDDS. Similarly, ambiguity still remains surrounding mobile device applications. The purpose of this article by Martin McHugh, Fergal McCaffery and Valentine Casey is to provide an overview of the FDA’s final rule on the safety classification of an MDDS, how this rule has been amended in comparison to the proposed rule and what this rule means for MDDS manufacturers. In addition, the authors will be discussing the challenges medical device manufacturers face in the changing regulatory environment

With the release of the latest European Medical Device Directive (MDD) standalone software can now be classified as an active medical device. Consequently the methods used to ensure device safety and reliability needs to be reviewed. IEC 62304 is the current software development lifecycle framework followed by medical device software developers but important processes are beyond the scope of IEC 62304. These processes are covered by additional standards. However since the MDD became mandatory these additional standards are not comprehensive enough to ensure the reliability of an active medical device consisting of only software. By employing software process improvement techniques this software can be developed and validated to ensure it performs the required task in a safe and reliable way.