Overview of ISO 14971

It has 9 clauses.
Clause -1 - Scope
It covers all medical devices including IVDs.
It applies to all phases of product life cycle.
It does not
-define acceptable risk
-Apply to clinical decision making
-Does not require quality system
Clause -2 - Definition
- Clause provides definitions of terms
- there are new terms and definitions
- To provide uniformity among standards many definitions are harmonized with other standards and also with Guide 51 which is used by ISO and IEC for common definitions
- Clause also contains updated definitions from ISO 9000:2005
Definition changes

-in vitro diagnostic medical device– “medical device intended by the manufacturer for the examination of specimens derived from the human body to provide information for diagnostic, monitoring, or compatibility purposes”

- life-cycle– “all phases in the life of a medical device, from the initial conception to final decommissioning and disposal”
- Post-production – new term – “part of the life-cycle of the product after the design has been completed and the medical device has been manufactured”
- Use error – “act or omission of an act that results in a different medical device response than intended by the manufacturer or expected by the user” – from IEC 62366
Clause -3 -General Requirements
- Sub-clause 3.2 “Management responsibilities” expands description of requirements and indicates that documentation created in the process and the risk management review can be part of the quality system documentation.
-Sub-clause 3.3 indicates in a Note that risk management activities can be performed by “representative of several functions, each contributing their specialist knowledge”
-Does not require a single individual be assigned the total responsibility for risk management
-Personnel assigned these activities must have proper training, background, education and experience
- Sub-clause 3.4 describes the Risk management plan
- Requirements unchanged
-In response to many comments in ISO 14971 voting process, extensive notes added to provide explanations and references to additional information in Annex D and Annex F

- Sub-clause 3.5 has been revised to include the traceability requirement removed from Clause 8 Risk management report
- Risk management report for complex devices was getting unwieldy
- Note indicates the Risk management file can be in any form or medium (such as electronic files)
Clause -4 - Risk Analysis
- Clause 4 covers Risk Analysis and Risk Estimation
- Sub-clause 4.1 re-titled to “Risk analysis process” from “Risk analysis procedure”
- New Notes point to informative annexes with additional information
- Sub-clause 4.2 Note 1 indicates “misuse is intended to mean incorrect or improper use of the medical device”
- Sub-clause 4.3 title changed to “Identification of hazards”
- Note points to E.2 and H.2.4 for guidance in hazard identification
- Sub-clause 4.4 title changed to “Estimation of the risk(s) for each hazardous situation”
- This is a new emphasis in Second Edition, from idea that harm cannot occur unless a Hazardous Situation leads to an exposure to a hazard
- Extensive notes used to explain this Subclause
Clause -5 - Risk Evaluation
- Evaluation requirement is in reference to “Hazardous situation” instead of “Hazard”
- Evaluation is comparison of Risk to Acceptability Criteria established in Risk Management Plan
Clause -6 - Risk Control
Sub-clause 6.1 removed requirement to reduce residual risk associated with each hazard to acceptable
- Addressed under “Residual Risk”
Sub-clause 6.2 Title changed to “Risk Control Option Analysis”
- Extensive Notes provide information and reference including use of other standards as part of option analysis
- Sub-clause 6.3 Implementation of risk control measure(s)
- Indicates that verification of effectiveness of risk control measures may include validation activities
- Sub-clause 6.4 Residual risk evaluation
- adds Note to Annex J for information on disclosing residual risk
- Sub-clause 6.5 Risk/benefit analysis
-Adds note referring to Annex D.6 for more information on Risk/benefit analysis
- Sub-clause 6.6 title changed to “Risks arising from risk control measures”
- Includes introduction of new hazards or hazardous situations
- Adds requirement that these new risks or increased risks be managed with process in sub-clauses 4.4 to 6.5
- Sub-clause 6.7 Completeness of risk control
- Changes “hazard” to “hazardous situation”
- Changes “The results of this assessment…” to “The results of this activity…”

Clause -7 - Evaluation of overall Residual risk acceptability
Clause 7 title changed to “Evaluation of overall residual risk acceptability”
- Adds requirement for deciding what information to disclose on overall residual risk
- Add reference to Annex D.7 on Overall residual risk
-Adds reference to Annex J on disclosure of residual risk
Clause -8 - Risk Management report
- Clause 8, removed the traceability requirement from the Risk management report to the Risk Management File (see Sub-clause 3.5)
- Adds requirements for responsibility for review and documentation of review that demonstrates
-“the risk management plan has been appropriately implemented;
-the overall residual risk is acceptable;
-appropriate methods are in place to obtain relevant production and post-production information.”

Clause - 9 - Production and post production process

- The Title was changed to “Production and post-production information” to emphasize that there is information available during production which is important to Risk Management
- Adds a requirements for systems collecting and reviewing device information

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