Challenges and considerations on the journey to a global UDI system

Michelle Van Wijk

Welcome, everybody, to our third UDI webinar. We're very pleased to continue to share information with you and hear your questions and feedback as we undertake our journey to implement UDI in Australia.

Today, we'd like to cover a couple of areas. One is, we have a guest speaker who's Dennis Black from Becton Dickinson. We're going to give you a progress update. We're going to give you a quick demonstration on our sandpit Australian UDI database. And we'll have some time for questions and answers.

So, I'd really like to introduce our guest speaker, Dennis Black from Becton Dickinson. Dennis has over years of experience in the medical device industry and has worked in a variety of roles and functions. He joined Becton Dickinson, a leading medical technical company, in 1998, and works within the regulatory affairs team as the UDI Program Director.

Dennis is currently focusing on implementing Unique Device Identification regulations in the US and globally. This responsibility includes ensuring that BD's product identification strategy meets healthcare provider needs and internal supply chain requirements while complying with all applicable regulations.

Dennis presently serves on the GS1 Healthcare Global Leadership team. GS1 US Executive Leadership Committee. And the Strategic Market Initiatives, SMI, Board of Directors, where he's also Treasurer.

He collaborates with various industry participants in AdvaMed, MedTech Europe, Global Healthcare Exchange, and the Association for Healthcare Resource and Materials Management, to solve a variety of healthcare challenges.

Dennis has very kindly offered to join us this morning to share insights from a global manufacturer perspective, and particularly because Becton Dickinson has already had to implement UDI across a number of other countries. So, Dennis very kindly offered to share some of the background and learnings and some of the things that have worked well, with our audience, today.

Thank you so much, Dennis, I'll hand over to you.

Dennis Black

Morning to everyone in Australia. This is Dennis Black. I'm currently the UDI Program Director for BD. We're a large medical device company. We currently do business in over 190 countries. And to that end, we have, I think, a vested interest in having a harmonised UDI regulation that we can implement across all these different geographies.

We have a diverse product line. And when you look at this from a UDI perspective, we have implantable products, such as stents, and hernia mesh, and ports. And, of course, when you think of UDI for implantable products that usually means a patient implant card. We have configurable devices that have multiple components or, perhaps, even software that changes the capabilities of these devices. That becomes complicated.

We have in vitro diagnostics, we have procedure packs. We have surgical instruments that must be direct marked. A lot of single-use devices that become incredibly complicated because some of them are small and difficult and have very little labelling space. And then, some complicated lab equipment that will have multiple components and flow cytometers, and just an incredibly diverse product line.

So, UDI becomes, I think, pretty complicated when you think of what must be done across an entire product portfolio. I think it's simple and easy if we look at one specific device, but if you look at all the changes that need to be made across a product line, UDI becomes complicated.

And I think what we'd like to cover today are some of the benefits to implementing UDI. We do believe there are benefits for all involved if we can get UDI implemented. UDI is complicated to implement and requires maybe more than it appears at first look.

We need to get harmonisation wherever we possibly can, and I'll cover some of the complexities and why it's difficult to have a globally harmonised regulation. And then, lastly, going over some of the collaboration that's needed for us to get the full value from UDI.

Now, for UDI benefits, BD implemented GS1 Data Standards several decades ago. And when we implemented these data standards, we had no idea that we'd have a UDI regulation. But we implemented GS1 standards, it was so that we could improve our internal supply chain. And that was for accurate shipments and supply chain efficiency, and to track product, which is an expectation of regulators in virtually all geographies.

And then we were also looking ahead towards a common business language. We could have used a proprietary standard and fulfilled our internal requirements. But believed that it was best if we picked a common standard so that others might be able to leverage our investments.

If you look at the pictures on the right-hand side, those are not recent images. These are over a decade old, and we were using, what we now call, UDI, or the Data Standards in our supply chain back before the U.S. FDA came out with the regulation. And that was in 2013. So, we have a long history of this, and we do believe that there are benefits in using Data Standards and implementing this within our internal supply chain.

But if we look at UDI, this now requires others to do something, as well. It's not just about what we do to mark our products. It depends on what the distributors and the healthcare providers and others in the healthcare supply chain ecosystem can use our products for.

