UDI Global Manufacturer Learnings and Project Update

Michelle Van Wijk

Thank you so much, Steven. And good morning, good evening, good afternoon to everybody. I'd just like to say welcome to our UDI webinar 8 today. Before we begin, I would like to start by acknowledging the traditional custodians of the land on which we meet today. Where I am in Canberra, it's the Ngunnawal people. And I'd also like to pay my respects to elders, past and present, and extend that respect to any Aboriginal and Torres Strait Islander colleagues attending our webinar today.

For our agenda today, we are absolutely delighted that we have an invited guest speaker, Roger Peterson, from Arthrex. He's going to be talking through his experience, some of the challenges he's seen in UDI implementations globally. And a little bit of an extra focus on labelling as well today. We're very excited that Roger has made the time available to share his experience with us today and with you. We'll do a project update, in terms of where we're up to. And also, what's coming between now and the end of June.

Then we'll have time for questions and answers at the end. As Steven mentioned, this is the first time we've been using Slido. And Rachel, as you know, is our normal operator, has lost her voice. So, we're going to be keeping everything crossed that the technology works for us. Please bear with us if it doesn't. And if you have any questions, please let us know. If, for any reason, you can't get Slido or you have any concerns, you're welcome to send us questions to our email, which is udi@health.gov.au.

And we'll make sure they get added in there as well. I'd like to now introduce our special invited guest presenter, Roger Peterson. Roger is a Senior manager for Global Labelling in the regulatory area for Arthrex. He has over 20 years' experience in the industry, within several roles, crossing product development, quality assurance, operations, and regulatory operations. He joined Arthrex in 2016, and he has experience across other organisations, as well as Arthrex, including Integer, Abbott, and Steris.

He's an active member. I don't know how Roger gets any time to sleep or work or have a life outside. You can see he's an active member of various committees and working groups and other groups, like the EUDAMED working group, the MedTech Europe implant card working group. He works with the ISO technical committee 210, which is working group three, that looks at graphical symbols and nomenclature, both critical to UDI. And also, he's working leading the Arthrex EUDAMED work, with global Unique Device Identification initiatives. So, very much focused on the European implementation at the moment.

Thank you, Roger, for making the time today. I'm very much looking forward to hearing your presentation, and we will hand over to you now.

Roger Peterson

Thank you, Michelle. Thanks everyone for joining today's webinar. Basically an introduction to Arthrex incorporated. We're headquartered in Naples, Florida, USA. It's basically South-west Florida. We have locations globally throughout the international community. We have a sister headquarters in Munich, Germany, as well as a central distribution logistics centre in Venlo, Netherlands. And we also have a subsidiary in Sydney, Australia.

We have over 19,000 product innovations within our product portfolio, all of which helping surgeons treat their patients better, within the orthopaedic sports medicine space. Products including arthroplasty, distal extremities, synergy, imaging, arthroscopic surgery system, shoulder elbow orthopaedics resection, knee and hip devices. We're also MDSAP (Medical Device Single Audit Program) certified in the US, Australia, Canada, Brazil, Japan. All under ISO 13485, with BSI and MDSAP certifications.

What is UDI and how do we use it? It's a question that's often asked by laypersons, not familiar with UDI. But I'm sure everyone on this call understands what the basics are, with that being device identifier, production identifier, a corresponding unique device identification database. A means to automatically capture, by automatic identification data capture, that being the barcodes paramount to the product labelling. With Arthrex, our UDI issuing agency is GS1, the UDI-DI that we use is a Global Trade Item Number.

Product identifiers, including expiry date, manufacturing date, lot and/or serial number. Following the International Medical Device Regulators Forum, there are four primary tenets of the UDI system. Assigning means to assign the device identifier, GTIN. Our labelling, containing device identifier and production identifiers. And then registering the subsequent data record, payload of UDI data attributes within a national registry. And then, of course, enabling healthcare practitioners to scan, transact and retain UDI information.

Within the Arthrex global UDI strategy, our UDI team reports into regulatory operations. We work with data stewards and champion the stakeholder engagement throughout the organisation, which continues to grow, as the need for UDI data increases. Partnered heavily with master data governance to ensure data integrity and data stewardship actually is maintained, via process and work instructions. We also work closely with supply chain logistics, the ability to scan and transact materials.

