Welcome to our new website! If this is the first time you are logging in on the new site, you will need to reset your password. Please contact us at raps@raps.org if you need assistance.
Your membership opens the door to free learning resources on demand. Check out the Member Knowledge Center for free webcasts, publications and online courses.
Communication Strategies. Case Studies. Applied Knowledge.
Hear from leaders around the globe as they share insights about their experiences and lessons learned throughout their certification journey.
Jaap Noordmans, BSc
RF Quarterly | 01 April 2022 | Citation | PDF
This article applies to software development and validation and discusses the security and usability engineering aspects of software. It uses the term “software” for software as a medical device (SaMD) and medical device software (MDSW), including MDSW that is embedded on, drives, or influences the use of a hardware medical device, software accessories, and software components. Keywords ‒ agile, development, incremental, software, static, waterfall
Manufacturers should take standards and regulatory guidance into consideration when implementing software development processes. This section introduces the most important standards and guidance documents. The internationally accepted framework for lifecycle processes for medical device software is IEC 62304.1,2 This standard defines the processes, activities, and tasks used in the development and maintenance of medical device software. This article will detail the parts of IEC 62304 that apply to software development. IEC 62304 defines software development lifecycle activities, except for design validation of the finished device, i.e., the process for confirming software specifications conform to user needs and intended uses. Design validation is covered by IEC 60601-13,4 for the software part of medical electrical equipment, or IEC 82304-15 for software-only products. IEC 62304 defines processes, not development techniques. The sequence of development process steps described by IEC 62304 appears to suggest a waterfall model be used, i.e., a once-through strategy, often represented in the classical V-model for sequential development. Nevertheless, the standard does not prescribe any specific software development methodology, approach, principle, or practice. The standard for quality management systems, ISO 13485,6,7 and the US Food and Drug Administration (FDA) guidance on design controls8 appears to suggest the design process should be completed in the following sequence: planning, design input, design output, design review, verification, validation, and transfer. Still, these documents are not intended to prescribe a specific chronological order for these activities. Historically, (software) development departments felt burdened by the waterfall approach in writing plans and requirements specifications, documented to the last comma and point, before starting with the real work: coding. In contrast to the waterfall approach, with an agile or iterative development approach, system development and delivery are performed in small increments. Agile development provides useful functions much earlier in the project, generates early feedback from strategic customers and users, allows developers to improve the functionality already on the market, and informs corrections to the original specification. Agile’s principal purpose is to overcome the problem of discovering, at the end of a (large) development project, that the developed system does not meet the customers’ real (and often, new) requirements. New systems will inevitably not only require, but also induce, changes to working practices unforeseen at the start of a project. That is why specifications are unlikely to be either complete or correct at the start of a project. Adhering to a rigid waterfall model can result in disaster early in the project. Changes to requirements will likely be needed throughout the project; regardless, it is unlikely the finished system will be able to meet its users’ needs. If a system is expected to be large and lengthy, and its requirements cannot be fully defined with confidence at the start, big-bang delivery using the once-through waterfall model may not be such a good idea. Agile development practices allow anomalies to be discovered early in the development stage, so the specification and development of later increments can be refined through user feedback. Manufacturers can use the agile approach even for the development of nonsoftware products. Obviously, agile versus waterfall has a serious impact on the implementation of software development processes in a quality management system; this article discusses both methodologies. The Technical Information Report (TIR) AAMI TIR459 for agile software development is widely used and accepted and is supported by FDA.10 AAMI TIR45 provides recommendations for complying with international standards and FDA guidance documents when using agile practices to develop medical device software. This article uses some of definitions in AAMI TIR45 and discusses some of its development concepts. Software user interface design is clearly part of software development. User interface specification and formative and summative evaluations are an essential element of usability engineering. IEC 6236611 defines processes related to safety for the usability engineering of a medical device. This article discusses the interaction between software development processes and usability engineering and how the usability engineering processes can fit into the waterfall or agile methodology. IEC 62304 does not cover the medical device’s validation and final release; however, validation of user needs is often part of software development.12 Furthermore, IEC 60601-113 and IEC 82304-1 both require validation for programmable electrical medical systems (software). ISO 1348514 and FDA guidance on design controls also require design and development validation.15 IEC 82304-1, although not harmonized in the EU, but recognized in the US,16 can be considered the state-of-the-art standard for software validation. It is important to note that the scope of IEC 82304-1 applies to software-only products. This article provides details on the software validation requirements of IEC 82304-1. The European Medical Devices Regulation (EU MDR)17 includes several general safety and performance requirements (GSPR) related to security. For instance, GSPR 17.2 requires that “Medical Device Software shall be developed according to researcher at the National eHealth Living Lab (Leiden University Medical Center) if state of the art, including information security.” The Medical Device Coordination Group (MDCG) released guidance on security for medical devices, MDCG 2019-16.18 Notified bodies (NB) must use MDCG guidance documents in their product assessments. Therefore, it is highly recommended (needed) that manufacturers also follow the MDCG guidance. FDA issued guidance on management of cybersecurity in medical devices19 and a guidance on cybersecurity for networked medical devices containing off-the-shelf (OTS) software.20 IEC 60601-1 presents requirements for devices incorporated into an IT-network. MDCG and FDA guidance as well as IEC 60601-1 do not address how to include security into software development. IEC/TR 60601-4-521 provides detailed technical specifications for security features and capabilities of medical devices used in medical IT-networks,22 which includes medical electrical equipment23 and medical device software,24 even though these products are not in the scope of the IEC 60601 series. The TR defines specifications for security levels based on existing documents for IT security, like IEC 62443-4-225 and IEC TR 80001-2-2.26 IEC 81001-5-1,27,28 addresses the product lifecycle activities from a security-specific perspective of connected medical devices or health software and is modeled after IEC 62304. This article uses edition 1.029 of IEC 81001-5-1 to address security-specific aspects during software development. The scope of IEC 80001-167 adds general requirement in the application of risk management for the accountable organization for the use and maintenance of medical devices in a medical IT-network.. Several definitions are used for medical device software. In the EU, MDCG 2019-11,30 defines two types of software:
Evolutionary. The evolutionary strategy acknowledges that the user needs are not fully understood, and all requirements cannot be defined upfront. In this strategy, customer needs and system requirements are partially defined upfront, and refined in each subsequent build. [IEC 62304, paragraph B.1.1]
Tags: agile, SaMD, software, waterfall