A software process improvement lifecycle framework for the medical device industry

This paper describes a software process improvement framework to ensure regulatory compliance for the software developed in medical devices. Software is becoming an increasingly important aspect of medical devices and medical device regulation. Medical devices can only be marketed if compliance and approval from the appropriate regulatory bodies of the Food and Drug Administration (FDA) [1] (US requirement), and the European Commission under its Medical Device Directives (MDD) [2] (CE marking requirement) is achieved. Integrated into the design process of medical devices, is the requirement of the production and maintenance of a device technical file, incorporating a design history file. Design history illustrates the well documented, defined and controlled processes and outputs, undertaken in the development of medical devices and for our particular consideration with this framework - the software components

An Agile V-Model for Medical Device Software Development to Overcome the Challenges with Plan Driven SDLCs

Through the use of semi structured interviews with medical device software organizations it emerged that medical 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

Software development and risk management in the safety critical medical device domain

The healthcare sector is one of the fastest growing economic sectors of today. The medical device domain is one part of that sector. An increasing part of functionality in medical devices and systems is implemented in software and many features should not be possible to implement without software. The use of medical software is an inherent risk to the patient and the outcome of a failure can vary from death to almost no effect at all. Risks and risk management is closely connected to medical device domain and it is crucial to all medical device companies to have a good risk management process. It is also stated in law that the companies developing medical devices must have a risk management process. One part of the research in this thesis focuses on the current state of practice in the medical device domain. As a result of this research, the need for high quality software in this domain has been identified and also the needs for new techniques, methods and processes to further improve software quality in the medical device domain. The results have been used to derive a set of requirements on new processes, methods and techniques in the area, to be used by researchers as a guide in the development of more adapted processes, methods and techniques for software development in the medical devices domain. The other part of the research in this thesis focuses on risk and is based on two experiments. A number of decisions regarding risks are taken during software project risk management and it is the people involved that make the decisions. Different people’s opinions about the importance of identified risks are investigated in an experiment and it is concluded that different participants have different opinions about how serious risks are concerning faults remaining after testing are. Probably it is possible to generalise this and conclude that in the software engineering process different people are more or less risk seeking. From the second experiment it could be concluded that multiple roles and thereby different experiences will affect the risk identification process. Involving multiple roles will result in a more complete set of identified risks than if only one role is included