We also support our healthcare providers, both from enabling data subscriptions through GDSN in syndicating UDI data, but also in regards to transacting within their scanning technologies. And then, also our in-country regulatory support. Various jurisdictions, such as South Korea, Australia, Saudi Arabia, where the in-country representative has or will be publishing our UDI data.

Within the global program, the USA, the FDA GUDID is fairly mature at this point. We are in the throes of meeting our European MDR requirements within EUDAMED, which is European Database of Medical Devices. Saudi Arabia, levels of compliance we've achieved thus far. South Korea within the integrated medical device information system. And then, of course, following the growing regulatory landscape within Australia, in the development of the AusUDID. China UDID and Singapore UDID.

And then, following the regulation within Brazil that was published this last December. And then, of course, there's other jurisdictions and various levels of regulation development that we're also tracking. Within the Arthrex UDI program, product development in engineering is, in essence, the starting point. Creating the materials, building materials, all associated product attributes, part description, GTIN, serial, is the device sterile or not, clinically relevant size information. And then, we also work closely with label development in designing the labels.

Required information, date of manufacture, if applicable, shelf life, expiry date, magnetic resonance safety information. And then, subsequently publishing the data to the FDA GUDID or jurisdictional registry or database. Supply chain: ability to manage product deep activity, material status, country of origin, and then, working within the various distribution channels. Label operations is key. Imaging the enterprise, labelling master data within the enterprise software systems. Printing correct and legible labels is paramount.

Ensuring the barcode scanability and maintaining barcode quality are characteristic. Managing manufacturing and operations: obviously, there's various depending on if you offer reusable devices, there's direct part marketing involved. Packaging, labelling application, product traceability, warehouse and logistics and material transactions, labelling, seamless customer order fulfilment. Of course, quality assurance and control while maintaining GTIN functional name and verifying labels.

And then, regulatory affairs is key. Maintaining correct FDA product codes, submission files. Global inclusion listings is key, as well as other regulatory data. As far as how we provide our UDI data, our system of record is our ERP system, which is SAP, based on the various projects within our UDI program. EUDAMED, for instance, where we're continuing to collect data, which may be in the form of spreadsheets. But we are moving towards populating the data within SAP.

Our data publication, basically by means of a Product Information management system, where we publish data through the GDSN to our recipients, whether it be hospitals, distributors, FDA, GUDID, outside of US regulatory bodies etc. Hospitals need the UDI data for transacting electronic patient health records, using such systems as Epic, Cerner etc. Some of the data challenges related, or data attribute comparison within our UDI challenges. We find that there are some data fields that match identically between, for instance, EUDAMED and GUDID. There are some fields that are similar, but different, as far as the type of data.

The enumerations, if you will. And then of course, data fields that are new within EUDAMED. Single registration number, authorised representative, contact information, risk class (European risk class), the additional trade names, restricted number of reuses for our reusable devices, URL for additional information, and critical warnings. Even endocrine disrupting data related to substances that might be used either in process or within some of our devices.

We found on average that data attributes in scope for Arthrex like the GUDID, were averaging roughly 59 data attributes, on average. That cascades into 81 for our EUDAMED legacy device registrations. And then, we're finding now that with our EUDAMED preparations for the EUMDR, that cascades even further into 135 data attributes. And what's interesting is, the data identification is step one. Step two is then the harvesting the data. And then, populating that within our ERP system, which is our source of truth.

Even once that's accomplished, then we have to build a process around maintaining that data, engaging the stakeholders and data stewards in supporting an ongoing process, which is key to the overall success of our UDI program. Some of the other things related to EUDAMED, under the medical device directive from our legacy devices, the key field within EUDAMED, which is in EUDAMED DI has a one-to-one relationship with the UDI-DI.

However, that is starkly different under EUMDR, where we structure multiple UDI-DIs within a single, basic UDI-DI, which is the global model number. This illustration illustrates how we need to nest or aggregate the UDI-DIs within a Basic UDI-DI. We're not doing that within our European system, however, within our Product Information management tool, we are planning on managing this essential relationship of UDI-DI with a Basic UDI-DI. Another challenge is the nomenclature.

Most of you are aware in the European Union they have adopted the European medical device nomenclature, which is founded on the former Italian classification for medical devices. What's important here is the relationship of EMDN and global medical device nomenclature, ensuring that we have that same relationship within our ERP system. Manufacturers are responsible for allocating the most granular code available. Here's some examples of the EMDN codes that we've allocated for some of our devices.

