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 webinar: Regulation of software, including software as a medical device, 7 March 2019

22 January 2020

Disclaimer

This recording is 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 recording 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 recording.

Recording of online webinar

  • Presented by: Dr Lee Walsh
  • Presented at: Online
  • Webinar date: 7 March 2019
  • Webinar summary: This webinar discusses how the current regulatory scheme applies to software.

Transcript

Male speaker (Lee Walsh):

First thing to say is, I'm not Elizabeth McGrath-she's our programmed speaker. Unfortunately, she is unavailable at the last minute so she's asked me to step in. I've got her material. But please be patient with me if I'm not across it as well as I might be. Never mind.

Obviously, I don't have Elizabeth's depth of knowledge, but I will do my best. So, some of you probably know me. I've been at the TGA a few years, both in pre-market and post-market roles. Currently, I'm the technical lead for Digital Health within the Devices Division and the Devices Branch. But I'm also leading some of the reforms work around regulation of software and regulation of security which you will have seen papers published on the last few months. So, a few things of my own before we start. The next webinar will be in May, and we're hoping in that webinar to look at the regulation of software again with our current consultation having closed. And the questions that have been coming in with registration are fantastic. Please keep sending those in. It helps us inform the material that the speaker produces. It also informs future topics and other activities that we can do to help engage and give you the information you need. So let's get started. These are the topics we're going to try and cover today. And if time, I'll take questions at the end.

So let's start with how you get a medical device on the market in Australia. So, first of all is the principles underlying the regulatory system. So you need to remember than no therapeutic good is risk free, and that's true of medical devices as well. So, our work is based on using scientific, medical, engineering, and other technical expertise to make decisions. And really what we need to know is that the benefits of any therapeutic good that comes on the market outweigh the risks. It's important to remember that a risk can't be eliminated from medical devices. It can be minimised, and it can be made acceptable when the benefits are considered.

So the way the Therapeutic Goods Administration regulates medical devices is that we administer the legislation. I've mentioned this before in our previous webinar and other engagements, but we don't make the rules, we're here to administer the rules which are in the legislation. Really, the Act is at the top, and then the Regulations provide more detail on how the Act is actually executed.

So we keep putting up the definition of a medical device because whenever people ask, "Do you regulate X?" So in digital health—do you regulate AI? Do you regulate SaMD? Do you regulate, you know, anything, and you can ask that question - 3D printed devices - it comes down to what the device does and its intended purpose, not its form. So it's sort of irrelevant whether it's software or hardware or 3D-printed or conventionally manufactured, in terms of deciding whether it's regulated. What matters is the definition of a medical device. Medical devices are regulated, and we have quite a clear definition in our legislation, which is a summary of here.

The other important definition is a ‘manufacturer'. So this is the definition in the Act of what a manufacturer is. So this is the person who is responsible for the design, production, packaging and labelling. They may not be actually doing the work—they can outsource or subcontract that—but they're the ones responsible, they're the ones who are certified by the regulators.

So your obligations under the Act if you're making medical devices. First of all, there's our risk-based classification system. So it's actually the manufacturer's job to determine what classification their device is. That's because you have the expertise to do that. You know your intended purpose before you approach the regulator.

You also need to make sure your device has undergone appropriate conformity assessment procedures, which are determined by the classification of your device. And the classification comes from the classification rules and the regulations, and conformity assessment procedures, the minimum conformity assessment procedures required for each class are also in the regulations. Once you've been through conformity assessment procedures, as specified for your class of device, you can then apply for inclusion on the Australian Register of Therapeutic Goods, or the ARTG. And once you're on the Register, you can begin to supply. So you're not allowed to supply therapeutic goods in Australia unless they are included in the Register. That's not the end of it though. You still have obligations around post-market monitoring and reporting once your device is in the market. So, it's not just about getting through the gate and onto the market. If you're a medical device manufacturer or a medical device sponsor, you have ongoing obligations if you want to maintain your device on the ARTG. So when we talk about risk-based classification, the rules are in the regulations but the idea behind them is really that they relate to the intended use of the device. The potential harm to patients is a big one.

