Using IEC 601-1-4 to Satisfy FDA Software Guidance Requirements

Medical Device & Diagnostic Industry
| MDDI Article Index

Originally published December 1995

by Debra S. Herrmann and David A. Zier

Developed as part of the 601 series of standards for medical electrical equipment, International Electrotechnical Commission (IEC) standard 601-1-4 "Safety Requirements for Programmable Electronic Medical Systems" is the first international consensus standard to specifically address the issue of software safety(Reference 1). It was submitted to final balloting by IEC and the European Committee for Electrotechnical Standardization (CENELEC) early this fall, and will soon be published as harmonized European standard EN 60601-1-4. In addition to the European Union, Australia, Canada, and Singapore have indicated their intention to adopt all or part of the IEC 601 series of standards. Thus, by complying with this standard, medical device manufacturers can demonstrate compliance with the regulatory requirements of multiple markets in North America, Europe, and the Pacific.

An earlier article (MD&DI, June 1995) previewed the contents of IEC 601-1-4 (Reference 2); the present article discusses how the new standard corresponds to the requirements of FDA's software reviewer guidance (Reference 3). Specifically, it examines how the development life-cycle activities, risk-management activities, and documentation/work products of IEC 601-1-4 correspond to the requirements in a premarket submission.


Before attempting compliance with IEC 601-1-4, U.S. device manufacturers should understand FDA's underlying philosophies with regard to standards. First, FDA does not mandate the use of any particular standard or standards; instead the agency actively participates in the development of national and international consensus standards and encourages their use. Second, device manufacturers are responsible for selecting and using any national or international consensus standards, and for justifying their
selections. They should choose standards that are appropriate for their product line, corporate culture, development environment, and knowledge base. Third, standards are not an end in themselves, but tools for demonstrating compliance with relevant medical device regulations and FDA policy and guidance documents.

Figure 1 shows the regulatory hierarchy for medical device software in the United States. At the top level is FDA's mission to protect the public health. This goal is essentially the same in any country. At the next level are relevant laws, such as the Safe Medical Devices Act of 1990 (SMDA) and the Medical Device Amendments of 1992. At the third level are the regulations found in Title 21 of the Code of Federal Regulations (CFR). FDA policy and guidance documents, which interpret regulations, form the fourth level. Finally, national and international consensus standards, at the fifth level, are considered tools for demonstrating compliance with regulations and policy. They are also useful for promoting international commerce.

The development of a revised FDA software reviewer guidance document has coincided with the issuance of IEC 601-1-4. It is not entirely by accident that this guidance document is being updated at the same time the IEC standard is formally issued: The agency has taken the requirements of the new standard into account. However, the primary motivation for the revision is to clarify the existing guidance based on the agency's four years of experience in using it. Feedback from both manufacturers and scientific reviewers is being incorporated. In addition, by clarifying the guidance the agency hopes to receive a larger percentage of complete premarket submissions the first time around. This will obviate the need for requests for additional information, which are time-consuming for both FDA and manufacturers. The new reviewer guidance will apply to all premarket submissions: 510(k)s, premarket approval applications, and investigational device exemptions.


The requirements of IEC 601-1-4 with regard to development life-cycle activities are reviewed briefly below, focusing on issues important to the software guidance document.

Both the standard and the guidance document are neutral about life-cycle models and software development methodologies. Annex CCC of the standard promotes an enhanced waterfall model; however, this annex is informative, not prescriptive. It is important to note that for both, risk-management activities are an integral part of the development life cycle. Manufacturers are responsible for selecting and justifying a particular life-cycle model and software development methodology. FDA looks for four particular characteristics in any such model: (1) distinct phases and associated work products; (2) feedback loops among the phases; (3) verification and validation activities that return to the source of the error, not necessarily the previous phase; and (4) integral risk-management activities.

The standard identifies several life-cycle phases, including specifications, architecture, design and testing, and verification and validation. Requirements analyses and specifications, which detail risk-related functions and identify safety integrity measures for controlling risks, are required for the device and each of its subsystems and subcomponents. It is important to the FDA software guidance that the manufacturer clarify the role of the software in the device during this phase, particularly in regard to risk-related functions.