It's a levelled floating structure, up to seven levels within the architecture of the nomenclature. As far as consumption of UDI, a change of subject here a little bit. The UDI data carrier, under certain regulations, European MDR Annexe VI, Part C, 4.5, AIDC carriers other than the UDI carrier shall be readily identifiable. Same with the FDA, where the AIDC technology and the barcode used to convey the UDI is not evident on visual examination, the device or label package must disclose the presence of an AIDC technology.

And this has been a challenge within at least the United States, having its genesis within the industry association for our healthcare practice for practitioners and surgeons.

The Association of Healthcare Resource Materials and Management, or learning UDI community, presented a work request to the ISO Tech Committee 210 working group 3, to develop a graphical symbol for manufacturers to use. And this is the result of that work that was put forth over the course of several years, the last three years basically, in developing this graphical symbol and validating it for inclusion into ISO 15223-1. That standard was published this past year in July of 2021. This is an example of where the UDI symbol was to be used.

Typically, where a medical device may have more than one barcode, being disparate from the UDI data carrier, it is recommended to deploy the UDI symbol with the UDI data carrier that only contains the UDI-DI and UDI-PI, leaving other barcodes in their own space. This enables practitioners to quickly scan and transact the UDI information within the surgical suite and hospital point-of-care locations. Another use for the UDI symbol is within the implant card.

This is actually a promulgated requirement within the Medical Device Coordination Group guidance of 2019-8, that the UDI symbol is actually included with the UDI-DI. And then, at the top right here, we see a couple of examples where the UDI symbol is deployed with a linear, typically a GS1-128 barcode or a 2D data matrix barcode containing the same attributes.

Within the US, the Centres for Medicare and Medicaid services, as far as reimbursement activities are concerned, are open payments. There's actually a regulation now where our healthcare practitioners are required to capture the UDI-DI for purposes of reimbursement. And this is critical in the sense that they need this information quickly. And they need it to be reliable. In essence, the UDI system as a whole, it starts with the manufacturers' allocation of UDI-DI and then, subsequently publishing the data to a UDI database.

But it's critical, because the practitioners, they're relying on the barcode quality, and being able to scan and transact that UDI-DI and UDI-PI, but also, being able to transact against what was published in a UDI database, such as UDID or other jurisdictional UDI database.

As far as the future of UDI, at least with the US, we have NEST, which is the National Evaluation System for Healthcare Technology coordination centre, partnering with the FDA Centre for Devices and Radiological Health has its foundations in UDI. And it's basically a voluntary data ecosystem, consolidating real-world evidence from the various clinical registries within a lot of patient health records, medical billing, reimbursements, patient-mediated data, and material logistics.

The reason being, is that when collected and used effectively, real-world evidence can actually benefit all the stakeholders within the NEST ecosystem by empowering patients, accelerating medical device innovation and overall improvement of healthcare outcomes. I think that's it, as far as what I have for tonight.

Michelle Van Wijk

Thank you so much, Roger. Really appreciate that. And we'll come back with some questions and answers at the end. If you have questions specifically for Roger, please put them into Slido. In terms of the update from a UDI perspective and where we're up to, I will just move forward. Thank you. We've been doing some work to, we have now successfully connected the Australian version of the National Product Catalogue, which is the Australian equivalent of the Global Data Synchronisation Network that Roger mentioned.

We've managed to connect that to our Sandpit version of the Australian UDI database. We've been doing some testing on that and we've successfully passed data into our UDI database through the NPC. So, that's a very big step forward for us. We also are looking at aligning the data between the ARTG, the Australian Register of Therapeutic Goods and the UDI. There are a number of data fields, for example, that will be in both the Global Medical Device Nomenclature, and perhaps clinical relevance, size, method of sterilisation, whether the product is supplied sterile. We need to look across both of those datasets now and work out how that will fit, and how those two datasets will align. We've also established a technical working group, really to look at the ICT components of the data interoperability. For providers of data, how does the data come from those systems into the UDI?

And then, for the users of the data, from hospitals, healthcare registries, for consumers, for looking up their device that might be on their patient implant card, to actually learn some more about what's being used and prioritise the formats, particularly, that we use to support those. We have split that group into two now. We have a providers of data group and an users of data group. Once a month we come back together, and we share the learnings from both of those groups and we have presentations.