So we expect that higher classes of devices, like Class III devices, have a higher potential to cause harm to patients. Which means there's more mitigation of that potential harm required, and therefore, there's more scrutiny by the regulator. Whereas a low-class device should, if the regs are working properly, have a low potential harm to patients and users. The degree of invasiveness is a consideration as well, and when you read the classification rules, you'll see that there's consideration for whether it's an invasive device and for how long it's used inside the body, as well. Which comes to the next point, which is duration of use, but also location has a role to play. So a device that's used on skin is classified under different rules to devices that are used inside the brain or the central circulatory system, for example. And the whole idea is that regulatory oversight increases as the potential risk increases. So, Class III devices get more regulatory scrutiny than Class I devices.

So step two is your conformity assessment procedures. Which procedures you need to undergo depends upon the classification of your device. But in general, there are four different points that you need to address. A declaration of conformity, your quality management system—which is the basis for auditing the manufacturers who are producing devices above Class I—and the technical documentation that you keep on your device is something else that the regulator will call up if required. And then we're going back again to post-market surveillance. So in terms of gaining market access, the TGA will also look at whether you have appropriate procedures in place to deal with complaints to address changes to your device and manage the ongoing risk once it's on the market. Then we have the Essential Principles of safety and performance.

So people often ask about standards, which standards do I need to comply with? Well actually, under the Australian legislation, standards are not used in a compulsory sense for medical devices. There are some key standards, which I'll come to later. But the legislated requirement is compliance with the Essential Principles. So you can conform to particular standards in order to help you demonstrate your compliance with the Essential Principles, but the legislated requirement is the EPs. So there's 15 of them. The first six are considered to apply to all medical devices. So you're going to struggle to make an argument that these are not applicable, OK? We're always going to expect compliance here. The last nine tend to be more specific in regard to the different properties of devices, and therefore they can be not applicable. So, for example, chemical and physical properties won't apply to a software device. And really, these are the ones that I would expect software manufacturers to be addressing.

People often look specifically for the one or two related to software and come and say, well, you know, we've complied with EP 12, but you see here, I've actually crossed out EP 12 ‘cause it tends to relate more to electronics. So when you're developing your device, regardless of software or hardware, you need to be able to demonstrate that it won't compromise health and safety. You need to be able to demonstrate that you've designed and constructed it safely, that it's actually appropriate for the intended purpose you've given it, that it's going to be safe in the long term, OK? You need to provide information with your device regardless of what it is.

So particularly if you're new to regulation and you're making software devices, don't make the mistake of trying to narrow in on just the software principles, OK, you need to look at the whole lot and actually go through and say, look, what do I need to do under each of the 15 EPs in order to demonstrate compliance? Now, because these are part of the legislation, you know, the wording that the TGA uses is under the regs. So you can search that on legislation.gov.au, you search for therapeutic goods medical devices regulations, and at Schedule 1, the Essential Principles—that's the wording that we use as regulators, so you should use the same wording we use. Clinical evidence is another one that we're always going to expect. Now, the level of evidence is going to change depending on risk, and the type of device you have is going to affect the clinical evidence you generate as well. But, we have specific guidance on this. So if you go to the web link here, you'll be able to read through the guidelines for medical evidence that we're going to expect for medical devices.

Step three: your evidence. So, this is where you need to start looking at which conformity assessment procedures are required for your class of device. So, if you've got a Class I, you can self-certify, and then you make your Declaration of Conformity.

Class IIas, and also Is and Im, so this is a sterile Class I, or a Class I that has a measurement function, and IIas, you're going to need certification in manufacturing.

