FDA/IEC Software Standard 62304

IEC- The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising all national electrotechnical committees (IEC National Committees). The object of IEC is to promote international co-operation on all questions concerning standardization in the electrical and electronic fields.

FDA has approved IEC 62304 as recognized software development standard, allowing submissions stipulating conformance to 62304
How FDA plays with it

• FDA uses QSIT in regard to auditing this area.
• By standardizing to 62304, companies can eliminate confusion during compliance audits, and especially show FDA personnel how the development happens for your S/W
• By adopting the standard, all staff will be on the same development platform, thus easing audits and lessening FDA Form 483’s and Warning Letters or worse.

Basic Assumptions
SOUP=software of unknown provenance (acronym)
SOUP is a SOFTWARE ITEM that is already developed and generally available and that has not been developed for the purpose of being incorporated into the MEDICAL DEVICE (also known as “off-the-shelf software”) or software previously developed for which adequate records of the development PROCESSES are not available
AUDIT TOOLS—REMEMBER FDA TIGHTLY AUDITS THIS UNDER 820.70(i) AND YOUR FIRM MUST CONTROL ALL SOUP VIA DESIGN, CHANGE PURCHASING AND DOCUMENT CONTROLS

Software safety classification

a) The MANUFACTURER shall assign to each SOFTWARE SYSTEM a software safety class (A, B, or C) according to the possible effects on the patient, operator, or other people resulting from a HAZARD to which the SOFTWARE SYSTEM can contribute.
The software safety classes shall initially be assigned based on severity as follows:
Class A: No injury or damage to health is possible
Class B: Non-SERIOUS INJURY is possible
Class C: Death or SERIOUS INJURY is possible

This standard does not specify an organizational structure for the MANUFACTURER or which part of the organization is to perform which PROCESS, ACTIVITY, or TASK. This standard requires only that the PROCESS, ACTIVITY, or TASK be completed to establish compliance with this standard.

This standard does not prescribe the name, format, or explicit content of the documentation to be produced. This standard requires documentation of TASKS, but the decision of how to package this documentation is left to the user of the standard.

This standard does not prescribe a specific life cycle model. The users of this standard are responsible for selecting a life cycle model for the software project and for mapping the PROCESSES, ACTIVITIES, and TASKS in this standard onto that model.

For the purposes of this standard:
· “shall” means that compliance with a requirement is mandatory for compliance with this standard
· “should” means that compliance with a requirement is recommended but is not mandatory for compliance with this standard
· “may” is used to describe a permissible way to achieve compliance with a requirement
·“establish” means to define, document, and implement
·REMEMBER—FDA DEFINES ESTABLISH THE SAME WAY
Compliance

Compliance with this standard is defined as implementing all of the PROCESSES, ACTIVITIES, and TASKS identified in this standard in accordance with the software safety class.

NOTE 1 This assessment could be carried out by internal or external audit{FDA expects this}

NOTE 2 Although the specified PROCESSES, ACTIVITIES, and TASKS are performed, flexibility exists in the methods of implementing these PROCESSES and performing these ACTIVITIES and TASKS.

NOTE 3 Where any requirements contain “as appropriate” and were not performed, documentation for the justification is necessary for this assessment.

NOTE 4 The term “conformance” is used in ISO/IEC 12207 where the term “compliance” is used in this standard.

Ref -
ISO 14971, Medical devices – Application of risk management to medical devices.
FDA expects ISO 14971 style r/m..although they cannot require it. By adopting thus standard, you now must comply to ISO 14971. ISO 13485:2003 also require ISO 14971
Make sure and study all of the definitions in the standard

Software Development plan

The MANUFACTURER shall establish a software development plan (or plans) for conducting the ACTIVITIES of the software development PROCESS appropriate to the scope, magnitude, and software safety classifications of the SOFTW ARE SYSTEM to be developed.
The s/w DEVELOPMENT LIFE CYCLE MODEL shall either be fully defined or be referenced in the plan (or plans).
AUDIT TOOL—INVESTIGATE DHF CONTENT FOR REQUIREMENT TRACES, MATRICES AND INTER-RELATIONSHIPS BETWEEN DEPARTMENTS

The plan shall address the following:

a) the PROCESSES to be used in the development of the SOFTW ARE SYSTEM
b) the DELIVERABLES (includes documentation) of the ACTIVITIES and TASKS;
c) TRACEABILITY between SYSTEM requirements, software requirements,
SOFTWARE SYSTEM test, and RISK CONTROL measures implemented software
AUDIT TOOL—PARSE APART THE DHF, SHOWING ALL PROCESSES IN USE,V/V FOR OTS S/W AND TRACE MATRICES