So, I think there are different value propositions for UDI. And I've got eight items listed here. I've heard some different perspectives. I've had the opportunity to work with healthcare providers across the US. And it's interesting because it's not as though they're trying to do one simple thing. Different hospital systems have different perspectives on what they're after.

Some are really closely aligned with the regulators' message of using UDI for recalls and safety and surveillance. Others are more focused on supply chain and how they're going to make sure they've the right products delivered to them.

Recently, we've seen more and more interest in point-of-care scanning. And when you study why hospitals want to point-of-care scanning, some want to make sure the correct product is utilised. Some want to make sure it's for replenishment. And then others are looking more towards how do you store this data in the Electronic Health Record and, perhaps, even use it for comparative effectiveness research. But the value proposition does vary by hospital system.

We look at a couple of the examples in our market. The first one is Mercy Health out of St Louis, Missouri. This is a large hospital system. They have 40-plus hospitals through five or six states in the centre of the country. They started off using UDI for supply chain specifically, but as time has gone on, they're more and more interested in the clinical integration of UDI into various systems.

They've been a leader from the start, and they published, really, several interesting studies on how UDI can be utilised. They continue to study comparative effectiveness research. And thinking through how they can better associate products with devices and draw conclusions about the effectiveness of those devices.

Another example is Franciscan Missionaries of Our Lady Health System out of Baton Rouge, Louisiana. And they've done extensive work, both from a supply chain view and, also, from a clinical respective. They've also provided tools for other hospitals to use in their journey. In this particular example on the slide that I have on the screen is describing how they're using tissue tracking and using UDI. And the requirements around tissue tracking to use this for whole chain of custody.

But they've done great work, and I think you'll find some of their information online, also. And what has been particularly helpful are some of the tools they've created for others to use.

We've also had uses and other instances by the Healthcare Transformation Group. There's a group of six leading hospital systems in the U.S., and they commonly work together to share UDI and what they can do across their various systems and pull this all together.

Now, to make sure that UDI does get implemented in a coordinated way, that requires a good regulation. And the slide in front of you is showing what's required for the regulator. And I think some of the industry engagement. And right now, the rule-making period in Australia, I think we've seen this tremendous outreach by TGA. And I think this is an example of that tonight, where they're going through this and sharing what they're working on. And offering up various groups for industry to get involved with and sharing some of their problems and challenges.

So, I think this, certainly, has worked well in the United States and other countries. And we're really glad to see that TGA is following down this path. A lot more needs to be done for implementation. And that would include clarity of data definitions. I know this seems simple, but we have struggled in some countries.

We have struggled to implement UDI and to think through how this all fits together and how we would go about implementing UDI. And we're still waiting in one area to get final data definitions. And I think that's a struggle. So, something that we do need to make sure that we have is clarity on what is expected.

Machine-to-machine data upload is important. Our data is going to continue to change, and we don't want to be typing in manually. And we look at things like helpdesk support and IT solution provider enablement, and some other things as being pretty vitally important to how this all fits together.

And then, post-implementation. It's going to be important to have that community engagement after the regulation has been written. And the implementation is taking place. And even after everything is finally implemented, it's going to be a long road ahead as we implement UDI.

Again, we're looking at having regulation, right now, in place in either six or eight geographies, depending how you want to count them. And then we know there are, probably, 11 or 12 more, including Australia that are in the process of writing regulation now. So, we know that this is going to be a long road ahead, and we're going to be at this for many years.

If we look at UDI at its most basic level, we know that you need to have a Unique Device Identifier, we know that, the UDI-DI. And we know we need to have barcodes on product. And I think that's a simplistic view of UDI, and I think that sometimes industry looks at this too simplistically. But there really is a whole lot more to it than just having Device Identifiers and UDI on barcodes.

We really need to look at UDI from product design, and then all the way through product usage and beyond. For the Device Identifier, yes, we have to have a UDI-DI. But as importantly, we need to think through production identifiers and to make sure that we have great clarity on how that product is being controlled and what data is going to fit on that label. Whether it's simply an expiration date and a lot number, or whether it's going to be a manufacturing date alongside of that, or, perhaps, serial numbers. And some of this is going to vary by product type. So, there needs to be a clear strategy on production identification.