And you can see that this builds up as we get to Class III. So Class IIb requires what you need for Class IIa, and there's the addition of some mandatory audits for particular IIb devices. And then we go to Class III which is your manufacturing certification, plus an examination of your design. So you give us the technical dossier, and the technical assessors will go through it, and then you have mandatory audits again on your application. So you see, this is how pre-market the level of scrutiny goes up as the classification goes up. Then once you're on the market, you've been included, and you start supplying, you need to meet your post-market obligations. So for your higher-class devices, this includes mandatory reporting annually, but you also need to be monitoring the product's performance and reporting adverse events to the TGA, and that's done through the incident and the IRIS scheme - Incident Reporting and Investigation Scheme. So that's the main avenue of reporting.

And then you need to keep your dossiers, your documentation, and everything else up-to-date, and that's through you maintaining awareness of the market and what's going on and what's changing, so that you can continue to manage the risks associated with your devices. There are exceptions—some things don't need to be included in the ARTG. So there are special access schemes for unapproved goods, which you can get more information on from our website. There are exemptions for experimental products, for custom-made products - so this is where the medical device is made for a single person—and there are some exemptions around in-house IVD devices.

And then there are those to deal with regulation when you do clinical trials. So there's two schemes here that are applicable. I'm not going to go into detail here. We have a guidance document on this that you can find on our website. But generally, there's two streams around whether you need to notify or whether you need approval from us before you proceed. So what I've covered so far applies to medical devices, and some of you might be thinking, well, you said this talk was about software and you're talking about medical devices. Software is a medical device; that's how it's regulated. So if your piece of software meets the definition under the Act of a medical device, it's regulated as a medical device. So all the things I've just been talking about apply to medical devices whether they're hardware or software.

So, when you're looking for what's the process I need to go through, what are the application forms I need to fill out, you go back to the general medical device guidance. Really, the issues around software really come in to just the particular details that might be needed because of the way software's produced, and that particular form of device when it's out on the market. But, software is not new. It's been around for a long time, and the TGA has been regulating it, at least since the medical device framework came into effect. So these processes are there, and they're for all medical devices.

The first question, is it regulated? And we come back to the definition under the Act, which is the second half of the slide. But, it's important to recognise that we're talking about all software that's captured under that definition. So really, there are three cases that we worry about. One is when it's part of the hardware itself, or part of the device itself. This is all those medical devices that have embedded software—so bedside monitors, infusion pumps, pacemakers—all these things have software as an integral component of the device, and that software is regulated in the same way as other medical device software.

Then we have software, application software that directly controls a medical device. So this might be application software that controls an imaging system, or it might be that there's application software that's used to program, setup a hardware medical device. It might interact regularly. So an accessory that plugs into your phone, and there's an app on the phone that controls that medical device accessory. In that case, they're still regulated together as a system because you can't use one without the other, and they have a combined risk, OK, and a combined design, so they're regulated together.

Then we have the standalone software products, which we refer to as Software as a Medical Device. And that's where there's no sensors or other functions of the platform being used, it's just data going in, being processed, and data coming out. There's no measurements, and there's no control of hardware.

So, Software as a Medical Device is basically what I just said, OK? It runs on a general-purpose platform. So this is not software that runs on a special medical device. So, the software that controls a bedside monitor or an infusion pump is not SaMD, OK—that's software embedded in the system. SaMD is for running on a Windows computer, or a smartphone, or a tablet, OK, something general purpose. General purpose could be a web browser. If the medical device runs inside Chrome, and the computing platform is Chrome. So in that situation, the software is really just using the computing power of a platform. Information is being put into it, it's doing some task, and information is coming out. It's got no control over hardware, and it's got no measurement, direct measurement capability.

So I've covered that [general-purpose platforms]. So these are some examples. So where you've got image-processing software where images are captured somewhere else and then they're put into the software for processing to make a diagnosis or to inform a pathologist. Certainly, anything that makes a clinical decision. If you're bypassing a doctor, that software is going to be a medical device. And dose calculators. So this doesn't capture general health and lifestyle apps. Now, I was asked today actually what a general health and lifestyle app is from the perspective of the TGA. So, my answer to that would be it's anything that relates to health that isn't a medical device under the Act. OK, so the TGA talks about medical devices because that's what we regulate. And when we're using this term, really, we're referring to apps that don't fit that definition and therefore we don't regulate them.