If you're not already on those, and you'd like to be included, please email us at udi@health.gov.au because it's a really important forum for sharing information. But also, to inform us on what's being used, which formats are being used, to assist us in our design and build work. Just sharing this slide again, for anyone who hasn't perhaps seen it. Our Australian timing is that we are planning to make our Sandpit version of the UDI database available in June. And that is really to assist, to get some feedback early on usability.

On how easy it is to connect to. Whether there's things we'd need to adjust to make it more useful and more useable ahead of voluntary compliance in January 2023. It will be only voluntary; it will be for high-risk devices. But really, that next six months on the use of the Sandpit is to help inform us, so that when we go live in January, we've already got that feedback around usability. What that also means is in June this year, we'll have a third consultation paper.

And that will be very much focused on the regulatory framework to allow us to be informed when we put our advice up to government, in terms of the regulatory framework for UDI in anticipation of that January start.

And then, we still need to work through what the transition looks like in Australia, given we know other countries have gone by risk class. We've also had feedback that we could go faster. We need to look at both of those, and that will be part of our regulatory consultation in June. So, really appreciate any input to the regulations through that consultation paper. And we'll provide more information about that.

A little bit more about that technical working group. We've got some themes that have emerged as part of the discussions there. You heard Roger and many of our other guest presenters from manufacturers, talk about the challenge of managing the data elements, so that we have that emerging theme of minimising anything additional for Australia. To make the definitions clear, to avoid any confusion, so everyone is aware of what a particular data item is meant to mean. The ability to allow changes to data.

We know, particularly from the US implementation that there are reasons for changing data and it should be easy to do that. We've used at some of the formats and the preferences around the formats for machine-to-machine data upload, including HL7 SPL and FHIR. We also heard to base initial considerations on the US FDA UDI implementation. Needs support for automated versioning of records. That's the ability to see what has happened over time, how the data relating to a device has changed and see what those changes are.

Also very strong feedback every time we consult on the importance of a helpdesk for support, the ability for us to provide those mechanisms to allow that support. And the relationship between catalogue number and UDI. They are discussions that are ongoing, from a provider working group perspective. Just a reminder, in terms of what's in the Sandpit. Ideally, we've broken it down into the four key user groups. Sponsors and manufacturers will be focused on how do I get my data into this system? How easy is it? Which data elements?

How might I make changes or delete those? How might I attach a document or a URL to a Product Information, for example? And then also, when we look at that alignment and integrity with the UDI and the Australian Register of Therapeutic Goods, what needs to happen as part of that work? From an early adopters' perspective, we have early adopter project based in Queensland with Queensland Health at the moment. Really, how do they get access to the data? How might they download it?

How might they see the changes over time, from a registry perspective, for example? The scanning, so the ability to actually scan. And then, look up that device information on labels and through barcodes and other symbologies. And then, the device data. We've downloaded quite a bit of US data out of the GUDID to support some of those projects, and for Queensland particularly, at the moment. From a public user, so as a consumer or as a theatre nurse, or anyone who might want to look up or download data. How would they do that?

How would the scanning work? And what access do they need for downloads, for example, using the comma separated values, because it's the most common, in terms of that use. And then, the Therapeutic Goods Administration, there's work that the TGA needs to do around UDI as well. They'll need to manage reference datasets. They'll need to look at operational statistics. We'll have to manage releases and reference data and do the data integrity and validation checking as well.

All of those four groups of users will have access to the Sandpit from June/July. Then, to look and test and see what works, including the portal. It's not just machine-to-machine, it's through our web portal or use on a phone or a laptop or a device as well. Some more specifics. We plan in our June webinar to provide more information as well. We'll have an onboarding process, so we'll need to provide separate logons because this isn't a production environment. It will need to manage user logons and provide those.

We'll have the dedicated helpdesk support. We're in the process of getting that ready now. And that will be available for Sandpit use as well. We'll put some guidance together, some user guides on how to use the portal, for example. How to connect to provide data via a machine-to-machine interface. And then, as I mentioned, we'll have some more specifics at the June webinar. If there's anyone who is interested in becoming part of that Sandpit group, please email us at udi@health.gov.au. We'd really love to hear from you and what your planning might be, in terms of when you might like to use it.

Looking ahead to our next webinar. Our webinars are generally the third Tuesday of every month at this time. Next month, delighted to let you know we have two invited guest speakers. A software organisation that incorporates UDI in clinical and other systems, and a speaker from a [UK] hospital, who is using UDI for products, as part of the hospital process. So, really starting to hear from that use perspective in our May webinar. We're very much looking forward to that.

