Martin McHugh

Barriers to Adopting Agile Practices When 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.

An agile v-model for medical device software development to overcome the challenges with plan-driven software development lifecycles

Through the use of semi structured interviews with medical device software organizations it emerged that medica device software organizations are experiencing difficulties when following plan driven Software Development Life Cycles (SDLC) particularly in the area of requirements management. To attempt to resolve these issues an examination of the non-regulated industry was performed to determine if lessons learned there could be applied to the development of medical device software This examination revealed that agile methods are being widely adopted in the non-regulated software industry. To learn if agile methods could be adopted when developing medical device software a mapping study was performed which looked for instances of where agile methods have been used in regulated industries and where they have been adopted, to what success This mapping study revealed that incorporating agile practices with the existing plan driven SDLC is the most favourable choice for medical device software organizations. This research aims to develop a SDLC which has a foundation of a plan driven SDLC which incorporates agile practices which can be followed when developing regulatory compliant software.

Standalone Software as an Active Medical Device

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.

Balancing agility and discipline in a medical device software organisation

Agile development techniques are becoming increasingly popular in the generic software development industry as they appear to offer solutions to the problems associated with following a plan-driven Software Development Life Cycle (SDLC). However, agile methods may not be suited to all industries or organisations. For agile methods to succeed, an organisation must be structured in a way to accommodate agile methods. Medical device software development organisations are bound by regulatory constraints and as a result face challenges when they try to completely follow an agile methodology, but can reap significant benefits by combining both agile and plan-driven SDLC such as the Waterfall or V-Model. This paper presents an analysis of a medical device software development organisation based in Ireland, which is considering moving to agile software development techniques. This includes the performing of a Home-Ground Analysis to determine how agile or disciplined the organisation currently is. Upon completion of the Home-Ground Analysis recommendations were made to the organisation as to how they could tailor their existing structure to better accommodate agile development techniques. These recommendations include adopting agile practices such as self-organising teams to promote a culture of “chaos” within the organisation.

Adopting agile practices when developing software for use in the medical domain

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 performing a literature review, this research has 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 the barriers to adopting agile practices. The survey revealed that half of the respondents develop software in accordance with a plan‐driven software development lifecycle and that they believe that there are a number of perceived barriers to adopting agile practices when developing regulatory compliant software such as being contradictory to regulatory requirements, insufficient coverage of risk management activities and the lack of up‐front planning. In addition, a comparison is performed between the perceived and actual barriers. Based upon the findings of the literature review and survey, it emerged that no external barriers exist to adopting agile practices when developing medical device software and the barriers that do exists are internal barriers such as getting stakeholder buy in. Copyright

Software process improvement to assist medical device software development organisations to comply with the amendments to the medical device directive

A recent revision to the European Medical Device Directive (MDD) 2007/47/EC made 14 amendments to the original directive (93/42/EEC). A number of these changes directly affect the development of software for use in healthcare. The most significant change in relation to medical device software development is that stand-alone 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 are understood within the industry as developing software in accordance with IEC 62304 and standards that are aligned with it. This study identifies how changes to the MDD affect medical device software development companies and recommendations are made as to how medical device software development companies can conform to the latest regulatory requirements. Additionally, the study 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.

An Agile Implementation within a Medical Device Software Organisation

Three surveys conducted over a 6 year period revealed that medical device software organisations have difficulties in the area of requirements management, namely accommodating changes in requirements. Medical device software is traditionally developed in accordance with a plan driven software development lifecycle (SDLC). These SDLCs are rigid and inflexible to changes once the requirements management stage has been completed. Agile methods are gaining momentum in non-regulated industries but as of yet, the adoption of these methods in regulated industries such as the medical device software domain remains low. This study presents an implementation of agile methods within a medical device software development organisation based in Ireland. This implementation involved integrating agile practices with a traditional plan driven SDLC. Upon completing this implementation within a medical device software development project, the organisation identified cost savings and a reduction in the rework required when introducing a change in requirements.

How Can Software SMEs Become Medical Device Software SMEs

The amount of software content within medical devices has grown considerably over recent years and will continue to do so as the level of complexity of medical devices increase. This is driven by the fact that software is introduced to produce sophisticated medical devices that would not be possible using only hardware. This therefore presents opportunities for software development SMEs to become medical device software development organisations. However, some obstacles need to be addressed and overcome in order to make the transition from being a generic software development organisation to becoming a medical device software development organisation. This paper describes these obstacles and how research that is currently being performed within the Regulated Software Research Group in Dundalk Institute of Technology may be used to assist with this transition.

Adopting Agile Practices when Developing Medical Device Software

Adopting Agile Practices when Developing Medical Device Software Agile methods are gaining momentum amongst the developers of non-safety critical software. They offer the ability to improve development time, increase quality and reduce development costs. Despite this, the rate of adoption of agile methods within safety critical domains remains low. On face value agile methods appear to be contradictory to regulatory requirements. However while they may appear contradictory, they align on key values such as the development of the highest quality software. To demonstrate that agile methods could in fact be adopted when developing regulatory compliant software they were implemented on a medical device software development project.

Improving Safety in Medical Devices from Concept to Retirement

As with many domains the use of software within the healthcare industry is on the rise [1, 2] within the last 20 years.