That's not to say there aren't other requirements from other agencies, but they're not under the TGA's remit. SaMD is not software that's built-in to the device, I've covered this already, but that software is still regulated. It's regulated as part of that device that it's integral to. And the same with accessories. An accessory, and the app that's required to use it, are regulated together as a medical device. Now, this is an important one, this last one, 'cause this is often confused with SaMD, where you have an app sitting on a smartphone; where that app just takes data, processes it, and puts out data, and it meets the definition of a medical device, that's SaMD. As soon as that app starts using sensors or features on the platform, it merges with the platform to become a medical device system, right, and then they're regulated as a combination. So, an example here is, so it says-sorry, I'll get back. There we go. Sorry, I thought there might be an example there. An example would be, so I talked about image-processing software in a previous slide where it might be captured somewhere else - so on an X-ray machine or MRI—and then it's uploaded to a server, and the radiologist does something with it. That software is not capturing the image. It's receiving an image and doing the processing. If you've got an app on your phone that's taking a picture of something, and then using a decision, it's dependent on the camera as a sensor, and therefore the sensor becomes part of the system, and part of the medical device, and therefore, now they come together as a system, and they're regulated as such. Other examples would be using the accelerometers or gyroscopes in mobile platforms. Some of the newer platforms have electrical sensors, or ECG and those sorts of things. If you're using those sensors with your software, they come together. That's not the case with SaMD because it's not standalone—it's dependent on those sensors. Same if you were controlling something outside—that brings in that accessory relationship. So, one of the problems with SaMD in particular, when it comes to software, is that the classification rules don't really mention software a lot. These are the rules in the current regulations that mention software. And because of the way the classification rules are written, this means that most standalone software, software as a medical device, comes in as Class I regardless of its intended purpose, or its potential for harming patients and users.

Now, the sorts of evidence you might need to provide if you are a software developer making medical devices, is we're always going to want to see that you're doing this under a quality management system. Quality management systems are fundamental to medical device regulation and they're fundamental to the sector. Now, experienced medical device manufacturers know this, they've been doing this for years, but it can often be new for people who are new to medical devices and to regulation. Version control is going to be critical. You're going to need to be absolutely clear about which version of software this is, which features and known bugs and the sorts of things it has.

You're going to need to have good release management so that you know which versions are out there, and that things don't get out there without your control. You're going to have to validate your design, you're going to have to have bug reporting and correction, you're going to have to have clinical evidence showing that your device does what you're telling people it does, also that it's safe and effective. And the benefit must outweigh the risk, which we discussed at the beginning. Now, most of those things, good software developers are already doing. Clinical evidence might be new, and benefits outweighing risks might be a new concept, but, look, good software developers, they manage the quality of their products already. They have good version control and release management. Certainly, they receive bug and issue reports and they correct those. What they don't often do is document it in a way that they can present it to the regulator. And this is a challenge for a lot of developers entering this sector.

You really just need to get your documentation under control, you have it in your quality management system, so that when the regulator asks for it, either pre-market or post-market, you can just hand it over, here it is, OK? Getting to market and not having written anything down means that when the regulator asks for it, you don't have the documents to prove you did that, so you don't have the evidence. So this is likely to be the biggest change, it's just writing it down in your quality management system.

Now, I said there were some key standards. And, unsurprisingly, following on from the previous slide, the main one relates to quality management. ISO 13485, the current version is 2016, is the gold standard, the state-of-the-art for quality management systems for medical devices. This is well established in the sector. All the regulators use it. All the auditors and notified bodies in Europe use it as well. If you're making products that are medical devices, you need to be across this standard, and you need to be designing your quality management system with regard to this standard.

