FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 1

FDA Webinar: Optimizing GUDID Data Quality

Moderator: Irene Aihie

August 3, 2017

1:00 pm ET

Coordinator: Welcome and thank you for standing by. At this time, all lines are in a listenonly mode until the question-and-answer session. We are only taking 

questions from the phone line only today. To ask a question, please press star 

then one and record your first and last name. Today’s call is being recorded. 

If you have any objections, you may disconnect at this time. Irene Aihie, you 

may begin.

Irene Aihie: Hello and welcome to today’s FDA webinar. I’m Irene Aihie of CDRH's

Office of Communication and Education. The FDA is committed to 

facilitating labelers’ submissions of high quality data through the Global 

Unique Device Identification Database, also known as GUDID. 

Healthcare systems, providers and patients need accurate, complete, consistent 

and timely data to make decisions about patient care. GUDID provides 

critical information about specific versions and models of devices that are 

implanted or used on or by patients.

In this session, the FDA will share observations on issues with the current 

GUDID data and the impact of those issues, identify best practices for 

organizing, validating, correcting and submitting GUDID data, and describe
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 2

the benefits of working together to optimize the quality and utility of GUDID 

data for all stakeholders.

Today, we have three center experts on UDI with us. Linda Sigg, our 

Associate Director of Informatics and the CDRH lead for UDI; Behnaz 

Minaei, UDI data quality lead; and Indira Konduri, our GUDID program 

manager. 

Following the presentations, we’ll answer questions about GUDID data 

quality and engage in a discussion with attendees about their experiences with 

GUDID data submissions. Now, I give you Linda.

Linda Sigg: Good afternoon. I'm going to give a very brief introduction and talk a little bit 

about the UDI rule just to make sure everyone's on same page. The UDI rule 

published on September 24th, 2013. The objective of the UDI system is to 

enable devices to be identified through distribution and use. A UDI is 

required on device labels and device packages and in some cases, on the 

device itself. 

Additionally, data about each device is required to be submitted to the Global

UDI Database or GUDID. We've passed several compliance dates at this 

point. The label, data submission and direct mark for the Class III and the 

implantable life supporting life sustaining devices. And the labeling and data 

submission compliance date for the Class II devices. 

In addition to compliance, it's vital that UDI is adopted by all the stakeholders

so that the UDI benefits are realized. We are working with stakeholders in 

supply chain and inventory systems, electronic health records, registries,

adverse events, recalls and other areas to ensure the UDI is integrated 
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 3

throughout electronic health information systems so that the UDI is available 

from the supply chain to the point of use and beyond.

We know that in order for adoption to be successful, we must have good data 

quality in the GUDID. And today, we want to talk to you about successes,

best practices and challenges with GUDID data quality. We held a GUDID

data quality session at the UDI Conference in June and we know that not 

everyone had the opportunity to attend the conference. 

So we want to share with you today what we see in the data and what we hear 

from our stakeholders, including our pilot project and early adopter end users. 

Our target audience today is labelers who currently have GUDID accounts 

and we do plan to hold future webinars with industry and other stakeholder 

groups.

Our goals today are to interact with you so that we can all share our 

observations and the impacts of data quality issues in GUDID. We want to 

talk about some of the best practices that we would like to see utilized as 

labelers enter their data in GUDID. 

And we want to hear about some of the best practices that people are already 

using for their GUDID submissions. And we want to discuss the GUDID

challenges that people are having with data quality and hear about ways that 

you've solved these challenges and what we can do to help. 

As of this week, you can see we have about one and a half million records in

GUDID and about 4,500 labelers have accounts in GUDID. We worked with 

the Office of the National Coordinator for Health IT and the Centers for 

Medicare and Medicaid Services to include UDI in their rules that published 

in October 2015.
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 4

As a result, the UDI is part of the EHR certification criteria and the common 

clinical data set. And an implant list will become part of a patient's medical 

record in 2018 in certified EHRs. 

Downstream users such as providers and other electronic information systems, 

will use the data in the implant list, which includes the UDI, company name,

brand name, model or version, MRI safety, latex information and GMDN or 

SNOMED categorization terms. The UDI captured in the patient record, will 

support integration with GUDID, and to ensure quality patient care, the 

GUDID must contain quality data. 

On June 2nd of this year, the FDA announced in a letter that we intend to 

issue enforcement discretion guidance for the class I and unclassified 

compliance dates for a period of two years. During this time, the UDI

program team will redirect our focus to data quality and UDI adoption. 

Everyone has made a significant investment in the UDI system and our goal is 

to ensure that the GUDID data is of acceptable quality to realize the public 

health benefits and also a return on our UDI investments across the entire 

healthcare ecosystem. 

Stakeholders must have confidence that the GUDID data is accurate and 

complete so that our electronic health information systems can be integrated 

with the UDI as the key that links the data. And we want to engage with all of 

the stakeholders to address challenges and optimize data quality and utility for 

the higher risk devices with the data already in GUDID. 

One of the ways that we are engaging with stakeholders is through the 

Learning UDI Community or LUC, which is open to the public and already 
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 5

has over 300 members. The LUC is hosted by the Association for Healthcare

Resource and Materials Management or AHRMM, and this is a collaborative 

community to engage stakeholders and enable them to work on areas of 

concern and establish best practices that can be used by anyone to make sure 

the UDI information is the best that it can be.

