Guidance on how to interpret Essential Principle 13B and how it applies to your device.
This guidance aims to assist sponsors, manufacturers, and software developers to understand the requirements of Essential Principle 13B.
It provides information on how to interpret Essential Principle 13B and how it applies to your device.
To supply a medical device in Australia, the sponsor or manufacturer must be able to demonstrate their medical device meets the relevant Essential Principles (EPs) for safety, quality, and performance.
For regulatory purposes, a software developer will be considered the manufacturer when their product is a regulated medical device.
The Essential Principles are legislative requirements.
41C - The Essential Principles set out the requirements relating to the safety and performance characteristics of medical devices. Therapeutic Goods Act 1989
Schedule 1 of the Therapeutic Goods (Medical Devices) Regulations 2002 describes the EPs in full.
There are 6 general EPs that apply to all medical devices.
There are a further nine EPs. They relate to design and construction that apply to medical devices on a case by-case basis.
See the Essential Principles checklist to review the EPs in full.
The Therapeutic Goods (Medical Devices) Regulations 2002 were amended in December 2019. They clarify requirements for regulated software. The changes to software-based medical devices came into effect on 25 February 2021 and included changes to the EPs.
EP 13B was introduced requiring the current version and build number to be accessible and identifiable to users of medical devices that are software or incorporate software. This information must appear in English and may be displayed in any other language as well.
Transition arrangements were made available for medical devices already included in the ARTG to meet the requirements of EP13B.
All medical device software must meet EP13B requirements by November 2024.
Sponsors are required to note that there are no transition arrangements available for EPs 12.1 and 13.2(3) as these changes clarified existing requirements and did not introduce any new requirements.
EP 13B requires manufacturers of software, or medical devices that incorporate software, to make the current software version number and build number (where applicable) accessible and identifiable to users.
For a medical device that is software, or that incorporates software, the current version number and current build number of the software must be accessible by, and identifiable to, users of the device.
The current version number and current build number of the software:
- Must be in English; and
- May also be in any other language
This principle applies to medical devices incorporating all forms of software including firmware and Software as a Medical Device regardless of the complexity of the software or its functions.
Version and build numbers help manufacturers, developers, sponsors, healthcare professionals, consumers, and us to identify and trace software.
Traceability must be implemented through the total product lifecycle of a device from the initial conception through to end-of-life and obsolescence.
Traceability is an important consideration to allow manufacturers and us to identify device-specific adverse event signals and take targeted and efficient post-market action.
It is key to demonstrating compliance with the applicable EPs including EP 12.1 including that the developer/manufacturer has implemented appropriate design controls and processes for product improvements over the software lifecycle.
There are many different types of version and build numbering systems currently in use.
The Therapeutic Goods (Medical Devices) Regulations 2002 (the Regulations) do not specify use of a particular style or convention.
This means manufacturers can choose how they demonstrate compliance with EP 13B.
Figure 1 - Version build and number
Figure 1 is an example that could be used (semantic versioning) – it follows the major. minor. Version. build version and build numbering approach.
Some software based medical devices can operate on more than one operating platform.
For these products, the manufacturer may demonstrate the associated operating platforms by including relevant information in the version and build number for the software component.
For example, Figure 2 indicates the 92.0.902.7201 version and build number of Beans AutoScan DX is made to run on the BeanOS 32-bit operating system, while another version–build might be developed for BeanOS 64-bit.
Manufacturers should include an explanation of the general approach selected to inform the users of version and build number.
This explanation, as well where to find the version and build number, should be included with the information provided with the device.
Figure 2- Documenting version and build number convention
Figure 2 indicates the 92.0.902.7201 version and build number of Beans AutoScan DX is made to run on the BeanOS 32-bit operating system, while another version–build might be developed for BeanOS 64-bit.
Manufacturers must determine the most appropriate form and location for the version and build numbers, depending on the device.
You will need to consider:
EP 13.2 requires manufacturers to provide information about their device as close to the device as possible.
If the information cannot be provided on or in the device, then it should be provided on the packaging, in a leaflet, in instructions for use or similar.
For software, this means the version and build number could be published on the manufacturer’s website or somewhere in the software, such as on the opening screen or in an “About” style screen.
Where the version and build number is provided on the website, users must be able to easily link the product they have to the information published on the website.
Consider:
Further guidance, including case studies, for choosing an appropriate location is provided below for devices:
We have been working towards finalising the Unique Device Identification (UDI) regulations and engaging with sponsors on the UDI requirements.
Implementation timeframes and compliance dates will be published as soon as they are confirmed.
The UDI is a globally harmonised identifier that can support tracking and tracing of medical devices.
UDI requirements, including labelling and provision of UDI data to the Australian Unique Device Identification Database (AusUDID) will be part of the EPs.
These requirements will not override the existing requirements of the EPs in the Medical Device Regulations. It will also not override the requirement to provide patient information materials.
You may meet the requirements of EP 13B if your medical device software bears a Unique Device Identifier (UDI) that includes the version number as part of the UDI-Production Identifier (UDI-PI).
For this to be applicable, your UDI must:
Devices taking a physical form with fixed software (software that cannot be updated after supply), it is generally appropriate to include the version and build numbers on the:
In this case, the expectation is that the version and build numbers will remain current for the lifetime of the device.
Example: A single-use laparoscope incorporating firmware.
Case study
A manufacturer is producing an eye-tracking device that helps physicians with the diagnosis of autism spectrum disorder.
The device contains static software and hardware (a monitor, stereo camera, infrared cameras, and control system).
The software is loaded just prior to supply of the device. It is static and will not be updated after supply. The manufacturer has a choice of providing the version and build numbers physically on the device, but this will involve a manual step of etching or labelling that the manufacturer wishes to avoid. Instead, as the device includes a monitor as one of the components, the manufacturer chooses to show the version and build number at the bottom of the screen.
The version and build number convention are detailed in the manufacturer's instructions for use available in the 'help' menu, satisfying the requirements of EP 13B.
For devices containing software that can be updated after supply, it is generally not appropriate to include the version and build numbers on the device itself.
This is because the information on the device will be out-of-date as soon as the software is updated.
The manufacturer should provide information to the user explaining how to identify and access the current version and build numbers from the device itself or through another electronic mechanism.
Case study
A manufacturer is manufacturing a blood glucose monitor paired with a mobile phone app to record glucose readings so patients can keep track of readings.
The device contains static hardware and an updatable software as a mobile phone app.
For the phone app component, as it is updatable, the manufacturer might choose to include the version and build number details in an About screen of the app.
In some cases, this information may be displayed on the app’s settings/configuration screen.
The version and build number convention are detailed in the manufacturer’s instructions for use available in the ‘Help’ menu or instructions for use, satisfying the requirements of EP 13B.
Some devices are systems comprising multiple components that each run different software. For example, a device could comprise of the following components:
Other devices (that aren’t systems) contain multiple embedded components, each running different software.
For example, a device could have a display (running firmware) as well as central processing unit running diagnostic software.
Where there is no universal version or build number set covering all components of the system or device, the manufacturer could choose to provide details of the version and build numbers for each component to the user via the app.
Whichever method is selected, the version and build numbers information provided to the user must be sufficient to enable manufacturers, sponsors, healthcare professionals, consumers, and the TGA to identify and trace the device’s software through the total product lifecycle of the device.
In some instances, a device will have an associated version number but won’t have a build number. Some software developers do not use the concept of build number in their development and release management process. In this case, the manufacturer would not be required to supply a build number.
Some manufacturers use version-control systems that do not distinguish between version numbers and build numbers.
In this case, the manufacturer can choose to indicate the version and build numbers are one and the same. For instance:
Some manufacturers may want to use an identification or other tracking number (such as batch, lot, serial numbers, etc) of the finished device instead of maintaining separate version numbers or build numbers.
Figure 3 - Same version and build number information
For example, Figure 3 indicates the manufacturer could choose to use the same number for version and build identification as used for the other number.
In this case, the manufacturer could choose to use the same number for version and build identification as used for the other number.
Whether or not other identification numbers are used in place of separate version and build number, the manufacturer must ensure its manufacturing and production systems provide clear and unambiguous traceability to the software residing in all components that make up the device.
It must always be possible for the manufacturer to precisely determine the current version and build numbers of the device’s software in its version control and configuration management systems from the identification number stated against the ‘Version–Build number’ label.
Examples
The following sub-sections provide examples of ways a manufacturer could meet the requirements of EP 13B for a range of different types of medical device software.
Apps and Software as a Medical Device
It is common for manufacturers of apps to include version and build numbers within an 'About' section or on the opening screen.
Software as a Service
Some digital devices are web services or supplied in the form of software as a service (SaaS). For example, a cloud-based web platform functioning as a medical device by analysing patient clinical data or images. This means the simple concept of version and build number may not be sufficient to meet the principle of traceability for safety. Relevant information must be made readily available and easily accessible on the portal or featured on a user screen.
Version and build numbers may be displayed via simple displays or screens when these are incorporated into a medical device.
Some devices incorporate software that is pre-programmed and cannot be updated, and such devices are commonly designed without any direct means of user communication (such as external connection ports).
In this case, manufacturers can include the version and build numbers on their website, providing the device can be easily linked by the user to the website information.
Some manufacturers may choose to mark the version number on the device itself (where possible and appropriate) via laser etching, other types of permanent marking or adhesive labels.
The manufacturer may also provide the version and build numbers in a leaflet provided with the device. As above, an identification or other tracking number (such as batch, lot, serial numbers, etc) of the finished device can also be used, if appropriate.
For implantable devices that can be reprogrammed or monitored remotely (such as pacemakers), the manufacturer could make the version and build numbers available via the external programmer or monitoring equipment, or on the manufacturer’s website.
The manufacturer may also provide the version and build numbers to the patient via patient information leaflets and implant cards, or on the manufacturer’s website
Title changed from 'Essential Principle 13B guidance' to 'Complying with identification requirements for medical devices that contain software' as part of migration to new 'Guidance' content type:
Original publication.
Title changed from 'Essential Principle 13B guidance' to 'Complying with identification requirements for medical devices that contain software' as part of migration to new 'Guidance' content type:
Original publication.