And then, in June, will be more information about the Sandpit, about getting access to what's in there. And the other thing in June that is part of that regulatory consultation we'll be doing using the new consultation hub tool. We will also provide information on that, probably in the June webinar, depending on the timing. But really, we're going to focus on how it might work in Australia, the impacts of accepting both US and EU labels and data, what the transition might look like in Australia. And also, what the regulatory framework needs to look like.

So, more detail on that to come. We need that in place by 1 January for our voluntary compliance. I'll stop there. Thank you very much for listening. We will do a quick five minutes of live poll. I appreciate your feedback on how the webinar went, how useful it was for you, what we might do differently next time, if you've got any ideas about future speakers. And we'll start to look over the Slido questions, I see they've been coming in. We'll come back in about five minutes and we'll start to answer some of those.

And I'll read them out and direct them to either Roger, or back to myself, as part of that process. We'll see you just in a few minutes. Thank you.

Michelle Van Wijk

Hi everybody. Welcome back. In terms of some of those questions and answers, we have a couple that haven't come through Slido. They were either pre-questions or they've come through the Q and A or the chat. I'm happy to kick off on those. We had a question on the timing for the integration between ARTG and UDI and how that's going to work. So, I'll just talk about that briefly now. We're at the point where we have a project plan that is going through final internal approval.

And the plan is that between now and June, we'll undertake some analysis to understand what the common data elements are. And what the quality of the data is in the Register of Therapeutic Goods already. And then, what we might do where we need to go back to sponsors for example, to get clarity on the data or make changes to the data if necessary. And how we align that with the UDI, going forward. It's something that I expect in July/August, we'll come out with a more consolidated view of conceptually, how the two will work.

We understand, we get lots of questions, particularly through the technical working groups, around the integration between the two and the processes. And so, they are things that we are working on. And we will be working on, as part of that project. I expect by July we should have a good idea of what that looks like, and be able to come back, perhaps if our July webinar with some more information. But appreciate the support there. The focus will be on the UDI integrations areas. And so, GMDN will be one, for example, supplied sterile.

Those areas that we know are across both. Hopefully that answers the question. And we will provide more information as we go. I've got a question for you, Roger, if that is okay? And I'm happy to chip in, if need be. But we have a question about, do you have any recommendations for Australian companies? We have a lot of Australian companies on the webinars who perhaps, haven't had to do this for the US or the EU, for example. Do you have any recommendations for them on how they might prepare for the implementation of UDI in Australia?

Roger Peterson

Yes. The person that comes to mind is their market access. Are they are global organisation, even though they're in Australia? If they are solely Australia, a thorough understanding of the IMDRF UDI requirements and building a program around the collection of the data relevant to UDI. But if they are indeed a global organisation, do you label for one market? That being said, is the labelling supportive of an international market, is a consideration, because it also relates to uniqueness of the registration within one jurisdiction to another.

For instance, in South Korea, a UDI-DI or an allocation rule could change, based on your registration. Something as simple as changing a distinct manufacture location could trigger a registration, which requires a new UDI-DI. And so, that is unique to one jurisdiction. But within Australia, a thorough understanding of the IMDRF UDI requirements would be a starting point. And then, of course, following the progression of the development of the AUS UDID, this forum and the forthcoming regulation.

Michelle Van Wijk

Thank you so much, Roger. That's really helpful. And I've got another one for you as well. Are you happy to share what you think the critical issues might be that regulatory authorities need to consider, that impact the harmonisation? You did the comparison across the data elements, for example. Or that impact multi-national companies the greatest. Are you able to share your thinking on those?

Roger Peterson

Sure. Again, the harmonisation is critical, the core product model of UDI attributes from one jurisdiction to the next is key. Where the challenges are, is where you have the uniqueness, where an allocation UDI-DI, you get a GTIN allocation rule which could trigger a unique UDI-DI, whereas 90% of your market might be fine under a particular UDI-DI, having one jurisdiction rule take precedent. There has to be a thorough understanding of how you manage multiple UDI-DIs in that instance, in essence, very specific to market access.

That would be one consideration. And then, of course, building your program. UDI is not a project, it's definitely a program which is a family of projects nested within that, because each jurisdiction globally is going to have uniqueness within their program, as far as what their requirements are, when data is submitted. Even the versioning of data is critical as well, because that will differ from one jurisdiction to another.

