TGA Internet site archive

The content on this page and other TGA archive pages is provided to assist research and may contain references to activities or policies that have no current application. See the full archive disclaimer.

TGA presentation given at the MSIA and MTAA, 27 May 2015

The regulation of software - medicines, biological, blood, tissues and devices

16 July 2015

Disclaimer

These presentation papers are provided on the TGA's website solely for the purpose of indicating or suggesting what TGA representatives spoke about to the various conferences and seminars to which it relates. The papers are not legislative in nature and should not be taken to be statements of any law or policy in any way.

The Australian Government Department of Health (of which the TGA is a part) advises that (a) the presentation papers should not be relied upon in any way as representing a comprehensive description of regulatory requirements, and (b) cannot guarantee, and assumes no legal liability or responsibility for, the accuracy, currency or completeness of the information contained in the presentation paper.

Presentation

  • Presented by: David Wotton and Elizabeth McGrath
  • Presented at: MSIA and MTAA, 27 May 2015
  • Presentation summary: This presentation is an overview of the software regulated by the TGA, a brief introduction to the International Medical Device Regulators' Forum's Software as a Medical Device project and details of how the TGA takes a systems approach to the regulation of software.

Transcript

The regulation of software - medicines, biological, blood, tissues and devices

David Wotton and Elizabeth McGrath

MSIA and MTAA, 27 May 2015

Slide 1

