The new article provides further details regarding the particular approach to be followed in order to achieve and maintain compliance with the relevant regulatory requirements.
Table of content
The Therapeutic Goods Administration (TGA), an Australian regulating authority in the sphere of healthcare products, has published a guidance document dedicated to the Essential Principle 13B. 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 and other parties involved in order to ensure compliance.
At the same time, the authority reserves the right to make changes to the guidance and recommendations provided therein, should such changes be reasonably necessary to reflect corresponding amendments to the underlying legislation. In particular, the guidance elaborates on how manufacturers can demonstrate compliance with Essential Principle (EP) 13B concerning the display of version and build numbers for medical device software.
It provides detailed advice on selecting the appropriate form and location for this information, depending on the nature of the device, its construction, and how users interact with it.
Choosing an Appropriate Form and Location for Version and Build Numbers
First of all, the TGA states that manufacturers must carefully select the form and location of the version and build numbers based on several factors. These factors include the type and construction of the device, intended users, the nature of user interactions with the device (such as through software interfaces), whether the device software is fixed or can be updated post-supply, the intended purpose of the device, and any other relevant considerations.
Considerations for Placement
EP 13.2 emphasizes that information about the device should be provided as close to the device as possible. When this isn’t feasible on the device itself, the information should be included on the packaging, in a leaflet, or in the instructions for use.
For software, this could mean publishing the version and building numbers on the manufacturer’s website or within the software itself, such as on the opening screen or an “About” page. It’s essential that users can easily link the device they have to the information provided, ensuring accessibility and traceability.
Manufacturers should consider whether the device has a physical or digital form, the type of user interface (if any), the size and form of any displays, the updatability of the software and whether the device is a system comprising multiple components.
Unique Device Identification (UDI) and Compliance
The Unique Device Identification (UDI) system is being developed to enhance the tracking and tracing of medical devices. Once implemented, UDI will become part of the Essential Principles but will not replace the current requirements.
If a medical device software bears a UDI that includes the version number as part of the UDI-Production Identifier (UDI-PI), this can satisfy the requirements of EP 13B.
For UDI to be applicable:
- It must be issued by an Australian-recognized Issuing Agency.
- It must be applied to the device, its packaging, and all higher levels of packaging or provided in a plain-text format on a screen, such as in an “About” box.
- It should be available in both Human Readable Interpretation (HRI) and Automatic Identification Data Capture (AIDC) formats, or in HRI format only if provided electronically.
- It must be easily accessible during normal operation and storage.
Demonstrating Compliance for Various Device Types
The document further provides additional clarifications regarding the approach to be applied with respect to different types of medical devices subject to regulation under the existing legal framework.
Devices with Fixed Software at the Time of Supply
According to the guidance, for devices that are supplied with fixed software (software that cannot be updated after supply), it is generally appropriate to display the version and build numbers on the device itself or the manufacturer’s website. This approach is practical since the version and build numbers will remain relevant for the device’s entire lifespan.
Case Study: A device used for diagnosing autism, which includes fixed software, may display the version and build numbers on a monitor integrated into the device. The manufacturer might choose to avoid manual labeling by showing this information on the screen, with further details provided in the instructions for use, accessible through a “Help” menu.
Devices with Updatable Software
For devices that include software that can be updated after supply, it is usually inappropriate to display version and build numbers on the device itself since this information could quickly become outdated. Instead, manufacturers should guide users on how to access the current version and build numbers through the device or an electronic platform.
Case Study: A blood glucose monitor paired with a mobile app for tracking readings would typically include version and build numbers within an “About” screen or settings menu within the app. The convention for these numbers would also be detailed in the instructions for use, ensuring compliance with EP 13B.
Systems and Devices with Multiple Software Components
For complex systems comprising multiple components, each running different software, manufacturers may need to provide separate version and build numbers for each component. This ensures traceability across the entire system.
Where a universal version or build number isn’t applicable, manufacturers must ensure that the provided information is sufficient for stakeholders to trace the device’s software throughout its lifecycle.
Devices Without Build Numbers
In cases where the concept of a build number isn’t used, manufacturers are not required to supply one. They may opt to use other identification numbers like batch or serial numbers, provided these offer clear traceability to the software version in use.
Devices Using the Same Version and Build Numbers
If a manufacturer’s version-control system doesn’t distinguish between version and build numbers, they may indicate that these numbers are identical. This approach is acceptable as long as it maintains traceability.
Use of Other Identification Numbers
Some manufacturers might prefer to use alternative identification numbers (e.g., batch, lot, or serial numbers) instead of maintaining separate version and build numbers. This is permissible as long as it allows precise identification of the software version in use.
Examples of Compliance
In addition to the above, the document provides a few examples demonstrating the particular way the regulatory approach described in the guidance should be applied in specific cases. However, it is important to mention that the said examples are provided for merely illustrative purposes, while in each of the cases, a separate assessment and analysis would be required.
Apps and Software as a Medical Device (SaMD)
For apps, version and build numbers are often included within an “About” section or displayed on the opening screen. This practice meets EP 13B requirements by providing necessary traceability information.
Software as a Service (SaaS)
SaaS-based medical devices, such as cloud platforms for analyzing patient data, may not fit traditional versioning models. Manufacturers must ensure relevant traceability information is available and accessible on user portals or screens.
Electronic Devices with Simple Displays
Devices with basic displays can show versions and build numbers directly on the screen, ensuring compliance with EP 13B.
Fixed Software or Firmware
Devices with fixed software that cannot be updated can have version and build numbers displayed on the device itself or the manufacturer’s website, providing a permanent record that remains accurate over time.
Implantable Devices
For implantable devices, version and build numbers might be provided through external programming equipment or on the manufacturer’s website. Additionally, this information could be included in patient information materials, ensuring accessibility and compliance with EP 13B.
Conclusion
In summary, the present guidance provides comprehensive advice for manufacturers on how to demonstrate compliance with EP 13B, ensuring that version and build numbers are appropriately displayed and accessible. According to the guidance, By following the recommendations provided therein, manufacturers can maintain the traceability of medical device software, enhancing safety and regulatory compliance throughout the product lifecycle.
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.
