Moderator: Heather Howell
December 18, 2013
1:00 pm CT
Coordinator: Welcome and thank you for standing by. At this time, all participants are in a listen-only mode. After the presentation, we will conduct a question and answer session. To ask a question, please press Star 1. Today's conference is being recorded and if you have any objections, you may disconnect at this time. I would now like to turn the meeting over to Heather Howell. Ma'am, you may begin.
Heather Howell: Hello and welcome to today's FDA webinar. I'm Heather Howell, the Deputy Director of the Office of Communication and Education and FDA Center for Devices and Radiological Health (CDRH). Today we will provide an overview of the Global Unique Device Identification Database, also known as GUDID. I hope you've had a chance to visit our CDRH learn website and review the presentation titled UDI, The Final Regulation which explains the unique device identifier requirements in great detail and helps set the stage for this specific discussion regarding the database.
Your presenters -- both from the Office of Surveillance and Biometrics -- will be Ms. Anne Hawthorn who is currently working on UDI regulatory and policy implementation and the Center GUDID expert, Ms. Indira Konduri. Following the presentation, we will welcome your questions and we'll do our best to provide answers. To assist with our questions, we also have in the room with us today Ms. Anita Rayner, a Senior Member of the Office of Surveillance and Biometrics as well as representatives from the Centers Division of Small Manufacturers International and Consumer Assistance.
We ask that you focus your questions on the specific GUDID database today. If for some reason we cannot answer your question, contact information will be provided within the slide presentation. We strongly encourage your questions and feedback about this very important program. I now give you Ms. Anne Hawthorn.
Anne Hawthorn: Thank you Heather. Good afternoon everyone. Before we hear about the Global UDI database -- that is the GUDID -- I want to lay out a brief overview of the UDI System and I will learn how to make the slides work. There we go. The legislation -- the 2007 FDA amendment fact or FDAAA -- established the statutory authority for the UDI System for medical devices. Then, in 2012, the FDA Safety and Innovation Act, FDASIA, set the timelines for establishing the system.
This UDI -- Unique Device Identification System know as UDI -- you should not confuse with my uncle (Udi) although he's pretty unique too. The goal of the UDI System is to accurately identify medical devices throughout their distribution and use to enhance patient safety. The 2013 final rule laid out FDA's consideration of 270 sets of public comments and the text of the regulations necessary to establish the UDI System. The final rule also gives the timetable of compliance date which phase in these requirements and the conforming amendments which are the changes to existing FDA regulations needed for the UDI System.
In order to be familiar with these topics, as we said, we hope that you've viewed the UDI video on CDRH learn and visited the UDI page on CDRH device advice. We plan to cover these topics in depth in future webinars. The key benefits of the UDI System are shown on this slide. There are many. They relate to adverse event reporting, identifying and analyzing devices in use, making the post market surveillance system more robust both to enhance patient safety and support free market approvals and clearance.
It will help everyone manage device recalls and also support the global distribution change. To see how UDI will achieve these benefits, let's take a brief look at the steps and the key players involved in establishing the UDI System. There are three distinct sets. First, step one, develop a standardized system to create unique device identifiers. Here, the key players are FDA which accredits the issuing agencies.
When the agencies have met the requirements set forth in the regulations, the issuing agencies themselves, who operate systems -- to issue UDI's according to the International Standard ISO15459 -- to ensure uniqueness of the code and the labeler. These are the parties who apply the label to the device or replace or modify the label with the intent to commercially distribute the device without any subsequent replacement or modification of the label.
In most cases, the labeler will be the device manufacturer. However, bear in mind, that a labeler is not a distributor. A distributor merely adds its name and contact information as the distributor of the device. The second step is to place the UDI in two formats, human readable -- or plain text as is stated in the regulation -- and machine readable format, the automated identification and data capture or AIDC on the label and the packaging and for certain devices, on the device itself. Here the key players are the labelers.
We will schedule another webinar to go into detail on the UDI, what information is required, where to place the information and how the requirements will be phased in over time based on the safety profile of the device. Now -- briefly before we move to step three -- I want to show you the highlight of the table of compliance dates. This slide shows just a few highlights. The complete table of compliance dates is given in the final rule and also, we placed a copy on the UDI webpage in device advice.
The first compliance date is highlighted on this slide. This date, next September, the labelers of class three devices -- and of CBER's BLA or Biologic Licensing Application -- must meet several requirements. One of which is to submit data to the GUDID. This is the reason and the primary audience for today's webinar on the Global UDI Database, the GUDID. As I said, we'll schedule additional webinars on the details of these compliance dates and what's involved and what's required and how we'll begin implementing the rule.
As we do so, we very much like to have your input and one way we can get your input is by your submitting regulatory and policy questions. At the end of the presentation, we'll give you the information about how to do so. One more thing before we move onto that third step, these are the conforming amendments. These parts of Title 21 or the CFR -- the Code of Federal Regulation -- has been changed and amended to accommodate the requirements of the UDI. Again, we'll have additional webinars to help you understand these changes.
Now, the last step in establishing the UDI System is creating, maintaining and using the UDI database, the GUDID. Here they key players are FDA which creates and maintains the GUDID, the labelers who enter data into the GUDID and the public, including the clinical community who access and use the data in the GUDID. As you can see, the GUDID is a very important part of establishing the UDI System.
GUDID is also the main topic of today's webinar and my colleague Indira Konduri will help you understand this important part of the UDI System. Indira.
Indira Konduri: Thank you Anne. That was a great intro to UDI and it's my pleasure to be here this afternoon to talk to all of you about the GUDID. As Heather mentioned, it's been my good fortune to have the opportunity to work on this brand new program in CDRH. I have a lot to cover so I'm going to get right to it.
Today, I plan to provide you an overview of the GUDID database and get into a little bit of the key concepts focusing on GUDID account and the device identifier record, talk to you about how to get started as labelers and submitters of GUDID data and then how to contact us. Most of this presentation is focused on, again, the labelers.
As I mentioned, these are these submitters of information to GUDID. That's the focus of the presentation. Let's get started with some basics. What is UDI? UDI stands for Unique Device Identifier and UDI is made up of two pieces, a device identifier portion and the production identifier portion. The device identifier is the mandatory auto fixed portion of the UDI and it identifies a specific portion on the model of the device.
This is what is issued by FDA accredited issuing agencies and this is what stays the same. It's the static portion. The PI is the dynamic portion -- the variable portion of the UDI -- and the PI is what you would use to control production of the device. It could be the lot or the batch number, serial, expiration date, manufacturing date and for human cellular and tissue based products, it would be existing identification code.
The GUDID. You've heard about it. That's what we're calling it. Global Unique Device Identification database. It's a depository. A depository of key device identification information and the key to note here is that we're only going to collect the device identifiers. We don't collect - We don't ask for PI's to be submitted to GUDID and neither do we store it but what we do collect, however, is that the GUDID - We ask you in the GUDID how do you control production of this device? Do you use the lot or the batch number? Do you use the serial number? We ask for yes or no flags and you answer the question yes or no and that's all we collect about production identifier in the GUDID.
Now moving along, this is a picture that provides a pictorial overview of the GUDID. On the top blue box you see there are two submission options to GUDID. There is an XML file submission option and then there is a web interface option. We'll go into details of all of this. In the XML option, you would take your device information, put it into the XML file format and send the file to use one DI record at a time. The web interface, you basically enter device information into a secure web interface.
On the right hand side, you see that there are two GUDID search and retrieval options and one option is public users could access of a GUDID web interface and pull data out. Later on in the presentation, we'll talk about what records can public see and what records they cannot see. Additionally, we also have two system to system search and retrieval and we have a very basic web service and then in the future, we're plan to provide download capability. This is a pictorial overview of the database and submission options.
Now, let's go look at it one at a time and we'll start with the GUDID web interface. Again, it's a secure web application. Access is by account so submission of device information is done via data entry one record at a time by labelers. You get an account established and then you have log-ins, you log in and you submit the information in a secure fashion. Then there is also a search and retrieval of device information by public users. Again, for search and retrieval, there is no need for it to have an account. Anybody can come and pull records out. We'll talk about what records are visible and at what time shortly.
The GUDID, HL7 SPL submission option is the XML file submission option. Let's go through the acronyms on this. First, HL7 stands for Health Level Seven. Health Level Seven is a standards (unintelligible) organization and what they do is work on messaging standards in the healthcare space. The idea is to enable standard formats to send and receive healthcare information. SPL is structured product labeling. It's a standard way to receive labeling information.
What we've done is taken the HL7 SPL standard and we've constrained it to the GUDID use case and we basically as you to take your device information, format it as an HL7 SPL XML message and send that to us and we tell you how to do that in our technical specifications which is available on the UDI website. Once you have your XML files, you then send it to us through the FDA Electronic Submission Gateway, the FDA ESG. What is that?
The FDA ESG is a solution that the FDA has been using for a while. Maybe some of you are familiar with it. It is a way to securely send electronic regulatory information. The FDA Gateway authenticates the sender so we know who it's coming from and then it makes sure that we get it in a secure fashion. We use the FDA ESG to receive it. Once it comes to CDRH, we pick up the XML file, (unintelligible) and then that gets loaded to GUDID. If everything goes well, we send you an acknowledgement and say your submission passed. If it doesn't go well, we send you an acknowledgement saying here are the issues and your submission failed and then you get an opportunity to fix it and send it back to us again.
The HL7 SPL option is going to require some testing. Before you can send it to production GUDID, you have to complete some testing. It is testing required by the ESG folks and there is testing required by us. The testing requirements for GUDID are specified in our technical specifications so you know what's required. You need to complete that prior to going to production.
Moving on to search and retrieval, as I mentioned, there are two options. The web interface search and retrieval, we have quick search which enables you to search on the four attributes listed there. In the advanced search we have exposed additional GUDID attributes so you can narrow down your search and do more finer searching. The system to system search and retrieval, we have a basic web service as I mentioned. If you have a device identifier number -- the DI number if you remember, the static version of the UDI -- you send us a DI number, if we find a match in our database, we will return back to you the published attributes that we have.
We're also working on database download capability. Hopefully we'll have it in the next year. The key though here, I want to point out that if I say they will be available - Both the GUDID search and retrieval options have been turned off for now. The main reason is there are no records in the database for folks to come and search. Results in an FDA database that has no records, people will have more questions than anything. Once they have some records in the database, we will open up and enable search for folks.
A quick word about data quality. Anne talked about a lot of the benefits of UDI and for UDI to really - For us to really realize those benefits, UDI needs to be widely adopted across the supply chain. Additionally, also in the provider community and into patient safety and electronic health records. My boss Terrie Reed is presently at the Office of National Coordinator and she is working to promote adoption of UDI as a meaningful stage criteria for electronic health records. As she works on that, data quality is paramount importance to us here.
Each day we work to see how we can beef up the quality of data that's coming into GUDID. We are working to implement a data quality program in parallel as we roll out GUDID and the goal really here is, as submissions come in, we're going to look at the submissions and try to understand the relationship between GUDID attributes and how the values that we're being provided relate to data that the center already has internally.
For example, we ask for premarket submission number as part of GUDID and we, of course, have premarket data in the center. We ask for listing number, product code. Presently, in GUDID, when you submit those things, we have a very basic validation. We say, is this premarket number approved. If yes, we say bring it in. No other validation is there. Is this product code valid? If it's valid, go right ahead. What we'll do when the submissions come in is we're going to try and see if there are links between those data and if those linkages all make sense, how does it relate to the data we have internally.
As we work through this, the goal is to come up with better validation. In the next enhancement round, we open an additional validation to check additional rules before the data actually comes in. We want to work with you to provide assistance to you whether it is understanding the data attributes or any questions you may have and work collaboratively with all of you. Don’t wait until September 24 of 2014 to submit your data. Get it in now when we have the time to assist you.
As you begin your work on GUDID, bake in that data quality into all your processes so it's not an after thought but you have it right from the beginning. Okay. That's a mouth full on data quality. Now, let's go on to GUDID key concepts.
We now have a very high level overview of GUDID. Now it's time to get into some of the nitty gritty stuff. Bear with me. Let's start with GUDID accounts. What is a GUDID account? The GUDID account is required for anyone who wants to submit information to GUDID. Obviously, we want to know who you are and we want to make sure you're submitting information for the right organization. We identify the label of organization, we have the GUDID account and we use the DUNS number and I'll talk a little bit more about DUNS number shortly and the GUDID account also enables you, the labeler, to manage access to GUDID inside your own organization.
You can say Sally and Mary are going to enter records into GUDID but Joe and Johnny will not or whatever. We give you access. All we do is, we create the account for you and then it's up to you who in your organization you want to access GUDID. A note though is none of the Sally, Joe, Johnny, Joe, nobody's information will be made public. The account user information is going to be purely for internal use only.
Moving on, this is a very, very busy picture. Labeler basically provides you the GUDID account structure. If you go on the website and reference the UDI website, there is a lot of information there and an important document that you definitely make sure you look at is the GUDID draft guidance document for industry. That document goes in great detail about the GUDID account structure and a lot of the nitty gritty details that I'm going through at a fairly high level. You will get all the details there. Definitely take the time to go through it, understand the GUDID account structure. What I will do in the next few slides though is highlight some key things for you.
The DUNS number - DUNS number is used to identify labeler organization in GUDID and many of you may know DUNS stands for Data Universal Numbering System. It's a nine digit number that was assigned by Dun and Bradstreet. I believe it was mostly used for our financial purposes. However, FDA is moving to using DUNS numbers as a universal (unintelligible) identifier and within our own center for devices, I believe that (unintelligible) of listing programs started to collect DUNS number as of a few months ago.
DUNS is being used in the agencies. We are using - We are going to use it. We are using it in GUDID so you might as well get used to it, understand it and start using it. How are we using DUNS in GUDID? The purpose for us is we want to standardize company name. If there is labeler A, we don’t want to type in labeler A Inc and somebody else will type in labeler A organization. We want to standardize it. We ask you to go to the DUNS database, put in the name as how you want it to be pulled into GUDID, put in the address you want to represent your organization.
We put the DUNS number in GUDID and we grab the name and address from the DUNS database. The is our attempt to standardize company names and we ask you to please make sure you check your information in DUNS and make up dates before you provide that to us. That's the information on DUNS. There are different types of DUNS numbers we collect in GUDID. Let's go through them really quickly.
Organization DUNS - The organization DUNS number is a grouper if you will. It identifies the GUDID account and it can be the headquarters or the patent DUNS for your company. It is pretty much how you want to identify the GUDID account. That's really the full purpose of the organization DUNS. Now, the labeler DUNS, each GUDID account -- if you see here, I've shown in yellow -- each GUDID account can have more than one labeler DUNS and what the labeler DUNS does is, it identifies the labeler as shown on the medical device label.
We want you to give us the labeler DUNS that has the name and address -- if we pull from the DUNS database -- that matches what's on the label of your medical device. I'm going to quickly flip over to the next slide just to show you. Here is a device identifier record. We'll talk about DI records in just a few minutes. Here is a device identifier and as you see here, I have multiple labeler DUNS listed for this organization and I can choose any one of these labeler DUNS. I've chosen one and this name and address is what would be on the medical device label. That's the idea behind labeler DUNS.
If consumers have your device and they grab this company name and they type it into GUDID, they should be able to pull the information for that device. That's the idea. Quickly about third party which is another type of DUNS we collect. You can choose to outsource submission to GUDID to a third party. A third party being any individual or company who is authorized to submit information to GUDID on behalf of you. Again, we want you to identify them and we're going to use DUNS to identify them also. DUNS is the primary mode that we're using to identify organizations in GUDID.
All right. Now, let's briefly talk about GUDID user roles. There are three key user roles as a labeler that you need to be aware of. Regulatory contact - A regulator contact is the person who will be responsible for GUDID submission requirements. These would be your (unintelligible) people. If we, the FDA, have any regulatory things that we want to discuss, this would be the person they would be calling. They will not have a functional role in the database so they wouldn't have a log-in and a password for GUDID. Their main job, like I said, is regulatory in nature.
Each account then can also have coordinators. These are - I think of them as the gatekeepers. These are the people who manage who in your organization has access to GUDID. Like we talked about Sally and Jane, Mary and Joe, they decide who should have access. They create accounts for Sally and Jane which would be the labeler date entry user role and each GUDID coordinator can have as you see in this picture in the middle, labeler DUNS one and labeler DUNS two. Each coordinator has a certain number of labeler DUNS that can be assigned to them and then they are then responsible to manage or gate keep access for those DUNS and data entry for those labeler DUNS.
Finally, the labeler data entry users or your worker bees, they're in there day in and day out entering the records and making sure that the records are submitted. Those are the key user roles in GUDID. Finally, third party submitters. We talked about it as folks authorize to submit on your behalf. The key think I wanted to point out here is, if you are a web interface submitter, if you choose to do the online entry, you, as a labeler, once you get an account, can designate a third party to have the coordinator user role or the LDE user role but if you are an HL7 XML file submitter, then you need to identify who the third party is when you submit your account request.
The reason for this is we want to know who is submitted on behalf of the labeler and if they're authorized to submit on behalf of the labeler. In the XML file, there is a block where we get the information that this coming from a third party and when we see that it's from a third party, we check to see if that third party is associated with that GUDID account. If the answer is yes, the submission goes through. If the answer is no, we don't even look at the submission. We reject it and say sorry you're not authorized to submit it. It's important that you identify them and make sure you provide the DUNS number.
Before I move on, I'm going to go back here real quick. One quick thing I want to point out too is, can one person take on all these user roles in GUDID? Yes you can. It's really up to you but you will have multiple log-ins. You will have a separate log-in for coordinator, you'll have a separate log-in for labeler data entry user but, yes, one person can be all of those or different people can each take on the different user roles. All right.
At a high level, I wanted to list some of the to-do's for you as you begin thinking about some getting ready to submit the GUDID from an account perspective. The first thing is, you need to understand the account structure and the user roles. Again, as I mentioned, the draft guidance document has a lot of information so definitely go to that. On DUNS numbers, identify the DUNS numbers for your company. If you don't have them, you can obtain them free of charge. I believe there is a 30 day turn around time. There are expedited options available for a nominal fee.
Verify - If you have DUNS numbers, verify that the information in the entry database is correct. As I mentioned, we want to standardize company names and please update them if necessary. GUDID user roles, you need to identify who is going to take on the different user roles for your organization and once you have that identified, make sure they understand the functionality associated with each role and the responsibility they inherit as a result of that particular user role. Regardless of the submission option you choose, you need to have a GUDID account.
All right. I believe that brings us to the end of the GUDID account. We should all take a deep breath and let it sink in. I take a deep breath and now we go onto more nitty gritty. This time, it's about the DI record. What is a DI record? Again, remember that DI stands for device identifier which is the static portion of the UDI that remains the same for a given device portion of the model.
The device identifier -- together with the GUDID attributes -- is what constitutes a DI record. The picture here shows a fictitious medical device label and we've mapped a lot of the GUDID attributes. The majority of GUDID attributes are pretty much directly found on the label or the labeling of a medical device. We're moving on to some key concepts of a DI record. I'm going to introduce these concepts and just bear with me. I will tie them together for you.
First, I'm just going to throw the concepts at you starting with the new DI trigger attribute. There are certain attributes in the GUD that when you change them, you're pretty much significantly changing the device itself. It's no longer the same device. We say if you change certain of these attributes, you have to give us a new DI because it's no longer the same device you told us it is. Example, let's say you said a device is packaged as a sterile device.
You said yes and then 10 days later you say I changed my mind. I'm going to make it device packaged as a device that requires sterilization prior to use. It's no longer packaged as a sterile device. If you change that you're pretty much changing what the device is because the way the device will be used in patient care or how it's handled was completely different. We say that's a new DI trigger attribute.
Hold that and now let's go onto the next concept. DI record publish date. When we were talking about public search, I said we give you, the labeler, the ability to determine when you let the public see your DI record and this is how you do it. By setting the publish date to a certain date, you determine when the public sees it. If the publish date is today or on a past date -- any date before today -- the public can see those records. If the publish date is in the future, the public will not see it. That's how you control what the public can and cannot see the information that you put into GUDID.
All right. Now, grace period. Another concept. Grace period ties in with publish date. Once you publish a DI record, we give you seven calendar days to make changes to the DI record. Within that grace period, it's just like a library card. You are late to turn your books in, you get a couple days. After that, the fines accrue. Similarly, we give you seven days within which you can edit pretty much all the attributes in your DI record except for the publish date. After the grace period passes, you can't edit any of those new DI trigger attributes that you remember from the prior slide.
The new DI trigger attributes can't be edited after the grace period and even other attributes, we put certain limitations on what you can and cannot do. The key here to note is before you put your record in and before it gets to the publish date, you pretty much need to be certain of the information you're putting in. The reason is, we want this information to be stable because we want UDI to be widely adopted and people need to be able to depend on this data. We can't have it changed. Somebody comes in, get the record today, 10 days later, they come back in and everything's changed. That's not going to help anyone. That's the main reason to have this set of restriction.
It's really optimal if you make sure your information is correct, complete and accurate before you even hit the publish date. Really, the within grace period edits are only allowed for those typos, the oops mistakes and things that we all do. That's the key concept. I hope I've tied the three key concepts for you by now.
Quick word on DI record lifecycle. In GUDID, when you create this device identifier record, it has multiple states and business goals associated. Very quickly, the draft DI record stage, there are no business rules. You enter these records and nobody sees them. The public cannot see them. Only the user who entered can see it. You can edit it an unlimited number of times and keep saving them as draft DI records. For those of you who are going to get an account, I recommend you log in and create some draft DI's. This is your playground. You can create records. Nobody's going to see them. A good way to get used to the database.
The unpublished DI records are DI records that have passed all the business rules and the publish date is in the future so the public cannot see it. Again, you can edit it an unlimited number of times. A published DI record is where business rules have passed and the publish date is either today or in the past and the public can see it. This is where I talked about those edit restrictions go into effect.
How does the record move between the different states? A draft DI record can become an unpublished DI record if you make sure the business rules pass and you submit the record to GUDID and the publish date is in the future. The same draft DI record, on the one hand, if the business rules pass and the record has been submitted but the publish date is either today or in the past, becomes a published DI record.
You may wonder, do I need to come do something to those unpublished DI records to get them to publish? No. You don't have to do anything. We have a nightly on system job that checks all published, unpublished records and say hey, did the publish date hit yet? If the publish date hits, the system automatically moves them to a publish date and the public can access those records.
Another busy picture for you. Again, I'm not going to go through this. This is just as a thing for you say go look at the guidance document that's out there. Go through it. There are multiple pictures similar to this for the different DI states. I'm sorry to tell you that you do need to spend time and get used to. Of course, we are here to provide assistance.
Quick word on device packages. I say here, package configurations of a device are part of the same DI record. What do I mean by that? Example, here is a catheter that's packaged singly, by itself, and it has a primary DI, 1,001. Then they've taken this catheter and they'll put it into a box of 30. There are 30 catheters in this box, DI 2,001. Then you take this box of 30 and then you put it into a case with 12. Twelve boxes of 2,001 is put into a case and the ID is 3,001. If you look at this DI record -- this is a screen shot -- we start with the catheter. The catheter has a primary DI record and it's 1,001.
Now, the packaged DI's, as you see here, 2,001, we are telling you the quantity is 30. What does it have 30 of? It contains which package. It contains the DI package 1,001. We're telling you this box, 2,001 has 30 of the singly packed catheters and it's in a box. Then the 3,001 we tell you has 12 boxes of which one? The 2,001 and it's in a carton. So the 2,001 and 3,001 aren't separate records by themselves but, in fact, they are part of this bigger record. The original record of 1,001. That's the idea.
I'm just going to go pull it back really quickly just to re-explain that the package configuration of a device are part of the same DI record. All right. What are some of the to-do's for the DI record? Of course you have to gather your data. We have an attribute list in appendix B of the GUDID draft guidance document. Please go through that. We tell you what's required, what's not required and provide you data entry notes.
The other thing, too, that could be a little bit time consuming if you're not aware of it is every DI record is going to require GMDN preferred terms. GMDN stands for Global Medical Device Nomenclature and it basically provides very broad, generic categories to group devices into. We are going to require that every DI record has an associated with it a GMDN preferred term that's active. You need to indentify those and if you don't have GMDN preferred terms, please, you have to obtain one and you can do that via the GMDN agency. I've provided you the website there.
FDA listing number is going to be required for every DI record. Make sure you identify and obtain the correct listing number for your devices. Again, make sure you're making data quality as you gather your data so it's meaningful, it's correct and it's complete. All the nitty gritty is over. I'm sure you're happy to hear that. Another deep breath to let it all sink in. Let's go back up from the nitty gritty. Now we're going to go back up a little bit and go up a level.
Let's talk about GUDID status. Where are we now and what are we doing? It all has come out on September 24. We're now in production and we're accepting submissions from labelers of class three medical devices and labelers of devices licensed and other PHS Act only. You may way why this restriction again? The main reason is we just want to get our processes together, get our feet on the ground and we've learned a lot since September 24 to now and making adjustments as we go along and this just gives us an opportunity to get other processes together before we open it up. As soon as we are able to, we will open up to all classes of device labelers.
The GUDID search and retrieval is temporarily disabled and I talked about that earlier. Currently we have 12 production accounts and zero published DI records. What should you do as a labeler to get started? Again, read up. Tons and tons of information on our website that is a guidance I've been referencing throughout the talk and then there's also the HL7 SPL implementation file. Go through it, determine what your submission option is whether you want to do web interface or HL7 SPL. I also did the to-do's for the account and the DI record earlier. Go through those and if you're a web interface submitter, request and obtain a GUDID account.
You don't need to do any testing. We talked about using draft DI records to get used to the system that's available to you. Submit a GUDID account inquiry by visiting our webpage. Get familiar with the system. Create your draft DI's. You can submit unpublished DI records with a future publish date and then, once you're ready, submit and publish those DI records.
If you are a HL7 SPL submitter, register with the FDA ESG and complete ESG testing. If you have an existing test account that you're using for another CDRH program or any agency program, it can be used again. You don't need to get a new test account. Request a GUDID account for testing with us. We will give you a GUDID test account complete. HL7 SPL testing that we have described. Request and obtain a GUDID account for production, then you can submit your DI record.
Now remember that our testing criteria is very minimal. We ask that you test as much as you would like to make sure that you are ready and then you can do all the test criteria which is really minimal. Additionally, I also want to point out that draft DI record state is not available via HL7 SPL. If you choose this option, your records can only be in unpublished or published record states. No draft option is possible to XML.
If you are a third party submitter and we have several who've asked us, yes you can test. You don't need to have a labeler associated for testing. You can request a GUDID account from us, let us know that it's for HL7 SPL testing and some of you have asked for dummy data. For example, for listing number or GMDN and we can make that available upon request. Make sure your DUNS information is accurate also.
Now, let's talk about how do you contact us if you have questions. If you are a HL7 SPL submitter and you have ESG question, they have an email address. Please send all ESG questions to them. They have a GUD website and we really prefer not to answer on behalf of the ESG. They know that program best. For all UDI questions, you may send it to us through the FDA UDI help desk which is available to you on our website. It can be the account request or it can be the regulatory question, technical questions. All questions UDI is the UDI help desk.
Here is a screen shot I show you. It's a simple web form and we ask that you please complete all the forms, all the fields on this web form. I believe there is a bug within internet explorer that allows you to submit this form not completing all the sections and I have got a very lengthy help desk inquiry from somebody who's taken a lot of time putting together questions from our implementation guide comparing it to our guidance document and if Cindy is out there listening, this is for you. I don't have an email for you to respond to the help desk.
This is really bad because we do want to respond to you. Definitely take the time to fill it out. Firefox does enforce the mandatory fields but please fill it all out, send your questions and as Anne mentioned, we want to hear from you and we're more than happy to answer them. Once you fill it out, the question becomes a case in our help desk tool and we will respond to you. You will get an email to us. If you have any follow-up questions, you just respond to that same email, it will amend the case in our help desk tool.
Again, please make sure you can receive emails from the help desk. They've heard from some people who've said we haven't received a response. Turns out, it actually went to their spam folder and we monitor the help desk during business hours, eastern standard time, and if you send something in the evening, we'll look at it the following morning.
GUDID system status. It's important to note that, pretty much every month there will be one weekend where we have to take the system down for routine maintenance. We will post those scheduled down times on the GUDID system status page. At times there will be unscheduled down times that we anticipate and if we have information, we will post that the minute we get that information. If you happen to be the unfortunate person to find that the system is down and there is nothing on our webpage, please contact us and let us know so we can look into it.
We also encourage all of you to please prescribe to the alerts via email. If you go to the GUDID webpage, there is an email alert and we use this to basically notify you whenever we have a system status update or if we have a new documentation that we post like when we posted the HL7 ESL guide. We try not to spam you but this is important information so we encourage you to sign up for that.
We are here to help you. I ask that you please take the time to submit complete and correct information whether it's help desk question or account request or DI records. I encourage you to build in data quality into all tenets of your processes as you're getting organized for GUDID. Account requests, please take the time to look through the account request document. If we ask for a listing number, please give us the listing number. Don't give us the premarket number. We've had account requests that we've done several back and forth just because folks didn't take the time to complete it the first time.
The more time you take upfront, the easier it is for all of us. I ask that you be patient with us because we are learning as we go along and making tweaks. Send us suggestions and comments and we are very open to hearing from you. I thank you for your attention. It's a lot of information that we threw at you and we are now ready for questions.
Heather Howell: Thank you Indira. As Indira said, we are ready to take your questions. The operator should have queued you and informed you how to ask a question and I am actually now waiting for the operator to chime in and take the questions as they come in.
Coordinator: Certainly. One second. if you'd like to ask a question, please press Star 1. Please un-mute your phone and record your first and last name when prompted. To withdraw the question, you may press Star 2. Once again, please press Star 1 if you'd like to ask a question. One moment please. Our first question is from Denise Hickstead. Ma'am, your line is open.
Denise Hickstead: Yes. I have two questions. One question is if I have a medical device that is sold in separate packaging configurations; do I need different UDI codes for each of the packaging configurations? The second question is, do I need to put the UDI code on the IF field or the patient implant card?
Indira Konduri: I got the first question. Yes. If it is - You do need a UDI for each of the packaging configurations and as we discussed during the presentation, you would just put that information as part of the DI record. Just note that you don't need to have a UDI on shipping containers. I'm sorry I didn't get the second question.
Anne Hawthorn: On the second question where you asked, Denise, if the UDI needs to be on the instructions for use and the patient implant card, the instructions for use, generally, no, although it's probably a good idea to do that and you can certainly do that voluntarily. The patient implant card is something we'd like to think about and talk to you. If you could submit a UDI question to the help desk, I think it's a good idea but again, let's talk about it.
Denise Hickstead: Thank you.
Coordinator: Thank you. Our next question is from Greg Ruben. Sir, your line is open.
Greg Ruben: Yes. So, for class three devices, everything has to be in the system by September 24, 2014. After that point in time, if you have a new class three device, is there a grace period to get it into the system?
Anne Hawthorn: Hello. This is Anne. You're asking if there's a grace period for new devices. No, there is not.
Greg Ruben: So it requires the PMA submission number to input into the database, is that correct?
Anne Hawthorn: That's correct.
Greg Ruben: Okay. So you have to do that simultaneously. Once you get the PMA approval, you have to -- the next day -- put it into the database? Is that the theory?
Anne Hawthorn: Before commercial distribution, how much time there is between your approval letter and commercial distribution, we generally think it's not going to be the next day for you. You'll have to ramp up production and on and on. I think that if you have a specific situation, you can always talk to us about it.
Greg Ruben: Okay. Thank you.
Coordinator: Our next question is from Alex Bonderanko.
Alex Bonderanko: Hi. How's it going? I have a question with regards to pretty much in the beginning of the presentation. It talked about the device identifier number that's given out by the FDA or our ability (unintelligible) accredited agency. I'm assuming one of those agencies is the (Hibic), agencies for bar coding and stuff. How does that actually get - Is that given to the FDA from a website or how's it downloaded into the website (unintelligible) number?
Anne Hawthorn: As the labeler, you will get the code from the issuing agency and then, as the labeler, you will enter it into the database, the GUDID.
Alex Bonderanko: Okay. Then, after that, that one number then becomes our device identifier throughout the whole...
Anne Hawthorn: Right. Once you get the labeler code, you will be able to build out the UDI for your devices and then the DI portion is what you submit to GUDID.
Alex Bonderanko: Okay. All right. I appreciate it very much.
Coordinator: Once again, if you would like to ask a question, please press Star 1. One moment please.
Heather Howell: Okay.
Coordinator: At this time, there are no further questions.
Heather Howell: Okay. I thank you all for joining us in our presentation today. Again, we welcome your questions and your feedback. Please refer to the slide presentation that will be posted on CDHR learn. Beginning next week -- most likely on Monday -- we will have the entire presentation posted on CDRH learn. We will have an audio recording of this presentation, this session as well as a written transcript. Look for that probably on Monday.
Coordinator: Ma'am, I hate to interrupt you but we do have some more questions that have come into the queue if you'd like to take them.
Heather Howell: Yes. Absolutely, we would love to take them.
Coordinator: All right. Thank you so much. The next question is from Gloria Einfield.
Gloria Einfield: Hi. I have a question regarding DUNS numbers. Are DUNS numbers specific to a manufacturing site or the label address?
Indira Konduri: With regards to GUDID, the DUNS number, like we said, could be the organization DUNS. It's what you choose as your - It could be a parent DUNS number, a headquarter DUNS number. It's what you choose to identify your GUDID account with. The labeler DUNS, yes, we do say that it should match. The name and address should match what's on the medical device label. Does that answer your question?
Gloria Einfield: Yes. If you have a large corporation with many different manufacturing sites, each manufacturing site would have it's own DUNS number and then that would be further broken down by the label address as well? If one manufacturing site had multiple addresses on its labeling due to different reasons, then within even one manufacturing site, you could have multiple DUNS numbers?
Indira Konduri: Right. I believe DUNS does provide multiple DUNS numbers for each site. We really let you sort out how you want to set it up for your organization. The GUDID's account structure does provide great flexibility so that it will put multiple situations and organizations. If you want to discuss your specific situation, I would be happy to do that. Just send us a UDI help desk case and we can work with you one on one.
Gloria Einfield: Okay. Thank you.
Coordinator: Thank you. The next question is from Amy Windham.
Amy Windham: Hello. We just have a question about the ESG accounts. We currently have an ESG test or production account for MDR submissions. Can this same account be used for the GUDID submissions or do we need to request a new account?
Indira Konduri: No. You can use your existing GUDID test account and existing - Sorry. Non GUDID. You can use your existing ESG test account and ESG production account you submit to GUDID also.
Amy Windham: Okay. Perfect. I had a second question on labeler DUNS numbers. Do all of your labeler DUNS numbers need to be submitted on the account submittal? I think we fall into the same category as the previous question in that we have 50 different labeler DUNS numbers. We've not yet identified exactly which ones would be tied to the account or to the address on our labels. Could we just request the account under our organization DUNS numbers and then have the coordinator add DUNS numbers as labelers or do all of those need to be indicated up front with the account request?
Indira Konduri: With your account request, you must at least provide one labeler DUNS number so we can complete creating the account. You can add them, certainly, after the fact. The only thing is you have to go through the UDI help desk. The coordinators functionality does not include adding labeler DUNS numbers. You just have to work with us and we'll be able to add that to your account.
Amy Windham: Okay. Perfect. Thank you.
Coordinator: The next question is from Amar Choula.
Amar Choula: Hi. I was curious if you would mandate the registration of these UDI's into electronic health records and if you do, when do you anticipate that to be done?
Indira Konduri: As I mentioned, we're not - My supervisor is on a detail at ONC working to promote adoption of UDI into electronic health records. That's not something that the FDA regulates or manages. We're just promoting that option. You have to look at information from ONC to work that end.
Amar Choula: Okay. All right. Thank you.
Coordinator: The next question is from Simen Journigan.
Simen Journigan: Hi. Earlier, there was gentlemen who asked about exemptions to the UDI ruling given when a device was placed into inventory and I heard the response as there were none. However, I've read and I quote it states, "In the final rule, FDA clarified that devices already in inventory and any finished device that is manufactured and labeled prior to the compliance date that applies to that device are exempt from the UDI requirements. The exemption expires three years after the compliance date that applies to the particular device. "
Anne Hawthorn: That's correct. The previous caller was asking about a device that had not yet been approved. That's a different situation. If the device has not been approved, we would not consider any units of the device to be in inventory to be an existing device because the PMA has not been approved yet.
Simen Journigan: Okay. Got it.
Anne Hawthorn: Does that clarify?
Simen Journigan: Yes. That does help a little bit. Thank you.
Anne Hawthorn: Very good.
Coordinator: That was our last question at this time.
Heather Howell: Okay. Again, I thank you all for participating in our webinar today and again, we look forward to further questions and seeing you. Please look for this webinar to be posted on the CDRH learn website on Monday morning. Thank you all for participating.
Coordinator: Thank you everyone for participating on today's conference. The conference has concluded. You may disconnect at this time.