Behnaz Minaei will share details about the LUC activities during her talk. 

And now to talk more about the different aspects of data quality, I’ll turn this 

over to Behnaz.

Behnaz Minaei: Thank you, Linda. On this slide, I'm sharing with you the comparison we did 

as part of a project included in the MDEpiNet that compares one record from

GUDID and two different registries. MDEpiNet or Medical Device

Epidemiology Network is a public private partnership that is engaged in 

evaluating an establishing - the National Medical Device Evaluation System, 

which relies on real world data, you know, data that comes from registries,

electronic health records and other electronic health information systems.

In order to have this data include correctly the information about medical 

devices, UDI is an integral part. As you can see on this comparison slide, 

GUDID has a device identifier. Registry one and two does not. The brand 

name included in GUDID is respecting what's on the label, the device for the 

brand name. The other two registries have a variation of this information. 

Not only that, the title of the data element is different. 

So standardizing on value and data element and definitions is an important 

step for us to include UDI and device information in registries, electronic 

health records and other healthcare systems. The other data element that we 

looked at is the company name.
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 6

Again, there are variations in this case. Catalog number is an important part 

of this dataset. We saw that in registry one, included catalog number even 

though it was a variation of the catalog number in GUDID, it enabled us to 

achieve better linkage with registry one versus registry two. So later I will 

talk about the data elements in detail and catalog number will be one of them. 

So not only we want to use UDI as a data element in healthcare, we also are 

recommending to use the GUDID as a reference data point. As Linda 

mentioned earlier, Office of National Coordinator had a requirement for 

electronic health record who are certified as of January 2018 to have certain 

data elements from GUDID in their database, including the UDI, the brand 

name, the version and model, GMDN and a few other data elements such as 

MRI safety and latex. 

Their requirement is to use UDI or the DI portion of the UDI and look up the 

data set that I just mentioned from GUDID. So the quality of data for these 

data elements, especially is of our utmost concern. What we need to do is 

make sure this data is correct, this data is going to be entered in patient health 

records.

Our families, our friends who are going to have implants in the near future 

will have this data imported into their healthcare information. And if this 

information is not correct, there might be impacts. Data profiling is one way 

for us to achieve data quality. This is a tool that data vendors are using to 

ensure correctness, completeness, uniqueness, consistency and reasonability 

of the data. 

If you're all familiar with the total quality management rule one 1- 10-100, it's 

sort of - you know, if you relate it to data quality, it takes maybe $1 - if it 
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 7

takes $1 to enter the data in any system, it will take 100 times more to correct 

it and it will take 100 - sorry 10 times and then 100 times more to not correct 

it and have to deal with the ramification of the incorrect data.

So having to start with correct data is the ultimate goal for all of us and here 

we are. Right before this data will be used in electronic health records, we 

have time to go back to our data and make sure that this data is correct. This 

data is publicly available. It’s online. You all know access GUDID and 

providers are using this data set. 

What can we do? Internal and external checks are a way to look at our data. 

GMDN device description, GMDN FDA product code, version and model and 

catalog number are sort of related data elements that could easily help us see 

inconsistencies.

In this example on the slide, I'm showing a company that has submitted data 

to us with the product code of OVD, which is intervertebral fusion device 

versus GMDN term for a surgical glove and the count for that combination is 

only one. So it's very easy when you group by related data elements that are 

in one record and count the records, it will show you - highlight for you where 

there might be problems. 

Next, I want to bring to your attention these key data elements that was 

already mentioned. I want to go over them one at a time. The device 

identifier, brand name, version and model, catalog number, description, size, 

MRI safety, latex, the company name that is pulled from DUNS number, the 

GMDN and FDA product codes.

These are very important because of that EHR certification that is going to 

pull this information to electronic health records. So this is our short term 
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 8

goal that these data elements must be correct and must be reviewed 

immediately. 

The GUDID data element reference table is one tool that we have to ensure 

we are all on the same page on what a data element means, with a description 

that we provided in our data element reference table, and with the data entry 

notes that we have provided and other information that you can see there.

One of the important columns in this spreadsheet is the “New DI Trigger”. 

These are again data elements that we think are very important and if changed,

then we need a new DI. Now, we understand that there are instances where 

there might be mistakes made in these data elements and data entry errors that 

should be corrected.

And of course a new DI will not be appropriate in these cases, but we need to 

have that understanding that these are - what does it mean? I mean I changed 

my brand name from this to that where the true brand names are completely 

different. That requires a new DI. 

But if I made a simple mistake in typing or added an extra character that 

should not be there, that should be - you should be able to correct that. And

later in webinars that will come up, we’ll go over new ways that we will allow 

editing of the records. And I understand editing is a challenge right now, but 

we would like to let you know that this is in the works and later during 

September we will have another webinar perhaps that will go over more 

details for what that means. 

But again this is a very valuable tool that we all should share and work 

towards making perfect. So if you all see any problems with this data element 
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 9

reference table, if you think there’s room for improvement, please let us 

know. 

So I'm going to go over those data elements that I mentioned one by one and 

hope that we can review what is it that we see and what can we do about 

achieving data quality for these data elements. The device identifiers in 

GUDID, this is a very important data element. If this data element is not 

correct, then the linkage between our database is not going to be possible 

What we need is a device identifier that is correctly formed in our database 

and on the label of the device. These two must match and the barcode or the 

AIDC format that is on the label of the device must match again this DI or 

