The new article provides further clarification regarding the regulatory status of the software products intended to be used for patient image transmission, alerts for healthcare professionals, and clinical workflow management.

TGA Guidance on Clinical Evidence for Implantable Pulse Generator Systems: Overview

The Therapeutic Goods Administration (TGA), an Australian regulating authority in the sphere of healthcare products, has published a guidance document dedicated to the interpretation of software exclusion criteria. The document provides an overview of the applicable regulatory requirements, as well as additional clarifications and recommendations to be taken into consideration by medical device manufacturers (software developers) and other parties involved in order to ensure compliance. 

At the same time, provisions of the guidance are non-binding in their legal nature, and could be subject to changes, should such changes be reasonably necessary to reflect corresponding amendments to the underlying legislation.

Storing or Transmitting Patient Images

As explained by the TGA, exclusion 14H pertains to software specifically designed for the sole purpose of storing or transmitting patient images. This exclusion ensures that such software is not subjected to the same regulatory scrutiny as software with more complex functionalities like image analysis or diagnosis. 

The exclusion is defined by the software’s intended use and is strictly applied to software that does nothing beyond storing or transmitting images. To qualify for Exclusion 14H, the software must have one and only one purpose: storing or transmitting patient images. 

If the software possesses any additional capabilities, such as displaying images for diagnostic purposes, it may not be eligible for this exclusion. The term “sole purpose” is critical, as it emphasizes that the software must not be used for anything other than its primary function of image storage or transmission.

The exclusion applies to software intended solely for the electronic storage and transmission of digital images related to a patient’s health or condition. If the software also analyzes images to aid in diagnosis, screening, monitoring, or treatment, it falls outside the scope of this exclusion. 

Similarly, software designed to display images for diagnostic purposes or disease screening does not qualify for the exclusion.

In order to illustrate the above approach, the document also provides a few examples:

  • Excluded Example: A database that allows for patient images to be received, stored, and transmitted to other software systems is excluded. This software is purely a repository for images and has no additional functionalities. Explanation: The software is intended solely for storing and transmitting images without any further processing or analysis.
  • Not Excluded Example: An app that receives patient images from a health record and highlights areas that require further review by a health professional is not excluded. Explanation: This software goes beyond simple storage and transmission by analyzing images and providing medical insights, thus falling outside the exclusion’s scope.
FDA on assessing credibility of computational modelling2

Alerts for Health Professionals

Exclusion 14I covers software designed for the sole purpose of providing alerts to health professionals in relation to patient care. This exclusion ensures that software that simply notifies healthcare providers of relevant information is not classified as a medical device, provided it does not replace clinical judgment or engage in diagnostic or treatment activities.

To be excluded under 14I, the software must be designed solely to provide alerts to health professionals regarding patient care. It cannot have any other intended use. 

This narrow definition ensures that the software remains within the bounds of a communication tool, rather than a clinical decision-making aid. The software’s role is to prepare and communicate notifications (“alerts”) that pertain to various aspects of patient care. 

These alerts might remind healthcare providers of tasks such as dispensing medication or warn of potential drug interactions. Importantly, the software must not replace the clinical judgment of a health professional, nor should it diagnose, screen, treat, or recommend treatment for any medical conditions.

The relevant examples will include:

  • Excluded Example: Software that checks potential prescriptions and sends an alert to a health professional about known adverse drug interactions, allowing the professional to decide whether to proceed with the prescription. Explanation: This software is solely for alerting purposes and does not replace the healthcare provider’s clinical judgment or engage in diagnosing or treating a condition.
  • Not Excluded Example: Software that checks potential prescriptions and prevents the healthcare provider from proceeding with the original prescription by recommending alternative medications. Explanation: This software replaces clinical judgment and makes treatment decisions, which disqualifies it from being excluded.

Clinical Workflow Management

Another category of the software products described in the guidance pertains to clinical workflow management. In particular, exclusion 14J applies to software designed for clinical workflow management. 

This category of software is intended to streamline and optimize the operational aspects of healthcare, ensuring that processes are efficiently managed without directly engaging in clinical decision-making or treatment activities. Clinical workflow management refers to the coordination of various administrative and operational processes in a healthcare environment. 

This includes tasks like managing patient admissions, scheduling, and accessing digital medical histories. The primary goal is to improve the efficiency of healthcare delivery without making clinical judgments or decisions.

To qualify for Exclusion 14J, the software must:

  1. Be intended for clinical workflow management.
  2. Not make claims or engage in activities related to diagnosing, screening, preventing, monitoring, or treating any disease, condition, ailment, or defect.

Examples of such products would include:

  • Excluded Example: Software that facilitates patient admission to a hospital by guiding the user through standard procedures without making any clinical decisions or diagnoses. Explanation: This software is strictly for workflow management and does not make any claims about medical conditions or treatments.
  • Not Excluded Example: Software that manages patient admissions while also providing screening recommendations for various diseases. Explanation: The software’s additional functionality of screening and providing medical suggestions means it is involved in clinical decision-making, thus it does not qualify for the exclusion.

Conclusion

In summary, the document explains the exclusions 14H, 14I, and 14J intended to delineate the boundaries for specific types of healthcare-related software that are designed to support, but not directly engage in, clinical decision-making or treatment activities. The document provides additional clarifications, together with the relevant examples, in order to assist the parties responsible for healthcare products in determining their regulatory nature and the specific legal framework they should comply with.

How Can RegDesk Help?

RegDesk is an AI-powered Regulatory Information Management System that provides medical device companies with regulatory intelligence for over 120 markets worldwide. It can help you prepare and publish global applications, manage standards, run change assessments, and obtain real-time alerts on regulatory changes through a centralized platform. Global expansion has never been this simple.