During the architectural analysis, risk-control measures are allocated to the various system components and subsystems. The role of software in these risk-control measures should be clarified. Manufacturers are responsible for selecting from among 10 architectural considerations listed in section 52.207 of the standard and for justifying their selection. The decision-making process should be documented, as well as how and why the chosen elements were incorporated.

Design and test specifications also are required for the device and each of its subsystems and subcomponents. These specifications should document which of 10 design considerations listed in section 52.208 of the standard were incorporated and how; again, the decision-making process should be documented.

Verification activities should estimate the realization of the device's functional and safety objectives while verifying their correct implementation. FDA has concerns in two areas that relate to verification activities. The first is the use of commercial off-the-shelf (COTS) software products. Most COTS products are not designed, developed, validated, or verified for use in a safety-critical environment. Hence, the responsibility for verifying the safety and reliability of a product falls to the medical device manufacturer. The second area of concern is the use of multiple complementary analysis and verification techniques, such as those listed in Table I. The agency encourages manufacturers to use more than one technique, so that a larger number and different types of errors may be uncovered.

Validation activities demonstrate that the correct functional and safety requirements have been implemented. To satisfy both the FDA software guidance and the standard, these activities should include validation
of the software and an assessment of its role in device validation. The results observed during validation should be documented, analyzed, and interpreted. This is an opportunity for the manufacturer to prove that the device has been adequately validated.


The following discussion examines the documentation requirements for premarket submissions, as outlined in the software guidance document, and indicates how they correspond to the new IEC standard. Table
summarizes the standard citations, for easy reference.

New Submissions. As set forth in the guidance document, there are five major components of a premarket submission for a device containing software: information about the level of concern, descriptive data, labeling, development life-cycle activities, and risk-management activities.

FDA uses the term level of concern to mean the severity of harm that a device could permit or inflict (directly or indirectly) on a patient or operator as a result of latent failures, design flaws, or misuse. In this section of a submission it is important to clarify the role of software in causing, controlling, and/or mitigating these events. Manufacturers should state the level of concern for the software and the device and explain how it was determined. Similar requirements are covered in section 52.204 of the standard.

The submission section containing descriptive data about the software development environment and intended operational environment should include a discussion of the hardware platform, operating system, compiler, and any simulators, emulators, and computer-aided software engineering (CASE) tools used. Device-specific performance requirements will be addressed by the appropriate IEC 601-2 standard.

The labeling section should comprise both a discussion of the device's intended use and instructions for use. At present, IEC 601-1-4 does not specifically include a section addressing intended use, but this information could be included in the system-level requirements specification (section 52.206 of the standard), since the intended use of a system must be known before architectural analysis can be performed. The instructions for use should be current, complete, and understandable by the end-user. Any known nonhazardous anomalies should be documented.

The fourth section of a submission represents the work products from each of the development life-cycle phases and reflects ongoing configuration management and change-control procedures. Specifications resulting from requirements analyses, architecture analyses, and design trade-off analyses should be developed and maintained for the device and each of its subsystems and subcomponents. The modularity of the specifications facilitates future product enhancements and the development of premarket submissions for them. Tables, charts, diagrams, and/or calculations should be used to present the information contained in the specifications wherever possible; certain information can be conveyed more concisely this way. Manufacturers should also report how compliance with IEC 601-1-4 (and other standards, if any) was assessed.

Finally, the fifth section represents the work products that result from the risk-management process. A hazard analysis by itself is not sufficient; manufacturers should also document what hazard identification methods were used, what the estimated likelihood of each hazard occurring is and how it was estimated, what the estimated severity of each hazard is and how it was categorized, and what risk-reduction and risk-
mitigation techniques were implemented and how their effectiveness was assessed. A standard risk-management template, such as that presented in Figure 4 of the June 1995 article, can be used to document this information.2 The hazard analysis should be performed for the device as a whole. Appropriate techniques must be chosen so that separate hazard analyses for the software, electronics, biomaterials, and so forth can be effectively integrated and analyzed at the device level as well.

Changes to a Device. Device modifications that require a new FDA submission could include a new functionality, corrections, or evolution to a new generation of technology. The documentation required for such changes builds upon that originally submitted; however, information should be included for each review element, not just those affected by the changes. The documentation also should reflect the current version of the software and its revision history, since many minor changes and corrections will probably have been made since the original premarket submission.