UDI. 

Each issuing agency has its own formula for creating the device identifier. 

You have only three issuing agencies and they have very similar construct 

where a company is given a identifier, for example GS1 company prefix, the

labeler identification code and facility identification number.

Using these identifiers, you construct an identifier for your device. And 

again, each one has the formula. Please follow this formula and make sure 

that your identifiers are correctly formed and are entered correctly in our 

database. We see primary DIs that have typos, that check digits are not 

correct for GS1. We have package Dis that are entered as primary Dis or vice 

versa. - these are the issues that we see related to the primary DI. 

The other issue that has been reported to us by healthcare providers is the 

issue of multiple Dis. This is where the same device, the same exact advice is 

given multiple device identifiers, the same brand name, same version and

model, but multiple Dis. 
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 10

When we investigated this, we came up with kind of three groupings or areas 

where is causing these issues, one being issuing agency DI rules. For

example, different language on the label of the device. Labeling will require a 

different DI or labelers’ internal processes and one I have already mentioned 

is FDA DI triggers.

So having these issues and knowing that we have a different perspective on 

how this multiple DI issue is an issue, not an issue, should be resolved, not -

where everything is working fine, we need to have discussions and we need 

stakeholders from the labeler side, from the provider side, to come together 

and discuss this. 

And as a result, we have asked for - or there is a request to the learning UDI 

committee that will gather appropriate people this - again the Learning UDI 

Community is open to all and please feel free to visit their website. You can 

find them by searching on ARHMM website, the Association for Healthcare 

Resources and Material Management. 

You can Google ARHMM and LUC and you’ll find that - the website that -

you know, it lists all the Learning UDI Communities that are in progress or 

have finished their work and their work product. Many of you already attend 

these communities or work groups and have substantially made contributions. 

Thank you for that and please continue supporting these Learning UDI 

Communities. 

The next data element that I'm going to be talking about is the brand name. A

brand name is supposed to be the identifier that the healthcare user of the 

device could refer back to. It’s the name that's on the device and it's easy for 

folks to read and use and then maybe look up in any system, just like your 
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 11

driver's license. You don't only have a license number on your driver's 

license. There are a few data elements such as your first name, last name, date 

of birth, that helps with finding that license number. 

So brand name is one of them. It’s like your - the name given to a device and 

it should be accurate. We have suggested in our data element reference table 

that if you do not have a brand name, enter NA in the brand name. However,

when we look up some of these records, we see that for example in our

registration listing, there’s a name. There’s a proprietary name. There’s a 

brand name for the device, but in our database that is NA.

We would like to hear back from you, how can we make our data element 

reference table’s definition more accurate so that we get better information in 

this field? And make this something that works for the end user. 

The next data element that I'm going to talk about is the version and model. 

Again, version and model is an important part of the record. If you look at the 

car industry for example, Toyota is a brand, but in order to figure out what

line of Toyota you're talking about, there's a model for Camry. There’s a 

model for Corolla and these forms are easy to find and communicate on.

And we think that version and model that is included in these records should 

follow the same line. Something that's easy to remember, something is related 

to - relatable to end users. For example, a calculated number such as 

580.90629999 is not something that the end user could easily remember or 

work with.

So long strings of calculated numbers don't work. We would like to have 

something that distinguishes this product from its family. And we do not 

think that repeating the word model, version in the data field is correct. 
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 12

And the next data element I'm going to talk about is the catalog number. I 

mentioned the catalog number earlier while we were talking about the 

comparison of the one record between GUDID and two other registries. 

Catalog numbers make us see data elements that hospitals and end users are 

used to using, and having seen or worked through that exercise and having 

heard from many hospitals, this is an important data element. It’s not 

mandatory in our database, but we ask you to please use the opportunity. This

is not a DI trigger. 

You can add this data any time and you can, you know, fill it with the right 

information, NA or, you know, information that is not useful is not something 

that we are looking for. We are looking for populating the field with what the

end users are using to order the device. 

Again, maybe it's not called catalog number in your organization, but there is -

there has to be something that your end users or your customers are using to 

order that medical device, and this is what we are looking for in this field. 

The next data element that I’d like to talk about is the clinically relevant size. 

During the same (MDEpiNet) project, we were looking at stents and 

peripheral vascular devices was the main subject for that pilot project. So size

was determined to be an important part of identifying or distinguishing the 

different medical devices that was in the registry. 

And we learned how important this data element is for clinical - clinicians and 

others that are doing research on medical devices. So one of the Learning 

UDI Community work groups spent some time on reviewing size and how 

size is entered in GUDID. 
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 13

They made recommendations on what needs to be done in terms of entering 

size in GUDID. Those recommendations will be final and be posted on our

website. One recommendation that they made was that each grouping of the 

device needs to convene meetings with appropriate clinical experts who will 

help determine what size, dimensions and values are appropriate for each 

grouping of those medical devices. 

And we would like anyone who could be helpful in this area to let us know 

what's the best way to perhaps get to this - the goal of having the right 

information, the right size dimension for each grouping of medical device.

Next data element is the device description. Now, this is another data element 

that is not mandatory, but it is so crucial in the - you know, helping the end 

users know what this device is, that we think it should not be left blank. Some 

suggestions that we are making to fill this information with is the cleared,

approved indication for use, or links to your label and labeling.

So this information is already available. Many of the records in GUDID that 

