You are here

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: Digital Devices Webinar 3, 20 June 2019

Webinar presentation: Proposed Reforms to the Regulation of Software, Including Software as a Medical Device - Consultation Results

15 July 2019

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: Dr Elizabeth McGrath
  • Presented at: Digital Devices Webinar 3
  • Presentation date: 20 June 2019

Transcript

Proposed Reforms to the Regulation of Software, Including Software as a Medical Device - Consultation Results

Dr Elizabeth McGrath
Director, Emerging Technologies
Medical Devices and Product Quality Division

Digital Devices Webinar 3, 20 June 2019

Slide 1 - Welcome

  • Links will be provided to you in the window below during the webinar
  • To ask a question, please type a question in the message box
  • Messages are privatised to Moderator and Speaker only
  • A reference page of links mentioned will be displayed at the end of event
  • Slides will be made available on the TGA website in the near future

Difficulties hearing sound from your computer?

  • Contact Redback services for support on 1800 733 416

Slide 2 - Purpose

  • Australian regulation of software - missing elements
  • International approaches
  • Proposed regulatory reforms
  • Consultation results
  • Registration questions
  • Live questions

Slide 3 - Australian regulation of software

Slide 4 - When is software regulated?

Software is regulated by the TGA

  • When it is part of a hardware medical device or medical device system
  • When it controls a medical device
  • When it meets the definition of a medical device.

That is, when the legal manufacturer intends for the software to be used for:

  • diagnosis
  • prevention
  • monitoring
  • treatment or
  • alleviation, of disease, injury or disability

Slide 5 - Current classification rules for software

Schedule 2

4.1  Active medical devices - general
An active medical device is classified as Class I, unless the device is classified at a higher level under another clause in this Part or in Part 2, 3 or 5.

Regulation 3.3

(5)  If a medical device is driven, or influenced, by an item of software, the software has the same classification as the medical device.

Most software is Class I under the current rules

Slide 6 - Current essential principles for software

12.1  Medical devices incorporating electronic programmable systems
A medical device that incorporates an electronic programmable system must be designed and produced in a way that ensures that:

(a) the performance, reliability, and repeatability of the system are appropriate for the intended purpose of the device; and
(b) any consequent risks associated with a single fault condition in the system are minimised.

Slide 7 - International approaches

Slide 8 - International medical device regulators forum

The IMDRF Software as a Medical Device Working Group proposed the following risk categories for SaMD:

  • IMDRF proposed risk classification for SaMD (IV, III, II, I is equivalent to Australian III, IIb, IIa, I)
State of healthcare
situation or condition
Significance of information provided by SaMD to healthcare decision
treat or diagnose drive clinical management inform clinical management
critical IV III II
serious III II I
non-serious II I I

Slide 9 - International medical device regulators forum

To treat or to diagnose

  • Treating and diagnosing infers that the information provided by the SaMD will be used to take an immediate or near term action:
    • To treat/prevent or mitigate by connecting to other medical devices, medicinal products, general purpose actuators or other means of providing therapy to a human body
    • To diagnose/screen/detect a disease or condition (i.e., using sensors, data, or other information from other hardware or software devices, pertaining to a disease or condition).

Slide 10 - International medical device regulators forum

To drive clinical management

  • Driving clinical management infers that the information provided by the SaMD will be used to aid in treatment, aid in diagnoses, to triage or identify early signs of a disease or condition will be used to guide next diagnostics or next treatment interventions:
    • To aid in treatment by providing enhanced support to safe and effective use of medicinal products or a medical device.
    • To aid in diagnosis by analyzing relevant information to help predict risk of a disease or condition or as an aid to making a definitive diagnosis.
    • To triage or identify early signs of a disease or conditions.

Slide 11 - International medical device regulators forum

To Inform clinical management

  • Informing clinical management infers that the information provided by the SaMD will not trigger an immediate or near term action:
    • To inform of options for treating, diagnosing, preventing, or mitigating a disease or condition.
    • To provide clinical information by aggregating relevant information (e.g., disease, condition, drugs, medical devices, population, etc.)

Slide 12 - International medical device regulators forum

IMDRF Essential Principles of Safety and Performance for Medical Devices 2018

