MS: Okay. A special treat for you all today. Since you did come back. Before we jump into Panel 3, which is going to be exciting on many levels, we have Elise Bernstein who many of you know works on the pharmaceutical side of identification at FDA. And she’s going to talk about some of the efforts that are underway there. A couple of minutes. But just to get a flavor for what’s going on on the other side of the house. Elise.
MS. ELISE BERNSTEIN: Thank you, Jay. I am your commercial break to transition you from lunch into the panel. And I am going to tell you about a draft guidance that FDA recently published that is very closely related to the efforts that we’re talking about here. And I didn’t get the tutorial. Should I just push the arrow? Or am I going to lose this? In the FDA Amendments Act of 2007, which created the requirement for the unique device identifier for devices, Congress also created a new section, Section 913, which created a new section of the act called 505 Big D as we call it. And in 505D are requirements that the Secretary shall prioritize and develop standards for the identification, validation, authentication and tracking and tracing of prescription drugs.
The identification part is the standardized numerical identifier or SNI as we call it. Congress could have easily have said some other thing like UDI type for drug. I guess UDI would have applied for drugs as well. Or devices. But because they wanted to throw in some more acronyms into the bureaucratic mix for drugs, the UDI is the SNI, the standardized numerical identifier. And Congress did put in a deadline that said that the standardized numerical identifier that is to be applied at the point of manufacturing or packaging, sufficient to facilitate the identification, validation, authentication, and tracking and tracing of prescription drugs at the pallet and package level.
And so the deadline is by March, 2010, FDA is to establish a standard for the identification part of these requirements. So just last month in January, we published a draft guidance proposing the SNI to be a serialized NDC or serialized National Drug Code. All drug products have an NDC associated with them. And the NDC, for those of you who don’t know, the National Drug Code, is made up of a label or code unique to each company, a product code that is unique to teach product, and then a package code the identifies a specific packaging of that particular product.
So what we came up with was the serialized NDC which would add a unique eight digit serialized number to the end of the NDC. And in the draft guidance ... and I’ll show you the reference to it later if you want to go to the website, we said that we’re not requiring that an expiration date or a lot or batch number be included. It could be if you want. But it’s not part of the SNI per se. We did not put out a recommendation for a specific data carrier or RFID or 2D or data matrix. We’re silent on that for now.
And the reason is that because we did say that this guidance is the first of several guidances or regulations that the agency may publish in implementing the standards for the tracking and tracing and authentication standards for prescription drugs. We did say that the numbers should be human and machine readable. And that this serialized NDC is compatible with the GS1 serialized G10. In the Federal Register notice announcing the availability of this guidance, we posed three particular questions that we wanted some more information about.
The first is the SNI that we put out was specifically for putting a unique number on a package. And we do not have enough information about what should be on a case or a pallet. So we’re asking questions about that. The law calls this a standardized numerical identifier. And we were wondering if you just leave that serialized portion to just numbers if you would have enough numbers. And so we’re asking should it be alpha numeric?
And also, for certain blood and blood components, there are some standards that are currently being used. The ISBT 128 and code bar. And we ask for comment on whether we should consider those separately for those specific products. Here’s some websites, information, where you can get the draft guidance. And the Federal Register notice, the reference is there where you can also get that, where it has more information about how to comment. But if you go to regulations.gov and type in this docket number, you can submit comments.
They’re due by April 16th, 2009. We’d love to hear from you. And tell us what you like about this, what you don’t like about it. How we should change it. Because we welcome and we want to hear that. And because we are in a comment period, any question that you ask me I probably can’t answer. So I’m not going to take questions unless you think that it’s something that’s way beyond something that we would want to hear in the comment. But send your comments and suggestions. Because we really appreciate that. Thank you. [applause]
MS: Send your cards and letters. So she’ll be here all week if you need to find her. So, as I promised before lunch, we’re going to jump into Panel 3. And we have an esteemed group of panelists here. We’re going to talk about what we’re calling the UDI data. So we’ve moved beyond the issue of coming up with the UDI, coming up with the code. We’ve moved beyond the issue of putting it on the device. And we all recognize and we’ve had a lot of very good discussion around the fact that it doesn’t really matter.
So we have this code. What’s important is what’s behind that code? What doe sit mean? What are the data elements that I have that I can find that I can use once I look up that code? And this is a very interesting issue. You can appreciate, I think, that there’s many levels of information that one might want. FDA wants certain information from a regulatory perspective. Others that are involved, other stakeholders, want other kinds of information. And the key really is making this database useful to all stakeholders.
So the question really is what are these data elements? How do we define them? A lot of this stuff ... and this is just a short list of things that we made up, some of it’s very useful. But some of it’s undefined. Or more importantly, it’s defined differently in different countries. So if we’re really moving towards international harmonization, we need to think about how we’re going to not only define these things in the U.S., but making sure that whatever we come up with has some global meaning.
So we’re to talk about the database. And do you guys have an order here? Dennis is going first. So Professor Dennis Black from BD is going to go first. Please announce that today’s PowerPoints are on CDHGDI website for those on the webcast. So, the web case, the PowerPoints are on our website. Please go there to find them. And for all of you as well, the PowerPoints are on the website. So when you get home, you can get them all. There will also be a transcript of the meeting that will be posted there. And the webcast will be archived if you want to watch all of this again. So with that, Professor.
PROFESSOR DENNIS BLACK: Good afternoon. I’m Dennis Black. I’m Director of E-Business for BD. I’d like to thank Corawin and others that made the comments this morning stating this would be the most interesting part of their day. I’ve been working on this topic for, gosh, five or six years. And I’ve never heard anyone say that before. So thank you very much for those comments. But really if we’re going to have any kind of a functioning UDI system, we’re going to have to have a UDI database. And I didn’t always believe that. When we first got started with this, it seemed to us we had good data in our SAP system. We’re sharing it. Why is there a problem in the marketplace. And I want to show you some examples of that. Because as recently as this morning, I heard comments that UDI database is not necessary.
So I’d like to share some information with you. As far as BD’s description, Jean has asked me if I would change this and put in the word doodads as we describe ED. And we are not going to be doing that at this point in time. But in addition to hospitals, where we think about how products are used and we focus mostly on hospitals. But in reality, we have to look at the physician’s office and ambulances, dental clinics and everything else. It goes beyond the hospital.
But what we’ve learned over the last several years in studying this is a UDI database that is properly scoped, defined, organized, implemented, maintained and utilized can in fact provide safety and supply benefits. Now, the three words I want to focus on here are implemented, maintained and utilized. We’ve debated this forever. I think it’s time that we have to find a way to implement and we have to figure out how we get going with this.
Now, BD has studied this topic extensively. Again, I mentioned that years ago, I did not believe this. And it wasn’t until we did a Six Sigma study, and I’m not aware of any others that have been out there. But we did a Six Sigma study to try to figure out where the errors are in the supply chain and why the product data’s breaking down. We’ve also been very involved with a lot of the industry groups. And there have been many forums that have studied this. And I’ve listed some of them here on this chart.
We’ve been really involved with a lot of the pilot activities that are going on. It’s been a great way to learn. And, you know, lastly, as far as implementation. We’re doing something very similar to this in Australia right now. And it’s not really regulatory driven. But there is something similar to a UDI database that is used in the Australian health care market today. And it works. The process works. But we’re finding lack of adoption by the health care provider. There are some instances where it’s being used. But it’s not being used the way we would have hoped.
Now, there is a system like this in the retail side. And those of you that serve that market, you know that retailers do in fact use GDSN. And if you don’t keep your data up, they’ll certainly let you know about it. And with implementation, you look at some of the examples in health care. This does not need to be something that is done in twenty years. Currently, we have implemented G10s and GLNs and some GDSM data with Seaton health care as part of Ascension health. We’re doing that today. So we’re able to transact with them. And they’re changing their system so that this does in fact work.
BD has made a significant investment in G10s and product data. As Erica mentioned earlier, we number all of our products with G10. So everything we make and sell in the U.S. does have a G10 assigned. We’re assigning labels. You’ve seen examples of that. We know that our ERP system has clean data because we’ve tested it and we’ve measured it. We’re sharing this information. And in spite of these investments, reality is there are a lot of errors that take place today and the customer has bad information on our products. And this is not a BD specific problem.
I’m told by providers that this is pretty universal. And I’m not referring to safety attributes or anything like that. We’re looking at basic supply chain information at this point in time. If you look at this chart and you look over at the right hand side, look at the percentage of errors that we found in the customer’s database. That’s pretty high. Manufacturer name problems, 30 percent. Obsolete products, 5-15 percent. So that’s what’s taking place. Another example is how many instances of BD show up in this customer’s database? There were over 350. And we were expecting just to see BD. But they had 350 listings for BD. And that’s because clinicians continually add new entries for companies.
Another example. I think this is a great one. Where the customer has done exactly what we would hope. And they’ve captured our catalogue number and they’ve captured our G10s. And it’s done perfectly. But if you look at the challenge here for this customer, the distributor is giving them a different number for the same BD products. And in many instances are labeled the G10s that we’ve invested in, are stickered over. So you can’t even see those. And you can’t use the bar code. And then in many instances, the health care provider has to add their own number.
So if you look at what’s occurring, you know, there are problems today that numbers are assigned and reassigned. And then lastly, you look at catalogue numbers. And we found some of the same things that John Roberts mentioned earlier. The catalogue number that is generally what is used for transactions is not necessarily unique. We’ve got a six digit number, but it’s not unique to BD. You think of electronic record. If you show that you used a 37-107-3, does that mean it’s a BD easy scrub? Or does that mean it’s a Codman bulldog clamp ring handle? What does it mean? So you can see some of the challenges that exist. And again, this is about primarily supply chain information. We did not study things like latex and sterility and some things that FDA’s interested in.
Now, the Six Sigma study that we did, it was really enlightening. It was showing all the sources that are out there. And I’m sure the providers in the room recognize this. You get your information from a lot of places. Yes, we are providing information to the customer. But they’re also creating self-generated information. They’re getting information from their distributors, from their GPOs, from websites, from data consultants. There are a variety of sources of data going to the provider for the products. And what we found is for future UDI success factors, we really have to think this through.
If once we have markings on that product, we have to make sure the system can support this. And I think the first assumption is that manufacturers need to own data creation. We can’t outsource that or expect someone’s going to do that. The manufacturer has to be creating their own data. And they have to manage it. The attributes have to be anchored to UDI. If we try to use a catalogue number, it’s going to get lost in the shuffle. Because we sometimes have the same catalogue number. We need to have precise standards for each attribute.
I think it’s impossible for us to have a different description for each customer in the supply chain or to keep redefining latex differently. We have to have a common agreed upon set of attributes. And they need to be global. I think near term, we have to look at static data only. I don’t see any way in the world we’re going to be able to have a UDI database and try to keep dynamic or transactional data in that. This has to be attributes that define the product, not things that get into what lot numbers run the market or how many or anything like that. And we’ve got to start small.
And I’ve sat in meetings where literally hundreds of attributes have been suggested as a starting point. And there is no way in the world this industry is going to be able to take 300 attributes and start pushing them through for each G10. It just won’t work. And this is something that can go on and on. But there are some success factors that we need to stick to to make sure that this is going to be reasonable and it’s going to work.
BD’s not the only company working on this. You see a list of logos. And there are a lot of manufacturers and more importantly providers that begin to understand this. This is the DOD sponsor GDSN pilot. And this group has been working together for some time. And it’s interesting. For those that are actually gathering up or creating data and those that are trying to use it, this group is not asking for more attributes. They’re trying to figure out how do you use the basic information? And most importantly, how do we share this effectively and make sense of it? And what existing processes do we need to change to make this succeed?
And this has been really I think a fantastic way to learn how this actually takes place. And I really suggest getting involved for those of you that have not participated to this point.
Certainly Jay is going to cover this and ask some more questions about it. But I just want to stress that we have to be precise with these attributes. And they have to be globally harmonized. We’ve learned that through our efforts with Australia and other countries that if we have the same G10 crossing borders, the information that’s associated with that has to be the same. Otherwise, we keep tripping over each other. We can’t define control mechanism one way in the U.S. and one way in Australia. Because they’re going to somehow end up with our data in their system. So this has to be globally harmonized.
For phase one, we’re going to have to start basic. And I didn’t mean this to be a complete list or rank order. But I think there’s a common theme. And that’s something I hope we can talk about as far as which attributes are essential to get started. But it’s clear that this is more than just clinical or regulatory. The two continue to intersect within customer systems. And I hope that we can have some discussion with providers. But that’s something that we’ve learned is if you’re pulling data inn through your MMIS and then distributing it from there, we can’t have a separate pool for clinical data and a separate pool for everything else in the supply chain. The two do intersect.
But anyway, Phase 1 attributes. You see a listing. And then other attributes, we have to figure out where we’re going to draw the line. And the four attributes you see listed, I didn’t make these up. These have come up. These have come up more than once. And we don’t know what flavor to put for a vacutainer tube. We don’t know what gender to put for re-agent. And we’re not sure what fragrance to list for a catheter. I mean, it’s possible that it makes sense for pharmaceuticals. But for devices, we don’t see any logic in some of the attributes that have come up to this point.
And some of it gets a whole lot more complicated. We’ve been asked to have a full bill of materials with every single product used and have that listed along with the G10. And it will just be so difficult we’ll never get started. So I think it’s key that we collaborate. We start small. And we get started.
Now, as far as industry-wide adoption, I think we’re making some progress. But I want to show you a picture. And for those of you who saw Rick’s slides earlier and you saw G10s all over it. This is a really old product. We had to dust this off and take a picture of it. But we used to use different bar code markings. And as we were making a change, what we wanted to do is make sure that we didn’t trip over everyone in the supply chain and cause a disruption when we change from one system to another. And we. And we met with our distributors and found that no one was using the bar codes.
And this was back six or seven years ago. But we found that there was really no use of the bar code at all. And we had spent a lot of money, a lot of time putting these bar codes on. But they weren’t being utilized. And then ultimately, when we did start making changes, I’m not aware of any disruptions at the customer level. This is six or seven years ago.
We also changed a data attribute. At that point in time, the term shelf pack is one that kept coming up. And we believed at that point in time the shelf pack was going to become a defined term that meant that inner level of packaging and that’s one that we would use and the customers would know what we meant. But we did change to it. And we used it in our SRP system. So we made the change. Now what happens when we use shelf pack is we get errors in EDI. Because we’re using a term that never did become the standard. And now we have problems with it. So I think as we think through these data attributes, we have to make sure that we get it clear and we actually do adopt.
And the third example is, and I’m sure other manufacturers do the same thing, but you continually audit the a quality of your bar codes and your packaging. And we’ve had some examples recently where you find that things drift and some of your bar codes aren’t scannable. So you go back and you check and see if there have been any complaints or any problems. And we find for some product lines that there are no complaints. Which tells us no one’s using them on the other end.
So really as far as industry-wide adoption, I want to stress how important this is. And we have to get total market adoption otherwise, it just ends up becoming art work on a package. And it’s expensive for us to produce. And it’s not what we’re looking for. We don’t want to put art work on packages. We have to find a way to make this work.
In conclusion, BD believes, if implemented correctly, industry-wide adoption of UDI and product data standards can improve FDA safety and surveillance initiatives, enable manufacturer and provider, patient safety initiatives, become the foundation for product tracking, NEHR, and remove cost and waste from the system. It seems like we can get all of these. But we need to collaborate to select and define and share a reasonable set of data attributes. And most importantly, we need to think through how we’re going to get adoption of this. Otherwise, it will be a waste of time and effort. Thank you for your time.
MS: All right. Well, I guess I know who’s up next. Thank you, Dennis. Jackie.
MS. JACKIE ELKIN: Thank you. I’m Jackie Elkin. I’m from Medtronic. And I’m going to try to be very brief today. And I just want to let you know I’m not here to present Medtronic or the world according to Medtronic. I just want to pass forward some thoughts that may provoke some actions and thoughts. They’re mainly related to work I’ve been engaged in either directly or indirectly with various organizations. And this slide depicts some of those organizations.
The one thing I want to stress here is the importance of getting engaged with these types of organizations. These are the organizations that I’ve been working with mainly on a lot of the e-initiatives around health care. Some of them are standards organizations as you can see. We have the agency there. We have the advocacy group, ADVAMED. And we have a taskforce, Global Harmonization Taskforce. The one thing they all have in common is in some way or some form, they are touching on elements of UDI. And it’s becoming critical that we work together and we all understand the different elements.
Some of these organizations are working together on some initiatives. HL7 for instance. On the structured product labeling initiative. Working with Bridge and Seadisk to develop that standard for the FDA. Now I also want to talk about some of the considerations. These are things that come up time and time again. Actually, one more thing I want to mention about some of the organization groups. I think there’s a misconception that if you want to have a voice in developing these standards in some of the standards organizations, you have to pay to play.
That’s not true at a certain level. The standards organizations, they all have work groups. And to be in a work group, to have your voice, your opinion, to be part of the big debate, you don’t have to pay. You just have to be there. You have to be in the room or on the phone. That’s where the things are vetted out. That’s where the big debates happen. You don’t have to pay for that. If you want to vote, you have to pay for that.
But a lot of the big decisions and discussions happen in those work groups. And I think the more people we get involved that understand the operations, understand from the manufacturer’s perspective through the hospital and the hospital folks that have to use that data, they have to be the voices we hear, the people that create the data and the people that ultimately use it.
So some of the considerations. Use of global standards. We’ve talked that one ... we’ve beat that to death. I think we all get it. The data elements must be clearly defined. It goes along with standardization. But we also have to understand the intended use. We can define data elements. But at the end of the day, if the end user is not going to use it, I don’t think that’s a good place to invest a lot of our time on. We need globally harmonized definitions if we’re going to include them in a minimum data set. Once we go outside the United States, country of origin means something totally different. That’s one example. There are many others.
The other thing we should consider are data entry points. There are many data entry points for the data. And how are we going to keep that synchronized? If we have several data points of the same data, we all know when that happens and you don’t have synchronization, it soon becomes disconnected. We also have to consider the timing of certain data and aspects. You need to understand the approval process, the manufacturing process through distribution, to understand when certain data elements will be available for you to enter into a database.
This is my Dr. Seuss spin on the world of UDI attributes. UDI attributes. Here, there, they’re everywhere. I put this together with a small group of people that are working on some of these initiatives. Their regulated product submission, standard, the structured product labeling standard. And then I looked at some of the databases that are out there, the MDR database, e-listing, registration, 510K, PMA. And then some of the attributes we’re looking at for UDI. And started looking at the similarities. And this is what I came up with. A lot of redundancy. So we have to think about that. How are we going synchronized?
Preparation. I think the time is over. The if’s are over. Now we’re moving onto how. So these are some of the things from the manufacturer’s perspective, what manufacturers need, the creators of the data, need to think about. What’s the minimum data set you can prepare for? You know it’s going to have to be something that identifies that product and gives you a description. So you have to start figuring out where am I keeping that data? Where is it? How much legacy data are we going to have to consider? We don’t know this yet.
But we have to start thinking about it. Have you completed a data assessment? Do you know how clean your data is? Where and how is the data maintained? IS it in paper? Is it in systems? How many systems? Are they connected? How will you extract the data? Are you going to have to build an internal database? Or are you going to use master data management tools to consolidate that? Start thinking about that. How are you going to send it? That’s going to be an important part. Who’s going to be responsible for the governance? Who’s going to own the data?
As we all know, this data is not in one nice neat place in our organizations. It’s coming from many systems, many different places. We have to consider that entire product lifecycle and where this data is and start thinking about how are we going to get that data together. The other thing that I would like to talk about is related to the core of this data. We had a debate this morning on which standard to use, this one or that one. This number or that number.
And there was a comment about, well, it’s going to feed the number of members. And it’s not about the number. It doesn’t matter. We know they both work, right? What matters is what is integrated in your system? Because that’s the number that you have tied everything to. So it’s the systems integration based on that key. That’s the issue. We know they both work. That’s it. [applause]
MS: All right. Thank you, Jackie. Who’s next? Kathy. Kathy Garden.
MS. KATHLEEN GARVIN: Good afternoon. I’m Kathleen Garvin here to represent the Department of Defense in medical logistics. I’m going to give you the bluff, bottom line up front, you know. And then I’m going to follow very quickly through some more detailed charts. DOD medical logistics supports the FDA’s unique device identification program. However, very importantly, to be a success, the UDI program will require product data standards with the support infrastructure in place.
DOD’s medical logistics mission has a need for product data standards. DOD has a broad mandate for all categories of assets across the department to be marked and tracked with a unique identification number. I think you heard a little bit about that this morning. It has some similarities to FDA’s UDI. DOD medical logistics has a long record of working towards industry-wide product data standards. DOD has maintained a strong collaboration with our industry supply chain partners in working towards data standards.
An example of our commitment to industry-wide data standards or the two pilot programs we sponsored under our data synchronization program as proofs of principle for the health care industry. DOD nor federal counterparts are in the business of promoting or selecting specific data standards. But due to our alignment, our close alignment, with industry practices through our prime vendor business, we will follow the lead of the industry in their selection of standards, including the UDI standards.
The biggest challenge to our logistics chain is during war time when prompt response is paramount. Identifying, sourcing and delivering devices to the war fighter is not as streamlined as pharmaceuticals. Due to the hodge podge of numbering, naming and identifying products in the med surg industry. And beyond wartime in national emergencies and disaster response where collaboration across federal agencies is required, standard identification of products is key in getting the right products to the right places on time.
During the 1990s, DOD medical logistics embarked on an intensive program to promote product data standards called universal product number of the UPN. Although significant progress was made in the assignment of numbers, the program really never worked as intended. Our lesson learned was that without a process in place to ensure the certification and synchronization of the data from a single utility, it was doomed to failure. We realize that other industries success with data standards was founded on a concept referred to as product data utility.
Running this in deployment support challenges in 2002 at the start of the war was our call to action to renew interest in data standards. This time with the PDU in the health care industry. We have since collaborated with many health care industry groups, including the coalition for health care standards, the health care supply change, standards coalition and others. This chart shows a very basic model of a product data utility. It performs data normalization, synchronization and validation against standards of compliance, certification of data and users and ensures that everyone in the supply chain sees the same data at the same time.
The grocery and electronic industries use this model prior to the establishment of the global data synchronization network. DOD’s commitment to product data standards in the health care industry is manifested through the two pilots we sponsored and supported. The first pilot was pre-GDSN and was called a build your own product data utility. We demonstrated this proof of principle as a potential industry solution. The second pilot came about with the tremendous rise in the use of GDSN by other industries and the Wal-Mart mandate to their suppliers. We considered this a potential alternative to a build your own PDU. The interest and success in the pilot from the industry has been huge, particularly from hospitals, IDNs and GPOs.
DOD instituted a requirement for unique item identification across the entire department for all assets meeting certain criteria. For medical devices, our goal is to use FDA’s UDI as the construct for our DOD, UID requirement. Thereby eliminating the need for separate markings for each program by the manufacturer. DOD will accept the application identifier for G10 plus serial number as well as several other formats for UID.
In conclusion, our lessons learned are based on previous experience with the UPN initiative as well as our more recent significant work in data synchronization and the industry pilots. Data standards and a process to control them are pivotal to the success of the FDA, UDI program to increase operational efficiencies, improve patient safety and facilitate complete recalls. Thank you to the FDA for the opportunity to present and to all of you for your time and attention. [applause]
MS: Who’s up next down there? David and Jay. Who’s going?
MR. DAVID McCONES: Good afternoon. My name is David McCones. I’m the Vice President of Enterprise Resource Planning and Supply Team Operations for the Balance Core Health System. I’m a late entrant to the panel. So I don’t have a presentation deck, but I’ll prepare one and forward it to you. I wanted to talk about the UDI database from the perspective of a provider and how we foresee using that and what its utility would be. And therefore, what we think some of the key attributes need to be in that database. And the three areas in particular focus on is data normalization or data scrubbing, data synchronization. And then setting up the database as a foundation for further analytics and database management.
Our system, our journey, we have eighteen hospitals, very disparate originally. And we’ve been on about a six year journey of creating our own internal micro version of this within our own numbering systems and so forth, all the issues we’ve discussed. And one of the key lessons I guess, and this goes back to process improvement training and so forth, is that the rate of progress and the penetration of progress and its impact and performance is critical.
And what I means is when you start at ground zero and you get 30 percent of the process or whatever control that was under control, you see an initial kind of breakthrough improvement. But then as you incrementally improve from that 30 percent of about 80 percent, you get little stair steps of improvement, but no major huge advance. It really takes from that 80 percent to 100 percent where you really see the true advancement and major change in performance. And we’ve seen that occur with our own model as we started out and had only maybe 60 or 70 percent of the items identified I our processes, through both our supply train and then linked to clinical.
And as we’ve now approached 90 percent. And between that 80 and 90, we certainly saw huge advances. But as we have that 87, 90 percent linkage now of items identified across all our processes, what concerns me is too that, number one, it’s sort of an inverse situation. The lowest risk items are clearly identified, commoditized. The highest risk items in terms of risk to patients, clinical care, are not. And I think that’s a function of the fact that those higher, higher risk items are often selected on a patient basis as a physician preference.
They often have very different distribution models and so forth. And they’re very dynamic and changing. So I think both our suppliers and our models just have adequately dealt with that. So on the data normalization and scrubbing issue, if the UDI is to be successful in facilitating that kind of effort, it’s got to deal with those high end issues. It’s got to get to that 80, 90 plus percent completeness in the category selected. Or in my opinion, it will be of limited value.
So my first input is to, within the selected areas, drive to completeness. And in fact, 80 percent is inadequate. As you move into synchronization, it needs to be 90, 95 percent complete to truly drive complete processes. And that leads to synchronization. Our other part of our journey has been to standardize our information systems and put in the electronic medical record and other electronic systems to truly drive a model where we can change the clinical care process and track it much more expertly than just intuitively.
And in that model for supplies used, supply items of all types, the source of truth is the item master. As we’ve worked through the interfaces and the intricacies or the linkage of that, we’ve determined that a source of truth must be the item identifier for supply and components. So the synchronization includes ancillary clinical systems, cath lab or et cetera. Where the item is identified, used and physiological data and other patient attribute data is attached. It includes the software we’re putting in for our electronic medical record, automated order sets, contraindication alerts. And again, the source of truth is the item identification. So throughout the process, we’re calling it the same thing. We’re ordering it the same way. We’re identifying an order set properly.
A third element of that is the alert in recall management capability. That when we’re alerted for recalls, again, we have the same identification throughout the process identified at the patient level. And this data is of no value if it can’t be brought to the patient level identification for clinical purposes. The third element, of course, is the supply chain system, the normal transaction. But it’s also critical for projecting and predicting utilization. So we have enough for the clinician to do their job. And identifying its location where we can move it around even urgent, emergent or other conditions.
And then the final is billing. Where in the past it was satisfactory and adequate to have high amounts of generic and miscellaneous coding, where our linkage of our items to our billings was maybe forty or fifty percent, we’ve now moved that to 70 or 80 percent. And we believe it has to be 95 percent. Payers are demanding transparency of all transactional data where you can link all the way from obviously the purchase of the item, the cost of the item, what patients use it for, how it’s billed, fully transparent.
So the synchronization issue is critical. And as we’ve learned in our model, the item identifier for at least the supply component of all those activities is the item number and the item file. So again, I think the UDI can serve a great purpose to create the standardization which all those systems can now adhere to. Just as HL7 was developed for information system interface linkages, just establishing that, no matter how quickly and largely is populated, will then serve as the basis to really facilitate that synchronization.
The other thing we’ve learned is timing. It used to be adequate to update our item databases annually, quarterly. Then transactionally you move to monthly. We now have a standard that we have to have a new item identified and then fully put into the system and linked in 72 hours. To adequately link to the patient level data and the electronic medical record to support ancillary systems, much less billing issues, it has to be that quick. So we have to ping to the manufacturer every time a new devices or through an item catalogue or whatever the mechanism is and accomplish that with 72 hours. You cannot do that unless you have a standardized streamline model across all the participants? And those who don’t have it will be left in the dust basically, including providers.
So the other issue I’d advocate is that there has to be ... while I agree that the amount of data can be relatively limited and I think the data set is identified as adequate, it must be frequent. It can’t just be once a year. It can’t be dated data. It needs to be ... and I don’t know that the frequency can be 72 hours. But I can tell you that’s our standard that we have to live within.
The third is setting up the database management as a future analytical tool. And again, I agree that the data base can’t contain all the detail attributes down to serial number and transactional data. But it is setting the foundation for what will be the primary analytic tool for many people, FDA and others. And therefore, the two things that I sort of question is, number one, there must be a classification system. Now, it can be one that the FDA adopts and has algorithms and crosswalks to take the data and sort it.
But it would be useful, it seems to me, to create that. There may be reasons academically or business-wise or others for different classifications to be developed for different purposes. But a classification system that fundamentally is the groundwork and can be used by others would be important. The other thing that worries me I guess is the issue of country of origin and raw material origin. We have so many of our medical items now that are not produced domestically. Huge blocks are totally moved. And we are now fully dependent on the quality, and the limited quite frankly, quality inspection of those. And, of course, we see the raw material problems that are occurring. While that may not be relevant as much today to some items as biologics, synethics merge, you know, with devices, it seems to me having somewhere the capability of understanding the country of origin or something to the raw material pedigree will be important. So our country, as well as us as providers, can deal with those issues as we identify them.
I guess the final word, it goes back to my earlier comment about the 80 percent or above. Practically, we have to be somewhat incremental in the process. But my advice would be to use the clinician’s input to select the risk categories where this makes the most sense and go deep, aggressively and complete and provide a system that we can really get the full benefit of, not just the 30 percent and just sort of struggle along. [applause]
MS: All right. M.J.
MS. M.J. WILEY: Good afternoon. And congratulations on now what appears to be the 13 th or 14 th PowerPoint presentation of the day. So give yourselves a little clap for staying with us. My name is M.J. Wiley. I’m Director of Global Data Standardization at the Global Health Care Exchange, GHX. And, first of all, I’d like to thank the FDA for inviting us to participate in an event such as this. I think we’re getting lots of opportunities as they say. That’s the better word than challenge, to see all the work that lies ahead for us.
So with that, what I’d like to do is a little bit of introduction to GHX for those of you that are not familiar. We are owned by twenty equity members that represent the entire supply chain, both manufacturers, distributors and the group purchasing organizations and hospitals. And built on very much an open and neutral platform. That certainly gives us a different advantage if you will for more of an aggregate view of how we see the industry and how we see the supply chain.
Basically, that’s around connectivity, the electronic connectivity. And more important about moving accurate data through that connectivity and the supply chain. Representing over 350 integrated suppliers. That represents over 85 percent of the products that are purchase regularly by a hospital. Those integrations were over 3,800 integrated providers in North America representing over 80 percent of the licensed U.S. beds as well as 90 percent of the United States integrated delivery network systems.
We also have operations in Canada, the U.K. and some European countries as well. We also enjoy strategic relationships with the group purchasing organizations that are represented here in the United States. As you can see on the chart, there’s over 7,200 buying and 2,400 selling organizations that transact through DHX. Since we began in 2001, that purchase order volume number is up over 1,200 percent at an estimated $25 billion per year. We also look at we’re the ones that enable the advanced, if you will, order cycle transaction sets. We also successfully integrate with many of the ... or all of the commercial material systems as well as the customer, the home grown systems.
This is just a little bit of what we do in setting the precedence of how this comes to be with database work and understanding what the industry needs. It puts us in a very unique position, if you will, of our industry expertise as well as our vantage point. We enjoy the expertise because we get to hear so many different levels of the challenges, the opportunities, the wins, the loses. Loses. Is that a word? I didn’t have red meat for lunch.
Okay. With that, the opportunity to say what does this represent for the industry? When you bring the lowest common denominator with the most advanced system, you can’t help but understand what the challenges are for those people to be able to communicate and talk to each other. It’s one thing to be connected. It’s another to be connected where you’re truly interoperable, you truly can move not just data, but accurate data, do that successfully through all members of those relationships.
That’s a strength in which the health care industry has been able to observe and with that been able to see a lot of our flaws. I think that transparency and visibility that we all want to bring to health care has certainly been eliminated the last few years as these connectivity strategies come more into play.
We also look at the perspective because we get to hear the good and the bad as well. We hear when it works. And we hear when it doesn’t work. And we’re able to learn those lessons. Something GHX I think has been able to do very effectively over the last few years is not only hear that information, but provide mechanisms back to the industry of being able to take it in and being able to report that back and be able to share that with other areas of the supply chain. Because we are member driven, everyone brings that back to us.
I don’t want to say we’re like the FDA. But considering that we are an open neutral platform, we can’t dictate a standard. What we can do is listen to the industry, know what our memberships are driving toward, what they want us to be involved in. And then help with that adoption and hopefully accelerate the implementation and ultimately the execution of those standards. Everybody gets their wind. But we all know most importantly is that point of use when it gets to patient safety.
So as we move through the deep and the broad connectivity that I just discussed, it’s important to understand when we bring this to bear, it’s about business and technology, drivers and the barriers across the supply chain. We talked about the interoperability challenges. That’s just basic science in today’s world to know that if we want to communicate electronically, there’s not a room for a margin of error if the product number’s incorrect. We happen to be in an industry where incorrect numbers can often cause fatal mistakes. I think that’s why we’re all here today, wanting to change that fact.
Technology limitations. For everyone that has a ten plus two system, somebody else has a minus one. And we all know that means sometimes we have to go to the lowest common denominator. So when we talk about a database or any kind of database in which to help with this UDI standard as it moves forward. You’ve got to be able to talk to everyone. Everyone has to be able to publish to, consume from and be able to make use of that data and leverage it in the best way.
We get into data security and data rights. I think it was brought up earlier today, who has access to this data? Does everybody? Or does somebody have access to publish? Someone else has access to just consume. Someone else has to maintain. What are the validation rules that go around this database? And the ultimate always is there is a UDI standard. I always reckon it to that’s a license plate. We’re all familiar with the license plate as a dumb number. But what it represents is your eye color, your address, for some of us tragically, your weight.
It’s going to represent a lot of information ... sorry, private joke. What it’s going to do is represent a lot of information that may or may not be useful when you first look at the license plate. So as we move forward and talk about a phased approach, we want to be cognizant of what that minimum data set looks like mostly likely. What’s the risk base that we’ve discussed a few times today? And how does that phase, what does that iterative approach look like as we move towards compliance?
This next bullet, accelerating standards and driving data synchronization. I wish I had a dollar for every time we’ve said standards today. And I wish I had a dollar for every time we said data sync. Because I could retire I think. The opportunities for synchronizing data only happens when people have a mechanism in which to do that. And I believe that right now globally we do have that advantage. And the other is if we’re working in some again operable standards, inoperable standards, that can communicate with each other.
At GHX, because of all the data that comes in at grade D minus versus an A plus, we must be able to synchronize to simply get a purchase order through. So given those kinds of opportunities and looking at the data synchronization, GHX is very involved with the global data synchronization network and will become a data pull later this year. One of the reasons is because our members have said this does make sense. This is important. We want to move forward with more data synchronization around these standards.
The last bullet, I think Jackie said that we had beaten global harmonization to death. But I’d like to take a stab. My line has always been if you work with anyone in the supply chain, I don’t care if you’re a small hospital, you’re a distributor, I don’t care who you are, if you do business with somebody that does business globally, you too are involved with the global health care supply chain. And if for one moment we think in the U.S. as a big island that we are not connected to that, just watch the next label go on a product and the cost go up.
We’re all in this together, representing our membership. I hear this often. This is all about trying to reduce the cost. But it’s always about leading us towards patient safety. So we need to be cognizant when we start talking about, oh, global. That’s for those guys over there or that’s just for those suppliers that sell to another country. We all are involved now in a global health care supply chain.
Looking at that, so you say so what? If we look at like what are the standards compliance areas, we have to go back and say what are some of the impacts going to be to even get us to standards compliance? Global standards. We’ve obviously touched on that. We look at UDI. We look at other regulatory aspects in which are going to be some needs. Again, if it’s a global supply chain, there’s going to be some other reckoning if you will for some other regulatory agencies. And on a side note, congratulations to J. Crowley represents the FDA.
And in my opinion, the U.S., every time there’s a global harmonization task force, the FDA representing the U.S. is a part of that. So I think that huge opportunity for us to move forward again. We can’t forget that people in France have a supply chain or the people in Serbia have a supply chain. And they too are driving towards patient safety and trying to reach that same type of interoperability with their communications. When we look at what’s the fit or the gap over some of the core systems, this has come up earlier.
What is your customer order flow? Whether you’re a buyer or a seller, we still have customers. Everyone still represents somebody they’re doing business with. What does your website look like if you’re a supplier or you’re a distributor? How is that database reckoning back with your internal systems as Jackie spoke to? If you’re a distributor, how are you getting your data? Because now you become a buyer and a seller. So now your buyer has maybe two potentials of working with perhaps the same product. What is the GPO admin processing look like? How much does that change if we standardize the who and the what when we move forward?
Back to data syndication. Syndication’s an interesting word that obviously gets confused I think with synchronization. Red meat. The play there is synchronization is something that’s happening between two. Syndication is pushing out. When we push out, do we throw the ball and hope someone handles the catcher’s mitt? Or do we assure that the catcher and the pitcher are together? Those are interesting phrases that are starting to happen when we start joining trading partners. And we don’t just do one-to-one. Now we’ve got many trading partners to many trading partners. Are they all throwing the same ball and catching at the same time? It’s not hard to realize how complex this gets around just transferring data.
The last one is probably my personal favorite from a data prep and movement position. It’s one thing to be prepared. What happens when you have the ball and you see the catcher’s mitt, but someone just drew the curtain? Is the catcher’s mitt in the exact same position? How are you going to move the data? How fast will it go? Will it take a curve? Will it go through another system that you don’t even know about yet? Those are some of the questions that we start to get ready for. And then you turn around and you say I have my catcher’s mitt on. I have no idea where the ball is coming from.
So now my system may talk to someone. It may not. The database that Jay’s wanting to put ... not Jay personally ... the database that the FDA’s wanting to put together has to be both the pitch and the catch. It has to serve both parties. There has to be enough rules and validation rules around this data for it to work. GHX, like I said, is very much like the FDA. I can’t pick a standard. I can’t tell you how to load your data. I can’t tell you how to pull the data out. But we are in a good position to help folks understand how important that database is going to be. And some of the rules that need to be pushed with that is we bring industry leaders in and hope to help with that.
So the last one, do your teams know how to support regulations? It’s probably one of the reasons we’re here is learning more how to do that. So as we think about those key points, we’ll look at this data publishing and consumption approach. We think about UDI and standard support. I refer to it as earth. It’s sort of like saying pizza. It means a lot of things to a lot of people. You’ve got to bring it back down, get good definition around it.
Then we start saying what does the published data set look like? What’s it really going to involve? What kind of analysis are we going to go through? What decisions are we going to make? And then we get to the final data build. And this is when people start saying I don’t know what classification do we use? Who knows? What’s the business purpose? I will always come back and ask anyone building a database what is your business purpose for this? What is the business process around your business purpose as you move forward?
So as we go in and start looking at this, the question is are you prepared? On the provider side, you guys can read. Here is a list of questions that we see from a GHX perspective that you need to be cognizant of. Are your systems and your people ready to consume the data? Consumption is a hard word for some people. I go back to my basic catcher’s mitt. Are you ready to get it if someone really publishes it? I think it was Dennis that said earlier ... Dennis and I go way back on this I think. The ability to want 327 attributes is a wonderful goal. But if you want them and you need them and you can’t consume them electronically as you ask for them, have we wasted our time? Have we made some impediment to even reaching the first part of the goal?
So how will you prepare for your business changes? What are your business purposes for the data? How are your internal systems impacted? We shared a little bit of this. Are they ready t accept and share the data financially, clinically, your material systems? What does your long term plan look like, your budget? What costs are going to be involved? Is your connectivity in place to ensure the data can even be received? What about the frequency? How often are you going to do this? How are your systems people and processes be prepared for migrations plan?
Do you know your timelines? If you change a vendor, how are you going to get the new data? Do you know how often you’re going to get it? If you’re sitting on the supplier side, the questions are very similar. But then again, we all agreed that the manufacturers own this initial data set to get us started. So do you know the minimal types of data that’s even needed? Is your data ready to be published externally for regulatory or other standardized requests, much less for global needs and some other global requests?
What’s the impact of your internal systems, your own internal systems interoperability, from marketing to regulatory sales to IT? Do you know the cost to your organization globally? Do you already know globally what the impact will be if you’re working from a centralized versus a fragmented model in your organization? And how are you going to pull that off? Is your connectivity in place? The same thing. Some of the electronic requests, the frequency. Do you have your migration plan?
Do you know if you bring out a new product how soon you’re going to get it into the system? Do you know how that’s going to look behind the scenes? What about when you’ve sunset a product and you get rid of that product? What’s that going to look like? So we’re going to transition your efforts to those internal systems. Do you know your timelines as well? So with that, it’s more about are you ready and are you prepared? And I think part of this today is what is that minimal interative approach look like? So with that, I appreciate your attention. Thanks again to Jay and the FDA. [applause]
MS: All righty. That was a lot of information. So let’s open it up. Let’s talk about this. Lots of issues. Lots of ideas. What do we do about this database? Questions? Comments? Remember to talk into the mike everyone. My sound people are very upset.
MR. JEFF SECUNDA: Jeff Secunda, Advamed. A question for the panel, including Jay. We’re talking about databases here. there are already existing databases that medical device manufacturers have to provide information. The question is do we envision that the UDI database would replace some of the existing databases such as the e-listing that FDA currently has?
MS: I guess I need to answer that question. I would hope eventually that we get to an integrated point, Jeff. I think it’s going to obviously take some time to understand how that will play out. But ultimately, we see UDI as the foundational element for actually most if not all of our systems. So eventually, migrating to a single system is ideal. I think it will take us a few years to get there.
MS: (inaudible) all the different business and other factors out there, early on the UDI will probably not serve that purpose. But what’s important is it establishes the standard that all databases would follow. And then if there’s some capabilities developed in any number of databases, as long as they follow that same model, then we get the standardization we need as the UDI develops to completeness. So to me, it’s as important to get on with the business of establishing and mandating the standard. And then with what will flow. And then the other databases will follow.
MS: This is (inaudible) from (inaudible). It appears that all the discussion going on is for the rich folks. That is the company which makes lots of margins and hospital with lots of money. Because current situation is lots of hospitals, as you know, with the current economic situation, they are not doing very well. So why not think outside the box? Why don’t you put out 2D bar code with all that information you want to try? So we can actually look at it at clinical bedside which 2D bar code reader. The cost of 2D bar code reader has dropped tremendously.
Partially because DOD’s effort of using 2D bar code. And we could see that information at bedside. And nurses could see it. And we could understand what it is. Because right now you guys are basically telling me I’m going to give you one D bar code. If you don’t get it to my database, screw you. And my question is can you make it a little easier for us to adapt? Because I don’t know if your Six Sigma process. Did you ask a question why the user doesn’t use it? Maybe because we don’t have any resources. Maybe the barrier you’re putting in front of us maybe it’s an excuse. Because maybe 2D bar code is something you should look at more closely.
MS: One of the challenges that we’ve found, first off, with the 2D bar code, a lot of hospitals are not prepared to read that today. And while we’re in this transitional period we’re getting up and running, it’s not human readable. And really what we looked at and a lesson learned through a database is we need to make sure that we establish a unique number for that device, make sure that everyone has that same information in their system and that we have to then correlate that to a database. Because this is going to grow over time. There is no way we can get all desired information in that bar code and continue to change it day after day.
MS: May I ask (inaudible) data set? Obviously, some key issues. For instance, since we are talking about device, let’s talk about IV pumps which needs to be calibrated once in awhile, needs to be checked. And those dates need to be there at the machine. So we can actually see it. Having it installed somewhere here and yonder, what happens when we don’t have a wireless or Internet working very well? Lots of hospitals don’t have those. So if you’re asking those hospitals, you’ve got to log onto my database from wherever you maybe.
I think that is setting up the arbitrary hurdle which is very difficult for those hospitals to overcome. And considering also, since I’m coming from Florida. We have hurricanes and a few other natural sort of unhappiness should we say. Those times, we lose power. And the service is not there, never goes down. And many times, the only thing we’ve got is battery packed device. So in that environment, the 2D bar code would give us lots of information locally we need. Because during that power down, we can’t ask a person coming in to ED can you wait thirty minutes? So I can get my power up. I don’t think that works for us.
So I think you need to work with us. And we’re simply saying we did the one D bar code. Nobody uses (inaudible) not interested. It’s not that. We are interested in it. but we don’t know how to get there because that barrier’s so high.
MS: Thank you. It seems like some of the critical information that you’re describing is already in the product label. We don’t make IV pumps. We should have somebody else answer that question. But when I think of the products BD makes, we have labeling requirements already. And there is certain information that is already on that product that you don’t need to go to a database. But if you look at some of the requirements today, it states whether it has latex, it states sterility. I mean, we are putting as much information as we possibly can on a label. And I think that’s one of the tradeoffs.
MS: The problem is that when you give us all the human readable information, how do we put that into our database? We end up hiring somebody probably paying minimum wage. Does the person care how it’s done correctly? They don’t. And we have done RFID projects now over fourteen hospitals. And the biggest problem is the database. So when we type it in, like you mentioned on BD, there are 320 configurations. IV pump, we probably have 320 variations also. So this is a problem.
So I think if you want to help us and slowly moving to the direction you want to go ... and I think everybody wants to go that direction ... that you need to make us be able to use your information somewhat more cost effectively. And technology does exist. I mean, if it’s five years ago, I would not ask for 2D bar code. Because that’s very expensive. But it is not like that. And FDA’s going to take time. Because they have to be sure we’re doing right. Meanwhile, I think you certainly could work with us, to other associations.
MS: Okay. Thank you. Dennis, you’re done. Thanks. You two can go and discuss this later.
MS: Jay, Bridge Taylor with Roche. You made a comment when the whole meeting started that you wanted to create a database that is NDC like. Well, that’s your perfect learning laboratory. What worked with the NDC database and what didn’t work? What was the scope of that database? What worked? What didn’t work? So if you take that learning and all you’re saying is that I want a unique number like I give a drug. I’m going to give that same number to a device and use the experiences you’ve had with the NDC database hasn’t worked for recalls. What worked, what didn’t work. And then use that learning. Information you’ve had years of experience with it and don’t walk away from that experience.
MS: Great. Thank you. Jim.
MR. JIM KELLER: Jim Keller from ECRI Institute. I had a question and comment about nomenclature. And full disclosure, ECRI Institute developed the universal medical device nomenclature system. The slide here refers to GMDN which I understand FDA is moving in the direction towards hundreds if not over 1,000 or more hospitals are using UNDNS in their databases to keep their inventories clean and also to do tracking of recalls. And actually, several of the computerized maintenance management system vendors are starting to incorporate UNDNS in their databases and doing automatic searching against UNDNS terms for recall notices. So should the unique identifier initiative adopt a different nomenclature, what approaches should hospitals take to link up their existing nomenclature terminology to a new system? Considering that the databases will have tens of thousands of records that have to be matched up to a different terminology.
MS: Am I supposed to answer that one? Jim, I think it’s a good point, of course. This is a question and not really a statement. So the question I think that we’ve batted around here quite a bit is on the issue of nomenclature classification. And I’m not saying there needs to be one either. So there are multiple systems that serve multiple needs. And there’s no reason that you couldn’t have multiple terms associated with individual products. You know, GMDN is something that may serve our purpose. But as you say, it may not serve everyone’s. And maybe there’s a need for other classification schemes for other purposes, other stakeholders.
MS: And just one follow-up point related to that. I see problems in having multiple nomenclature systems to match to especially related to the surveillance part of it. If FDA’s database of adverse events is pointing to one of the several nomenclature systems that are out there, it will be hard to have a good match to what’s really going on with that particular problem that’s being reported through the adverse events system. So ideally, they’re all linked up to one another. So they have some sort of linking or harmonization.
MS: You’ll take care of that for us?
MS: We’ll do our best.
MS: Thanks.
MS: I’m Lee Grennan from West Virginia University Hospitals. My question is somewhat about the scope and something what the gentleman from ECRI was talking about. Most of the conversations today have been about supply chain things which are to me items that have a reasonably short lifespan. My job involves capital equipment. Where we’re talking about like the guy from BD said stuff that has kind of ten to twelve years of life expectancy. Devices change over the life. They get updated and stuff like that. With a static UDI which is what they’ve kind of talked about previously, I see a UDI that in my line has to change over the life of things. And how would that work out? Can this be all work into one thing? Do we force fit a long life expectancy life in with a supply chain type of thing? Or do we need different sets of rules?
MS: I’ll take that unless somebody wants to comment. No. Well, I don’t think that ... let’s just take an example arbitrarily. You’ve got an infusion pump let’s say. And it has a serialized unique device identifier on it. I don’t think that it would change over time. I would expect that it would remain on the products as a way of identifying the product. The question then becomes, for you and for others in the room, how do you manage the life of that device? Where does information about software updates, recalls, changes in parts, what have you, where does that information reside? And I don’t know the answer to that. I think it’s a great question. It doesn’t seem to be something that we could manage. It’s something that maybe a manufacturer would manage. Maybe it’s something that you manage. But I do think that the unique identifier just provides the way that you always identify that problem and make changes to it or updates to it.
MS: Great. And part of the question came up earlier and I kind of waited until now. The whole mother/daughter UDI concept comes in where you have modules. And so overall, if the medical device is made up of seven or eight UDI type devices, how is all of that managed? And would that then fall to me to manage for my hospitals? Because there’s compatibility issues. There’s a lot of different issues that are involved in this.
MS: Agreed. I started it. So I guess I’ll continue. I think the parent/child relationship is very important. I think it does need to be maintained. I don’t know if it’s a static relationship or a dynamic relationship. I’d have to think about that. But I do think about that. But I do think it’s very important to maintain that. So the question is, and this is why we’re having this conversation. What does need to be maintained? And what information do you need to try it? So that you need to know what you need to do. And I’m happy to continue to have conversation. I don’t know right now. But it’s a great question. Corrine
MR. CORRINE HAYWORTH: Corrine Hayworth, (inaudible) comment about classification. One of the challenges with classification ... I’ve been working with a couple of industry groups talking about classification ... is that very different stakeholders have very different ideas of what they mean by classification. And the difficulty in having one database to work from is if you use any particular classification model, then you exclude others. And then you have interoperability issues. And so if you have multiples, the problem then becomes that you have the responsibility falling on some stakeholder to classify correctly multiple models. And that could proliferate to ad infinitum. Let’s just take a global type example where maybe an English classification system will not do in the case of France. So classification is a really thorny issue. And until we can come to some consensus as an industry of what we might want, it might be best to use something that is used for say the FDA’s purposes. And I’ll leave it at that.
MS: Great. Last question.
MS: Thank you. Yes, I remember working at an old spitfire. And the manual said get a twelve millimeter spanner. And I had to figure out that they meant wrench. So that’s a good classification example. Where does the master database live? And that may sound like an obvious question. The reason I ask it is as a provider, I could subscribe to a drug file. First Databank, for example, is a company that’s prominent in that area. And they do some value added classifications such as if two drugs are equivalent. So have you had any thoughts to third party companies taking this database, doing value added things to it? And does that cloud the water for classification, you know, the data elements, terminology and so on? What are your thoughts on that? Where do you see that going?
MS: Well, I’ll just take a stab. Again, you mentioned before, we obviously FDA and NDC. So we understand that space. And I do envision that there would be a master database. But that third parties like First Databank or others would get into the business of taking the data and adding value and reselling it. And that’s fine. I mean, that’s a fine model. So I do envision that that could happen, would happen. That’s great. Master data would be FDA’s. But in the same way that we publish it ... if that’s the right word, M.J. ... for others to use in the NDC space, we would do the same thing in the device space.
MS: Thank you, very much.
MS: My response is going to be I think from a provider, the provider’s always going to have to own and validate its database because of the patient care liability issues and so forth. So I think the UDI or other databases are more supplemental to facilitate keeping that data accurate and timely. And again, serving as a standard for synchronization. But I think on a brighter level, you have to own that database. And I don’t mean, I’m not talking about ownership for profit of selling the data. I’m talking about ownership for profit of selling the data. I’m talking about owning its validity and accuracy.
MS: Thank you. Okay. Two more. This is it though. So quick.
FS: This is probably a tie onto the gentleman over there who talked about the capital equipment. I don’t know whether anybody’s put any thought to this about reprocessed items and how they would be handled. And maybe the answer maybe that they’re not. So if you reprocess, you have to handle that separately in a different system. I just think it’s important for somebody to think about that. And whether that has to be a consideration at some level.
MS: We thought about it. Do you mean single use or reasonable process? Single use. Okay, yeah. We can talk about that later. That’s a whole other issue.
MR. MARK LEAHEY: Mark Leahey with the Medical Device Manufacturers Association. Again, from our perspective, I think obviously focusing on patient safety is key. And I think obviously FDA is best suited to oversee the information across the country. I think the one concern, from this panel at least, it seems to be more oriented towards e-transactions and e-commerce. And I think, you know, again, representing small companies, you want to make sure that this UDI system doesn’t create particularly by GPOs, for example, a tool for them to drive compliance for their contract and vendors and exclude other companies or exclude physicians or patients from getting access to those products. So we certainly support FDA using this data to monitor products throughout the supply chain. And wouldn’t want to see it be used by certain third parties to exclude patients or physicians from gaining access to those products.
(END OF TRANSCRIPT)
Updated March 9, 2009
CDRH Home Page | CDRH A-Z Index | Contact CDRH | Accessibility | Disclaimer
FDA Home Page | Search FDA Site | FDA A-Z Index | Contact FDA | HHS Home Page
Center for Devices and Radiological Health / CDRH