And then the UDI-DI is not going to stay the same forever. And this has been a challenging spot in the industry. There are conditions, referred to as a UDI-DI trigger, of when that Device Identifier is going to change. And that's something that the industry, overall, is still working through. There are different rules, different requirements by geography. And the industry has to get this all sorted out.

We need to place the UDI on the device, and then there's a lot that needs to be done for data. Creation of data and the continued publication and maintenance of it. And a lot of work needs to be done to add UDI to applicable processes, whether that's complaint handling, whether it's recalls, or if it's commercial applications. But there's a tremendous amount of work to take this information, integrate it into internal processes. And then, also, make sure it's going to work with healthcare providers, distributors, and regulators.

And then, lastly, to maintain the system. You will not be done with UDI the day you reach that milestone with the regulator. It will go on, and on, and on. And, of course, there will be other countries that will be coming aboard that we're going to need to implement that, as well. So, this is something that's going to require ongoing support and resources.

If we look at UDI simplistically, what we would like to see is, if we have a global product, we would like to see the ability to use one label, label a product once, have a small set of UDI data, and push this out to every country and every regulator in the world. The reality is it's not going to be that simple. There are some instances where we have to add supplemental labels to products, and then, of course, there are some instances where you have country-specific or regional-specific products, and it's going to vary.

And then there's also been unique country-specific data attributes in each and every country that's come up with the UDI regulation. Now, we know that TGA can't come up with the regulation that's going to align to all the existing regulations that are out there. It's virtually impossible. And the reason we know that is there is much difference in regulations that we have today.

Before I get into that, I'd like to share a little bit behind the curtain of what's being done right now to gather all this data up. If we look at the US and Europe, we have, between the two, about 125 data fields. I think where we're going to end up is we're going to have, probably, 400-plus data fields that we're going to need to maintain in our system as we look across the world toward UDI.

Currently, this data lives in a lot of different places. It could be from the product label, it could be in our TrackWise system, it might be something that's stored in our warehouse management system. It could be a technical file, it could be in paper files. But we need to gather all this data up, we need to make sure that we have clarity on what's expected of it, and we need to put this into PIM system, Product Information Management, put it in our PIM system and then push it out to all these countries.

Again, this is why we're really, really interested in making sure that we can have harmonised requirements wherever possible because it will make it just that much simpler and improve our data accuracy the more we can align these different values across the world.

A summary of the challenges that we see. There are seven categories I have listed on the screen. I'm going to go through this quickly, just in the interest of time. But there are seven unique areas that I look at that we're hoping that we can get alignment across the various regulators and have global requirements more similar than dissimilar.

We're starting off with the US and the European Union. There are differences between the two regulations, and I'm not going to go through this in great detail. But if you look at even who is responsible for the label, in the US, the FDA describes it as the labeller. In Europe, it's going to be the legal manufacturer. Europe is grouping products together with the Basic UDI-DI. There's no such concept in the US.

If we look at which products are exempted, the U.S. FDA exempts GMT Class 1 devices. There's no such category in Europe. We have the National Strategic Stockpile in the U.S., those items will be exempted. That concept does not exist in Europe.

Europe has an exemption for space limitations. U.S. FDA will provide exemptions if you request something specific from your regulator and they agree. So, if we look at which products are required, well, it's generally the same. And in most instances, we can think of a product that requires UDI, one geography requires it at the next, there are differences.

If we continue to go through this... Again, there is not time to go through a detailed comparison of each. But for retail, we have an exemption specifically for Class 1 products in the US, it's more extensive in Europe. If you study the two regulations side by side, you'll see that there are differences. So, there's no way that whatever TGA comes up with can be exactly the same as the U.S. and exactly the same as Europe because there's differences between the two regulations.

If we think of the barcodes or the data carriers, whatever you want to refer to it as, that fits on the products, most markets have movement towards market-selected UDI carriers. And at the top, you'll see an excerpt from the China National Medical Products Administration regulation, where they describe this, that it'll be the registrant that will select which data carrier is going to be used.

And something similar is in the U.S. regulation and in European regulation, where they're relying on the ISO IEC requirements, the issuing agencies, and for the market to sort it out. And we've had something interesting that we're still working through, and this is with the Saudi regulator, where they want a single barcode. And in some instances, if we appy this with 2D it could cause confusion in other markets.