5.8 Medical Devices and IVD Medical Devices that Incorporate Software or are Software as a Medical Device

  • 5.8.1 Medical devices and IVD medical devices that incorporate electronic programmable systems, including software, or are software as a medical device, should be designed to ensure accuracy, reliability, precision, safety, and performance in line with their intended use. In the event of a single fault condition, appropriate means should be adopted to eliminate or appropriately reduce consequent risks or impairment of performance.
  • 5.8.2 For medical devices and IVD medical devices that incorporate software or are software as a medical device, the software should be developed, manufactured and maintained in accordance with the state of the art taking into account the principles of development life cycle (e.g., rapid development cycles, frequent changes, the cumulative effect of changes), risk management (e.g., changes to system, environment, and data), including information security (e.g., safely implement updates), verification and validation (e.g., change management process).

Slide 13 - International medical device regulators forum

IMDRF Essential Principles of Safety and Performance for Medical Devices 2018

5.8 Medical Devices and IVD Medical Devices that Incorporate Software or are Software as a Medical Device (continued)

  • 5.8.3 Software that is intended to be used in combination with mobile computing platforms should be designed and developed taking into account the platform itself (e.g. size and contrast ratio of the screen, connectivity, memory, etc.) and the external factors related to their use (varying environment as regards level of light or noise).
  • 5.8.4 Manufacturers should set out minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorized access, necessary to run the software as intended.
  • 5.8.5 The medical device and IVD medical device should be designed, manufactured and maintained in such a way as to provide an adequate level of cybersecurity against attempts to gain unauthorized access.

Slide 14 - International medical device regulators forum

IMDRF Principles of Labelling for Medical Devices 2019

8.0 Labelling Principles for Medical Devices Containing Software or Software as a Medical Device

  • 8.1 Software that is incorporated into a medical device or IVD medical device or that is intended for use as software as a medical device (SaMD) should be identified with an identifier, such as version, revision level or date of build release/issue. The unique identifier should be accessible to the intended user, unless the medical device does not have a wired or wireless electronic interface.
  • 8.2 For software incorporated into a medical device or IVD medical device, the identifier does not need to be on the outside of the medical device or IVD medical device.
  • 8.3 For SaMD without a physical form or packaging, the label may be available electronically. In this situation, the medical device should incorporate a means for the user to easily access the electronic label via the software itself or via inclusion of a web address or other means.

Slide 15 - New requirements in Europe

The EU MDR 2017/745 has introduced the following new classifications for software (Annex VIII 6.3, Rule 11):

  • Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as Class IIa except if such decisions have an impact that may cause:
    • death or an irreversible deterioration of a person’s state of health, it is Class III
    • a serious deterioration of a person’s state of health or a surgical intervention, it is Class IIb

Software intended to monitor physiological processes is classified as Class IIa except if it is intended for monitoring of vital physiological parameters where the nature of variations of those parameters is such that it could result in immediate danger to the patient, in which case it is Class IIb.

All other software are classified as Class I.

note: The EU already has an additional classification rule applicable to software compared with Australia:
(Rule 16 MDD 93/42/EEC)
Devices specifically intended for recording of X-ray diagnostic images are in Class IIa.

Slide 16 - New requirements in Europe

The EU MDR 2017/745 has introduced the following new classifications for software (Annex VIII 6.3, Rule 11):

State of healthcare situation or condition Provides information used to take decisions for diagnosis Provides information used to take decisions for treatment Monitors physiological processes (Vital/ Non-vital)
Critical (Vital) III III IIb
Serious (Vital) IIb IIb IIb
Non-serious (Non-vital) IIa IIa IIa

Silent on Software that Directly Provides Therapy: Defaults to Class I

Slide 17 - New requirements in Europe

EU MDR 2017/745 General Safety and Performance Requirements

17. Electronic programmable systems — devices that incorporate electronic programmable systems and software that are devices in themselves

  • 17.1. Devices that incorporate electronic programmable systems, including software, or software that are devices in themselves, shall be designed to ensure repeatability, reliability and performance in line with their intended use. In the event of a single fault condition, appropriate means shall be adopted to eliminate or reduce as far as possible consequent risks or impairment of performance.
  • 17.2. For devices that incorporate software or for software that are devices in themselves, the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation.
  • 17.3. Software referred to in this Section that is intended to be used in combination with mobile computing platforms shall be designed and manufactured taking into account the specific features of the mobile platform (e.g. size and contrast ratio of the screen) and the external factors related to their use (varying environment as regards level of light or noise).