do not have descriptions. I have searched them online, I find them easily and 

I find a very good description for those medical devices. So we would like to 

again figure out or hear from you what would it take for this data element to 

be populated or what are your challenges for populating this data element. 

GMDN and product code, two very important data element. Again, this is 

where the end users will know whether this device is related to the work 

they're doing. Is this perhaps a device that belongs to a certain specialty or 

not? 

And maybe if in the future, decision support systems need to make decisions 
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 14

or help providers make decisions on how to care for a patient for a specific 

implant, this is where the GMDN or SNOMED or product code or the 

grouping of device will help, you know, figure out where this device lands, in 

which grouping. And having this information correct is, you know,

invaluable. 

Again, there is a Learning UDI Community workgroup that is kind of looking 

at the GMDN SNOMED categorizations and is looking into, you know,

figuring out whether the current GMDN coding and SNOMED coding is 

working, not working, does it serve the clinical needs. Does it serve the 

regulator needs? And so on and so forth.

For product code, we have been asking you to enter the product code in our 

database. And now that we are comparing the product code that you have 

entered versus the product code that we have in registration listing for the premarket system, we see differences. 

And we are evaluating whether we should go back and instead of asking you 

to enter the information, we should be pulling that information based on the 

listing number or the pre-market number that you have entered. So this is 

another area that we're thinking about making changes. 

To recap, we have a list of data elements in this - on the slide and what the 

best practice we think it is. So device identifier, ensure it is correct. Validate 

- check digit for the DI. We only should have one primary DI per version and 

model of the device. 

The brand name, do not include extra information in this data field such as 

size or other information that is later stated in the record. Brand name should 

be matching what you have on the label of the device, for the device names. 
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 15

Version and model, enter value, the value of the version and model. Do not 

restate the words version or model. Make sure it’s a meaningful value and 

it's going to be useful for your customers and end users. 

Catalog number should be whatever your customers are using to order the 

device. Clinically relevant size, we would want to use structured size in this 

case, and we would like to work with everyone to make sure that everyone is 

consistently entering size dimensions and values for the same grouping of 

medical devices.

Device description. Please do not leave this field blank. It is not required to 

be entered, but we encourage you to make sure that this field is populated with 

information that is useful to your customers. 

And GMDN codes, we think that one GMDN code per device should be 

sufficient. I know that in cases of kits, we have said that it makes sense for 

each constituent in the kit, if there are different GMDN codes, to have 

multiple ones. But for most devices I think one GMDN code should be 

sufficient.

All right. So here I will end my presentation by saying that if we get one 

source of data, clean and useful, we will not have to repeat, you know, 

providing data to many data users on this guide. Some of the data users’

examples are registries, payers, distributors, hospitals.

And as a labeler, if we could get the GUDID database clean and useful for 

these end users, it will become a reference point and one submission will 

make it work. And if there is - there are problems, one place to fix and 

everybody will get the right information. So I think this is a model for cost 

saving and if we can follow this, it would benefit us all. 
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 16

So we want to hear from you. What are your challenges with identifying and

correcting data quality issues? What changes do you recommend to help 

improve GUDID data quality? How do you solicit and use feedback from 

your customers on the use of your GUDID data? So these are some of the 

questions that we would like to hear back from you. And I will turn it back to

...

Irene Aihie: The operator. 

Behnaz Minaei: The operator. Thank you.

Coordinator: At this time, if you’d like to ask a question, you may do so by pressing star 

then one and recording your first and last name. To withdraw your question, 

you may press star then two. Again, to ask a question, please press star then

one, unmute your phone and record your first and last name. One moment for 

the first question please.

Our first question comes from Michelle at Miami Device Solutions. Your line 

is open. 

Michelle: Hi. Thank you again for the presentation. Can you hear me?

Behnaz Minaei: Yes.

Michelle: Okay. So we have a bit of a unique situation at our company. The owner of 

my company recently made the decision to split the company in two. To

simplify, you have company A split into company A and B. Both companies 

reside at the same location, same address, same building, same employees.
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 17

However, company A currently has ownership of the five (10-Ks) and a

GUDID account with all the registered UDIs and all that stuff. However, the 

owner would like to transfer the ownership of all the five (10-Ks) to company 

B. How would you capture this in the GUDID? Could we possibly keep

Company A’s good idea account and add Company B as a labeler (Dunn)’s 

organization?

(Indira): Hi, good afternoon, this is (Indira). We absolutely can assist you with this 

situation. We do have capability in GUDID to manage situations such as 

yourselves where either a company is split or company is bought by another 

company.

We do not presently have any information on our website to guide you. First 

what I would recommend is for you to just send a UDI help desk case.

Michelle: I’ve already done that a few times but I understand that you guys have like a 

two to three weeks lead time on getting back. I wasn’t sure if maybe with this 

webinar whether you had a little bit more information on that, but.

(Indira): Oh, I believe we weren’t aware. If you already have it, we’ll definitely look 

up your company name and see where it is in the que and try to get back to 

you. 

We would love to assist you online but I don’t know if we would be able to get into the nittygritty details. We really would like to get feedback from you from the 

questions we have out there.
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 18

Michelle: I understand, thank you so much and again the presentation was very 

informative. Based on the information you’ve given, I think we’ll definitely 

apply changes to make this better for everyone, thank you.

(Indira): Awesome, thank you and we’ll definitely get back to you on your help desk 