Sitting under that is the risk-management standard, which is really there to support 13485, and that's ISO 14971. This gives you, really, the state-of-the-art principles for documenting the risk and managing the risk associated with your medical device so that you can present it to the regulator when they ask for it. And then we have IEC 62304, which is specific to medical device software. This is your life cycle process. So, if you're a software developer, some of this stuff will be familiar to you. But, really, this is how you can demonstrate that you're applying good software development practises and good life cycle processes to your software when it's a medical device, and most of the regulators as well look at this standard whenever someone says ‘medical device software'. So these three are going to be the key standards you need to be across if you're producing medical device software.

Then we move to international guidance. So the International Medical Device Regulators Forum, as you will have heard me and others from TGA talk about before, have a software working group. And they produced four documents between 2013 and 2017. And the 2017 document is looking at how you can produce clinical evidence for software that's a medical device. So, if you're in that sector, particularly if you're developing the software as a medical device products and you need more guidance, this would be a good document to look at for additional information.

Now, we want to look at how Australia can differ from some of the international regulators, and as well as how we're looking at reforming our regulations around software. So this table here just goes through the processes that I described up to this point in this webinar where you could be self-assessed, or you may [require] assessment of your product, or your manufacturing certification. So you can see here that the Class Is in Australia use self-certify, and we covered that earlier. Class IIas and IIbs is where you need your manufacturer certification. OK, so you're going to do these other things and get product assessment, and you're going to be assessed as a manufacturer, but you won't get on the ARTG if you don't have your manufacturer's evidence... of your certification. Whereas if you contrast that with the [US] FDA, you see that there's a product assessment but no manufacturing assessment, and therefore no certification. So that's the FDA system being quite different to Australia, and I should say Australia and Europe [EU] because Australia and Europe are quite well harmonised. We go up a class again to Class III, and we see the level of scrutiny increasing again because Australia and Europe add the examination of the product itself and certification of that design exam[ination], and the FDA add that as well, but they still don't have the requirement for manufacturer certification. So this is really the big difference between Australia and Europe and the FDA is that the FDA have historically tended to focus more on the product, and Australia and Europe tend to focus more on the manufacturer. So… this I think just summarises what I've said. The only addition there is that Australia is currently consulting on changing classification of software, which would change the conformity assessment procedures and therefore the level of scrutiny for some products. And that consultation is live, at the moment, closing at the end of March.

Europe has already been through some changes with the introduction of the medical device regulation. And that includes some specific mention of software. So, software that provides information being used in diagnosis or for treatment. So you see the points here. Class III, so software is classified as Class III if the decisions have an impact that may cause death or irreversible deterioration of a person's health, and they're Class IIb if they could cause serious deterioration or require a surgical intervention. Otherwise, they're Class IIa. And this is where software's making a decision. So there's still scope for Class I software, but not where it makes decisions for diagnosis or treatment.

And then the note here is that the EU already has a rule relating to diagnostic imaging around X-ray recording. Now we just highlight this new requirement in the US by the FDA. So we said before that the FDA hasn't been requiring certification with manufacturers, and yet for what they call digital health software, and their definitions can differ slightly to Australia, but basically, we're talking about software products, and requiring certification of the manufacturer. Now it's important to recognise that this is new for the FDA system, but Australia, Europe, and pretty much the rest of the world have generally been working on the GHTF model, which is certification of the manufacturers. So this is quite a big change for the US, but there isn't a need for Australia and Europe to harmonise with this, so to speak, because we already certify manufacturers as a fundamental part of our regulation.