A submission covering device changes should contain a description of the changes, including what was changed, why it was changed, and how the changes affect safety and reliability. It should also contain a comparison of the design, functionality, operation, performance, and safety and reliability features of the new and predicate devices. At present, the new IEC standard does not address these two requirements, but it does cover traceability and revision history. Traceability between the development life-cycle and risk-management activities for the new and predicate devices should be demonstrated in the documentation, and a revision history log that records chronologically changes made to the device and its associated life-cycle documentation should be maintained.


There is a strong correlation between FDA's software guidance document and IEC 601-1-4. Almost all of the premarket submission requirements identified in the software guidance document are addressed by the standard or its normative references. Therefore, IEC 601-1-4 can be a useful tool for demonstrating compliance with U.S. medical device software regulations, including those covered by the FDA guidance document.


Medical Electrical Equipment--Part 1: General Requirements for Safety--4, Collateral Standard: Programmable Electrical Medical Systems, IEC 601-1-4 (committee draft version), Geneva, Switzerland, International Electrotechnical Commission, July 1995.

(Return to text)

Herrmann D, "A Preview of IEC Safety Requirements for Programmable Electronic Medical Systems," Med Dev Diag Indust, 17(6):106-110, 1995.

(Return to text)

Reviewer Guidance for Computer-Controlled Medical Devices Undergoing 510(k) Review, Rockville, MD, FDA, Center for Devices and Radiological Health, August 1991.

(Return to text)

Debra S. Herrmann is a computer scientist in the Office of Science and Technology of FDA's Center for Devices and Radiological Health (CDRH). David A. Zier is an electrical engineer and senior reviewer in CDRH's Office of Device Evaluation.

FIGURE 1. U.S. regulatory hierarchy for medical device software.

Mission Protect the public health
Law(s) Federal Food, Drug, and Cosmetic Act
Safe Medical Devices Act of 1990
Medical Device Amendments of 1992, et al.
Regulation(s) Code of Federal Regulations, Title 21
Policy/Guidance Software reviewer guidance document, et al.
Standards IEC 601-1-4, et al.

TABLE I. U.S. regulatory hierarchy for medical device software.

Analysis Functional Logical
Dynamic Traditional testing
System integration
Trajectory-based testing
Static Formal scenario analysis
Code inspections
Cleanroom analysis
HAZOP analysis
Petri nets
Timing analysis
Testability analysis
Critical path analysis
Formal methods and proofs modeling
Software fault tree analysis and failure modes and effects analysis

Back to article

TABLE II. IEC 601-1-4 sections that correspond to FDA's documentation requirements for premarket submissions.

FDA Software Guidance Requirement IEC 601-1-4 Reference
New submissions .
Level of concern: .
- Software and device
- How it was determined
Descriptive data: .
- Development environment 52.207
- Intended operational environment 52.208
Labeling: .
- Intended use .
- Instructions for use 6.8.201
- Known nonhazardous anomalies 6.8.201
Development life-cycle activities: .
- Requirements specifications 52.206
- Architecture analysis 52.207
- Design specifications 52.208
- Test specifications 52.208
- Verification plan 52.209
- Validation plan 52.210.2
- Analysis of validation results 52.210.6
- Configuration management and change control 52.201.2, 52.211
- Compliance assessment report 52.212
Risk-management activities: .
- Risk-management plan 52.202
- Hazard analysis
- Hazard identification method(s)
- Risk likelihood estimation
and estimation method(s)
- Severity estimation and categorization method(s)
- Risk-control measures 52.204.4
- Evaluation of effectiveness of risk-control measures 52.204.6
Changes to a device .
Description of changes: .
- What changed .
- Why it was changed .
- Impact on safety and reliability .
Comparison of new and predicate device: .
- Design .
- Functionality .
- Operation .
- Performance .
- Safety and reliability .
Traceability to previous development life-cycle
and risk-management activities
52.201.2, 52.210,
52.211, 52.212
Revision history: 52.201.2
- Device/software .
- Specifications .
- Plans .
- Procedures .

Back to article

500 characters remaining