case.

Coordinator: Next, we have (Karen Tew) from Astute Medical. Your line is open.

(Karen Tew): Hi everybody. I wanted to again echo thanks for providing additional updates 

over the phone today. We tried to rely heavily on the GUDID data elements 

reference table and the description that was found in there for what we had to 

do.

So first of all we’re a kit manufacturer and I think we continue to find the 

packaging information and how to load that into the GUDID to be confusing. 

So maybe you can consider if someone checks the box for kits that there has 

been sub-boxes that make that kind of information around size, etc., around 

kits.

And that may help you get away from the issue of size around implantables 

like stents, because I think we’re trying to find a one-size-fits-all solution, and 

with that a data element title that we all interpret certainly differently 

depending on our products and one size doesn’t fit all.

So maybe you can drive us to one decision versus another based on the tree 

that splits off kits for example. So that’s one comment.
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 19

Another around the brand name, the proprietary name. So one of the things 

that we also sometimes face in IVD world is, we have control of (calvares), 

test kits and sometimes an instrument.

And we’ve had instances and this is in particular to my company, where 

things have been cleared as a system. So we get one (DeNovo) number for 

example and one 510K number.

But we might have multiple GMDN numbers and again it’s kind of one of 

those things where I get a little worried when you said, we would pull things 

from the product code in the instances where things had been cleared as a 

system.

So it’s another thing to consider, and then the brand name version model and 

catalog number.

So I thought your advice on the phone today where you described the catalog number as the 

number that the end user would use to purchase is much better than the 

description you have in the elements reference table where you talk about the 

number that would be found on the device label.

So for certainly you probably put that in incorrectly and I think we are also 

confused about theversion or model. For a test kit again, and you don’t 

normally necessarily have one and so we were putting the catalog number in 

the version or model.

So I think again going by the description of what’s in the elements reference 

table, just the clarity provided on the phone today was very useful and even if 

you did an update and I know those things are never fast to the data elements 
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 20

reference table, based on your guidance that you gave today, I think even that 

would be helpful for a lot of us.

(Behnaz): Well, thank you very much for this comment, I really appreciate it. Right so, 

we are intending to update our data element reference table and, you know, 

hearing from you and others will help us determine the best avenue to take 

this.

I guess I’m wondering if we should convene a – maybe a Learning UDI 

committee where the data element reference table would be subject of 

discussion and everyone could provide input in how best to update this tool.

Frankly, when we, you know, talking to many people lead us to this idea of 

maybe we should say that this is the number that end users use to order the 

product and these are the conversation that helps everyone because it is – we 

are not everywhere and you all are out there.

So this is great, thank you.

Michelle: Yes, that was very helpful and (Indira) I think it would be great if you were to 

open the elements reference table up for discussion. You might even be able 

to pair with places like Avamed where you would get maybe some IVD kit 

type folks involved as well.

So cause I know you guys are worried about implantables as well you should 

be, but then the kits kind of get left behind of going how do I make this work 

for a kit.
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 21

And we have the same issue when we talked about just labeling in general and 

size of the labeling and information had to go on labels for devices versus kits. 

So thank you for that.

Coordinator: Next we have (Karina Arinan) from Pfizer, your line is open.

(Karina Arinan): Hi, can you hear me?

Michelle: Yes.

(Karina Arinan): Great, thanks. So my company, we actually have a lot of kind of combination 

products and kits and as a result a lot of those products are registered under an 

NDA, rather than under a PMA or 510k. 

And I know the last time we had tried to submit data to the good ID – it wouldn’t validate for 

that reason and we were told that some changes needed to be made to the 

system.

I was just wondering if you had an update on that, if that’s something we’ll be 

able to do for the 2018 compliance date.

Indira: You know, we have not had a chance to include validation for the pre-market 

numbers that are approved under the Center for Drugs. So far in GUDID but 

we definitely plan to – so it’s pretty high up on our priority list and we will be 

getting to it and we thank you for your patience as we work on it.

(Karina Arinan): So we should still plan on targeting those submissions for 2018 unless we hear 

otherwise.
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 22

Indira: Yes definitely stay engaged in some of these conversations you’re hearing, so 

hopefully the database will have improved validations by then.

(Karina Arinan): Oh, absolutely.

((Crosstalk))

Michelle: Supposed to be (unintelligible) as possible, yes, definitely. 

(Karina Arinan): Great, thanks so much for the presentation today as well. It was definitely 

helpful. 

Coordinator: Next we have (Kim Finch) from Choice Spine, your line is open.

(Kim Fench): My question is concerning what are the necessary steps to take if you update 

the trade name. Did I understand earlier in the presentation that required a 

new device identifier?

Behnaz: So brand name in our database is a DI trigger and means that – that means 

that, you know, whenever you make a change right now in our system, that’s 

not allowed unless you call us through a help desk and then we unpublish the 

record and allow you to edit the data element or the brand name.

What we have said and are saying is that this brand name, if it substantially 

changed, that may require you to create a new DI, but if you have, you know, 

made data entry errors in your record for example, any spelling of a word or 

additional characters that should not be there or vice versa, you fix that back 

to be corrected via editing without having to create a new DI.
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 23

Man: Okay, alright so let me see if I understand you. We can reach out to FDA 

with, I mean, if we have hundreds of parts that the data has already been 

entered correctly into the good ID, and all we want to do is change the trade 

