# Presentation: 139610

## Software Overview In Vitro Diagnostic Devices

- The Office of In Vitro Diagnostic Device Evaluation and Safety (OIVD)
- Presented by
- James V. Callaghan

## IVD Premarket Review of Software

**Guidance for the Content of Premarket Submissions for Software **
**Contained in Medical Devices**
- Other FDA related guidances
- Policies impacting on IVD software controlled device
- Recognized standards

## Other FDA Related Guidance...

- Guidance for Industry, FDA Reviewers and Compliance of Off-The-Shelf Software Use in Medical Devices
- General Principles of Software Validation
- Glossary of Computerized System and Software Development Terminology

## Policies Affecting IVD’s

- 510(k) Memorandum #K86-3 ... (device combinations)
- Deciding When to Submit a 510(k) for a Change to an Existing Device
- Replacement Reagent Policy
- 510(k) Paradigm... (Special and Abbreviated)

## Recognized Standards

- AAMI/ ANSI SW68:2001, *Medical device software - Software life cycle processes *
- ISO 14971:2000, Medical devices - *Application of risk management to medical devices*
- NCCLS Suite of Lab Automation and Informatics Standards

## Documentation in an IVD Software Premarket Submission

- Level of Concern  - section 3.1
- Software Description  - section 3.2
- Device Hazard Analysis - section 3.3
- Software Requirements Specification (SRS) - section 3.4
- Architecture Design Chart - section 3.5
- Design Specification - section 3.6
- Traceability Analysis - section 3.7
- Development - section 3.8
- Validation, Verification and Testing - section 3.9
- Revision Level History - section 3.10
- Unresolved Anomalies (Bugs) - section 3.11
- Release Version Number - section 3.12

## Level of Concern - 3.1

- OIVD considers most IVD software to be at a moderate level of concern.
- Based on risk prior to software mitigations.
- Major Level - incorrect or delayed information could result in death or serious injury of the patient and/or operator.

## Section 3.1 (continue....)

- Clinical judgment overriding incorrect information - one lower level of concern (major to moderate).
- Healthcare Professionals are becoming increasingly more reliant on computer controlled devices.
- 21 CFR part 820 subpart C – Design Controls - follow and document all items in the guidance no matter what level of concern.

## Software Description - 3.2

- Total IVD Test System in terms of:
- Role of the software in the device such controlling functions, monitoring, data analysis....
- Interface with the user and with its subcomponents through the software...

## section 3.2 (continued....)

- Instrumentation description; random access, assay types, signal detection, instrument calibration descriptions....
- Information displays and user messages.
- Describe how the system determines and displays the analyte data analysis and any other displays or messages.

## section 3.2 (continued....)

- Errors conditions....
- Incorrect test processing,
- such as temperature errors, instrument calibration errors, process timing errors, using deteriorated or outdated reagents....
- Data processing errors,
- such as sample identification, record mismatch, database integrity, data transmission....

## section 3.2 (continued....)

- Alarms and other feedback.
- Describe error detection and recognition by the software.
- Describe error messages that are displayed.
- Describe how the system detects and alerts the user when signals are outside the range of the system.
- Describe any self-diagnostic routines that the system performs....
- Describe how the system responds to user actions or inaction or system status, e.g., voltage fluctuations or high ambient temperature....

## section 3.2 (continued....)

- Describe how the system recognizes and/or distinguishes use of quality control materials versus specimen.
- Describe how the system compensates for differences between reagent lots....

## Device Hazard Analysis 3.3 (includes risk management documentation)

- Conduct a hazard analysis to identify potential causes of system failures.
- Used as a basis for rating associated risks prior to mitigations,
- Identifies appropriate mitigations and residual risks to characterize the operational limits of the device.

## section 3.3 (continued....)

- Consult the following standards for help:
- ISO 14971-1, Medical devices - Risk Management - Part 1: Application of risk analysis
- ISO 14971:2000, Medical devices - Application of risk management to medical devices and
- EN 1441:1997, Medical Devices - Risk Management.

## section 3.3 (continued....)

- Hardware and electronics integrity...
- Evaluation of power,
- Evaluation of failure in hardware,
- Evaluation of failure in software,
- Evaluation of electronic failure,
- Incorrect timing of analysis
-    (semi-automation),
- Evaluation of physical trauma to  test system.

## section 3.3 (continued....)

- Hazards produced by use-related (process) failures ...
- Incorrect system setup,
- Incorrect system operation,
- Contaminated or outdated test reagents, calibrator, quality control materials or incorrect usage.

## section 3.3 (continued....) 

- Use-related (continued...)
- Incorrect specimen collection, pre-analytical processing,
- Failure to save/use stored data correctly,
- Improper maintenance of the test system.

## section 3.3 (continued....)

- The hazard analysis requires critical thinking on device design and impact of failure of subsystem components, operator error....
- Test system calibration stability issues - factors that may interfere with calibration baselines.

## section 3.3 (continued....)

- Failures due to environmental stress on the test system, reagents, specimens:
- Temperature, humidity, altitude,
- Variables related to sample processing,
- Electromagnetic compatibility,
- Physical stress....

## Hazard Analysis Results

- Present the hazard analysis in a tabular format.
- Include identified hazards, causes, mitigations, risks before and after mitigation and a link to provide traceability to the VV&T tests.
- List all hazards not mitigated to ALRP      (ISO-14971)
- Impact on safety and effectiveness on the IVD test system and accessories for these hazards.