So as I mentioned a couple of times, we are consulting on software, and it's important, I want to highlight again, it's the regulation of software including SaMD. So all medical device software, those three that we talked about earlier. And these are the three main points that we're consulting on. So I said earlier on that under our current classification rules, most software, standalone software, is going to come in as Class I regardless of the potential harm it can cause to patients. So what we're doing is looking at revising the classification rules so that classification of software products is consistent with hardware products and is classified for its potential to cause harm to the patient. The other proposal is to exclude SaMD products from the personal importation provisions. Now I discussed this, I think, as a challenge in the digital health webinar. I'll just go through it again now because we haven't talked about it today. But the medical device regulations includes provisions for people to bring devices in from overseas without them being included on the ARTG. Now, this is intended to allow people to bring in devices for personal use, and for a short-term use. So you're talking about a few devices being used for a short period of time. And so, in that case, the importer, the individual who's bringing those products in, are taking on a risk themselves because it's exempt from inclusion in the ARTG. Now, what's happening with software apps is software developers overseas can publish their software on a website or an app store, and people in Australia can download it and start using it, and that product hasn't been required to be on the ARTG. And one interpretation of legislation is that it's actually covered by the personal importation provisions. So that means that not a few devices for a short period of time, but could be potentially millions of Australians downloading these products and using them, and those products haven't received regulatory oversight, and in fact they're not even visible to the TGA because they're not on the ARTG.

So the proposal from the TGA is to require those products to have an Australian sponsor, which means somebody in Australia is accountable to the TGA for monitoring those products and reporting to the TGA, but it also means they need to be included on the ARTG. Finally, is some changes around the Essential Principles. Now, this is not actually to change the way we regulate software, but to make the way we regulate software clearer. The Essential Principles don't currently talk about specific requirements for software. And so, as manufacturers, it can be hard just from the Essential Principles to decide what the TGA requires with regards to software complying with the Essential Principles. So, we have our internal experts, and we have standards to look to for guidance, and we're already doing that in the products that we are already regulating, but that's not as clear as it could be. So the proposal here really is to just make changes to the Essential Principles, to make requirements for software products clearer to manufacturers but also to other stakeholders, because it would be in the regulations themselves.

So, here are some important references from today's materials. So the first part of what I talked about is just the basics of medical devices regulations, which is how we regulate software products when they meet that legislated definition. We do have a specific guidance page for the regulation of software as a medical device. That page should continue to change over the next months, and at least throughout 2019, as we build on that to provide more information, so keep an eye on that. If you are unsure how to get your medical device on the market, the pre-market inquiry line is there to answer those questions. And then we have our specific digital devices team who can help you with questions related specifically to those classes of devices. More general information on TGA, you can go here. And for those who don't know, we are on Facebook, Twitter, and YouTube.

So now: questions. So thank you again for your registration questions. I've got 15 minutes left. So I'm going to go through some of the questions that were asked during registration, and then if there's time, we'll take some of the questions that you've asked during this talk. So, just give me a minute because I was brought in here. I didn't get time to prepare slides on these like last time.

Female speaker (Rachel)

In the meantime, while he's just having a quick look, we might just pop up some poll questions in between as well. So if you can just bear with us, that'd be great.

Male speaker (Lee)

Registration questions, I think a lot of them have been answered through the slides. But there are a couple that jumped out. So I'll go through these, and then we'll see about taking questions in the chat. So there's a question here about the reverse of the personal importation provision. So, as an Australian developer, if we place SaMD on an app store, or download apps outside of Australia, does it constitute an export? So, under the current legislation, I would say yes it does. If it meets the definition of a medical device, then it's captured under the legislation. And if you are supplying that device to places that aren't Australia, then you are exporting. But the place to check for yourself is to go to the legislation and look for the definitions of supply and export, and a medical device.

So then, have any significant regulatory changes happened in the past three years, or are they anticipated in the future? And this question came through a lot. So this was covered partially in the presentation I just gave. We are consulting, so you can expect there to be changes in the near future. But in terms of the past, no. The regulatory changes have been minimal around software. So in terms of if you've got software products on the ARTG, do you need to do anything right now? The answer is probably no with regards to changes in regulations.

Obviously, you always need to be monitoring your product with your post-market obligations.

How would SaMD be classified under the new or current classification system? So, I did cover the current classification system. Generally, it's always going to be Class I, which is part of the problem for the higher risk products. In the new classification system, really what we're aiming for is classification appropriate with risk. So if you're producing products that would be considered high risk or moderate risk, you can expect that there might be changes to the classification rules that affect you. We don't know what they are at the moment, and we're going through the consultation process to see if there's agreement here, but I think you can expect that one of the classification systems, is one of the things that will change in the near future.