name and we would contact FDA, they would unpublish it and then we would 

go back and put the new trade name in?

Michelle: You can correct a brand name via unpublishing -- now we are also again 

working on a better mechanic for editing and, you know, there is a webinar 

that is coming up and (Indira) is going to go over some of the options that we 

are considering.

So stay tuned perhaps for that webinar where, maybe you will not have to call 

and have the records unpublished, you will be able to unpublish the record, I 

mean, or edit the record.

I mean these are the options that are kind of going back and forth, but the 

editing process will not involve a step for you to call us and then you can edit 

the record and the edited record will attach a version number for the record.

It will be published to maybe Access GUDID more quickly rather than 

waiting until the grace period and have more information such as the last 

updated date, the status of the record where it shows that it’s been updated 

versus added at the beginning of the time.

So these are some of the things that we are considering and if you can join us 

during that webinar and help us with these options that we’re thinking about, 

it would be great. Okay, thank you.

Coordinator: Next, we have (John Lorenz) at Reed Tech.
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 24

(John Lorenz): Hi, again thank you for this webinar. I think it’s very helpful as others have 

said. Basically my comment is a little bit of a piggyback off one of the 

previous ones and that is related to describing the data elements, specifically 

the ones which are marked as applicable.

I know others think of it as optional, but it really is applicable because some 

feedback that I’ve received working with folks, either with UDI or even 

within (Judea SN), is there’s no – no one really has a concern with sharing 

data that may not be required, but they are more interested in understanding 

what it’s going to be used for prior to making this corporate decisions.

So I’ve heard that quite a bit and again echoing off of how you would describe 

the usage of the catalog number. So perhaps if there is some more – I don’t 

want to use the word guidance to the update kit.

But just more information related to potential use cases of that information that may help drive 

thinking that organizations to, you know, further understand the data that’s 

being requested, if applicable and make some better decisions as to what data 

is included and the quality of that data.

So just kind of my two cents based off of what I was hearing there, I just wanted to pass on some 

things that I’ve heard.

Behnaz: Great suggestion, I think we could expand our data on the reference table to, 

you know, perhaps for each data element say why is this data element 

important?

I hope during this call I have made a, you know, some of those cases for 

example, the catalog number that you mentioned, it is invaluable to the 

hospital today because what they have is the existing system, and existing 
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 25

datasets and they would like to get to where they are going to use GUDID as a 

reference.

You know, and to get there, there is a period of time where they have to match 

what they have against what’s in GUDID and the linkage point – one of the 

linkage points is the catalog number.

The other linkage points are the brand name, the description of the device, the 

size, the type, so what the whole point here is to make this dataset useful for 

the hospital, for the providers.

And we think the learning UDI community could perhaps be whereyou take 

these questions and we all get there as a workgroup and work through some 

on these suggestions that you are making. Thank you.

(John Lorenz): No problem, thank you.

Indira: And just to add to what (Behnaz) said, you know I guess ultimately the intent 

of the UDI rule is accurate device identification. So if everybody does their 

part and provides complete and correct data for all the data elements, people 

will only benefit from, the intent that we have which is to improve patient 

safety.

So all the data elements are important and we have made it clear which ones 

are going to be going to be out on AccessGUDID, and is going to be used for 

patient safety purpose.

So we really urge all of you to please provide the complete information, that is 

of high quality. Thank you.
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 26

Coordinator: Next we have (Neal Farquerson) from GHX, your line is open.

(Neal Farquerson): Yes, I think I’m just going to repeat some of the things that have been said 

before. If the elements guide, some of the descriptions could probably be 

updated. 

For instance something like brand name, you know, clearly state what you – although the 

element guide already (sets) the stage, it should be something that should have 

a trademark or registered, or maybe include some language that also says hey, 

we don’t want this in the brand name. For instance just like the slide says 

don’t include size or description information.

The other thing too was brand name is, and this can probably come up with 

the (luding) communities is probably not have NA as a value for brand name 

cause everything out there should probably have some form of brand 

identification even if it does not have a registered or trademark.

Should it not include that maybe a company name that appeared on the label is 

a brand name, just throwing those out. But I think we can go through these 

through the learning groups.

Behnaz: Yes, that makes sense, so but just to add that the learning UDI community as 

you all are aware has already convened a workgroup on catalog number and 

(clinic 11-5) and had documents that are out there for all of you to review.

And definitely there is a discussion for brand name and some of these other 

data elements that we went over today. 

And if you need to have to convene in learning the UDI community and have discussion of how 

to improve our reference table, that is useful for everyone.
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 27

Coordinator: Next we have (Nancy Toledo) in Pegro Life Sun, your line is open.

(Nancy Toledo): Thank you very much. We have a question with respect to secondary DIs due 

to the structure of (HIBCC), a dash is not an acceptable character when you 

are structuring the primary DI via (HIBCC) and we are encountering instances 

if we remove the dash, we are actually having duplicative (HIBCC) score.

It appear to be the same device but it’s not – there are two complete different 

devices and we are challenged with that. Can you provide any direction on 

how to manage those.

Behnaz: We’ll have to take your name and get back to you on that, or ask you to 

submit a help desk question. Have you submitted a help desk question?

 (Nancy Toledo): No, not yet, not at the moment but we were intending on doing so.

Behnaz: Yes, please do so and we’ll get back to you through the help desk. Thank you 

for this question.

