MD+DI Online is part of the Informa Markets Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Articles from 1995 In December

IoPP Honors Device Industry Packaging

Medical Device & Diagnostic Industry Magazine | MDDI Article Index

Originally published December 1995

Medical device industry winners of the Institute of Packaging Professionals (IoPP; Herndon, VA) 1996 AmeriStar Packaging Competition were announced at an awards ceremony held in Anaheim, California, last October, in conjunction with the Westpack 95 conference and exhibition.

The annual competition honors entries in 11 categories, including medical device packaging. Winners are selected by a panel of packaging industry experts and academics.

In the device category, the competition's gold star for 1995 was awarded to Nalge Co. (Rochester, NY) for its micro packaging vials. The vials are used for the packaging and shipment of small-volume diagnostic and molecular biology reagents. According to the company, the vials represent an improvement over previous models because they do not use O-rings that are prone to leaking or falling out, permitting the introduction of contaminants.

The second-place silver star was awarded to Boston Scientific Corp. (Watertown, MA) for its use of phosphorescent labeling on an esophageal catheter package. The labels are incorporated in the device package as well as on the shaft of the catheter and are intended to facilitate gastroenterological work in a room darkened during dilatation of an esophageal stricture. According to Robert Thompson, senior packaging engineer at Boston Scientific, gastroenterologists must often work in the dark in order to accurately view images on a video screen. "Phosphorescent labeling can eliminate a source of difficulty caused when the physician's eyes are exposed to light during complicated procedures," he says.

The bronze star was awarded to Sealed Air Corp. (Sycamore, IL) for its Korrvu suspension package for a cardiac monitor manufactured by Cardiac Evaluation Center, Inc. (CEC; Milwaukee). The package protects the product from shock, vibration, and impact by enclosing it between two close-fitting layers of plastic film suspended in the air space of the corrugated shipping container. The suspension design of the package also reduces the amount of packaging material required for the device.

For further information about the Ameristar Packaging Competition, contact Kathleen Deeney, IoPP membership services manager, at 703/318-8970.

--Steven Halasey

(This article originally appeared in the December 1995 issue of Medical Device & Diagnostic Industry. © 1995 CanonCommunications, Inc. All rights reserved.)

Device Groups Reach Consensus on FDA Reform Legislation

Medical Device & Diagnostic Industry Magazine | MDDI Article Index

Originally published December 1995

In a display of unity, three leading medical device industry groups have reached a consensus on FDA reform goals and have sent it to Congress in the form of draft legislation. The proposal, submitted as the Medical Device Reform Act of 1995, was developed by the Health Industry Manufacturers Association (HIMA; Washington, DC), the National Electrical Manufacturers Association (NEMA; Washington, DC), and the National Medical Device Coalition (NMDC; Washington, DC) over several months of discussion. The draft legislation arrived in the hands of key congressional members on October 12.

The legislation provides a detailed blueprint for reforming the agency, a process that the industry groups believe will enhance the competitiveness of U.S. device manufacturers and place medical technologies in the hands of U.S. consumers more rapidly. "We believe the reforms outlined in this legislation will help stem the outflow of innovative medical device products and jobs that are now moving offshore," says Alan Magazine, president of HIMA.

The industry proposal comprises a number of specific reform measures. One involves articulating a mission for the agency that emphasizes the enhancement of public health while deemphasizing enforcement. According to the draft, "A goal of [FDA] must be to ensure that the citizens of the United States receive this country's finest medical technology at the same time or before persons from other countries."

The draft legislation would require FDA to recognize applicable national and international consensus standards. The legislation would also create product review exemptions for devices that pose the least risk to patients. Under section 3, Class I devices would be exempt from the 510(k) requirement, and a regulatory process would be established for exempting Class II devices without the need to reclassify them. In an attempt to abolish the much-criticized reference list, FDA would be prohibited from delaying a 510(k) on the basis of a company's failure to comply with the agency's good manufacturing practices (GMP) regulation.

The section covering premarket notification provides one of the only instances in which a basic disagreement among the groups makes its way into the structure and language of the draft legislation. The major points of this section--510(k) exemptions, eliminating the reference list--reflect a consensus, but the draft then gives lawmakers two options to choose from. The HIMA and NEMA option would require FDA to review a 510(k) submission in 90 days or inform the submitting company of the need for additional time--in writing and with an expected completion date.

The NMDC option, on the other hand, would delete from the law the requirement that FDA issue an order before a product can be legally marketed. Under its alternative, if FDA did not find a device "not substantially equivalent" within 90 days, the company could proceed to deliver the device into interstate commerce. According to Larry Pilot of the law firm McKenna & Cuneo (Washington, DC), this option would restore the premarket notification concept that was in place from 1976 to 1990. Pilot serves as legal counsel to the Medical Device Manufacturers Association, one of the 10 industry groups that constitute NMDC.

Like premarket notification requirements, the premarket approval (PMA) process would be amended under the legislation to help move products out of the regulatory queue and into the hands of U.S. consumers. To achieve this end, the industry legislation would allow companies to use accredited third parties for 510(k) and PMA reviews and for GMP inspections. It would also expand the availability of investigational device exemptions beyond the requirement that a device address a life-threatening or "irreversibly debilitating" disease.

Although one might expect that the degree of compromise needed to hammer out a near-industrywide position would make for a fragile coalition, MDMA's Pilot disagrees. "I think there were only two major points of contention during the negotiation. One was the status of the Center for Devices and Radiological Health within FDA, which NMDC and NEMA clashed over. The other was the 'order' issue with respect to premarket notification, which was solved by including one option from NEMA and HIMA and another from NMDC. In all other instances, the parties involved seemed to recognize the contribution that the discussion and the resulting compromises were making to the public good."

The consensus proposal was given to key congressional members, including Senator Nancy Kassebaum (R-KS), chairwoman of the Senate Labor and Human Resources Committee, and Congressman Thomas Bliley (R-VA), chairman of the House Commerce Committee.

For a copy of the draft legislation, contact Beverly Ross of HIMA at 202/433-7262, Robin Wiley of NEMA at 202/457-8414, or Jeffrey Kimbell of NMDC at 202/898-5700.

--Jeff O'Connell

(This article originally appeared in the December 1995 issue of Medical Device & Diagnostic Industry. © 1995 CanonCommunications, Inc. All rights reserved.)

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

Medical Device & Diagnostic Industry Magazine | 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 II 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