Requirements management software for medical devices in Australia
One traceable record from user need to verification evidence, built for the Essential Principles, ARTG inclusion and a TGA assessment.
Short answer: to supply a medical device in Australia you have to show that it meets the Essential Principles in Schedule 1 of the Therapeutic Goods (Medical Devices) Regulations 2002, hold the evidence that proves it, and have an Australian sponsor who can produce that evidence on request. Requirements management software is how teams keep that evidence complete and current instead of rebuilding it for every application and every market. Matrix Req is the tool we build for that job. This page covers what the Australian regime asks of your requirements process, the clauses it rests on, and what to look for in a tool.
We work at Matrix One, the company behind Matrix Req, so read this as a vendor's account of its own market. We have tried to make it useful anyway by citing the regulation and the clauses rather than asserting things about ourselves, and by saying plainly further down who Matrix Req is wrong for.
Australian teams end up maintaining the same evidence several times over
One connected record that every regime can be mapped to
Supplying Australia means meeting the Essential Principles in Schedule 1, holding evidence your Australian sponsor can produce on request, and often reusing an assessment from an overseas regulator. When requirements, risks and test results live in separate documents, every market gets its own pack, every pack drifts, and the differences turn up during an assessment.
Matrix Req holds requirements, risks, test cases and results in one system with live links between them. The traceability an assessor or your sponsor asks for is a view of that data rather than a document somebody rebuilds, and the same record supports your TGA application, your EU technical documentation and your FDA submission.
Australian teams end up maintaining the same evidence several times over
Supplying Australia means meeting the Essential Principles in Schedule 1, holding evidence your Australian sponsor can produce on request, and often reusing an assessment from an overseas regulator. When requirements, risks and test results live in separate documents, every market gets its own pack, every pack drifts, and the differences turn up during an assessment.
One connected record that every regime can be mapped to
Matrix Req holds requirements, risks, test cases and results in one system with live links between them. The traceability an assessor or your sponsor asks for is a view of that data rather than a document somebody rebuilds, and the same record supports your TGA application, your EU technical documentation and your FDA submission.
Built for the Australian regulatory stack
What Matrix Req gives a medical device team supplying the Australian market.
What does the TGA require from your requirements process?
Nothing in Australian law names a tool or a category of tool. What it names is evidence. You have to hold proof that your device meets each applicable Essential Principle, and be able to produce it when the TGA or your sponsor asks. Every requirements management decision in Australia follows from that single obligation.
Which legislation sets the rules?
The Therapeutic Goods Act 1989 is the primary legislation. The Therapeutic Goods (Medical Devices) Regulations 2002 carry the operational detail: the Essential Principles in Schedule 1, the classification rules in Schedule 2 and Schedule 2A, and the conformity assessment procedures in Schedule 3. The class assigned under the Schedule 2 rules decides which Schedule 3 procedure applies, and the higher the class the more rigorous the procedure. Our guide to Australian medical device regulations covers the wider TGA process. This page is about the evidence underneath it.
What do the Essential Principles actually ask you to prove?
Schedule 1 works much the way Annex I of the EU MDR does. For each Essential Principle you either show how the device meets it or record why it does not apply. Building the checklist is not the hard part. The hard part is that every entry has to point at a real requirement, a real risk control and a real verification result, and in most organisations those three things live in three different systems maintained by three different people.
Who holds the evidence, the manufacturer or the Australian sponsor?
Both, in different senses. The manufacturer holds the evidence that the Essential Principles are met. The Australian sponsor, who holds the entry in the Australian Register of Therapeutic Goods, has to hold that evidence as well or be able to obtain it from the manufacturer on request within a reasonable time. If your traceability is a document somebody assembles by hand, every sponsor request becomes a small project and the answer is only ever as current as the last export.
How does the comparable overseas regulator pathway change how you keep evidence?
The TGA accepts market authorisation evidence and assessment reports from comparable overseas regulators and assessment bodies, among them notified bodies designated in European member states, the United States Food and Drug Administration, approved bodies designated by the MHRA in the United Kingdom, and Singapore's Health Sciences Authority. That evidence can abridge the assessment the TGA has to carry out.
The catch is that abridgement only pays off if your evidence agrees with itself. A manufacturer holding one set of requirements, risks and verification results, mapped to each regime, reuses the work. A manufacturer holding a separate pack per market maintains the same content several times over and finds the contradictions during an assessment rather than before it. Australia also takes part in the Medical Device Single Audit Programme, so one quality system audit can serve several regulators, which pushes in the same direction.
Which standards does an Australian medical device team work to?
ISO 13485 clause 7.3, design and development
Clause 7.3 is the requirements clause in all but name. Design inputs in 7.3.3, outputs in 7.3.4, review in 7.3.5, verification in 7.3.6, validation in 7.3.7 and control of changes in 7.3.9 form a chain, and an auditor reads it as a chain. A gap anywhere along it becomes a finding, and because the same quality system often has to satisfy several regulators, it becomes the same finding more than once. Our explainer on traceability from user needs to CE marking walks the chain end to end.
ISO 14971 clause 7, risk control
Risk controls are requirements. Clause 7 requires that each control is implemented and verified and that you check it has not introduced a new hazardous situation. Clause 10 then requires you to collect production and post-production information and feed it back into the risk file. Neither is straightforward to evidence if your risk file and your requirements live in different systems. We cover the full process in our ISO 14971 risk management guide.
IEC 62304 clause 4.3 and clause 5, software lifecycle
Software safety classification under clause 4.3, class A, B or C, decides how much of clause 5 you have to perform and document: software requirements analysis in 5.2, architectural design in 5.3, unit implementation and verification in 5.5, integration and integration testing in 5.6, and software system testing in 5.7. Traceability between system requirements, software requirements and tests is written into the standard rather than left implied. Our practical guide to IEC 62304 compliance goes clause by clause.
IEC 62366-1, usability engineering
Use related risks turn into a use specification and user interface requirements, and those get verified like any other requirement. Usability findings that never become requirements are among the most common gaps in a design record, and they surface the moment somebody traces a use error backwards looking for the control that was supposed to address it.
What changed when UDI commenced on 1 July 2026?
Unique device identification became mandatory for Class III and Class IIb medical devices on 1 July 2026. Identifiers and the associated device data go into the Australian UDI Database, AusUDID, and the lower risk classes follow in later years. Early compliance was permitted before the commencement date and some manufacturers took it.
For a requirements team the consequence is that an identifier attaches to a device configuration, and the configuration is defined by your design record. A change to a variant has to reach the labelling requirement and the UDI data together, with an audit trail behind both. Manufacturers already carrying EU UDI obligations start ahead here, because the underlying data is largely the same, which is one more argument for a single record rather than one pack per market.
Where does Matrix Req fit?
Matrix Req holds requirements, risks, test cases and results as linked data rather than as documents, so the traceability matrix is a view of the project rather than a deliverable somebody maintains, and technical documentation and the design history file are generated from that record. The Matrix Req product page covers the product in full, and the risk management module covers the ISO 14971 side. For how it compares with the rest of the category, see our ranking of the best requirements management software.
Do not buy Matrix Req if you are not building a regulated product. The whole design assumes you need design control, risk management and an audit trail, and if you do not, a general purpose issue tracker will be cheaper and lighter. If you are two people shipping a Class I device, documents and a spreadsheet will hold for a while, and the honest answer is to move when the manual version starts costing you more than the tool would.
Hear from our customers
With Matrix Req, we avoid all the challenges of using manual or custom-developed tools. Instead, we get a purpose-built solution that's designed by medical device experts, enabling much faster ISO 13485 compliance.
François Audéon, Chief Technology Officer
FAQ
No. Australian regulation names no tool and no category of tool. It requires design controls, traceability and evidence against the Essential Principles that is complete and current. You can meet that with documents and spreadsheets, and plenty of smaller manufacturers do. Teams move to software because the manual version gets expensive to keep accurate as the device and the team grow, and the exposure rises with every stale link.
The manufacturer holds the evidence that the Essential Principles are met. The sponsor has to hold it as well, or be able to obtain it from you on request within a reasonable time. That is a practical argument for a record your sponsor can be given a view of, rather than a pack somebody rebuilds each time it is asked for.
In Schedule 1 of the Therapeutic Goods (Medical Devices) Regulations 2002. The classification rules sit in Schedule 2 and Schedule 2A, and the conformity assessment procedures in Schedule 3. Your device class decides which Schedule 3 procedure applies, and the procedures get more rigorous as the class rises.
Often, yes. The TGA accepts market authorisation evidence and assessment reports from comparable overseas regulators and assessment bodies, including notified bodies designated in European member states, and that evidence can abridge the assessment it has to carry out. How much it helps depends on your device and your route, so treat it as a reason to keep one shared record rather than as a guarantee about your particular application.
The recognised set includes notified bodies designated by the medical device regulators of European member states, the United States Food and Drug Administration, approved bodies designated by the MHRA in the United Kingdom, and Singapore's Health Sciences Authority. Check the current TGA guidance before you rely on any particular body, because the list is maintained by the TGA and changes.
UDI became mandatory for Class III and Class IIb medical devices on 1 July 2026, with identifiers and device data submitted to the Australian UDI Database, and the lower risk classes follow in later years. An identifier attaches to a device configuration, and that configuration is defined by your design record, so a change to a variant has to reach the labelling requirement and the UDI data with it.
Australia takes part in the Medical Device Single Audit Programme, so a single quality system audit can serve more than one participating regulator. That matters for requirements management because it rewards manufacturers who keep one design and risk record rather than assembling a different evidence pack for each audit.
Jira handles engineering workflow well and it is not a design control record. Matrix Req has native two way integrations with Jira, Azure DevOps, GitHub and GitLab, so development work stays where your engineers are while the regulatory record stays complete.
The pattern is the same. IVDs have their own classification rules and their own Essential Principles considerations, and they sit on a different UDI timeline, but the ARTG, the sponsor relationship and the evidence expectations are unchanged.
Summary: what does requirements management in Australia come down to?
It comes down to evidence that is still true on the day somebody asks for it. The Essential Principles decide what you have to prove, your sponsor decides how quickly you have to produce it, and the comparable overseas regulator pathway decides how much of the work you can reuse. Matrix Req is built so that all three draw on one live record rather than three documents that drift.
Keep one record, not one per market. It is what makes the comparable overseas regulator route and MDSAP worth having.
Link risk to requirements to verification. Schedule 1 is an argument about risk, and an unlinked risk file cannot support it.
Make traceability a view, not a deliverable. A matrix that is produced is stale; a matrix that is queried is current.
Last updated: 11 September 2026.