(Nancy Toledo): Thank you.

Coordinator: Next we have (Ilan Gilette), your line is open.

(Ilan Gilette): Hi, my question is regarding the unit of use DI number. It’s a good database, 

I have an individual device but it’s labeled with its own UDI and then I have 

the device in a box.

Thirty-six of those individuals that are packaged in a box and the box also contains UDI, it’s not 

the final shipment box, they have just only DI.
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 28

And when submitting these reference release products, do I count for the box 

is number of individual devices inside and since its greater than one, the 

database is requiring me to enter a unit of use DI and from what I got from the 

GUD ID data on that reference label is a unit of use DI is only applicable to an 

individual device that is not labeled with its own DI. So how to go about 

solving this issue.

Indira: Sorry, I missed your description, so are you saying that you have a box that 

contains 36 individual devices and that 36 devices inside each are labeled and 

have their own UDI.

(Ilan Gilette): Yes, that’s correct.

Indira: In that case, then the primary DI in GUDID should be the DI from the 

individual device, and then the box 36 will be entered as a package DI within 

that same DI record.

(Ilan Gilette): Okay because what I thought was that a big package was – there was no 

package that I needed because the box is the big package and the package DI 

is only applicable when you have multiple units of a (base) unit.

Indira: That’s right but remember that a base package is the lowest package level that 

contains a full UDI. So it looks like in your case, each device has a full UDI 

so that would be the base package that would serve as the primary DI.

(Ilan Gilette): Okay, so how many to submit when one record to be for the primary DI and 

then under that one I put the package DI.

Indira: Yes.
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 29

(Ilan Gilette): Okay, and I thank you and I also have another question. When we’re talking 

about catalog number I also found out very useful about the end user 

customers, what they’re using to order the (delay). 

What if it’s the same as our version and model number. Would we just put 

the number twice or we just re-catalog blanks, or how do we go about that?

Behnaz: So our data element reference table says that you can re-use a catalog number 

and version model if you do not have a version or model that is different from 

your catalog number.

(Ilan Gilette): Okay, so is it better to just input it twice or leave it blank?

Behnaz: Oh no, input twice.

(Ilan Gilette): Okay, thank you so much. I thought the presentation was very helpful.

Michelle: Thank you so much for your question, thank you.

Coordinator: Next is (Vera Gates) from AVI.

(Vera Gates): Hi, thank you very much for this presentation. I think you made it very clear 

why UDI is important and some of the outcomes and uses that we can use for 

patient health and medical records.

I was wondering if you saw a way to use this in clinical trials or if you see this 

being expanded to clinical trials in the future?
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 30

(Behnaz): Thank you for this question, we have not – we haven’t been thinking or 

working on that yet. Please, you know, stay tuned and submit a help desk 

question and we’ll get back to you.

(Vera Gates): Okay, thank you.

Coordinator: Next, we have (Shantel Harper) from Mason Matthew.

(Shantel Harper): Hello, how are you? One of the slides previously addressed the reuse of 

information which we absolutely subscribe to. We currently use some of our 

existing data elements as well in order to submit to the (unintelligible) the 

GUDIID.

One of those in particular is the device description where in the table you had 

suggested not including the size. For us, our description already includes the 

size and provides all of that information into the device description field and 

GUDID.

But my question is what are your thoughts on replicating the size of 

information into the (current) week relevant 5 field?

Behnaz: So I think maybe I misspoke, I was talking about the brand name not to 

include the data from other fields, the size or you know, other information that 

is already included in other places.

Your device description could be a description of what you think your end 

users would like to see. If repeating that information in a device description is 

helpful, we do not say do not enter it so.
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 31

(Shantel Harper): Well it’s not what’s on the table, on the clinically relevant side, it says do not 

include 5 in this device description or brand name.

Behnaz: Okay so, let me go back to that slide. Okay, it says I think either the device 

size text.

(Shantel Harper): It was a table.

Behnaz: Okay, let me go back to that table. This table is (phase) for the device 

description, includes device description, recommended approved and cleared 

of indications for use.

For the brand name, they’re saying do not repeat the size.

(Shantel Harper): But what about in a clinically relevant size.

(Indira): Oh, okay so it says that device size should not be included. here are some 

records that put the size in the device description but forget to include it in the

size field. So that perhaps we should clarify this. Thank you for that.

I think you initially said should your device description always includes size, 

so yes, you may provide size as part of device description, but what we would 

like to see is that you provide the size also as part of the size as a structured

data field in GUDID.

So please provide – it’s a replicated, it’s okay to replicate it but put it into 

device description and also make sure you provide it as a discrete value in the 

size field in GUDID.
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 32

(Shantel Harper): Alll right, thank you (Indira). One other question as relate to communicating 

challenges and recommendations, do you prefer that we submit UDI help desk 

to get to that or just to join the LUC group.

(Indira): You can do both, that would be great.

(Shantel Harper): Okay, great, thank you.

Coordinator: Okay, if you’d like to ask a question, please press Star then 1 and record your 

first and last name. Next we have (Philistina Smith) from Walgreen.

(Philistina Smith): Hi, can everyone hear me?

Michelle: Yes.

(Philistina Smith):Okay, I’m sorry if this was already talked about in regards to the brand name, 

but it wasn’t really clear if we change the brand name if we have change the 

DI number. Could you explain that again?

Behnaz: Sure, so a brand name is considered a DI trigger and that means that if you’re 