Michelle Van Wijk

Thank you. That's very helpful. And if there's any others you might want to provide later, we'd be happy to share those as well, if you have any other thoughts.

We have a question around, will the UDI replace the GMDN code? And I'm happy to take that one. And the answer is every UDI record will still require a GMDN code. The GMDN code is a piece of data for that device, but the UDI won't replace it. We have a question on who issues the UDI and who is responsible for ensuring it's in the label, the manufacturer or the sponsor? And I'll take that one, because we have a slightly different model in Australia. But the general rule is that the issuing agencies are responsible for the formats of the UDI.

Globally, they're generally GS1, HIBCC and ICCBBA. The three of those are generally common throughout all of the jurisdictions, but the manufacturer is primarily responsible for then assigning the UDI and labelling. In Australia we have a sponsor who is legally responsible for the device in Australia, but the labeller is generally responsible for the UDI.

We have two questions around the Global Data Synchronisation Network, around how do sponsors use it to push data through to customers and then, also, through to regulators, and whether that's double work? And the second one is, in other countries, can the UDI regulators push to the GS1 and GDSN supply chain customer portals, instead of reverse? The second one, I can't answer it. It is a very interesting question and we might go and do some more investigation on that one.

But on the first one, the anticipation is, it would be the same mechanisms for data to go through to purchases, for example, or hospitals as to the UDI. It is something we're working through. It shouldn't be double work, but we're just at the moment now, now we've got our connection up and running into our Sandpit, we'll start to work out a little bit more what that might look like, should we connect in our production version, going forward.

Another question is, what will the maintenance costs or annual fees be for subscription to Australian UDI database for manufacturers and sponsors? It's a good question. It is something that we don't yet have an answer on, but we will need to. So, for our project or program of UDI implementation, we did receive specific funding for the establishment. But UDI will need to be included in fees and charges, going forward. So, there will be future regulatory engagement on what that looks like and what those costs might be for users of the data.

Anyone who wants to download the data as a public user, there's no charge for that data access. It will be available free of charge for viewing through the portal or for download, including machine-to-machine download as well.

Another question around the integration, or the work that's going to look at the data held in the ARTG and UDI databases and will there be a plan to link them so that the manufacturers and sponsors won't need to populate them? It's a really good question and it is something we are looking at. How we can link the data from one to the other, how we can validate it if it's different, or whether we might start to auto populate in the future. A lot of that work we anticipate will come through the TGA transformation, which is looking at broader systems, outside the UDI and how that might work going forward. Because a lot of our existing systems, including the ARTG are older and more difficult to change.

But it's a good question, and we will definitely be looking at that. Hopefully, we'll get some more questions for Roger, but I've got another one, which is a TGA question. We have a question on, is there consideration of having an ARTG unlock facility, as in the FDA GUDID, to unlock critical protected fields? It's a good question.

I can't answer that for the ARTG, but from a UDI perspective, part of the work we're doing with the technical working groups is to understand which data might change, how regularly it might change. We've got feedback, for example, that in some cases, a manufacturer might accidently make an error in the data and they might not discover that for two years. And so, having a short unlock timeframe is helpful in some ways, but there are definitely going to be scenarios later on where you do need that data.

Roger talked about, for example, for triggers. When a UDI-DI changes in another country, say the EU, what does that mean for data that's provided to Australia? And would locking make that difficult, for example? Really looking at that, as part of that technical working group and also, we can consider putting it in the consultations as well. But if you have advice or thoughts or insight into that, it would be great to join one of the technical working groups. Or send us an email. That would be very helpful.

I think I've just about got to the end of the questions. Are there any more for Roger before we sign off? No? I've got another question around expected compliance requirements for different types of devices, such as surgical instrument kits and comparison to the US GUDID and MDSAP. It's something that we'll be looking at, as part of our regulatory framework and consulting on in June, really to look at UDI for those specific device types. In some cases, there are definitions that don't quite align between the IMDRF, the US, the EU and Australia, for example.

So, we'll need to look at how those comparisons will work and what we'll need for Australia. All right, we'll give everybody four minutes back. Roger, thank you again so much for joining us today and answering the questions, and providing your insights. We really appreciate you making the time, it was very helpful.

Roger Peterson

Thank you, Michelle.

Michelle Van Wijk

Thank you, everybody. Have a good Tuesday.