Is TGA planning to implement IMDRF guidelines? This is a tricky question because the IMDRF guidelines are guidelines, they're not regulations. So in terms of implementing them, no, we don't pick them up and turn them into legislation. That's not their intent. However, the TGA helps write them. We're a founding member of the IMDRF. We sit on their working groups. And so these documents are produced with Australian representatives so that they are harmonised with Australian regulation ideally. So they are a good guidance for how we, as Australia, can move our regulation towards more harmonised, internationally harmonised systems. So, when it comes to the IMDRF guidance, we will always be looking to harmonise with it where we can. There are special things about Australian legislation that doesn't make that possible all the time, but we will always harmonise where we can. We provide input into those documents so they should be compatible with us. But we can't pick them up and turn them into legislation, that's not their intention.

Products based on machine learning. How is their performance assessed given their methods of training are classified? Now, my reading of this question is not relating to device classification, but potentially commercial-in-confidence or classified information. So if you're new to regulation, I understand why you're asking this question. Regulators know everything about your product. The legislation gives us the power to ask those questions and compel that information. And it's a normal thing in regulated sectors for the regulator to have access to commercial-in-confidence information. That's how we can be sure that the product complies with legislation. So your non-disclosure and IP agreements won't counter a legislative request from TGA. We need access to that information, and we have the powers to access it. And if you talk to you peers who are experienced in the medical device sector, these relationships with the TGA are normal and ongoing. That said, obviously, commercial-in-confidence information that you provide to the regulator stays with the regulator. This is part of our job, is to protect your information when you give it to us. So we have the powers to ask for it, but we also need to protect it when it's in our possession.

So that's all the pre-registration questions. I've got a couple of minutes left. Yeah? So let me have a look at what's been flagged. OK, so software used to program radiology therapy equipment is also used to manage patient data, while the former function would fall under the medical device regulations, the latter doesn't. Will all patient management software be included in the evaluation too if this is the same application? This is a really good question. So, to give some context to people less experienced with the regulation, patient management systems that just record patient data but are not actually involved in the treatment or the diagnosis are not medical devices - they don't meet that definition. But we are now seeing more products that merge these things together.

So, absolutely, the function that is captured by the regulations would need to be assessed under the appropriate conformity assessment procedures. Whether the rest of the software is provided to the TGA or not is going to depend whether it's easy to separate it. But we're not going to be looking there and assessing that part of the system unless there's a risk there that interacts with the feature that's captured under the regulation. So, our assessors are going to be looking at what's essentially patient management software, and saying, well, that's out of scope, that's part of, that's not a medical device on its own. However, if in assessing the component and the features that are medical devices, they see linkages to other parts of the software, they are going to want to see those risks mitigated, and that's where those parts may be captured. But that's where the manufacturer's risk management comes into effect and that just means that we expect them to have considered those risks and made the software compliant. Now, give me a minute because I'm betting, as I go -

Female speaker (Rachel)

You've got five minutes.

Male speaker (Lee Walsh)

I've got a couple of minutes. I'll go down and try to find another question for you. Five minutes, sorry, my clock is wrong. I need a more accurate clock.

[READING] Can Australian patient data be stored overseas?

So the simple answer is yes. That already happens with existing medical devices. But again, it fits under your risk management, your quality management, and your ability to demonstrate to the regulators that you are compliant. And I said regulators plural there because we now see increasing amount of legislation around personal data, which is someone else, not me. But from the TGA's perspective, it will come under your risk management of the medical device.

[READING] How do you recognise [US] FDA approval?

So I think we've covered this before. I'm going to direct you to the TGA website to search for information about comparable overseas regulators. So that's a new change in the framework, which gives us more ability to look at the evidence produced by comparable regulators. So I'll direct you there.

[READING] What would I describe as different talking about SaMD for an IVD?