changing your brand name, you’re making a substantial change and you 

probably will be issuing new labels for your devices and you’re making 

substantial changes, and that means that the device should get a new device 

identifier.

But what we are hearing from some of our data submitters is that we have 

made a, you know, a typo mistake in the brand name and they have, you 

know, somehow additional characters got into the brand name or one never 

submitted, or situations like data entry error exists.
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 33

For these we do not think you need a new DI, and that’s what’s being clarified 

during this presentation. Is that making sense now?

(Philistina Smith):So any records that are entered into GUDID, there is the brand name, there 

were no errors, clean data, and we, you know, we do have rebranding where 

we change the packaging and the branding is different.

And then we use the UPC as the DI so how would we change the DI. Will I 

have to go back to GS1 or have the suppliers go back to GSI and I guess.

Michelle: Right, so GSI has its own Gtin allocation rules. UPC is another form of a Gtin

and I think they’re recommending that if you’re making changes that you just 

mentioned would require a new GTIN(key).

Now, do you think that this is not clearly explained or how should this 

question be clarified for people like you in the future?

(Philistina Smith):So it should be clear if, you know, if all of your data is good for the brand 

name, like there are no errors and it’s a true rebranding, then you say okay, 

you know, you have to change the DI number.

Michelle: Okay, perfect so.

(Philistina Smith):Yes.

Michelle: The word rebranding is something that we should perhaps using that would be 

better understood. Okay.

(Philistina Smith):Yes, so in my case, is it recommended to go back to GS1.
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 34

Michelle: Yes, that would be helpful I think to work with your issuing agency and your 

case GS1 to look for guidance.

(Philistina Smith):Okay, thank you.

Michelle: No problem, thank you.

Coordinator: Next we have (Tony Abler) from Bisco, (Tony) your line is open.

(Tony Abler): Hello, sorry, the slide has been very useful, especially the one that shows the 

formatting for the DI. I wish that it had been in the data element table a year 

ago when I was doing this because there caused me all sorts of problems.

And in correcting that data this past Summer, I noticed the software the 

validation still didn’t toss up invalid DIs. I use (Civic) and in the corrected 

records I had and one bad one that’s still formatted improperly, and the 

validation didn’t catch it.

So the recommendation I guess as far as validation of the data to really to be 

really important if I use (Civic) for example the format is correct or GSI or 

whatever.

Cause that’s what’s causing me more headaches than anything else. The 

other question I had – had to do with publishing versus deactivating because I 

was recommended to unpublish all my bad records which I did and they did 

unpublish them but I found out that had to wait for 30 days to go back and 

publish state and was told last week, you need to deactivate.

So I guess, what’s the difference?
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 35

Behnaz: Hi, thank you very much for this question. So, the going back to the 

construction of the DI from –we’re hoping that you all receive this as a service 

from your issuing agency and are being educated by them how the device 

identifier is to be formed, how to make sure the formed device identifier is 

valid and correct.

They do provide, you know, a couple of websites that I have myself gone to 

and entered the DI both for (HIBCC) and GS1 and found whether these is 

valid DI or not.

We know this is one at a time and it might be kind of difficult to use for many 

DIs, but at least you can have taken one of your DIs out there and tested it. So 

I know that, and I appreciate that.

(Tony Abler): Well, I was using the data element table as my bible and in that data element 

table, like that slide you had there is really useful and if it hadn’t been in the 

description in the data element table, I wouldn’t have known what to do, 

number one.

And number two, like I said, the data doesn’t get validated by at your end. So 

if it had been crossed out, I’d know right away I did something wrong. 

(Behnaz): And for validation in our system we are working very hard to make these 

validations smarter and smarter. We have limited resources, and we’re 

making it work as far as it goes. 

Trust me, we’re working very hard to make sure that you can validate 

everything in a database, with limited resources.
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 36

When there are resources out there that you can already use, we recommend 

those so that you have options.

The other question that you mentioned was the difference between unpublish 

and deactivated records. I think those have been explained very well in our 

GUDID guidance document that came out at the beginning of, launch of our 

Good ID database.

The unpublished record is temporary and published for editing and 

deactivated means it’s been removed or deleted. We see that many people are 

interpreting it differently.

We need to do a better job of making this information available to you all. I 

think maybe if short videos would help with that we can start working on 

these short videos of what things mean in our Good ID database and make it 

available for webinars.

We also have webinars that are out there already and we could add on to it.

(Tony Abler): Okay, thank you.

Michelle: Thank you.

Coordinator: I would now like to turn the call back over to Irene Aihie.

Irene Aihie: This is Irene Aihie. We appreciate your participation and thoughtful 

questions. Today’s presentation and transcript will be made available on the 

CDRH1 web page at www.fda.gov/training /cdrhlearn by Friday August 11.
FDA Webinar

Moderator: Irene Aihie

08-03-17/1:00 pm ET

Page 37

If you have additional questions about Good ID, please use the contact 

information provided. This is the end of the slide presentation. As always, 

we appreciate your feedback. 

Following the conclusion of the webinar, please complete a short 13-question 

survey about your FDA CDRH webinar experience. This survey can be found 

at www.fda.gov/cdrhwebinar immediately following the conclusion of today’s 

live webinar. 

Again, thank you for participating and this concludes today’s webinar.

Coordinator: This concludes today’s call, you may hang up at this time.

END