And I think that we applaud the Saudi regulator for the work that they're doing on market adoption, but this is a point that we need to think through and coordinate. Because it could possibly be that we would have devices that would be labelled in such a way that we could sell them in Saudi Arabia, but that marking might not work, and might not be viable in other markets. And that's what we really don't want to see. We don't want to see differences where we could have had the same device but have to split it and have another device because of the barcode.

So, I think that there needs to be continued coordination amongst the regulators and, also, healthcare providers and distributors in the market so that we can sort through this. And the example I just provided, there are currently discussions with the Saudi regulators to think how this can best be coordinated.

Other examples would be when we study the product data. Here's an example where we have the same data definition, the same data name, Primary DI, but yet it has a different definition in the U.S. and Saudi Arabia, compared to what we call it in China. So, we can work through this, but we need to have clarity, we need to have a clear data dictionary so that we know even though we have the same attribute name that it has a different meaning.

Another example is clinically relevant size. Some of the regulators want to have the clinically relevant size in their database. And we find this to be something that healthcare providers really like. They want to understand beyond the description which sizes the device comes in and which one they're referring to when they think of a certain UDI-DI. So, whether it's a stent, syringe, or a catheter, whatever it is, you could think of those devices as being, generally, the same, except they would have different size data.

Well, it turns out that we have a different list in the US than what we have in Europe. And before it's all over with, we're going to end up with the same device that we're going to describe one way in the U.S. and one way in Europe. I think this will be as confusing as can be for the regulator, the manufacturer, and, also, the healthcare provider when they study this. But we're going to end up with some situations where we're going to have to describe the product differently because the choices within the regulations aren't the same.

Another example is sterilisation methods. If we look at the choices between China, South Korea, and the U.S., we have different choices. And this applies to devices that must be sterilised after they've been shipped to the healthcare provider, and you have to give instructions as to how this is done. But we don't have the same list.

And you can see how confusing this is going to be. And of course, we have etcetera, where we could write that in for South Korea. But ideally, what we'd like to see is the same set of choices so that we could describe that product in the same way if it's sold in multiple markets.

For non-harmonised data attributes, this is a comparison with Europe specifically. And we do a similar analysis in each market. And the idea is, we want to make sure that we understand and that we have just perfect clarity on what the data definition is. And to know if we can use a piece of information in each market.

So, if we look at the U.S. compared to the European Union, in our internal system, we need to have 68 data fields for the U.S.. And of those, we know that 36 of those fields can be used in the U.S., they can be used exactly in the same way within Europe, so we end up with a 53% overlap.

So, we've done this for each, and every market and you can see how confusing this does get because we need to understand right across Europe, which attributes can be recycled. And then for each other market, we need to do this, and it becomes complicated in that we look at just the overlap between those two markets and the products that are sold in them.

But this is the type of analysis that device manufacturers need to do. And we have to have specific policies, procedures, and processes to make sure that this is perfectly clear and that we train the individuals in our business units that create this data. And I'm guessing that other device manufacturers on this call are doing something similar or, perhaps, the same thing. But it's going to be absolutely essential to get alignment between these attributes.

In addition to aligning regulations with other geographies and other existing regulations, we also think it's important to have alignment between what supply chain is going to use UDI for and, also, what clinicians want to use UDI for. And I think this is going to have to be balanced through the regulation. Yes, you need to have something that's going to fit for safety and surveillance purposes. But if no one can use it, well, then, I think UDI is not going to achieve its goals.

So, I think there's an important set of considerations that you can expect for both clinicians and for the distributors. If we look at the clinical usage of UDI, these are the questions that are coming up in our market. UDI needs about which barcode that needs to be scanned. If you look at products in the market, you'll see that there are sometimes proprietary barcodes that have nothing to do with the UDI and might have other functionality with the product.

I think there's a desire for a one-to-one relationship between catalogue numbers and the UDI-DI. Accurate master data continually comes up. I think stability on the assignments, that the healthcare providers looking for the logic, how are UDI-DIs assigned and when do they change? When's the manufacturer changing this UDI-DI and what's different? The healthcare provider will want to know is it, in fact, the same device or is it something that is different, and do they need to have different precautions when they use this?

But just a tremendous number of questions come up as the healthcare provider thinks of how they're going to harness the UDI data. And the challenges we continually hear, gaps in IT, challenges for funding because there is a cost for healthcare providers to implement this information. And then, also, the desire to have C-suite support. And these are questions that come up over, and over, and over with healthcare providers across the U.S..