## Software Requirements Specification (SRS) - 3.4

- Describes the specifications for the software imposed by the role of the software or firmware described in the Software Description and by the Hazard Analysis.
- The SRS provides a baseline for VV&T tests for the software.
- Documents each functional requirement and link them to VV&T tests in the submission.

## Section 3.4 (continued....)

-   The SRS for IVD test systems should take the following into consideration:
- What algorithms are implemented in the software to address software description and identified mitigations,
- Are all algorithms compatible with each other for all operations?
- What external interface is the software required to support?

## Section 3.4 (continued....)

- How does the software interact with people, the system’s hardware, other hardware and other software?
- Is any Off The Shelf (OTS) software or hardware to be used?  What software interface is required for them?
- What are the required software response times of various software functions?

## Section 3.4 (continued....)

- What OTS software components will be included in final product shipment?
- What hardware platform will the software be designed to run on as opposed to the hardware platform will the software be validated on?
- What software platform will the software be validated with?

## Section 3.4 (continued....)

- What are the hardware requirements for the system that the software is being designed for?
- Design Constraints – Are there any required standards in effect, implantation languages, operating environment, and hardware configurations?

## Refer Directly to the Software Guidance Document

- Architecture Design Chart - Section 3.5
- Design Specification - Section 3.6
- Traceability Analysis - Section 3.7
- Development - Section 3.8

## Validation, Verification and Testing -3.9 

- Validation of use should involve testing with users that involves realistic use, objective performance information and subjective evaluation by the users.
- Part of the validation should address whether the information (alarms, displays, messages, feedback, etc.) is sufficient to enable the user to use the device correctly.
- Method comparison and precision for representative assay types; not necessarily same assay specific reagent validation protocols

## Section 3.9 (continued....)

- Describe VV&T activities at the unit, integration and system level.
- Include error code, and result flag validation, system level test protocols, pass/fail criteria.
- Testing results (linked to the Hazard Analysis and software functional requirements).

## Section 3.9 (continued....)

- Specific process and elements to be considered include a discussion of testing results and a discussion of how the following was tested:
- fault, alarm, and hazard testing,
- error, range checking, and boundary value testing,
- timing analysis and testing,
- special algorithms and interpretation tests and analysis,
- stress testing,

## Section 3.9 (continued....)

- Specific process and elements (continued...)
- device options, accessories, and configurations testing,
- communications testing,
- memory utilization testing,
- qualification of OTS software
- acceptance and beta site testing, and
- regression testing.

## Section 3.9 (continued....)

- Provide a signed statement stating that
- all versions were developed and validated according to the described software development, verification and validation plan, and
- testing met predetermined acceptance criteria.
- Additional versions will follow these activities and meet acceptance criteria before release.

## Revision Level History – 3.10

-    Provide a complete revision history, denoting all changes and reasons for change implementation.

## Unresolved Anomalies (Bugs) -3.11

-     Include full disclosure of any unresolved anomalies remaining in the device.
- Discuss the impact on safety or effectiveness.
- No anomaly shall have an unacceptable risk associated with it.
- Include operator usage and human factors considerations as possible anomalies and risk analysis.

## Release Version Number

- Include the planned release version.
- Differences of tested version verses release version.
- discuss the impact of the differences on the safety and effectiveness of the device.

## Minor and Moderate Level of Concern IVD devices* 

- May comply to ANSI/AAMI SW68:2001-“Medical Device Software-Software life cycle processes”
- Requires the following our Guidance documentation:
**Software Description**
**Device Hazard Analysis**
**Software Requirements Specification**

- * Additional documentation for Consumer Use and New Technologies

## Complying with SW68:2001

- Rational for choosing:
- section 1.3.1 of SW68:2001 -Compliance for software that can cause a hazard or that controls risk,
- or 1.3.2 Compliance for software that cannot cause a hazard and that does not control risk.
- Hazards that may be indirectly caused by software, i.e. incorrect results leading to inappropriate treatment, should be considered when choosing compliance to 1.3.1 or 1.3.2.

## Complying with SW68:2001

- Provide a list of all items not addressed or variations in ANSI/AAMI SW68:2001 (Tailoring Report)
- Include justification on why these items were not addressed.
- CDRH has the right to deny recognition to an improperly tailored standard.

## Complying with SW68:2001

- List all hazards not mitigated to a broadly acceptable level -ISO 14971
- Describe mitigations
- VV&T activities and discuss the impact on safety and effectiveness on the test system and/or accessory for these hazards.

## Complying with SW68:2001

- Unresolved Anomalies (Bugs)
- Include full disclosure of any unresolved anomalie remaining in the device.
- A complete risk analysis should be preformed to determine the impact on safety or effectiveness.

## Complying with SW68:2001

- Bugs (continued....)
- No anomaly shall have an unacceptable risk associated with it.
- Include operator usage and human factors considerations as possible anomalies and risk analysis.

## Summary

- Overview of Software Guidance IVD Specific
- Policies that Impact on IVD Software Controlled Devices
- Recognition of Standards
- Alternate approaches for IVD Software Submissions

## Contact Information

- Jim Callaghan
- CDRH/OIVD
- 301-594-1243
- jvc@cdrh.fda.gov