This document answers some Frequently Asked Questions (FAQs) about the certification of computer software for medical applications. The answers to the questions are not intended to provide a definitive technical answer but rather to inform the reader in a general manner.
SAFETY AGENCIES
SAFETY CERTIFICATION STANDARDS
Q. What does IEC-601508 require?
Q. Who determines which class is required?
Q. What is the total list of potential deliverables I will need to create for certification?
Q. How is a software verification performed?
Validated Software Corporation’s Validation Suite
Q. What are Validated’s Validation Suites?
Q. What comprises a Validation Suite?
Q. Is the Validation Suite a special version of the product code?
Q. Can the Validation Suite be reused on new projects?
Q. How do I order the Validation Suite?
Answers
SAFETY AGENCIES
IEC is the acronym for the International Electrotechnical Commission, the international standards and conformity assessment body for electrotechnology; specifically, functional safety of electrical/electronic/programmable electronic (E/E/PE) systems.
IEC is located in Geneva, Switzerland.
The IEC’s web site is: : www.iec.ch
The FDA is the acronym for the U.S. Food and Drug Administration. They can be reached at:
U.S. Food and Drug Administration
5600 Fishers Lane
Rockville, MD 20857-0001
Tel: 888-INFO-FDA (1-888-463-6332)
The FDA’s web site is: www.fda.gov
The CDRH is the acronym for the Center for Devices and Radiological Health. It is a sub-organization of the U.S. FDA, with the responsibility for all medical devices sold in the United States.
The CDRH web site is: www.fda.gov/cdrh
SAFETY CERTIFICATION STANDARDS
FDA Section 510(k), or Premarket Notification (or PMN), of the Food, Drug and Cosmetic Act requires device manufacturers to register and/or notify the FDA at least 90 days in advance of their intent to market a medical device. Specifically, medical device manufacturers are required to submit 501(k) premarket notifications if they intend to introduce a device into commercial distribution for the first time or reintroduce a device that will be significantly changed or modified to the extent that its safety or effectiveness could be affected. The safety implications are similar to FAA requirements, where life-critical devices and/or safety-critical devices are required to have a prudent design, code, and test/QA strategy in order to produce a product that is safe to use.
IEC-61508 was developed to create a standard for the functional safety of electrical/electronic/programmable electronic safety-related systems. IEC-61508 allows for the standalone certification of a software component, unlike FDA/CDRH. The documentation requirements of IEC-61508 tend to lean more heavily on design, usage, and manufacturing, due to the standalone component aspects of this certification. One of the most critical documents is the Safety Manual, which contains the rules and guidelines on how to use the software component in a system that is certified.
The IEC has a great FAQ at: http://www.iec.ch/61508/index.htm
Q. What does IEC-601508 require?
The IEC standard is published in seven parts, as shown in the table below:
IEC-61508 Part References
Reference
Full Part Title
61508-1
IEC 61508-1:1998, Functional safety of E/E/PE safety-related systems - Part 1: General requirements
61508-2
IEC 61508-2:2000, Functional safety of E/E/PE safety-related systems - Part 2: Requirements for E/E/PE safety-related systems
61508-3
IEC 61508-3:1998, Functional safety of E/E/PE safety-related systems - Part 3: Software requirements
61508-4
IEC 61508-4:1998, Functional safety of E/E/PE safety-related systems - Part 4: Definitions and abbreviations
61508-5
IEC 61508-5:1998, Functional safety of E/E/PE safety-related systems - Part 5: Examples of methods for the determination of safety integrity levels
61508-6
IEC 61508-6:2000, Functional safety of E/E/PE safety-related systems - Part 6: Guidelines on the application of IEC 61508-2 and IEC 61508-3
61508-7
IEC 61508-7:2000, Functional safety of E/E/PE safety-related systems - Part 7: Overview of techniques and measures
The first four parts of IEC-61508 define the way to comply with the specification. IEC-61508 can be used in a broad variety of safety-critical systems, including emergency shutdown systems in power plants, turbine controls, railway signaling systems, and other electromechanical systems in safety-critical environments.
IEC-60601 is a series of standards containing the requirements concerning basic safety and essential performance that are generally applicable to medical electrical equipment. These requirements may be supplemented or modified by the special requirements of a collateral or particular standard for certain types of medical electrical equipment.
The IEC 60601 standards series consists of four basic parts.
IEC 60601-1 defines the general requirements for electrical medical products.
Standards numbered IEC 60601-1-x are collateral standards that contain issues that deal with many different types of medical devices.
Standards numbered IEC 60601-2-x define the requirements for a specific type of medical device. Device specific standards can amend, modify, and/or supersede requirements specified in IEC 60601-1.
Standards numbered IEC 60601-3-x are performance requirements for specific types of devices.
Medical Electrical Equipment – Part 1: General Requirements for Safety, Collateral Standards:
IEC 60601-1-1
Safety Requirements for Medical Electrical Systems
IEC 60601-1-2
ELECTROMAGNETIC COMPATIBILITY - REQUIREMENTS AND TESTS
IEC 60601-1-3
General Requirements for Radiation Protection in Diagnostic X-Ray Equipment
IEC 60601-1-4
Programmable Electrical Medical Systems
IEC 60601-1-6
Usability
IEC 60601-1-8
General Requirements, Tests and Guidance for Alarm Systems in Medical Electrical Equipment and Medical Electrical Systems
Medical product classes (I, II and III) are based on the potential of the software to cause safety-related failures identified in the system safety assessment. The FDA/CDRH has three general safety classes:
Class III: Software whose failure could cause or contribute to the death or serious injury to the patient or clinician.
Class II: Software whose failure could cause or contribute to the serious injury to the patient or clinician.
Class I: Software whose failure could cause or contribute to the injury to the patient or clinician.
Q. Who determines which class is requried?
The level to which a particular system must be certified is selected by a process of failure analysis and input from the device manufacturers and the certifying authority (FDA), with the final decision made by the certifying authority. Note that software does not need to be certified specifically at each designated level. Certification at any level automatically covers the lower-level requirement; but, obviously, the converse is not true. Software certified at Class III can be used in most medical devices.
Q. What is the total list of potential deliverables I will need to create for certification?
The following table lists the documents and records you may need to provide for a 510(k) submission:
Software Life Cycle Data List
Document Title
Type Section PSAC
Plan for Software Aspects of Certification
Document 11.1 SDP
Software Development Plan
Document 11.2 SVP
Software Verification Plan
Document 11.3 SCMP
Software Configuration Management Plan
Document 11.4 SQAP
Software Quality Assurance Plan
Document 11.5 SRS
Software Requirements Standards
Document 11.6 SDS
Software Design Standards
Document 11.7 SCS
Software Code Standards
Document 11.8 SRD
Software Requirements Data
Document 11.9 SDD
Software Design Description
Document 11.10
Source Code
Software 11.11
Executable Object Code
Software 11.12 SVCP
Software Verification Cases and Procedures
Document 11.13 SVR
Software Verification Results
Records 11.14 SECI
Software Life Cycle Environment Configuration Index
Document 11.15 SCI
Software Configuration Index Document 11.16 PRs
Problem Reports Records 11.17
Software Configuration Management Records Records 11.18
Software Quality Assurance Records Records 11.19 SAS
Software Accomplishment Summary Document 11.20
Q. How is a software verification performed?
FDA 501(k) defines specific verification objectives that must be satisfied; these include:
Verification of software development processes
Review of software development life cycle artifacts
Functional Verification of software
a. Requirements-based testing and analysis
b. Robustness testingStructural Coverage Analysis
Structural Coverage Analysis is generally perceived to be the most difficult task to undertake by people unfamiliar with rigorous code development and testing. Furthermore, an operating system is tightly integrated with the hardware, cache, interrupts, memory management, and process/task management, thereby making structural testing even more difficult. These low-level aspects create a significant challenge to the verification process. For example, Class III certified applications should address:
Statement Coverage
Decision Coverage
Modified Condition/Decision Coverage
and from the code coverage table above along with:
Identification of dead or deactivated code
Traceability from source to object code
Fortunately, a variety of commercial tools are available to assist in this challenging task.
See our Code Coverage Tools page for a list of known vendors in this space.
Validated Software Corporation’s Validation Suite™
Q. What are Validated’s Validation Suites?
Validated’s Validation Suites are packages of standards, plans, requirements, designs, and tests to address manufacturers requiring safety certification documentation for projects. Validation Suites are typically developed for software products widely used in safety-critical products. The use of our Validation Suites allows developers to concentrate on their core product and lower their costs by purchasing an essentially off-the-shelf Validation Suite as a component.
Q. What comprises a Validation Suite?
Due to different requirements for different certification levels, the amount of documentation will differ, but, in general, the following documentation will be provided in Level A through Level C Validation Suites.
Validation Suite Component
Item
Plan for Software Aspects of Certification (PSAC)
11.1
Software Development Plan (SDP)
11.2
Software Verification Plan (SVP)
11.3
Software Configuration Management Plan (SCMP)
11.4
Software Quality Assurance Plan
11.5
Software Requirements Standard
11.6
Software Design Standard
11.7
C Language Coding Standard
11.8
Software Requirements Document (SRD)
11.9
Microprocessor Port Requirements and Design Documents
11.9
Software Design Document
11.10
Software Source Code, Test Code and Build Code
11.11
Software Port Image
11.12
Software Unit Test Plans and Procedures
11.13
Software Integration Test Plans and Procedures
11.13
Software Unit Test Reports
11.14
Software Integration Test Report
11.14
Software Test Coverage Report
11.14
Software Life Cycle Environment Configuration Index
11.15
Software Configuration Index
11.16
Software Problem Report History
11.17
Software Change History
11.18
Software Quality Assurance Data
11.19
Software Accomplishment Summary (SAS)
11.20
In addition, Validated also offers port-specific documentation to provide all the board support package (BSP) documentation, for example:
Port Software Design Description, Special I/O
Port Software Design Description, Special 80x86 Protected Mode Port
Q. Do I also have to pay another manufacturer for a production license when I purchase a Validation Suite?
Yes. The Validated Suite does not include a production license for the software.
Yes. The Validation Suite contains all source code to the product and all source code to test files, all test scripts, and all build/make files. Please note however that all of the products we validate are licensed by another manufacturer. As such we can not ship source code to a product until we receive confirmation from the manufacturer that you have a valid license in place with them.
Q. Is the Validation Suite a special version of the product code?
No. The source code we provide is functionally identical to the manufacturers original code. In some cases the code may belong to a "safety-critical" version of the manufacturers product, but this is the exception not the rule.
Q. Can the Validation Suite be reused on new projects?
Yes. Depending upon the system changes between projects, the Validation Suite can be used for multiple projects. (Note that additional license fees for both MicroC/OS-II and the Validation Suite may apply, regardless of re-use.)
MicroC/OS-II was chosen for many reasons:
MicroC/OS-II is a very stable operating system that has been used in tens of thousands of systems and hundreds of commercial applications. It has been in use for over 10 years, with minor modifications made periodically.
MicroC/OS-II has been “open source” since its creation. Therefore, it has been reviewed by thousands of individuals. But, unlike some open source projects, revisions are tightly controlled and reviewed by Micrium, and then openly reviewed by the MicroC/OS-II community.
MicroC/OS-II was written against a very strict coding standard, which improves readability, understandability, and maintainability – all key aspects of creating software used in critical systems.
Every line of MicroC/OS-II is well documented. This is extremely rare in the software industry and is ideal for safety certification where the mapping of requirements to source code to test for every line of code is required.
Q. How do I order the Validation Suite?
All Validated Software products can be ordered from the Validated Software Sales office.