Another example is we think of supply chain usage of UDI. And this includes the distributors. So, when I say supply chain, I mean everything the device manufacturer does when they ship that product, whether it's going to be shipped directly to the distributor or whether it's going to go to the healthcare provider. But there are some different considerations.

When you think of what needs to take place in general distribution, it could be that that case or that product needs to fit on a conveyor belt or an automated scanning system. There's a desire for big bold barcodes that you can scan when it's up on a rack in a warehouse. Or if it's coming through a conveyor belt at a pretty good speed, to be able to scan it quickly.

There are question marks on which production identifiers are going to be used and which ones need to be scanned and which ones can be ignored. And then just the ability to absorb, process, and use UDI data. These are questions that come up continually and need to be thought through and need to be planned.

I think that U.S. FDA did an excellent job of taking this into consideration. And when they were first picking issuing agencies, did a lot of work in studying this to think through how this would all fit together.

Challenges that we see as we're looking at UDI globally. How do we migrate to newer barcode formats? There is a desire to use data matrix and some other more compressed formats. But portions of the industry are stuck as they are able to use linear and maybe they can't use the 2D barcodes yet. And as we have the desire for more information in that barcode, there's some challenges that we need to work through.

And for the distributor or even for the healthcare provider, when you look at clinical applications, they need to make sure this fits in their ERP system or their warehouse management system before they can use it. So, this becomes, I think, just a complicated topic.

And to provide one simple example. I know this seems really simple as we look at the slide, and you'd wonder why this ever caused a problem. But this is something after eight years in the US, we are still sorting through.

This is a product line that has three levels of packaging. We have an individual base unit for each. We have a box. Some might refer to it as an inner pack or a shelf pack, that's at interim level that you might have stored at the hospital. And then we have a case that we think in terms of what we ship through the supply chain.

Now, this seems simple, but we would have a different UDI-DI on each level of packaging. And something that seems simple has been incredibly complicated for us to sort through because a lot of hospital systems don't have the ability to easily store this in their system. Or it could be their distributor removes the case and only sends them an inner pack, and they're not familiar with the third level of packaging.

Something this simple has required a lot of time and we're still sorting through this. I know in the U.S., for BD, we make a lot of these devices that have three levels of packaging. But something that's seemingly really simple has to continually be reminded and we have to go through and sort this out and make sure that it's clear to the user.

Here's an example of a training slide that we've used to try to make this clear. We've tried to remove some of the different names, the case, and the box, and the each, and just referring got this as level one, two, and three. And you can see the extract from our SAT system, the device identifiers are listed, and what the quantity is. And we've tried to boil this down and make this clear for our internal users and, also, for our customers.

But this is something that I suspect is going to occur in your market, as well, as you work through UDI. This is just one example. We could have 20 other instances of some challenges that you'll face in months and years to come, but this is just one.

So, as far as the current status in the U.S.. We have a regulation in place going back to 2013. There are still a handful of extensions that the U.S. FDA has provided, so I can't say that we're 100% complete. They have some exemptions that still will go a bit longer, but probably, I don't know, 97% of devices have UDI on them today. So, it's been implemented by U.S. device manufacturers.

We, certainly, have healthcare provider interest in implementation. And then we have support and engagement from U.S. FDA. What we don't have is widespread UDI adoption by hospitals. I mentioned earlier some of the success stories, and we tend to see the bigger, better resources hospitals using UDI. But we do not have all 6,000-plus hospitals in the US using UDI today. We simply don't.

And I think part of this comes down to the collaboration that is required. And there are a number of organisations that continue to focus on UDI in the U.S.. We have GS1 U.S. that has a user community of the device, manufacturers, and healthcare providers that are familiar with the GS1 standard. We have AdvaMed, that's our industry association. And that's something that device manufacturers will reach out to AdvaMed to coordinate various points and bring them to U.S. FDA.

And then we have examples such as the Healthcare Transformation Group, that's made up of healthcare providers, specifically, and they have their own interests. I think one that cuts across all these boundaries is the AHRMM Learning UDI Community. If you're not familiar with this organisation, this is the Association for Healthcare Resource Materials Management. They are part of the American Hospital Association.