Presentation to:

  • the Medical Software Industry Association (MSIA) of Australia
  • the Medical Technology Association of Australia (MTAA)
  • Slide 2 - Disclaimer

    • The Australian Government Department of Health (of which the TGA is a part) advises that:
      1. this presentation should not be relied upon in any way as representing a comprehensive description of regulatory requirements, and
      2. cannot guarantee, and assumes no legal liability or responsibility for, the accuracy, currency or completeness of the information contained in the presentation paper or auditory statements.
    • The presentation is not legislative in nature and should not be taken to be statements of any law or policy in any way.
    • The presentation is not intended to be representative of the views of the International Medical Device Regulators' Forum and should not be taken to be statements of the forum's policy or position in any way.

    Slide 3 - Today

    • Regulated by the TGA
    • IMDRF SaMD Project
    • A systems approach
    • Key messages and Q&A

    Slide 4 - Regulated by the TGA

    Administered by the TGA

    Legislation
    • Therapeutic Goods Act 1989
    • Therapeutic Goods Regulations 1990
    • Therapeutic Goods (Medical Devices) Regulations 2002
    • Other legislative instruments including excluded and exempt goods orders

    Slide 5 - Regulated by the TGA

    • Software with a therapeutic purpose (medical device software)
    • Software used in manufacturing
    • Software for maintaining quality management systems
    • Software, systems, and toolsets applicable to all

    Slide 6 - Regulated by the TGA

    Software with a therapeutic purpose (medical device software)

    • Infusion pumps and blood-pressure monitors
    • IVD instruments and equipment (e.g., analysers, pregnancy testers)
    • Portable electronic devices, e.g., pacemakers, hearing aids, defibrillators
    • Patient monitors, ECGs, MRIs, and radiation-therapy machines
    • And many more...

    Slide 7 - Regulated by the TGA

    Software with a therapeutic purpose (medical device software)

    • Embedded software (firmware, EPROM, etc)
    • Mobile, server (incl. cloud), desktop programs and apps
    • Programmable hardware (e.g., FPGAs)
    • Software that drives or controls other medical devices

    Slide 8 - Regulated by the TGA

    Software used in manufacturing

    • Building-management systems
    • Production, sterilisation, water, and cleaning systems...
    • Statistical-process control systems
    • Lab equipment used in manufacturing

    Applies only to systems used for or affecting production (manufacture)

    Slide 9 - Regulated by the TGA

    Software for maintaining quality management systems

    • Enterprise resource planning systems
    • Documentation management systems
    • Corrective Action Preventive Action systems
    • Training and record-keeping systems Other compliance systems

    Applies only to QMS/GMP/compliance (not divorced business) systems

    Slide 10 - Regulated by the TGA

    Software, systems, and toolsets applicable to all

    • Backup, fail-over, and redundant systems
    • Infrastructure and security systems (networks, firewalls, etc.)
    • Software-development toolsets (IDEs, compilers, etc.)
    • Monitoring and management systems (including load, performance, analysis)

    Easily overlooked but important aspects of QMS/GMP, performance, and safety

    Slide 11 - Regulated by the TGA

    Software with a therapeutic purpose (medical device software)

    Medical devices

    Therapeutic Goods Act 1989, section 41BD:

    • (1) A medical device is: a) any instrument, apparatus, appliance, material or other article (whether used alone or in combination, and including the software necessary for its proper application) intended, by the person under whose name it is or is to be supplied, to be used for human beings for the purpose of one or more of the following:
      • i. diagnosis, prevention, monitoring, treatment or alleviation of disease;
      • ii. diagnosis, monitoring, treatment, alleviation of or compensation for an injury or disability;

    cont(...)

    Slide 12 - Regulated by the TGA

    Software with a therapeutic purpose (medical device software)

    The intended purpose

    Section 41BD (2) states that the intended purpose is to be derived from labelling, instructions, advertising material, and technical documentation provided by the legal manufacturer.

    NOTE:

    • The Secretary may declare particular things, devices, classes, types, or articles to be medical devices or not.
    • Such a declaration under this section does not stop articles from being therapeutic goods.

    Slide 13 - Regulated by the TGA

    Software with a therapeutic purpose (medical device software)

    When software becomes a medical device

    Software becomes a medical device when it meets the definition, that is, when the legal manufacturer intends for the software to be used in:

    • diagnosis;
    • prevention;
    • monitoring;
    • treatment; or
    • alleviation of disease, disability, etc.

    The manner, form, material not relevant to whether an item meets the definition.

    Slide 14 - Regulated by the TGA

    Software with a therapeutic purpose (medical device software)

    How medical device software is regulated in Australia

    Software is regulated under the medical devices regulatory framework

    • Regulation is risk based
    • Manufacturers are required to demonstrate that their devices meet the Essential Principles of Safety and Performance
    • Manufacturers apply Conformity Assessment procedures
    • Different classes require different Conformity Assessment procedures to be applied by the manufacturer

    For further information, refer to:

    Slide 15 - Today

    • Regulated by the TGA
    • IMDRF SaMD Project
    • A systems approach
    • Key messages and Q&A

    Slide 16 - IMDRF SaMD Project

    Software as a Medical Device guidance documents

    1. Software as a Medical Device (SaMD): Key Definition (pdf,119kb)
    2. Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations (pdf,242kb)
    3. Software as a Medical Device (SaMD): Application of Quality Management System (consultation underway)

    Slide 17 - IMDRF SaMD Project

    1. IMDRF definition of Software as a Medical Device

    Software as a Medical Device (SaMD) is defined as software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.

    This includes:

    • mobile phone and tablet apps,
    • desktop applications (e.g., radiation treatment planning SW),
    • software that runs in the cloud (e.g., Web applications), and
    • software that runs on any other general-purpose computing platform (smart watches, smart eyewear, etc.)

    Slide 18 - IMDRF SaMD Project

    1. IMDRF definition of Software as a Medical Device

    The SaMD definition excludes:

    • embedded device SW
    • SW that controls or drives hardware devices
    • SW used for maintaining quality systems
    • SW for manufacturing control & monitoring systems
      • production, sterilisation, and cleaning systems
      • building management systems
      • etc.

    Slide 19 - IMDRF SaMD Project

    The definition of SaMD in context

    Health IT is comprised of TGA/IMDRF Software Scope, Medical Device Software and SaMD

    Slide 20 - IMDRF SaMD Project

    1. IMDRF definition of Software as a Medical Device

    SaMDs predominantly manage information rather than (directly) controlling the administration of energy or substances to or from a patient.

    The information is then used directly for diagnosis or indirectly for treatment*.

    The GHTF/IMDRF regulatory model makes minimal reference to information as a potential source of harm.

    *Cognitive behavioural therapy applied by an SaMD would be considered by the TGA to be direct treatment.

    Slide 21 - IMDRF SaMD Project

    2. Proposed risk categorisation and considerations document

    Objective is to introduce:

    • a foundational approach,
    • establish a common understanding for SaMD,
    • harmonised vocabulary, and
    • general and specific considerations

    for manufacturers, regulators, and users

    Notes

    • No intention to replace or modify existing regulatory classification schemes or requirements. Further efforts required prior to regulatory use.

    Slide 22 - IMDRF SaMD Project

    2. Proposed risk categorisation and considerations document

    Contents
    • Introduction
    • Scope (including objectives)
    • Definitions
    • SaMD Definition Statement
    • Framework principles
    • General considerations
      • Design and development
      • Changes
    • Specific considerations
      • Socio-technical environment
      • Technology and system environment
      • Information security with respect to safety
    • Appendices
      • Clarification of definition of SaMD
      • Analysis of SaMD framework with existing classifications
    • References

    Slide 23 - IMDRF SaMD Project

    2. Proposed risk categorisation and considerations document

    Some challenges with software

    Highly connected and dependent nature of software means that disruption in the ecosystem can result in loss of information, delayed, corrupted, or mixed patient information, or inaccurate information which may lead to incorrect or inaccurate diagnoses and/or treatments.

    Recent example:

    A change to the firewall rules on a hospital network made by IT staff resulted in the alarm signals from patient monitors in ICU not being delivered to the nurses' station.

    Slide 24 - IMDRF SaMD Project

    2. Proposed risk categorisation and considerations document

    Software-related 'failures' => Where software is involved in an adverse event
    • Most relate to problems with requirements (incomplete or flawed assumptions)
    • Changes in socio-technical environment
    • System errors mis-attributed as 'user errors' (errors following user actions)
    • Insufficient controls for maintaining safety
    • The software behaved exactly as designed...
    • Traditional safety engineering approaches based on probability analysis (FMEA, FTA, HAZOP, etc.) have limited applicability to complex systems
    • Emergent properties (safety is an emergent property)

    Slide 25 - IMDRF SaMD Project

    2. Proposed risk categorisation and considerations document

    SaMD Categories
    State of Healthcare situation or condition Significance of information provided by SaMD to Healthcare decision
    Treats or Diagnoses Drives clinical management Informs clinical management
    Critical IV III I
    Serious III II I
    Non-Serious II I I

    Slide 26 - IMDRF SaMD Project

    2. Proposed risk categorisation and considerations document

    • SaMD Definition Statement
    • Socio-technical environments
    • Technology and system environments
    • Information security with respect to safety
    • Reduced (external) verification options
    • Importance of a methodical and systematic development process

    Slide 27 - IMDRF SaMD Project

    2. Proposed risk categorisation and considerations document

    The proper and safe functioning of SaMD is highly dependent on a sufficient and common understanding of the socio-technical environment that includes the manufacturer and the user.

    Software that is highly reliable and correct can be unsafe.

    Slide 28 - IMDRF SaMD Project

    3. Software as a Medical Device (SaMD) mapped to ISO 13485

    The objective of this third document is to provide guidance on the application of existing, standardised, and generally accepted quality management system (QMS) practices to SaMD.

    Consultation out now (closes Monday 1 June 2015)

    Slide 29 - Today

    • Regulated by the TGA
    • IMDRF SaMD Project
    • A systems approach
    • Key messages and Q&A

    Slide 30 - A systems approach

    The TGA approaches inspections and reviews by:

    • taking a holistic rather than reductionist view
    • treating safety and performance as a dynamic control problem rather than a reliability problem
    • identifying system behaviour safety constraints
    • assessing the sufficiency and adequacy of controls put in place by manufacturers

    Safe - May include specific performance requirements (e.g., timing in a pacemaker)

    Slide 31 - A systems approach

    Some of the lifecycle steps

    • Design
    • Develop
    • Monitor
    • Improve
    • Report

    The TGA looks to see that the manufacturer:

    • designs for safety and performance
    • develops for quality, robustness, resilience, and predictability
    • monitors, reports, and improves

    using appropriate, sufficient, robust, and defensible tools, approaches, and methods.

    With sufficient breadth and depth of expertise.

    Slide 32 - A systems approach

    Safe state(s)

    Safety-constraint examples:
    • Temperature limits
    • Toxicity limits
    • Timing limits
    • Accuracy, specificity
    • Voltage, current, frequency of applied energy
    Types of controls:
    • technical,
    • process (e.g., procedures),
    • social (people),
    • environmental,
    • etc.
    Example controls:
    • Visual inspection procedures for steps in manufacture
    • PCDs, monitoring of temperature, humidity, and vacuum for EtO sterilisation machine
    • Real-time ECG monitoring for patient monitor
    • Database integrity constraints

    Slide 33 - A systems approach

    Review of safety controls

    The TGA will look at controls that might affect safety, e.g.:

    1. An unsafe control action is provided that creates a hazard
    2. A required control action is not provided to avoid a hazard
    3. A potentially safe control action is provided too late, too early, or in the wrong order
    4. A continuous safe control action is provided too long or is stopped too soon
    5. A control action required to enforce a safety constraint (avoid a hazard) is provided but not followed (e.g., a procedure or instruction provided by the manufacturer).

    Slide 34 - A systems approach

    Where applicable, the TGA might look for:

    • Necessary and sufficient technical (including clinical) competence
    • Understanding of safe system states and constraints
    • Resilience engineering (robust, resilient designs)
    • Use of appropriate and sufficient risk-management tools, e.g., STPA
    • Methodical and systematic design and development (e.g., design patterns and contracts)

    Designs for safety and performance

    - ISO/IEC/IEEE 29148; IEC 62304; ISO 14971; IEC/TR 80002-1; and IEC 62366.

    Slide 35 - A systems approach

    Where applicable, the TGA might look for:

    • Lifecycle development of software (i.e., IEC 62304)
    • Use of good software- and systems-engineering practice
    • Understanding of benefits and limitations of chosen development tools
    • Use of appropriate and sufficient risk-management tools
    • Methodical and systematic design and development (e.g., design patterns and contracts)

    Development for quality, predictability

    - ISO 13485; ISO/IEC/IEEE 29148; IEC 62304; ISO 14971; and IEC/TR 80002-1.

    Slide 36 - A systems approach

    The TGA might also look for:

    • Signal monitoring and analysis (ISO 13485, leading safety indicators)
    • Understanding of limitations of monitoring processes (shadow faults, medical and domain context of use)
    • Adverse-event and fault reporting (transparency) and investigations
    • Trends analysis
    • Corrections, corrective actions, and preventive actions

    Monitoring, reporting, and continual improvement

    - ISO 13485; ISO/IEC/IEEE 29148; IEC 62304; ISO 14971; and IEC/TR 80002-1.

    Slide 37 - A systems approach

    Post-market monitoring, surveillance, and action

    • Capturing and tracking incidents and complaints involving software is a significant challenge.
    • Manufacturers are expected to identify leading safety indicators and are required to link incidents to CAPA and risk management activities - closing of the feedback loop...
    • Recognise, Retain, and Report campaign

    Not easily detectable after supply

    Easily detectable after supply

    Difficult but possible to detect after supply

    Essentially undetectable (not possible to identify SW system failure as the cause)

    Slide 38 - Please report adverse events (incidents)...

    Large datasets are needed for the identification of shadow faults.

    In addition to the direct management of safety issues, the data reported to us helps us to see trends and better understand the causes of adverse events where software is involved.

    Your reporting helps us to identify and respond to safety matters.

    Website: www.tga.gov.au

    Slide 39 - Today

    • Regulated by the TGA
    • IMDRF SaMD Project
    • A systems approach
    • Key messages and Q&A

    Slide 40 - Recap Key messages and Q&A

    • The TGA regulates a broad range of software systems.
    • A holistic systems - engineering approach is used
    • Many factors may be reviewed during an inspection or review
    • Lifecycle, design and development, monitoring, and reporting are very important elements for safety
    • Please help by reporting adverse events

    Slide 40 - Q&A

    Key messages and Q&A

    TGA information services:

    • Safety alerts
    • Recall actions
    • Medicines Safety Update
    • Medical Devices Safety Update
    • Consultations
    • Publications
    • Scheduling

    Website: www.tga.gov.au

    Print version

    How to access a pdf document

    *Large file warning: Attempting to open large files over the Internet within the browser window may cause problems. It is strongly recommended you download this document to your own computer and open from there.