Authors: Dr Marion Lepmets, Dr Paul Clarke, Dr Fergal McCaffery and Anita Finnegan, Regulated Software Research Centre, Dundalk Institute of Technology

Software that is incorporated into a medical device, or which is a standalone medical device in its own right, is of a safety critical nature and subject to regulation from various jurisdictions (principally the EU and the US). In order to satisfy jurisdictional regulations, developers of medical device software often implement standards and guidance provided by international standards bodies and national administrative departments. However, the various standards and guidance documents are generally not integrated, with similarities and differences evident in their content. Through our applied research at the Regulated Software Research Centre (RSRC), we integrate the extensive content of the standards and guidance documents into a single best practice framework. Such a framework enables objective assessment of medical device software development processes. It also supports device manufacturers in their task of developing and/or outsourcing software for producing safe medical devices, while reducing the time and cost associated with the application of standards and guidance.


A basic requirement of the design of medical device software is that it satisfies the regulatory demands associated with the medical devices under construction. Failure to satisfy regulation in a particular region will mean that the device cannot be placed upon the market. A medical device can consist entirely of software or have software as a component of the overall medical device system. In order to be able to market a medical device within a particular region, it is necessary to comply with the regulatory demands of that region. Two of the largest global bodies responsible for issuing and managing medical device regulation belong to the central governing functions of the US and EU. In the case of the US, the Food and Drug Administration (FDA) issues the pertinent regulation through a series of official channels, including the Code of Federal Regulation (CFR) Title 21, Chapter I, Subchapter H, Part 820 (ref. Figure 1). Under US regulation, there are three medical device safety classifications: Class I, Class II and Class III. The medical device safety classification is based first and foremost on the clinical safety of the device. Class I devices are not intended to support or sustain human life, and may not present an unreasonable risk of human illness or injury. Examination gloves are an example of a Class I medical device. Class II medical devices are those devices for which Class I general controls alone cannot assure human safety and effectiveness. Class II devices could cause damage or harm to humans. An example of a Class II medical device is a powered wheelchair. Class III medical devices are usually those that support or sustain human life, and are of significant importance in the prevention of human health impairment. An example of a Class III device is an implantable pacemaker. All implantable devices are Class III medical devices as the surgery required carries with itself additional high risks from anaesthesia and possible infections that go beyond the technical and engineering safety risks of the correct performance of the device. [caption id="attachment_11213" align="alignright" width="653"] Fig 1: Medical device standards and regulation (click to enlarge image)[/caption] In the EU, the corresponding regulation is outlined in the general Medical Device Directive (MDD) 93/42/EEC, the Active Implantable Medical Device Directive (AIMDD) 90/385/EEC, and the In-vitro Diagnostic (IVD) Medical Device Directive 98/79/EC - all three of which have been amended by 2007/47/EC. Although slightly different to the US safety classifications that are based on clinical safety of the device, the EU classifications essentially embody similar classifications and limitations, where Class I corresponds to Class I, Class IIa and IIb to Class II, and Class III to Class III. A further safety classification applies to the software in the medical device as outlined in IEC 62304:2006 (IEC 62304 from hereon), wherein the safety classification is concerned with the worst possible consequence in the case of a software failure (as compared with general medical device safety classification which is based on the difficulty of a regulator to determine if the device will be safe). Hence, some Class II medical devices can cause serious injury or even death, but they are Class II because they are similar (in clinical use and safety) to well understood devices that have been used before. Since IEC 62304 safety classifications are based on the worst case failure of the software, it is possible that Class II medical devices can have Class III software (note that in the case of IEC 62304, software safety classifications are identified as A, B and C as opposed to I, II and III). Adherence to the various medical device regulations highlighted in the previous paragraphs may be demonstrated through the implementation of international standards and guidelines. The aim of this paper is to describe the motivation for developing a best practice framework from these various standards and guidelines. This framework helps to ease the burden of standards compliance on medical device software developers of all sizes as the medical device software developers can utilise the framework to quickly navigate to the practices that are relevant for them. The following section describes the web of standards and guidelines commonly implemented in medical device software organisations.


