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.
View how it is placed among other Medical Device Standards.
Scope of the Standard
- Provides a framework of life cycle processes with activities and tasks necessary for safe design and maintenance of medical device software.
- Identifies two additional concurrent processes
–Software configuration management
–Software problem resolution process
- Assumes that medical device software is developed and maintained with in a Quality Management System (QMS) and a risk management system per ISO 14971
- Basic Assumption : 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
- This standard requires documentation of TASKS, but the decision of how to package this documentation is left to the user of the standard.
- Some additional risk management is required for software (addressed in Clause 7 – Software risk management process.
Out of Scope
- Is not a Quality Management System (QMS)
- 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.
- Does not specify content of documentation to be developed for example it does not prescribe the name, format, or explicit content of the documentation to be produced.
- Does not prescribe a specific lifecycle model such as:
- Waterfall
- Iterative
- Evolutionary
- 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.
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
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
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 SOFTWARE 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 SOFTWARE 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