Slide 18 - New requirements in Europe

EU MDR 2017/745 General Safety and Performance Requirements

17. Electronic programmable systems and software (continued)

  • 17.4. Manufacturers shall set out minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended.

23.4. Information in the instructions for use

  • (f) where applicable, information allowing the healthcare professional to verify if the device is suitable and select the corresponding software and accessories;
  • (ab) for devices that incorporate electronic programmable systems, including software, or software that are devices in themselves, minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended.

Slide 19 - US FDA requirements

Software Classification

  • By comparison to existing products - no classification rules
  • If no comparator: PMA or DeNovo assessment

Software Quality Safety and Performance Requirements

  • No essential principles - new regulation for each type of device

New Pilot Pre-cert Program for Software Manufacturers

  • Certifies manufacturers (Australia and EU already do this)
  • Criteria based in good QMS practice for software

Slide 20 - Proposed regulatory reforms

Disclaimer
The proposed regulatory reforms (pages 21-26) are subject to formal consideration and approval by the Australian Government. Please refer to the disclaimer at: https://www.tga.gov.au/tga-presentation-digital-devices-webinar-3-20-june-2019#disclaimer

Slide 21 - Proposed new requirements in Australia

  • New rules to appropriately classify Software products according to the potential harm they could cause to patients
  • Exclude Software products from the personal importation provisions so that SaMD products will be required to be included in the ARTG and have an Australian sponsor
  • Ensure the essential principles for medical devices include clear and transparent requirements for demonstrating the safety and performance of Software.

Consultation: Regulation of software, including Software as a Medical Device (SaMD)

Slide 22 - Proposed classification rules for software

Software that processes data (e.g. - images, sensor data, big data) to provide information for diagnosing a disease or condition and that is intended to:

  • Make a direct diagnosis (e.g. - self testing, emergency situation, rural or remote medicine) for:
    • a critical situation where the disease or condition is fatal or debilitating in a short timeframe, or poses a risk to public health, or a serious situation where the disease or condition is not life threatening but may cause a serious deterioration in a person’s state of health if not identified. The device is Class III.
    • any other situation. The device is Class IIa.
  • Screen patients to determine the need for further assessment for:
    • a disease or condition that is fatal or debilitating in a short timeframe, or that poses a risk to public health. The device is Class III.
    • a disease or condition that is not life threatening but may cause a serious deterioration in a person's state of health if not identified. The device is Class IIb.
    • any other situation. The device is Class IIa.
  • Aid a clinician in making a diagnosis. The device is Class IIa.

Slide 23 - Proposed classification rules for software

Software that processes data to provide information for treatment or intervention in a disease or condition and that is intended to:

  • Specify a treatment or intervention that will be administered without further consideration (e.g. - the patient will inject the amount of insulin calculated) where:
    • the treatment or intervention, or its absence, could result in death or debilitation.
      • The device is Class III.
    • the treatment or intervention, or its absence, could be harmful.
      • The device is Class IIb.
    • the treatment or intervention, or its absence, is unlikely to cause harm.
      • The device is Class IIa.
  • recommend a treatment or intervention for a clinician to decide and administer.
    • The device is Class IIa.

Slide 24 - Proposed classification rules for software

Software that provides therapy through direct interaction with a patient where:

  • The software directs patient activity based on input from the patient and could result is patient harm (e.g. - directing a recovering heart patient to undertake activity that is too vigorous).
    • The device is Class IIb.
  • The software directs patient activity based on input from the patient and the activity is unlikely to cause harm.
    • The device is Class IIa.
  • The software directs patient activity based on a non-interactive intervention.
    • The device is Class I.

Slide 25 - Proposed classification rules for software

State of healthcare
situation or condition

Processes data to provide information for:

Provides therapy by Directing patient activity based on:

Diagnosis Specifying treatment

For direct diagnosis

For patient screening

As clinician's diagnosis aid

For direct treatment

As clinician's treatment aid

Input from patient

Non-interactive intervention

Critical

III III IIa III IIa IIb I