So, yes, I apologise in the past if you've heard me speak on this, I don't know where to make this distinction. So, IVDs do have their own framework. And, while in my head I capture them together, we haven't been very good at making it clear where software regulation applies to an IVD. And that's quite important because a huge number of IVDs include software, particularly when we're heading towards things that are making diagnoses, they're parts of instruments, or they are processing images for pathology, or something like that. So, when we talk about SaMD and regulation of software, we do need to be better at highlighting when it applies for IVDs. But, if you are an IVD manufacturer, please look at the current consultation, and please keep asking questions and reminding, particularly me who are not an IVD person, that we need to keep making sure we let you know when it's relevant.

[READING] Can you confirm would a software developer need to be quality assured even in the pre-market period?

So quality assurance, from our perspective, quality control—all aspects of it—fit under, sorry, quality management, which is quality control and assurance, fits under our manufacturer certification. So, if you're not supplying a medical device, you're not required to be included in the ARTG. But at some point before you apply for inclusion, you're going to need to go through your conformity assessment procedures. If those require manufacturer certification, then yes, you will need to be certified, during the pre-market process before you make your application. I'm not quite sure if that's what the question's asking, but that's my reading of it. So, at the moment, if you're a SaMD developer, you're going to be Class I. If the classification rules change and you require manufacturer certification, then yes, you're going to have to get that in your pre-market period before you can apply to be included on the ARTG.

So there's a question here about our draft medical device cyber security guidance. When does the comment period end? Unfortunately, that ended in the middle of February. That was published late December or very early January. So that's closed.

And then it says, 'I hear it's a nice document. It mentions a lot of standards, some of which may not apply to specific devices, is that clear?'

So this comes back to standards are not required under the legislation. Use them where you can to help demonstrate compliance with the legislation. But the TGA can't enforce particular standards without making the instrument that does that. And with regards to security, those standards are not yet required under legislation. I shouldn't say not yet, because we don't really have intention doing that at the moment, but in terms of which standards may not apply, that's up to you as a manufacturer to decide: this standard applies to my device so I'm going to use it as guidance and help me attain compliance with the Essential Principles.

[READING] If a company adopts GMP, do they still need ISO certifications?

So, GMP generally applies to medicines, when we think about therapeutic goods. Under the medical devices framework, you're going to be expected to be compliant and certify against ISO 13485. If you don't have that, you're going to have a very difficult case convincing regulators, not just TGA, but other regulators that you are compliant with the requirements. That really is a gold standard in the industry. Are we still going or have we finished time? OK, one more.

[READING] We've been advised to get a CE mark as preliminary to a TGA assessment, is this correct?

That's one pathway. This is really a business decision, from my perspective. There are pathways to have European evidence recognised by the TGA, and you can go to our website and look for the processes there. But I'm not going to say if it's correct or not. That's really a business decision. But yes, there are ways to have European evidence recognised by the TGA and also TGA evidence recognised by Europe.

[READING] Does software for 3D-printing require regulations? And is the 3D print considered a medical device?

So, not quite clear here. So I'm going to explain how I'm reading this. Does software for 3D printing require regulations? If the software, if the 3D-printing is, say, part of your medical device manufacturing line, that's going to be captured under the medical device manufacturing processes, which is captured under your quality system, which is audited by the regulators. So that you're going to have to document your processes. If we go with 13485 under all of that, and demonstrate that way. Is the 3D-print considered a medical device? This comes back again to the definition of a medical device. What is it being used for? What do you intend it to be used for, more importantly? If it's going to be a container that sits on somebody's desk to hold pencils, obviously, it's not a medical device. If you are printing implantables that have a clear medical intended purpose, and are captured under Section 41BD - yes, the product will be a medical device. This comes back again to, it's not about form, it's about what you intend the device to do, and how it's then captured under the legislation.

So Rachel's giving me the time's up sign. So, thank you again for all of your questions. Thank you for participating in these events. All of your questions, even if I haven't answered them, are logged and used to inform our future activities. So please, for future webinars, keep sending registration questions, keep asking questions in the chat, but thank you very much.