IEC 62304 is a medical software development standard. It discusses the assignment of medical device software safety classifications, and the development of safety-critical software to fulfil resulting requirements.
The EU and FDA definitions of what constitutes a medical device encompass a large majority of medical products other than drugs. A huge range of diagnostic and delivery systems rely on medical device software. The reliability of that software and the risks associated with it are an important consideration for the industry and patients alike.
The International Electrotechnical Commission, IEC, published Amendment 1 to the IEC 62304 standard “Medical device software – software life cycle processes” in June 2015 in response to those concerns. The set of process activities and tasks described in the standard establish a common framework for medical device software life cycle processes.
Functional safety addresses risk management in a piece of equipment or a system.
Functional safety development processes aim to identify potentially harmful conditions. They identify corrective actions to avoid or reduce the impact of an incident such that the response is proportionate to the risk.
In practice, functional safety relies on active systems that can implement risk control measures in response to potentially dangerous situations. One example is the raising of an alarm and perhaps contacting an on-call doctor in response to a patient’s rising temperature. Another involves responding to reverse flow in an infusion pump.
IEC 62304 is applicable to both examples. It defines processes that are necessary for the safe design and maintenance of medical device software. The standard breaks the processes down into activities and tasks, the thoroughness of which varies in proportion to the criticality of the software.
If all had gone according to plan, the focus would now be on a second edition of IEC 62304, published in 2021. The essential requirements assigned to the development team were to
None of the resulting sequence of draft documents was able to resolve the different interests of the stakeholders commenting on them. The result is that IEC 62304:2006/AMD 1:2015 remains current.
IEC 62304 includes a hierarchy of terms which can be confusing. Consider a simple toy cart as an analogy.
A software unit is a part of a software item, which is part of a software system.
These definitions are flexible. Just as the wheel component may or may not include the tyre, so the definition of software units and items can vary.
The level of effort required to comply with each objective in the standard depends on the Software Safety Class. These are categorised in proportion to the likelihood and consequence of software failure. The standard defines three classes:
Amendment 1 of the standard introduced a risk-based approach to assigning classes as shown in a decision tree.
IEC 62304: Partitioning of software items
IEC 62304:2006 +AMD1:2015 helps to minimize development effort by permitting software item segregation. Amendment 1 permits both physical separation and separation in software.
The standard uses the example of a Class C designated software system. System segregation can result in one software item to deal with functionality of limited safety implications (software item X), and another to handle the highly safety critical aspects of the system (software item Y).
Repeating the system segregation processes on the resulting classes (segregating software item Y in the example) helps ensure the assignment of the least demanding classes possible to the whole code base.
There are many international standards for medical devices and their development. This is not a comprehensive list.
IEC 62304 is a sector-specific functional safety standard derived from IEC 61508. It includes terminology and best principles established in the medical devices industry before the release of IEC 61508. For example, the use of “classes” rather than “SILs” aligns with the FDA’s classification system. IEC 61508 also places emphasis on the use of “SOUP” (Software Of Unproven Provenance) which is common practice in the sector.
ISO 13485:2016 “Medical devices — Quality management systems — Requirements for regulatory purposes” is complementary to IEC 62304, but not directly related to it. It specifies objectives for a quality management system to ensure products and services of consistent and adequate quality. It is possible to comply with IEC 62304 and ISO 13485 simultaneously, but it is not obligatory.
ISO 14971:2019 “Medical devices — Application of risk management to medical devices” defines a generic process for risk management of medical devices throughout development and deployment. Risk management is a complementary activity to the development life cycle requirements defined by IEC 62304.
The European Medical Device Regulation (MDR) and the In Vitro Diagnostics Regulation (IVDR) require that manufacturers selling into the EU apply best practices. The regulations suggest that IEC 62304 offers an appropriate definition of best practices with respect to the software development life cycle.
The U.S. Food and Drug Administration (FDA) recognises IEC 62304 as a consensus standard, allowing its use as a benchmark to comply with FDA regulatory requirements.
AAMI TIR45 provides guidance on the use of an Agile approach to the development of medical device software development. Software development in the safety critical sectors is traditionally based upon a V-model, and there is ongoing debate in the community on the best model to use.
Medical device software developers from several organizations have shown that they can incorporate Agile practices into their workflow. TIR 45 collates feedback on the practices they thought appropriate.
IEC 62304 uses a V-model to illustrate the relationship between its component parts, but it also states that “it does not require that any particular life cycle model is used, but it does require that the plan include certain ACTIVITIES and have certain attributes.”
Irrespective of the life cycle chosen, the LDRA tool suite supports those activities and provides a means to checks for those attributes.
The LDRA tool suite helps ease the path to compliance by automating the required validation and verification work and by providing traceability throughout the life cycle, complete with evidential artefacts.
The V diagram illustrates how the LDRA tool suite and other tools fit into the example software development process illustrated in IEC 62304 §5. The tool suite also provides critical assistance through the software maintenance process (§6) and the risk management process (§7)
5.1 involves planning the tasks needed for development of the software to reduce risks and communicate procedures and goals to members of the development team.
Achieving a format that lends itself to bidirectional traceability will ease compliance with the standard. Bigger projects (perhaps with contributors in different locations) are likely to benefit from an application life cycle management tool. Smaller projects can cope with carefully worded spreadsheet or word processor documents, written to facilitate links up and down the development process model.
Most projects suffer from unexpected changes of requirements, or failed tests that demand a rethink. Both can cause a project management headache. The TBmanager component of the LDRA tool suite helps by automatically maintaining the connections between the requirements, development, and testing artefacts and activities. Its impact analysis facility draws on that information.
5.3 requires the manufacturer to define the major structural components of the software, their externally visible properties, and the relationships between them. The software architecture must include a description of software component behaviour such that the specified software items can implement all software requirements. Verification takes the form of technical evaluation.
Developing the architecture means defining the interfaces between the software items that will implement the requirements. Any SOUP integration must be in accordance with IEC 62304 §4.4, “Legacy Software”.
Where there is a model-based approach to software architecture, LDRA tool suite’s integration with the chosen modelling tools will make for seamless analysis of generated code and ensure traceability to the models.
5.4 involves the specification of algorithms, data representations, and interfaces between different software units and data structures to implement the verified requirements and architecture. Later in the development cycle, the LDRA tool suite can help by generating graphical artefacts suited to the review of the implemented design by means of walkthroughs or inspections.
5.5 involves the translation of the detailed design into source code. Coding standards are required to achieve the desirable code characteristics, to specify a preferred coding style, aid understandability, apply language usage rules or restrictions, and manage complexity. Verifying the code for each unit using a static analysis tool will ensure that it complies in a timely and cost-effective manner.
TBvision component of the LDRA tool suite largely offer support for a range of coding standards as defined by MISRA, CERT, and many others. It achieves coverage of very high percentage of the rules dictated by each standard, and user-defined rule sets are also supported. The TBexclude® module provides for the efficient management of justified rule violations.
IEC 62304 also requires strategies, methods, and procedures for verifying each software unit. Amongst the acceptance criteria are considerations such as the verification of the proper event sequence, data and control flow, fault handling, memory management and initialization of variables, memory overflow detection and checking of all software boundary conditions. The TBrun® unit test component of the LDRA tool suite provides a means to automate dynamic analysis techniques, with the TBextreme® module providing a straightforward means to analyse boundary values without creating each test case manually.
5.6 focuses on the transfer of data and control across a software module’s internal interfaces and external interfaces such as those associated with medical device hardware, operating systems, and third-party software applications and libraries. This requires the structured integration of software units into ever larger aggregated software items, culminating in the verification of the integrated system. Integration testing can also demonstrate program behaviour at the boundaries of its input and output domains and confirms program responses to invalid, unexpected, and special inputs.
5.7 requires the manufacturer to verify the successful implementation of the requirements in the complete system, and that the performance of the program is as specified.
The LDRA tool suite has the capability to perform code (structural) coverage analysis during unit, integration and system test to illustrate which parts of the code base have been exercised.
The optional TBjustify module can be specified to manage the documentation of justifications concerning coverage for certification and compliance purposes.
With the advent of the connected device and the Internet of Things, system maintenance takes on a new significance. For any connected systems, requirements don’t just change in an orderly manner during development. They change without warning – whenever some smart Alec finds a new vulnerability, develops a new hack, compromises the system. And they keep on changing throughout the lifetime of the device.
For that reason, the ability of next-generation automated management and requirements traceability tools and techniques to create relationships between requirements, code, static and dynamic analysis results, and unit- and system-level tests is especially valuable for connected systems. Linking these elements already enables the entire software development cycle to become traceable, making it easy for teams to identify problems and implement solutions faster and more cost effectively. But they are perhaps even more important after product release, presenting a vital competitive advantage in the ability to respond quickly and effectively in response to any security breach.
Like many other safety critical standards including IEC 61508, ISO 26262, and EN 50128, IEC 62304 references the need for due consideration of response timing for time-critical applications, and memory constraints.
IEC 62304 §5.2.2 is concerned with the definition of functionality and capability requirements. It suggests that these should include “timing requirements”.
The WCET of a computational task is the maximum length of time that the task could take to execute in a specific environment. Hard real-time systems need to satisfy stringent timing constraints imposed by the nature of the functions they fulfil. Unfortunately, it is not possible in general to calculate definitive upper bounds on execution times for programs.
There are further complications in the case of multicore processors. The use of additional cores results in resources being shared between them. Time-related delays occur as users wait for access.
These interference channels cause the execution-time distribution to spread. Instead of a tight peak, the distribution of execution times becomes wide with a long tail.
This page presents a practical, compliant approach to addressing this problem. It involves the optimisation of system configuration by means of interference research through measured execution times using the TBrun component of the LDRA tool suite supported by the optional TBwcet module.
The LDRA tool suite is TUV certified for security- and safety-critical development, including projects requiring IEC 62304 certification.
Where proof of fitness-for-purpose within a specified tool chain is required, the LDRA Tool Qualification Support Packs (TQSPs) contain the test cases to demonstrate both the structural coverage analysis and programming rules checking capabilities of the tool suite itself. In addition, associated documentation for the development and verification of the product is provided, including plans, procedures, and expected results.
Email: info@ldra.com
EMEA: +44 (0)151 649 9300
USA: +1 (855) 855 5372
INDIA: +91 80 4080 8707