Serious

III IIb IIa IIb IIa IIb I

Non-serious

IIa IIa IIa IIa IIa IIa I

Slide 26 - Proposed additions to the EPs

It is proposed to add the following points of clarification into the essential principles.

Manufacturers should ensure that:

  • the features, capabilities and risks of the computing platform be taken into account during design and manufacturing
  • the cyber security risks associated with network connectivity be minimised
  • software be designed and produced using best practice software engineering principles
  • medical devices indicate when critical features and connections are or are not enabled, and provide appropriate alarms
  • best practice cyber security principles be used regarding the risk of unauthorised access to the device
  • medical devices be designed to facilitate software updates, and information about the clinical risk of an update is provided to the user
  • requirements relating to the computer platform, operating system, accessories and network security be provided in the instructions for use

Slide 27 - Consultation results

Slide 28 - Consultation submissions

Slide 29 - Consultation submissions

Agreed

Mostly agreed

Partly agreed Opposed No response
Manufacturer 4 5 3 2 1
Industry Association/organisation 3 0 2 1 0
Healthcare representative body 3 2 0 1 0
Other 1 1 0 0 1
Consumer peak body 2 0 0 0 0
Research organisation 1 0 1 0 0
Federal Government Department 1 1 0 0 0
State/Territory Government 2 0 0 0 0
University 0 0 0 1 0
Not for profit 1 0 0 0 0
18 9 6 5 2

Slide 30 - Consultation submissions

Agreed

Mostly agreed

Partly agreed Opposed No response
Manufacturer 4 5 3 2 1
Industry Association/organisation 3 0 2 1 0
Healthcare representative body 3 2 0 1 0
Other 1 1 0 0 1
Consumer peak body 2 0 0 0 0
Research organisation 1 0 1 0 0
Federal Government Department 1 1 0 0 0
State/Territory Government 2 0 0 0 0
University 1 0 0 0 0
Not for profit 1 0 0 0 0
19 9 3 3 6

ADD IMAGE

Slide 31 - Consultation submissions

Agreed

Mostly agreed

Partly agreed Opposed No response
Manufacturer 4 4 2 1 4
Industry Association/organisation 4 0 0 1 1
Healthcare representative body 3 2 0 1 0
Other 1 1 0 0 1
Consumer peak body 2 0 0 0 0
Research organisation 1 0 1 0 0
Federal Government Department 1 1 0 0 0
State/Territory Government 2 0 0 0 0
University 1 0 0 0 0
Not for profit 1 0 0 0 0
20 8 3 3 6

Slide 32 - Generally opposed

  • Medical software used to support or provide recommendations about prevention, diagnosis or treatment of diseases should not come under the purview of the proposed recommendation. This is quite different from the case of medical devices like pacemakers and their operating systems which could cause serious harm and require a strict regulatory system.
  • Pathology software should be regulated via existing accreditation systems (i.e. ISO standards) and not have another level of regulation imposed.
  • A regulatory approach originally designed for devices and medicines is not fit for purpose for software, is unlikely to achieve the intended benefits, and could have the unintended consequence of increasing risks to patients and users through inhibiting improvements and upgrades in software.