And this is a group that worked with the FDA under a Memorandum of Understanding. And what they've done is they come together, and they try to sort out various UDI questions that have come up. And there are a number of things that have come up and continue to come up in the U.S., and this has been a very good group for us to work towards and for us to work with as we're sorting this out.

So, I've covered a lot of material. I went through this really quickly. But if we were to think through what UDI success looks like from a manufacturer's perspective, and if we look back five years, eight years, ten years, whatever it requires to get UDI implemented in Australia, the three things that we'd like to see. First off, we'd like to see globally harmonised requirements to the extent possible.

And we know that it's not going to be possible to have something that's going to align with all requirements, for some of the reasons I've already given. But the more alignment we have, the better off we all are. If we have existing labels that are already suitable in other geographies that are sold into Australia, then it means you can move that much quicker on implementation.

If we have the data that's better aligned, then we can have better clarity on what's expected, I think that helps device manufactures. I think that helps healthcare providers, specifically, as we start thinking in terms of registries, where products are being compared across different geographies. I think it helps to have this when thinking in terms of clinical studies.

And then I also think it's beneficial for the regulator to be able to study data across markets. So, if we have globally harmonised requirements to the extent possible, I think that helps the entire market. If we have an uneventful implementation process with ample planning time and includes pilots and the ability to learn, I think that's helpful.

And then I think, finally, when we look back when this is finished, if we have widespread adoption by healthcare providers, and the overall healthcare ecosystem. And that leads to the patient safety and the other associated goals and objectives, then I think we could look at this as having been successful.

So, anyway, in the interest of time, I'm going to stop here.

Michelle Van Wijk

Excellent. Thank you so much. Thanks, Dennis, for your presentation. Really appreciate your insights and, particularly, the views from implementing across multiple countries. I will ask our mediator to please pass, (or our moderator), back control to me. And I will move forward with the slides from here.

So, this is our landing page for our Australian UDI database. As I said, our test version, but it aligns with many of the standards that are in place, we're building that in as we go. This is a particular device which is a Compass Hinge, and our data is off the US GUDID database. So, this is publicly available data for a real device.

So, what I'd like to show you is a couple of things on here. So, what we've done is we've taken the clinical characteristics versus device information. We've characterised the data down the right-hand side in a way that we think is meaningful. But, obviously, that's something that we're going to test. So, from here, you can see all of the device information, including the packaging and other information.

What I wanted to show you on this case, I wanted to show you a couple of things specifically, we've done. If you think in clinical use or, for example, as a consumer, I might have a patient implant card with my details on, so there might be some things that you would want to see as a flag.

So, in this case, we've mocked up this version where we know the MRI safety status is that it's unsafe. And we've put a little flag over here so you can actually see. It gives you an alert that there's something that you might want to have a look at.

So, I wanted to show you that. And if we come back to our search results, you can see here this is where I actually did my search for a device. So, at the moment, we've got some functionality that allows you to search for a device using any of the text or, in this case, that's the actual device identifier. We also have a function that you can scan a barcode.

So, this version I'm showing you is on the screen, but this actual version will also run off a phone or another device, like an iPad. So, what you can do, and I won't show you that this morning, is you can actually scan a barcode on your phone, you can do it from your computer, as well, or you can type in that number manually. And it will go and search the data.

And so, if you think of a scenario, Dennis mentioned a big and bold barcode so they're easy on a shelf, you can actually take your device around, if you want, and scan off a phone or another similar device and get the device information up.

We've put some download functionality in place to actually give periodic updates or full snapshots. The other thing I want to do is I want to show you another data, another device. So, what it's doing now is it's automatically searching every time there's a device there. I'll show you this one, as well.

So, the search has brought up the data. I'm now asking the system to load the device data, and I wanted to show you a couple of things on this one. So, again, this is an idea that we've had around how to make some of that device information more available and accessible. Because there is a lot of information that is being stored around the devices.

So, a couple of things you'll notice here, we have that flag up here that says this device is software. We have a link here that says additional information is available. So, if there are electronic instructions for use, for example, you can actually click on there and it will automatically take you through to the website that's got those IFUs on there.