In the medical device domain, ISO 13485:2003 (ISO 13485 from hereon) outlines the requirements for regulatory purposes from a quality management system (QMS) perspective. ISO 13485, which is based on ISO 9001, can be used to assess an organisation’s ability to meet both customer and regulatory requirements. However, ISO 13485 does not offer specific guidance on software development. IEC 62304, which can be used in conjunction with ISO 13485, does offer a framework for the lifecycle processes necessary for the safe design and maintenance of medical device software. As a basic foundation, IEC 62304 assumes that medical device software is developed and maintained within a QMS such as ISO 13485, but does not require an organisation to be certified in ISO 13485. Therefore, IEC 62304 can be considered to be a software development specific supplement to ISO 13485. IEC 62304 is based on ISO/IEC 12207:1995 which although a comprehensive standard for software development lifecycle processes has effectively been decommissioned following the publication of the more extensive ISO/IEC 12207:2008. IEC 62304 is presently being revised in order to better align with ISO/IEC 12207:2008. Other developments in the ISO and IEC communities for software development, such as ISO/IEC 15504, have provided significant additional levels of software process detail to support ISO/IEC 12207:2008. Notwithstanding its foundation in ISO/IEC 12207:1995, IEC 62304 is a critical standard for medical device software developers as it is the only standard that provides recommendations for medical device software implementations based on the worst consequences in the case the software failure causing hazards. Furthermore, for general medical device risk management, IEC 62304 is used in conjunction with ISO 14971, with IEC 80002-1 providing guidance on the application of ISO 14971 for software development. Although IEC 62304 considers a medical device system to consist of software as part of an overall medical device system, the system level requirements are not included within IEC 62304. These could be found within the medical device product standard IEC 60601-1 instead. It should also be noted that due to the increasing importance of usability within the medical device industry, organisations should also adhere to the medical device usability requirements outlined in IEC 62366. In addition to the various standards identified above, the FDA issues and maintains a number of guidance documents for developers of medical device software: 1. General Principles of Software Validation (GPSV) – Final Guidance for Industry and FDA staff; 2. Guidance for the Content of Premarket Submissions for Software; 3. Guidance for Industry, FDA Reviewers and Compliance on Off-The-Shelf Software Use in Medical Devices. Although this suite of documents is not mandatory for implementation in medical device software development organisations, it is generally presented as being the minimum set of requirements for the various concerns. Indeed, the EU MDD states that the state of the art best practices should be implemented in the medical device software development industry, which also implicitly recommends adoption of these three FDA guidelines. It should further be clarified that for manufacturers, regulation requirements are twofold: first, premarket clearance to allow products to be placed on the market and second, compliance with the regulations. In the EU, these are looked at together for the most part (at least for software intensive systems) because a manufacturer must have a certified quality system in order to get a CE mark. In the US, premarket clearance is not based on the quality system or on following the process, it is based only on the safety and efficacy of the product as determined by the FDA reviewer based on the documentation submitted by the sponsor. Compliance with the regulations is treated separately by audit of the manufacturer. While the pre-market documentation that the FDA requires is dependent on the safety class (therein terms the Level of Concern) of the software, compliance with the regulation does not consider the safety class of the software and the manufacturer is expected to also follow the FDA guidance found in the GPSV. Although the FDA emphasises that the process followed should be consistent with the risk of the device, there is no safety class specific guidance in the GPSV. Furthermore, there is no validation requirement for medical device software in IEC 62304.


Numerous different standards exist for medical device software development, some of which are related and others which offer unique guidance that is not to be found elsewhere. As a result, navigating and comprehending the full spectrum of standards and guidance is a complex and challenging undertaking for medical device producers. Furthermore, there also exist software development best practices in generic software development frameworks (such as ISO/IEC 15504) which are outside the scope of any of the existing medical device specific standards and guidance; and the authors of this article suggest that these additional best practices would form a valuable additional resource for safety critical medical device software development. The areas of intersection and distinction between the different standards and guidelines are complex to determine and are the subject of extensive research in the Regulated Software Research Centre (RSRC). In the RSRC, individual researchers are active members of the international standards community, influencing the direction of the pertinent standards and collaborating with international experts and working groups to improve the impact and efficacy of medical device software development standards and guidelines. One of our projects in the RSRC involves the development of a best practice framework for medical device software development. This new framework, which is being developed in collaboration with the relevant ISO and IEC working groups for both general purpose and medical device software, will centralise the diverse practices contained in the many standards and guidelines into one central best practice framework. Furthermore, the framework will permit the consistent assessment of medical device software development practices using one of the leading international software process assessment approaches: ISO/IEC 15504. By unifying the best practices from the various disparate sources into a single solution, our framework will ease the burden of standards compliance on companies of all sizes. Rather than having to dedicate resources to the understanding and application of numerous standards and guidelines, companies can utilise the framework to quickly navigate to the practices that are relevant for them – often a decision that is led by jurisdictional market requirements. Gaps in practices can be highlighted and targeted for resolution. For companies that already have satisfied some or all of the medical device standards and guidelines, there are opportunities to assess against general software development best practices, thus identifying the most appropriate areas for further improvement, and therefore helping to raise the overall safety of the software produced. For organisations of all stages and sizes, the framework will permit a consistent approach to assessing medical device software processes, an approach that can be utilised by the organisations themselves – or by independent, certified third parties in order to evaluate the software development process. This best practice framework, which leans heavily on the accumulated expertise of many international standards and guidelines, represents a significant source of value to the medical device software development community – both from a technical perspective (as the disparate knowledge is assembled, for the first time, in one place) and from an economic viewpoint (as organisations may now access one point for all relevant material rather than expending significant resources attempting to relate and satisfy all relevant requirements).

Dr Paul Clarke is one of the speakers at an upcoming event entitled ‘Medical Device Software – Standards and Regulatory Developments’, to be held at Engineers Ireland HQ on 6 February. A panel of speakers – including Chrissie Keane, NSAI and Brian McAuliffe, Dell Inc – will address the topic from different aspects in terms of regulation development and its application within the medical device industry. Admission free. Work at the RSRC is supported by the Science Foundation Ireland Stokes Lectureship Programme, grant number 07/SK/I1299, the SFI Principal Investigator Programme, grant number 08/IN.1/I2030 (under a co-funding initiative by the Irish Government and European Regional Development Fund), and further supported by Enterprise Ireland and the European Regional Development Fund under the National Strategic Reference Framework 2007-2013; and in part, by Lero - the Irish Software Engineering Research Centre under grant 10/CE/I1855.


Note: In general, the full titles for the relevant standards and guidance documents are provided in Figure 1. IEC 60601-1 - Medical electrical equipment – Part 1: General requirements for basic safety and essential performance 2005, IEC: Geneva, Switzerland. IEC 62366 - Medical devices - Application of usability engineering to medical devices. 2007, IEC: Geneva, Switzerland.