Slide 33 - Opposed to new classification rules

  • We do not support the proposed classification rules. Under the new proposal, our apps would be classified as Class IIa devices which would incur significant costs. The costs of registering our apps as Class IIa devices would be prohibitive and we would no longer be able to innovate in this area. Withdrawal of our apps due to cost would have a negative impact on patients and their doctors. Instead, we suggest that SaMDs remain Class I devices.
  • Our software does not perform any diagnostic or therapeutic functions. It does not collect any patient data. Under current classification rules, our product is classified as a Class I device. Under the proposed scheme, our product would be classified as Class IIa. Compliance with Class IIa requirements is too onerous. [Is it a device?

Slide 34 - Wants more clarity

  • In case of AI with machine learning, it is unclear how TGA regulates it.
  • It is unclear how TGA regulates services using SaMD.
  • If the changed regulation is unclear and not transparent, manufacturers or vendors may hesitate to distribute health IT or SaMD in Australia.
  • What about open source software?
  • Is software used as a QA tool for SaMD regulated?
  • Need definitions of key terms used in the consultation document to avoid misunderstanding and to provide adequate clarity for developers seeking to comply with the new classifications and requirements.
  • Clarification around the pre-market review process for SaMD versus traditional medical device products would help.
  • Clarity regarding when new approvals are required.
  • Need examples of software that would NOT be considered medical devices.

Slide 35 - Suggestions

  • Fees and charges should be minimised. They should scale based on organisation size.
  • Should harmonise with international regulatory regimes relating to digital health products across medical regulation and data privacy and security.
  • Provide an understanding of the timeframes companies may face when seeking to gain regulatory approval for both existing and new SaMD products and consideration to the level of support required of the TGA in this transition period.
  • We support unambiguous, risk-based classification rules that are based on the IMDRF framework.
  • The classification rules should align with the EU MDR.
  • Excluding SaMD from personal importation could prevent access to innovative products.
  • Provide financial support for NFP organisations developing SaMD to meet their regulatory obligations.
  • Mental health SaMD should be specifically addressed in the classification rules.
  • Provide regulatory advisers, guidelines, templates and toolkits to support sponsors in complying with the new requirements.
  • Some low risk products should be exempt from regulatory oversight based on specified criteria, as undertaken by the US FDA.

Slide 36 - Alignment of classification rules

Proposed Australian classification rules for SaMD with

EU classification shown in RED where different

State of healthcare
situation or condition

Processes data to provide information for:

Provides therapy by Directing patient activity based on:

(note: software that provides therapy is not addressed in the EU rule)

Diagnosis Treatment

For direct diagnosis

For patient screening

As clinician's diagnosis aid

For direct treatment

As clinician's treatment aid

Input from patient

Non-interactive intervention

Critical

III III IIa

IIIb

III IIa

III

IIb

I

I

Serious

III

IIb

IIb IIa

IIb

IIb IIa

IIb

IIb

I

I

Non-serious

IIa IIa IIa IIa IIa IIa

I

I

Slide 37 - Alignment of classification rules

Proposed Australian classification rules for SaMD with

IMDRF classification shown in GREEN where different

State of healthcare
situation or condition

Processes data to provide information for:

Provides therapy by Directing patient activity based on:

Diagnosis Treatment

For direct diagnosis

For patient screening

As clinician's diagnosis aid

For direct treatment

As clinician's treatment aid

Input from patient

Non-interactive intervention

Critical

III III

IIb

IIa

IIIb or IIa

III IIa

IIb or IIa

IIb

III

I

III

Serious

III

IIb

IIb

IIa

IIa

IIa or I

IIb IIa

IIa or I

IIb

IIb

I

IIb

Non-serious

IIa IIa

I

IIa

I

IIa IIa

I

IIa

IIa

I

IIa

Slide 38 - Registration questions

Slide 39 - Answers to registration questions

  • How are Artificial Intelligence and Machine Learning technologies regulated?
    • As software products
      • AI and ML technologies are implemented in software
      • Are medical devices if the intended purpose meets the definition
      • Additional challenges for assessment methods and change management

Slide 40 - Answers to registration questions

  • When are software updates required to be assessed by the TGA?
    • It depends upon the risk
      • A software update is a change to the medical device, and is treated as such
      • The manufacturer conducts a risk assessment to determine the impact on safety and performance and the need for regulator notification
      • Software updates that are likely to affect patient safety, or introduce new features are likely to require pre-market assessment
      • Routine updates that have little or not clinical risk are unlikely to require pre-market assessment
      • Change management is reviewed during manufacturing audits

Slide 41 - Answers to registration questions

  • Will the classification of IVD medical device software change?
    • The IVD classification rules are separate and will be consulted separately
      • The current proposed changes to classification rules will only affect non-IVD medical devices

Slide 42 - Answers to registration questions

  • Is electronic medical records (EMR), laboratory information management systems (LIMS), or practice management software regulated?
    • Maybe
      • Check if any features of the package meet the definition of a medical device
      • If the system is modular, some of the modules may be medical devices
      • Products may become medical devices if regulated features are added

Slide 43 - Live poll

Elizabeth is currently reading over the online submitted questions and will be back with your shortly for Q&A. We'd appreciate your participation to complete our live poll.

Slide 44 - Questions?

Slide 45 - More information

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.