The other thing is, you can see up here, you can download this data if you want to, and we've got a couple of formats up there. We're working on the ones that we think are the most frequently used or common. And you can actually click on here and report an adverse event for this device. And so, what that allows you to do is it will show you... It just takes you through to our TGA screen. So, there's no provision of data from one system to another, but right now, what it does, it allows you to click through and do that.

So, I'm hoping that was useful. I wanted to really give you a view of what it is, how it's starting to look. And when we start to have these collaboration sessions, that we'll be able to do that in a lot more detail. We're now at the end of our session and we'd really appreciate if you can take five minutes to complete our live poll.

And in this five minutes, I'll go through the rest of the questions and see if there's anything for Dennis, in particular. And if not, we'll answer some of the questions. We got some prior to the webinar and we'll be able to provide a response to those. So, we'll switch over to the live poll, and we'll be back shortly.

Hi again, everybody. I just wanted to thank, again, Dennis, for his presentation. I don't have a single one, question, that I need to refer to you, Dennis, but I would imagine we might get some after the session. So, hopefully, you will be happy to answer them in the future if need be.

So, I'm going to cover off some of the questions that we got pre-webinar, as well as some from the webinar itself. The answers to all of our questions will be going up on our website, as will our recording of the July session.

So, I've got a question that says who will be responsible for typing the products into the database? It's a good question. So, we're still looking at what is going to be the most effective way of having the data come into the database. So, you saw Dennis mentioned things like machine-to-machine for manufacturers. It is really beneficial. We're looking at the mechanisms, but also, then, who can provide the data, whether that's the manufacturer or the sponsor.

So, we did ask that in our second consultation, that question, and we got about a 50/50 split. So about 50% of respondents said it should be the manufacturer because the manufacturer actually creates the device identifiers, and has all that information in their systems. And 50% said the sponsor is the legal representative in Australia so it should be the sponsor.

So, it is something that we are continuing to consult and engage on. We'll definitely do that around the mechanisms, and then the question for whom is responsible, we will need to do that, as well.

We've had some comments, as well, but one of the questions was is the UDI applicable to lower-class medical devices, such as Class 1? And you'll see that Dennis talked about some of those differences between countries, in his spreadsheet, in his presentation. Again, it's something that we are looking at to see which of the devices need to be included, and we will look at that as part of that. So that'll be part of our ongoing work, as well.

There was a question that says, who assigns the UDI if the device is manufactured in China and needs to be imported into the EU or U.S.? So, I would imagine, in that scenario, it has to be one of the issuing agencies that is responsible for, or assigned, or accredited in the EU or the U.S.. But again, that's something that from a TGA perspective is not really within our remit.

Another question we've got is, is UDI required for every device or as per the GMDN coding, i.e., like kind of device? So that's referring, specifically, to our regulations that require an inclusion or the kind of device, which is determined by the GMDN code. The UDI database is at the level of the model of device. So, the device identifier will be required for every model of device, which will be different to the level that we included in the ARTG.

So, I'm just scrolling through some more of the questions. A lot of questions around the classes, which will be included. So, we'll be continuing to explore that, going forward. We will likely start with high-risk devices, as have other organisations in countries.

Where can I obtain the Australian UDI data elements is one of the questions. So, once we have defined what they will be, we will publish those in a document that makes it useful for anyone providing or using the data to understand what the data is and what it's called. So, as we continue to work, we will publish those guidance and those documents, as well.

Will the UDI be applicable to software that is a medical device, such as EMR? So, I think the answer is yes to that, that if it's regulated as a device, that it will also require a device identifier, and that's similar to what other countries have already implemented, as well.

One more question, we've a minute left to go. Does the TGA expect to align with the EU or the FDA? And so, we asked that in our second consultation paper about the benefits of aligning with one or the other. And we got about a 50/50 split between the benefits of aligning with the U.S. or the EU. We got some feedback, such as the benefits of the U.S. is that it's already in place and has been running for a period of time. And the EU is still evolving and emerging.

And we know, we talked last webinar, about the data that the EU is capturing, in addition to the standard data that is from the core from the IMDRF regulations, for example, the Basic UD ID, and we'll continue to explore whether that's something that we might keep, as well.

I'm going to stop there. It is 12:30 our time. Many other different time zones, I know, have dialled in. We'll make the webinar available on our website. And again, I wanted to thank Dennis for his time today and for his really valuable input.