• Decrease font size
  • Return font size to normal
  • Increase font size
U.S. Department of Health and Human Services

Medical Devices

  • Print
  • Share
  • E-mail

Unique Device Identification (UDI) for Postmarket Surveillance and Compliance Public Workshop, September 12-13, 2011 - Transcripts


Day 1

>> Jay Crowley: All right, Good Afternoon, and Welcome. Thank you all for coming. My name is Jay Crowley with the U.S. Food and Drug Administration, and you are at the UDI for Postmarket Surveillance Compliance Public Workshop. If that's not your cup of tea perhaps there's another meeting here for you. Welcome everyone on the webcast; just want to remind everyone this entire session is being video taped and audio taped, so you are forewarned. And hopefully we have quite a few people watching on the webcast, as well. To get us starting, I would like to invite Dr. Jeff Shuren, Director for Devices and Radiological Health to open our session and give us some opening remarks. (Applause)

>> Jeff Shuren: Thank you, Jay, good afternoon and welcome to all of you here in person and the many of you who are watching by webcast. I'm happy to see so many of you could make it to public work shop on the subject of unique identification. Today we have a wide variety of EH vendors, clinical community, and vendors. We're working -- to establish unique device system for medical devices. I recognize that many of you have been waiting for this regulation for a long time, so have we. However, because UDI is new and applies to all device types we have been careful to craft a proposed regulation that meets the needs of our stakeholders as well as ourselves and minimizes the burdens on device industry to comply. Because this meeting is focused on the incorporation of UDIs into appropriate datasets we will not discuss the proposed rule, and in fact the proposed rule isn't even out so we can't talk about it yet. However, Jay Crowley will provide a high level overview of the UDI system during his opening remarks. There are many numerous potential benefits for patient safety and public health to properly implement the UDI system. The purpose of UDI is to allow all stakeholders to unambiguously and consistently identify medical devices throughout the supply chain up to the point of patient use and throughout the device's life cycle. And the incorporation of UDI and its associated data elements in health related electronic databases and health-related data standards will be the foundation for a host of benefits - including postmarket surveillance, more efficient device recalls, better reporting and understanding of device related adverse events and product problems, better device identification registries, and more robust data collection from clinical practice generally that can be used to better understand a device's benefit/risk profile in the real world and generate information that can support future pre market approvals and clearances. And as it relates to this workshop we expect that UDI will provide a mechanism for documenting specific device use in patients' electronic health records. There are also a number of other benefits, including improvements in tracking and tracing, supply chain security, identifying device for disaster, terror preparation, and device shortages, anti-counterfeiting and diversion, and reducing medical errors. In addition, UDI will provide an easily accessible source of device identification information to patients and health care professionals. Establishment of the UDI system is also of critical importance in fulfilling the promise of robust multi-faceted postmarket surveillance effort. Health related electronic data from large data sources such as insurers and integrated health care systems contains a wealth of public health information that could be harnessed to contribute to the understanding of device safety and effectiveness, and improving the benefit-risk profile of medical devices. Currently, however, these data, absent UDI, cannot be used to identify device- specific exposures in patients because of the lack of unambiguous standardized device information. This is not the case for drug exposure, where the regular documentation of NDC numbers allows for robust analysis of pharmaceutical safety and effectiveness. Such information for devices and a vast amount of potentially useful data regarding patient safety and health outcomes remains untapped. FDA is continuing to work towards the best public health use of health-related electronic data that incorporates UDIs and leverages existing procedure and device registries. And this public workshop is one very important piece of that strategy. The purpose of this public workshop and your charge over the next day and a half is to help to begin to develop a national strategy, incorporating UDIs into appropriate electronic datasets. That is, what are the key next steps to bring this vision to life, including barriers to remove or reduce incentives, the roles and activities of various stakeholders including government, and any other issues or concerns that could affect that work. As repositories are important to health information, hospitals play a vital role in the adoption and implementation of UDI. This requires a cross-cutting approach, which integrates information across a number of hospital systems, including supply chain, clinical, and reimbursement. Currently, these systems and processes are fragmented and will inhibit the use of UDI in its use in electronic data. Therefore it's critical that health care facilities actively participate in this work. FDA would like to accelerate the documentation, implementation and use of UDI in these various health related electronic data systems and we need your help to make this happen. So thank you for being part of today's events, and good luck to you over the coming 36 hours. Thank you. (Applause)

>> Jay Crowley: All right, thank you, Dr. Shuren. There is our charge and I hope everyone is up for the next day and a half's activities. My hope and as we put this meeting together, you know, we really had some great ideas, we have some great speakers, some great panels here, we're hoping that this is a very interactive meeting. So I ask you, I request, that you bring your questions, your issues or concerns, forward. I will go into a little bit more detail but there are 6 panels that I'm sure you're aware of and we have left plenty of time, actually a lot of time, for discussion both amongst the panel and with the audience. For purposes of the meeting, of course, I ask that you do come up to one of the microphones, one of the four microphones, there's two on either end and two in the center, please identify yourself, and then ask your question. And so that everyone can hear it. So with that, I'm going to go into a little bit of background, just so that -- to level -- set this and make sure we all understand what UDI is and what it is not, where we are going with it, and ultimately, what the purpose of this meeting is. As Dr. Shuren mentioned, and as many of you know, that I've been working for many years on this - the UDI proposed regulation is close to coming out. We continue to work through some final details but hope it's out soon. But for those who have seen this before, the sort of how UDI will work hasn't changed. This is sort of my world view; this is what happens to medical devices after they leave the device manufacturer. And for those of you who haven't seen this eye chart before it's a bit to take in, but this is the reality of the situation. We lose visibility right now; we don't really know where devices are at any given time. Not at any granular level not any specific level, and we really don't know what devices are used on patients except in the rare occasion where they're documented in such a way that we can. So what we're trying to do is bring some visibility to this challenge right now, with UDI, so that as Dr. Shuren mentioned, we're all talking about a device in exactly the same way. And on some level, this isn't rocket science; we do it with all products with NDC numbers. People in the retail space have been doing this for many, many years, so this is what we want to do with medical devices. There are some unique challenges that you know the proposed rule takes on, but we do think we can definitely do this. And you can see, I think, in the end there are some benefits that particularly FDA and many of the people in this room are interested in when we start talking about adverse event reporting, postmarket surveillance, FDA Sentinel that Dr. Gross will mention. This is with we're hoping UDI will really bring us a lot of benefits. Mentioned NDC numbers, I'm sure you're all familiar with them, originally started by what is now CMS, and taken over by FDA in the early 70s and originally intended to facilitate the reimbursement of all products. Obviously, the use of NDC numbers has created a host of benefits well beyond that original charge. For example, with the post IOM FDA bar coding rule we now have NDC numbers encoded in linear bar codes to support bar code medication administration systems - just one of the many benefits our standardized identifier has brought. And for medical devices we're not quite there, we do -- if manufacturers are using standards, sometimes they use them appropriately, sometimes they don't. The numbers are not necessarily unique or unambiguous. They don't include all the levels of uniqueness that we necessarily need to identify devices. And what this has created is sort of a cascade of events that by which other people downstream - the device manufacturer can't rely on the numbers that are coming to them from the manufacturer, and they create their own numbering system, so you have distributors with their own numbering systems, you have hospitals with their own numbering systems, you have reimbursers with their own coding sets. We have lots of coding sets, we have lots of numbers, they don't talk to one another, it's very difficult to use. So what we hope with UDI and the UDI database is we have a single way of identifying a device and a single dataset associated with it that everybody downstream can actually use. And this is what we're hoping for, a consistent unambiguous standardized identification system that is unique at all levels, and importantly, and though maybe not for everyone in this room, but for many of us who have been working on it that is harmonize globally. For those of you who don't know, we've been working on a UDI system that provides not only a U.S. numbering system but a global numbering system, a global identification, so the number that's put on that device is the same and can be used and has the same meaning throughout the world. It's a big challenge, but one that we're making very good progress on. Just to be clear, medical devices, for those of you who are not familiar, covers an extremely wide range of products from an FDA perspective, all over the traditional devices we think about all the hospital based equipment, ventilate Erin fusion pumps beds, etc. All the implants many of you are familiar with but also a whole host of other products that maybe you don't think about as traditionally being medical devices, at least from FDA's perspective. So we have all the home-use devices, all the patient use devices, a lot of devices that are used , a lot of products used in the dental space, most products that you see in clinical labs or point of care clinical testing, certain parts of health information technology, also medical devices. So it's a very wide array of products and the UDI system is intended to apply to all of these types of products. Dr. Shuren touched on this, a lot of benefits to UDI, we think. Obviously, when you have that visibility and that traceability you can start to do lots of things we can't do right now. From FDA's perspective we're obviously interested in more efficient, more effective recalls, improving our adverse event reporting system. We get reports and we don't know which device we're getting reported on, it makes aggregation a challenge. A host of other benefits – obviously, there are a lot of events in supply chain security, right now, trying to avoid counterfeits, this sort of thing once you have a fundamental way to identify products you can start to accrue these benefits. In addition, segueing into this meeting UDI can provide other benefits, we can talk about identifying a specific device and registries which can lead to other studies that can be done for example documenting device used in patients personal health records, trying to get that a information in there, claims status Dr. Shuren mentioned; Dr. Gross will talk about other postmarket activities in the center, for example the Sentinel initiative. For those of you that don't know we've been working on UDI for some time. We received this mandate in 2007 in FDA, pretty straightforward that have taken us time to define a system. I'm going to spend a few minutes, very high level overview of what UDI is and how it's going to work. UDI is the responsibility of device manufacturer; the device manufacturers are to create a UDI code according to currently available device identification standards. This is in contrast to what occurs in the pharmaceutical space where often each country or each regulator has their own numbering system so you come to the U.S., you get an NDC number, you go to German you get a PDZ number, etc. Going back to that global harmonization we can't want a global standard we can use in any country. So the device manufacturers create a code according to the standards, and importantly there are two device identifiers - device identifier similar to a UPC number and identifying it as being one of these things, you know, it's a different -- smaller bottle will have a different number than a larger bottle it works very much the same way, and production identifiers are the serial numbers lot numbers, expiration date however that process ‘is currently controlled’ becomes part of the UDI. Device identifier and production identifier bring those two pieces together on the label device, and you have the device's full UDI. The UDI is applied to the device and to all levels of packaging. So you take a catheter package of one has a UDI, you put it in a box - the box has a different number, etc., and again all this is intended to promote its use throughout the distribution of the device . The UDI is both human-readable and encoded in some form of auto ID, bar code, two dimensional bar code, we're not going to dictate. I'm sure there are kinds of technologies, and I'm sure this will all play out very naturally. There will be direct part marking for devices this is where you put the UDI on the device itself where the need to know that identifier exists well after you remove that product from its package. So you think about reusable surgical instruments, certain implants where you really want to know the identifier of that device long after it's been removed. So there are part marking for certain devices. A picture is worth a thousand words, can you see that? Thank you to my friends at Medtronic. The bottom lower left is a linear bar code. I hope you all can see it, it's a bunch of vertical lines, you know what a linear bar code looks like and there's a bunch of numbers underneath it. If you had your decode ring you would see that's a code identifier, which is the part that follows the parenthetical 01. There's a lot number and serial number for this product so the information that follows the parenthetical 17 and 31 is the lot number and serial number for that device and that information is encoded in that linear bar code. That's it. Not very exciting. That's UDI, that's how it works, that's what it looks like. Another example, maybe one you can read a little bit better, again you've got a linear bar code and some information underneath of it you've got a device identifier and a lot number, and an expiration date in this case just a different set of information, same kind of thing. If you scan that, that's the information that you would get out of it. So we talked about Batman decoder rings. In order to get some meaning out of the UDI we are developing the UDI database. Remember we talked about device identifiers and production identifiers, so the database does not have any production information in it, the production identifier serial numbers are only on the label or on the device itself. The database contains static information about that particular product. So you look up the device identifier, and this is the kind of information that you can find in the public database. What is it, manufacturer make model those kinds of things how is the product controlled, do I expect to find a serial number or lot number on it, who do I call if I have problems. GMDN is the Global Medical Device Nomenclature. It is as the name implies a nomenclature - we have been working on it - is a way to identify the device. There's other information in the database to help users use the product appropriately, how does it need to be stored, does it contain latex, is the package sterile - these kinds of things the user as they're receiving the product can better manage the product in distribution and use. Just sort of close the loop on this, implementation is phased in by premarket risk class. So FDA classifies all medical devices according to one of three premarket risk class, class 3 is our highest risk products and those are the ones that would be implemented first with UDI, so one year after implementation of the final rule, so we talk about the proposed rule coming out relatively soon, probably say a year from now for the final rule, and then a year after that for implementation of class 3 products. So we're still two years out until we see implementation initially for class 3 products. Class two products, ventilators infusion pumps those kinds of things two years after that, and class 1, most of your disposables, two years after that. Just to be clear again because I don't want any confusion about what UDI is and what the database is, UDI is a foundational element, and this is the standardized way that we're going to identify all devices. As Dr. Shuren mentioned, we really need all stakeholders to use this system otherwise we don't accrue the benefits we'd like to see. FDA regulates device manufacturers but, we don't have any authority over hospitals who distribute this, but hopefully they'll see the value and start to use it as well. The database does not contain production information, that information is going to be stored when a hospital or distributor scans that product and pulls that information into their database, that's where the information gets stored, and then that gets transferred say into a patient's electronic health record other clinical information systems. That's where you see the storing of the production information, not in FDA's UDI database. And that brings us to this workshop. Dr. Shuren gave us our charge, we're really here to talk about next steps, where we are today and where are we going and how are we going to get there. So I'm hoping that everyone has some great ideas and is willing to share those with us. This is how it's going to work we're going to have 6 panels. I hope you all have an agenda. If you don't, Diana has those outside. Today and for tomorrow they're all going to call each the same format we're going to have a number of panelists 5, 6, 7 panelists a few of them will give some opening remarks sort of to set the stage, and as I mentioned before, we're going to leave plenty of time for questions, answers, discussion, debate. Again we're really trying to generate interest, ideas, how are we going to do this. I mean we're really very much interested in trying to move this adoption curve forward. I'm sure this would happen organically over the next 15 years. We'd like to see it happen a whole lot quicker than that. That's really what we're here to do today, push this forward. Just 6 panels so you understand - we hope. The first one here is going to talk about documenting device use, using UDI in electronic health records, next we're going to talk about the role of UDIs in device registries, so those are today's two panels. Tomorrow morning we'll start off with UDI's role in national and local data standards; we'll talk about integrating UDI throughout the hospital, as Dr. Shuren mentioned we have to move from UDI being something that's only supply chain, to clinical, to reimbursement, we're going to talk about how to push this information through these systems. Dr. Gross will talk about UDI for postmarket surveillance and compliance, and finally Dr. Fotsch will talk about UDIs and personal health records, the last panel of the day. I'll tell you it's going to be a very exciting panel I hope you all stay here for the end because I think it will be a lot of fun. This is website and e-mail address where we post our UDI so if you're looking for anything or want to see what we've done in the past I'd invite you to take a look. If you have any questions about UDI, please feel free to e-mail me at this e-mail address. And with that I'd thank you all for being here and I'd like Dr. Gross to come up and give us some opening remarks. (Applause)

>> Thomas Gross: Good afternoon, everyone. I'd like to add my welcome to all of you here and all of you joining us via the webcast, for this important public workshop. I sincerely hope that it's a first in the series of FDA- sponsored workshops to begin to address the multitude of issues attending UDI adoption, implementation and use. I've titled my talk UDI in the service of public health, a call to action, because I fundamentally believe that UDI is an essential tool to help FDA fulfill its public health mission i.e., to promote and protect the public health. And I also believe that all of you, as important stakeholders have a critical role to play in this endeavor. Now, these are the topics I'll briefly touch upon during my presentation. First, UDI is a key enabler of postmarket surveillance and compliance activities. Second, a world without UDI poses postmarket challenges. Third, FDA efforts to facilitate and explore use of UDI, and lastly, putting the puzzle together. UDIs are a critical piece of the national infrastructure, but it's only one element of several others that have to be put into place to have a robust postmarket surveillance system. Now, by UDI as an enabler, I mean that UDI has the potential to unlock vast amounts of information housed in a database of data sources on medical device performance. And over the next day and a half, you'll hear testimony from data owners to that effect. UDI also has the potential to facilitate linking across various data sources, there by amplifying the utility of each. We're all too aware of electronic and other data sources sitting in silos, disconnected, not linked, and therefore not optimally used. Now, this is a high-level view of the postmarket challenges in a world without UDI. Dr. Shuren and Jay touched upon some of these and over the next day and a half you'll hear from stakeholders and presenters in much more detail in their respective domains that speak to these issues and others. So what is a world without UDI in terms of adverse event reports? It certainly hampers signal detection capabilities; this is true at FDA where many reports do not have brand-specific identifiers, for instance. So it hampers our trending and data mining capabilities. A world without UDI hampers the timeliness and effectiveness of recalls. The data sources sit in silos; they're disconnected and therefore hamper timely recalls. We've touched upon registries. By and large registries today are procedure-based registries, adding device information is an afterthought. With the advent of UDI, we hope that this information can be built into registries and make them much more useful. And then lastly, electronic health care records. There's limited exposure information in these records, identifiers typically are not documented, nor accessible. And again, there are no national standards for incorporation of UDI into these important data sources. Now, claims data are another important data type or data source, and they too have their own postmarket challenges. The level of granularity offered by claims data is often insufficient. As you know, claims data are used for billing procedures and its diagnosis and procedure codes that gets billed and thus claims capture procedure codes. So for instance, cisti seal repair is a procedure that can be billed for, it involves device implementation but that's not captured in the procedure code. There were procedure coast that capture device information, such as insert synthetic graft, but again it's at a device type level not a manufacturer level, not a brand specific level. Occasionally, and rarely, we'll get a device a unique code for a device that is first to hit the market. So for instance, drug eluting stents, where the code can point to that particular device and that particular manufacturer. And of course with the advent of UDI this will open up this very important data source for manufacture specific and brand-specific investigations. Now, claims data, having said that, are still used by FDA, in its postmarket initiatives, and I've mentioned two here. The Sentinel initiative is an active surveillance initiative which is looking at realtime monitoring and exposure cohorts. So for instance, drug eluting stents and the rate of coronary thrombosis. To the extent that these efforts rely on claims-based data sources we run into the same problems, i.e., lack of specific identifiers, and in that case, we cannot do active surveillance across manufacturers or brands of devices. Similar situation exists for part of our evidence synthesis efforts, which are there to combine data from disparate data sources such as clinical trial registry and claims-based data sources. The type of synthesis that we can do currently is at the device-type level for reasons just previously mentioned. Now, briefly I'd like to touch upon a few FDA efforts that we hope to embark on within the next few months to the next couple of years. First and foremost, is develop a road map through workshops like this and other stakeholder meetings as well as white papers hall -- that will help to inform all significant stakeholders about the intention with the documentation and use of UDI. Secondly, we hope to facilitate demonstration projects first and foremost in hospital environment because hospital care is so critical to understanding device performance. We'll look at hospital systems as they integrate or don't integrate device- specific information. One of the barriers -- what are the barriers to that implementation, incentives how are systems that are connected within hospitals be scaleable to hospital systems, and health information exchanges. And lastly, we'll look at device attributes and their evidence-based use. It's extremely important, as has been said already, that we have UDIs incorporated into electronic health care records, but it's also important that we understand, by device type the attributes related to that device type that may affect device performance. So for instance, if you look at total hip implants, their attributes such as femoral head size, femoral neck angulation or bearing cup articulation that may affect device performance. Those attributes have to be identified and they have to be linked to unique device identifiers, so those attributes could be studied across device types, again to look at device performance. Now, Jay has already mentioned the workshop topics, and by now you're very familiar with those. These are the workshop topics that we'll engage. There are several themes that will cut across these topics. What is the current state, what are the barriers that currently exist impeding development of UDI-based surveillance, what are the opportunities, and what are the visions for the future in each of these domains. And this really covers the waterfront but we felt it important to do so because by tackling all of these issues, we can indeed develop a robust postmarket surveillance system. Lastly, better public health through incorporation of UDI. As I stated initially, UDI is an important element, it's necessary but not sufficient for a robust postmarket surveillance system. There are certainly other important elements that feed into this. The development of electronic health care records, development of standards, methods development, and addressing issues of access and privacy, they're all important if we're to make full use of electronic health care records. And on that note I think we're ready to kick this off. Thank you. (Applause)

>> Jay Crowley: All right, thank you Dr. Gross. If I could have panel 1 come on down. Okay, so as I mentioned before, here is how this is going to work. We're going to have a couple of the panelists come up and give us some presentations, short presentations about what they're doing, what they see the issues are, and then we'll move into sort of a larger discussion around the issues. So with that, I would like to introduce our first panelist who will give us a presentation, Kristine Martin Anderson leads Booz Allen’s Health Implementation, Affordable Care Act. Before joining Booz, she was at Strategies Care that she helped launch in 2000.

>> Kristine Martin Anderson: Thanks very much. Thanks for having me. That introduction tells you exactly nothing about why I'm standing here. So these set of slides I think will do that a little bit better. I wanted to start by telling you a little bit about, as they asked me to, some work we had done with the FDA last year around evaluating potential data sources for the Sentinel initiative, and this is work that was done largely the data was mostly collected between March and April of last year, so those of us that are involved with electronic health records and data storage systems you know that it's ancient by now. So this particular report was supporting the standup of the Sentinel initiative and trying to understand what were some of the data sources that were available in order to support postmarket surveillance. And our goal really was to try to survey industry and find out what type of data was being collected, and some very detailed information, the survey is actually available on line and it dives quite deep into even you know what are the missing data rates and how often is the scale actually populated in the dataset. And we did include some device information in there, so that's how it all fits together. And as you know, the Sentinel initiative is trying to support near real-time vufrls so the needs for data -- surveillance so the needs are rather large for data availability. The survey itself had about 200 questions, we targeted 246 organizations but it was also announced, the Sentinel initiative, in order for others who wanted to come online and fill out the survey, and it was open, so others could fill out the survey as well. There were 10 questions that were specifically targeted toward devices. We got about 50 organizations reply, so it's a relatively small sample size, but it's a unique sample. And so we'll talk a little about that. And we'll go through some of the quick results. The way that the survey itself was structured was really to try to get at some very general information first. As I mentioned, since this is targeted for the Sentinel initiative, the size of population mattered so we were trying to understand how big was the group of patients that are represented in the data source. The degree of capture. The duration of the longitudinal capture of the data, in other words, how long -- how much information over what period of time did you have about individuals in it. We touched on structure and coding, which is very applicable here, completeness, timeliness, accessibility of the data, the level of data that was available to assess the temporal relationship between the time that care was delivered and the time that you might have an adverse outcome. And then also, some potential limitations if these data sources were to be used for product safety surveillance. So the types of organizations that were targeted in responding was quite large as you can see. As I mentioned these are population based data sources. On average -- I won't say on average, the median number of unique patients per data source for the respondents was over a million. Unique patients. The number of sufficient to median was 10,000 greater than 10,000, and for the number of unique encounters the number was 5 million these were large data source there were some smaller ones in there but for the most part the research networks were aggregated claims systems, hospitals large IDMs -- IDNs, vendors, registries, etc., were replying to the survey. We had a question in there that asked whether or not specific fields or data types were available in the data source, and this report is also available in the public domain. And we asked questions around -- four devices product codes, device type, manufacturer brand, model, and you can see in the blue, the blue answers are yeses, and the reds are nos, and then there's a bunch of not applicable for -- in some cases we're talking to large labs, and they maybe didn't see this question as applicable. We got a lot of in the text fields that, it depends. And it depends usually says what do you mean by a device, which I think is a question that is to be clarified. And there were some -- it depends, in terms of what you might mean by identifies. So this is something that was very familiar to me, in my world at care science, before I came to Booz Allen, we were measuring doctor and hospital quality and then also tracking resourcing patterns in hospitals that led to specific outcomes. And in that world we were collecting for a long time a lot of drug information, lab information, device information, and what we found was that there were a lot of very deliberate coding rules that applied to serve other business purposes, that obscured a lot of data, if your purpose was to track safety. So I think that it depends really is around why did they create this data source to begin with, and what did they find valuable at that particular time. So that seemed to make a lot of sense to me. So that said, I think the yeses and the nos, the yeses are probably overstates I guess I would put it based on past experience and I guess that's true if you look around the individual questions around, are all the devices included, 19 said yes, it depends on their definition of a device. And then there were comments that said only those devices that are surgically implanted, and only through links with quis region stries, so it really depends. Is the device information linked to the medical record. We had 13 yeses of the 49 responses. And, can it be linked, you know, it went up to 20. And again, there were some examples of how their secondary use database links device information if it's documented by a clinician, it's possible, but we have to look it up in the chart. We have some information that could link it, but it's not going to be automatically linked. And then also is the device information linked or could it be linked to claims data. You know, there were a lot of responses that made sense around the fact that some devices were relevant to their claims process, and some were not. And so you would find some difference there. And again, this reminded me quite a bit of my past life where we were trying to look at drug information, and while most of the hospitals we worked with had an NDC code somewhere in the hospital, usually in the pharmacy information system, its purpose of migrating through to other data sources, it generally did not. Because those were analytic data sources and so what they really cared about was rolling up and rolling down this idea of aggregation and disaggregation. And there were also some very practical considerations that I'm sure would apply to devices as well, in fact I've heard them applied to devices as well that says, we don't really want that showing up when a physician does the order. And I'll tell you why. I don't want them getting involved in which brand I buy. I really only want them telling me what they need for the patient. And in our culture, if I put it on there, they will -- they might be influenced to choose certain things, and they don't maybe have all the information, and the way our supply chain system works we change that all the time, and we don't want to alarm people when we make changes that we feel strongly about, so we intentionally keep it out of all of our transaction systems, so it doesn't interfere with what we really want to have happen with our formulary, or with our device strategy, or with our materials management process. And I'm sure that that's going to be a challenge, because you need it, and you need it linkable, but I do think there's a question around electronic health records of how much you have to bring in and expose in the record, versus what you have to be able to link to the record, and how you get it. So I'm a big fan of health IT in large and not over prescribing your individual hopes and dreams all on the electronic health record itself. And so I don't know the answer to it with devices, but I know that it's likely to be the same type of an issue. And then just kind of thinking about coding systems, I didn't put this one in here but then I went back and looked up some of the data, and we had a question in the survey that asked about -- in this case it was on drugs, where you do have a coding system, and said, what coding system do you use. And interestingly, of those who answered the question, none of them said NDC code right they had first data bank, etc, and it reflected the purpose of those datasets. Also interestingly when the question was asked just about the dataset itself, what coding standards do you use, where we had - went through lot of effort to make sure we had a lot of different coding standards, everything from older coding standards up to HL 7, etc, for what we found is that most of the responses were blank, or none. And that gets to a different issue, which is around education, around knowing, you know, what the source of these codes are that you see. It's generally not something that if you don't work in data management or if you're not a person who is doing search, you don't really much care what that code stands for. So we found even some of the owners of the dataset weren't aware -- I'm certain none of them are no code sets in there, right? But more than half of the records the responses were that. So I think we have a lot to learn about once you create it how do you get it used and I think there's lots of great examples in health care of that. My one hope is that it's -- the communication and the articulation of the value is, in this case, able to get out in front of the implementation. And that I think can help a lot. Because I think a lot of the other coding systems suffered from that. So thank you. (Applause.)

>> Jay Crowley: Thank you, Kristine, great points, things we need to learn. Next, Tami box, Lead in clinical resourcing and tracking program, VA web solutions in the new VA office of informatics and analytics, with 16 years in the department she's helped with cardiac surge, and since 2003, cardiology. So Tami. -- forget health IT, I can't get this IT to work. That -- no, no. Is that the right one?

>> Tami Box: Perfect. Good afternoon. It's great to be here and thank you for the opportunity to speak on behalf of the Veterans health administration and the CART program the clinical assessment reporting and tracking program I've obviously said that a lot of times so it rolls right off the tongue. My colleague, Dr. Paul Ross, will be introducing in the second panel. Today I want you to know there is a small bit of overlap between the things we're going to talk about his perspective is a little bit different but just in case you had a really big lunch and you fall asleep for the next 10 minutes or so you'll have a second chance to get a little more information maybe from a different angle. So I'm admittedly biased but the VA has been a leader in health IT for quite a long time. We've had an electronic health record system in some form, some shape, since really the 1980s. But properly, with a front-end graphical user interface since the 90s, and we were the first major healthcare to broadly adopt an electronic health record system and we're moving that system from an EHR to incorporating the -- EHR to incorporating the values, and concepts behind learning a health system, and evolving our system into a health management platform in fact. So with this broad history behind us what we have achieved is a huge pile of data, and currently we have tens of billions of individual data pieces and billions of free text clinical reports. So this positions us to always be interested in surveillance, and looking at patient safety efforts, and using our system prospectively. I want to mention in terms of recalls and alerts we have a national center for patient safety, and they do a wonderful job keeping us all in check. So I can't speak authoritatively in broad detail to all the device surveillance activities in the VA, there's probably too many to recount. However, I've chosen 3 use case from my wheel house which happens to be in cardiology IT. So today I'm going to talk about the Veterans implant tracking and alert system V ATAS, national cardiac device surveillance program and clinical assessment reporting and tracking program or CART. Just recently, secretary Eric Senseki set out 16 major initiatives to guide the VA through the next 5 to 10 years of health care delivery and innovation. And as part of one of those initiatives, specifically the enhanced Veterans experience and enactment initiative there's another one called VITAS, Veterans implant tracking and alert system, this is to track all implanted devices either whether they were implanted in the VA or outside of the VA, and ideally it's the look at better disseminating recalls and looking into clinical issues. Currently, we are linking a number of different clinical domains, cardiology, radiology, ophthalmology, orthopedics, prosthetics and surgery, in the first iteration of this system. So the idea here is that we can take these disparate silos of information and pull them together into one centralized repository, so that a provider has that as their authoritative record that they can look at that and see all the various devices that are impacting a specific patient. Now it's not intended to take place of other implant tracking system, like what you'll see with CART and what you'll see with the cardiac device surveillance program, however, it's intended to be a way to pull all of this information together. So already you're probably hearing in the back of your head gosh it would be great if they had a unique device identification system to link beyond the patient record. So the system right now is a web-based GUI, and it's also in the next implementation going to be accessible directly to the electronic health record system. A key limitation, however, is that a lot of this information is manually data entered. So there's a lot of opportunity for error and redundancy. The national cardiac device surveillance program is centered in San Francisco and led by Dr. Ed Chung and this particular surveillance program monitors cardiac implantable devices, so pacemakers, ICDs, CRTs. I'm going to geek out just a little bit, here. I think it's utterly fascinating how they track some of the devices. Effectively, a veteran can hold up the phone to their chest and have that device communicate through transtelephonic monitoring and transmit information. And this is important because our Veterans are all over the country, geographically disperse ed and they're only specific centers that are able to do some of these higher level implantable procedures. So the national cardiac device surveillance program tracks 18,000 patients plus who have these types of devices, and that transtelephonic monitoring. I mentioned there are at least 75,000 ICD transmissions being tracked through that process. This program has been very successful, and it has been wonderful in terms of being able to alert people in the network and patients regarding recalls, and other issues like that. Again, we have a limitation that we don't have a UDI involved and we also have primarily manual data entry, again. Now, to my specific wheelhouse, the main role that I play in the VA is as a health IT lead for this CART program. CART is a quality improvement program, in patient care program, and at its foundation is a cardiovascular information system that was developed by VA providers. And it took the place of their normal doums method which was dictation. The beauty of this system, and I think its two fold is it number one, a technical model, it's actually a mental model, I believe and we've applied it already to a number of domains. Number two - the CART model a point of care model. So the fields that the providers are entering are entered as they're doing the procedures. The old way of doing things, was the provider would finish the procedure, often do dictation that would go into a vacuum, and end up in the patient record 30 days later. That doesn't allow to you do prospective anything. And you're reacting to all the different things that happen with the patient. We started CART in 2004, and the number varies, we have about 80 cath labs throughout the United States in the VA, 76 are currently active, so knowing early on we have the care I believe data force we spoke with FDA -- extensible data source we spoke with FDA and tried to engage the CART program to be a Sentinel network for cardiac cath labs in the VA. What we did was we modified our implication interface to include a place where there would be a free text report for any unexpected problems with devices, and we solidified our partnership with FDA in the end of 2008, with a memorandum of understanding. This is just an example of our initial screen where we were capturing unexpected problems with devices. And I've blown up the little section of the screen so you can see it better. As we share data with the FDA and discuss these problems with them on a monthly basis, we define three levels to exchange data. And I'll just rapidly go through these. Level one is what I call a lot of noise. And we like the noise, because sometimes you see -- you know, a diamond in the rough and you want to investigate that. But there's a lot of noise in the level 1 data. Level 2 means that either the CART program or the FDA has looked at the free text report or thought there might be something to it related to a problem, a real problem with the device. And then level 3 is something that is very likely related to a device and should be reported through the med watch system. So this is an example of what we look for, this is a real report, and this is what we would call a level 3 report, regarding a delivery system that malfunctioned. And I'll let you read that for yourselves. And this is just a little bit of sample data geographically visualized of some of our early data when we started this program and where we were seeing the reports coming from. Last year, we added two additional places to record unexpected problems with devices, both on our interventional screen and also on our diagnostic screen. And then we also implemented an automatic alert. So when the report is filed right after the procedure, our information system will alert us if, via secure e-mail, if someone checked off that there was an unexpected problem with a device so we're able to immediately adjudicate those and get in touch with a provider, because as you notice all we have is a free text field. There are a lot of limitations with us. We very rarely get to the granular level we need like serial numbers, and model numbers and lot numbers. Since we started this effort we've looked at well over 200,000 procedure reports and filtered those down to find somewhere over -- these are approximate numbers, tom Gross has worked with us for years on this, I'm sure he's think willing well have I really looked at 825 of these? It's actually more because this is just your may. But we've actually looked at that many reports which results in probably close to 150 we've dug into deeper and tried to get more information to see if it needs to get reported through the medwatch system. So as of May this year, probably 20 to 30, we think should be reported. And those are small numbers for such a large health care system but they're extremely important to the VA and also to the CART program and also I believe to FDA as well. From these 3 use cases I've just laid out, you can tell that there are some significant limitations. We do have the siloed data, we do have the burden of the manual entry, we also have free text data coming in, which is hard to parse at times because people write it in whatever way they want. And then we have mixed record identifiers. What I mean there is something that's important to cardiology and related to a device in a cath lab might be recorded differently as it relates to cardiac surgery just because of the clinical perspective. So this complicates the way we can exchange data. We do have unique identification of devices, in many of our datasets but it's hard to combine those in a meaningful way without introducing errors and redundancy. And this prohibits us from doing a very good job of prospectively being able to predictively model event outliers, and we have some very exciting research that we're going to engage in, in VA cardiology though look at those things. Tomorrow Dr. Fred Resnic, will be speaking and thees doing some very exciting things in that field that we would like to implement in the VA as well. So in short, there's no guarantee that high risk patients, recalled products, or unexpected problems with devices are fully and validly captured. I just wanted to briefly walk you through something that I see as a huge opportunity for the VA as part of another of the secretary's major initiative, we are now implementing realtime locater services, and I'll be very interested to hear comments from any of you in the audience or to the webcast who are already in the process of this or have completed this as well in your organizations. I think you all know what RTLS in this crowd, so I'm probably preaching to the choir, but I think it's fantastic. We're very excited, because in the initiative they identified four areas to implement RTLS. 3 of them were the usual suspects of equipment monitoring, and temperature control . SPD. The fourth was cath labs. The reason for that is because the stuff in the cath labs is very expensive. We're always at the top of the spend a lot of money column in the reports. It's important also from a patient safety perspective, obviously, for recall management and device surveillance, and we have a ripe opportunity with the CART information system, because it's very easy to integrate and pull in information and exchange information with CART. So this is how it comes around and looks like. And I apologize to my full panelists you can't see the slides. This is the only pretty one. So. This is actually a cath lab. So the idea here is that the realtime locater service, we'd be able to track the devices at the granular level we really need in order to do all the wonderful analytic things that we need to do. That data would come through CART, and then we would be able to push it out to the medical record, which I didn't list here but hopefully that's obvious because we are part of the medical record -- we'd be able to share better data with FDA to improve on our postmarket surveillance, we'd share with VITAS as well, the national cardiac device surveillance program, we'd able to inform inventory tracking and then we'd also be able to bidirectionally share information with our hemodynamic systems, which if you're not familiar with cath labs, hemodynamic systems record appellant by minute second by second all the different things that are happening in a cath lab. And looking toward the future we are already in talks and looking for four specific areas and beyond this, but in particular, incorporating granular cath lab data and CART reports into the personal health record which is called my healthy vet. We are also working with what we call in the VA IEH R which is our VA, DoD, joint electronic health record (DOD) Veterans lifetime electronic record and the nationwide health information network in order to be able to transmit some of this information oufflet VA and incorporate that when appropriate in the nationwide data as well. So I thank you again for your time and thank you for the ability, the opportunity to come and speak with you about what the VA is doing in device surveillance. (Applause)

>> ???(Speaker): So as all of you in this room know, the sophistication in the health care industry around device identification has lagged far behind other things, and my iPhone, apple, knows exactly which iPhone this is, where I am, and exactly what I'm doing with it. A lot more than any of us would like to know our own activities in Kaiser Permanente, which Jay asked me to touch on just a few specifics, we have over 250,000 devices, not counting the various home and other potential things that are out there in the Kaiser Permanente system. We own and operate soon to be 38 hospitals in California, Oregon and Hawaii, and we have our own facilities in all of our regions, many of these have a variety of devices. Less than 15 percent of these are currently on our network, or in any way, shape or form integrated. Our current integration initiative is shooting for the top three, this is not complete or even fully funded for implementation, but our targets are the physiologic monitors, ventilators and infusion pumps we're undergoing an infusion pump conversion as we speak, so that is stimulating a good deal. We have studied, though, consequences of this integration as part of the business case, and the estimate is we will have a 9 percent reduction in adverse events that actually occur. This is not the near-misses this is the actual adverse events, reduce 9 percent. And in an 8 hour nursing shift, the relief from the burden of documentation will allow each nurse to have an additional 55 minutes per 8 hour shift available for patient care. And that's an extraordinary bonus for the care of our members. We have fortunately in the audience somebody far more expert than I, but we have in addition to our electronic medical record, we have a mature registry for implants, our total joint implants are well over 100,000 in the registry. With you currently do about 17,000, or more than 17,000 total joint implants a year in our population. All of these are tracked, and Liz about share with you later a good deal of this. Unfortunately, remains manual, although we have been able to automate considerably more than we had a few years ago in that data entry. And we have published a great deal of outcomes, research from the benefit of that registry. The benefits from tracking implants include post approval studies, clinical trials, as many of you know, even when they are published and available and the data available for further analysis, they do not reflect typically the realities of clinical practice. And we know that the trials are very tightly controlled and the reality is in the patient population that is somewhat different than that in the clinical trials. The surgeons or other physicians providing care are not the same ones, they may not have had the same training, there are many other variables that are introduced, and it is very critical to track outcomes in the larger population, outside of the clinical trials, that's something we're very interested in. Recalls have been referenced as well as supply chain and procurement, and one thing I wanted to talk about for a moment is the potential for clinical decision support. And we're not trying to dictate patient care, but as many of you know, it is such an overwhelming volume of information that people are dealing with, the opportunity, if we can support our clinicians in choosing the most appropriate devices and timing for the care of our patients, would really be a huge step forward. So I called this Utopia, and in my ideal world, and I agree that we can't put everything as a burden on the electronic health record, but it seems to me that there's a great deal of potential we don't currently utilize. And it is theoretically possible to understand the demographics, the age of the patient, gender, their weight, their life style, and whether or not they smoke, other issues, what medications they're on, their family history, and then with genomic sciences coming along, with potential to predict certain other things that may arise in their future. And there may well be an appropriate device for that individual that we can support our clinicians in their decision process, and help them with that. And then, obviously we could then utilize that to have the right device ordered at the right time, and in the location where it's going to be placed, all of that can be brought together. And then followed with the registries, looking at subsequent outcome, triggering whatever follow-up is necessary, unfortunately we're going through some recalls currently with some orthopedic devices that are going to entail a number of lab tests imaging, and all of that could be fully automated in the ideal world in the future such that the individual is aware of what the plan is, and gets alerts, and arrangements are made for all of these things to be provided. As well as outcomes at the individual level to inform our physicians in procurement and industry to facilitate refinement of how we select patients for various procedures, what devices we utilize, industry could refine the devices for better outcomes, and the potential is really quite extraordinary. Monitoring devices, this is a somewhat chaotic field, I hope you'll hear more about this later but it's rather shocking to know that we don't even have a mechanism to manage the time stamping in devices, and that creates all kinds of mischief and chaos. We don't have necessarily accurate information. In order for that ideal I talked about to take place, there has to be accurate tracking of the devices, the link to the appropriate patient, and the documentation are critical, or just cannot happen. And some of the reason that this has been very slow are the security concerns, and we've had, as you may have seen in the press recently, I believe as early August, that a researcher just fooling around happened to be diabetic, and decided to see how easy it would be to hack into an insulin pump and glucometer to create some interesting things. You may remember the sunny von bulo case she died recently, apparently her husband attempted to overdose her with insulin, relatively easy to do. This gentleman was able to hack into the equipment, a relatively easy crime. There's a television series in there somewhere. But frankly, it is probably one of the major barriers to progress, and the integration and wireless data transfer for many medical devices, people are very concerned about the potential to have mischief and security and privacy breaches. So that has been a significant barrier. I think in the interest of time, because I think that the opportunity to discuss everything among the panelists is really the critical one, I'm going to go to the role of government which we were also asked to look at. And I think that Jay's earlier comment about having this unique device identification be truly universal, global, with a single number and code that it provides the critical information across the various markets, is one that is an incentive for industry to pursue. It has to be completely -- drive everybody crazy to try and create whatever is requested in one country or another country and have to constantly modify that. So any kind of support that the U.S. government can provide working with others is really probably one of the key opportunities to make some progress. I think to mediate and influence the entities that do in fact have some opportunity to make this happen, whether it's the national electrical manufacturers association or their subsidiary, medical imaging technology alliance, there's a whole suite of alphabet soup of various groups that can help come to a consensus where it's not an obvious solution, and I think a lot of this space is far from obvious at this point in time. Thank you. (Applause.)

>> Jay Crowley: All right, we're going to continue in the absence of slides, as you can see, and I apologize for that. But with that, I'm going to ask our next speaker to come on up. Dr. Joe Drozda, I'm going to get that out now, is a cardiologist and director of outcomes research at Mercy health. He's a member of the board of trustees at the American college of cardiology he also chairs ACC's clinical committee and also a member of the cardiologists, data registry management board and also is -- of the national quality forum. Dr. Drozda. Let's see if I can open your slides without ruining the computer. There we go.

>> Joe Drozda: You know I'm the only one that's seen the slides that can mix stuff up. That's one of the things. First of all, I'm happy to be here, I'm going to be discussing this from the standpoint of a physician, and a knuckle dragging health services research. So I'm going to say some stuff about health IT, and supply chain, that I really don't understand fully. So don't ask me questions about it. You will hear from Vance Moore tomorrow, who is Mercy's senior VP in charge of both of those areas, so you can ask the questions of him when he's on the platform. First of all, at Mercy, we are -- we are a fairly large multi-state health system, located in the heart of the country, in Missouri, Kansas, Oklahoma, and Arkansas. We have something like 34 hospitals currently, ranging from large tertiary care centers in metropolitan areas right down to rural critical access hospitals. We have about $4 billion in revenue and over 1200 integrated physicians, integrated is code word for employed. So they're primary care and specialty care. Now, Mercy is actually engaged in a journey that we hope will ultimately take us into the great new world of a UDI system in the future. This journey to this point has really been led by Vance Moore and his supply chain people at ROI. And they succeeded I think in setting an infrastructure that we're going to be able to build on going forward, and just recently earlier this year announced the ability to you know, accomplish the perfect order of fully automated purchase from order to payment. And this was adopted by GS1 standards and by integration of all of this into this software, our Lawson software in Texas and a partnership with Beck and Dick en son, but nevertheless we were able to achieve that and that really sets the foundation, I think, for what we need to do next. The other piece of the foundation is our electronic health record. Six years ago, Mercy began implementing the epic health record across all of our systems. We now have it in all of our hospitals except for one or two critical access hospitals. And we have it in the offices of all those integrated physicians. So we're on one single health care record EHR. There were still some challenges left and we're in the processes of optimizing one of the biggest ones from my standpoint is we have free standing clinical software like in our cath labs, cam tronics is the one we use in our cath lab and it's not fully integrated with epic yet, although we are working on that. By the way you notice all the cardiology around here think we have expensive devices or something that if they don't work might kill people. So we've got those two foundations, what we were able to do in the supply chain side, what we're able to do in electronic health records side. So where do we see we need to go next? I think what we're trying to do now; next step we'd like to do is the integration of unique device identifier into the electronic health record. And it's more than just the identifier that we heard from Jay a little bit ago. We're looking to have associated with that identifier key attributes of the type that Tom mentioned earlier. We're calling key clinical attributes that will tell us something about the device that may impact its clinical performance, and I'm going to be using coronary stents as an example through all of this. So a coronary stent may have its performance impacted by things like whether or not it has a drug impregnated on it. Which drug that is. Whether there's a polymer, how long the stent is, what the diameter is. There are all sorts of things about that stent that might have an impact on its performance and its safety. We'd like to see that associated with the UDI. Once we've gotten that, once we've gotten it into the electronic health record then we're interested in creating data, all that information into a computerized data warehouse from which we can extract data and put them in clean datasets for purposes of analysis. Those data sees in turn can be linked to national registries; they can also be linked with other health systems with whom we might want to partner for purposes of surveillance and research. I think a model for this is one that's been eluded several times today, and that's the NDC - the national drug codes. Add Mercy, we do get those NDCs provided to us by first data bank and upload them into our electronic health record. So they are actually in the EHR right now, again a model for what we might do with UDI in the future. And physicians find significant use from this, and their use for reordering drugs, obviously, but also they're looking at it as a link to warnings alerts that come to the point of care and actually use that in providing vital care to the patient. We'd like to see that as a model where we'd like to go with our electronic health records with UDIs. Okay, so why go through all the trouble of this? Of you know putting UDIs into electronic health records? Let me try to give you an answer as to why we're doing it from the standpoint of maybe three categories of people. First of all, our supply train, in Vance Moore's group - they're the ones who got us going on this, and I think what their major interest is and Vance keeps telling me over and over again, he wants to actually find out what works, for Mercy DOCs and Mercy patients, and that's what I've been hearing for the last year and a half, since I've been at Mercy. So I tend to believe him. Okay so why would the clinical support team the nurses all the people that are taking care of patients, why would they be interested in UDIs? Once you see the system, once you see how easy it is to scan a bar code and get all that information into the electronic health record, get all that information into the cath lab report on that device, say boy you're really making life easier for me. And I think I think although the clinical team would like to improve care as well there's also that self interest, that mace make my life easier, I glommed that statement on about 50 more times in an 8 hour shift, and that really speaks loudly to the health care team. For decisions I think the answer is improving care. You know, to be able to see a patient -- and you may be seeing a patient who had that device placed somewhere else by another physician, you're seeing them for the first time in your office or your emergency department, to be able to pull up exactly what that device is, right there, what you're -- while you're seeing the patients, when it was implanted, what were the key clinical attributes, etc, I think physicians are really going to love this. And also there's the communication, the warnings and recalls that I mentioned earlier coming to the point of care. Now I said I was a knuckle dragging researcher so why am I interested in it? I think the answer is obvious. This is a way of getting significant information into our databases that would help both in comparative effectiveness and safety research. We're looking at the automated collection of significant data elements, we're able to link those data elements with larger datasets, where there's the possibility of creating a health information exchanges in which we could participate with other health systems for the purposes of safety, surveillance, and research, and there's the ability to link with national registries. In my case it would be the NCDR for purposes of research. Finally it would enhance safety monitoring, obviously when you have the data collected this way, put into an electronic health record, put into a searchable database, if nothing else you've got a denominator. When something happens, when there's a safety signal on a device, you can find out right away, or very quickly, or even concurrently, how frequent that safety issue occurring. So let me just throw up something for you here on -- I can't show you on the screen, it's just going to drive me nuts not to be able to point this out, but it's a modest appropriately, maybe an immodest appropriately, it goes beyond borders of Mercy. Mercy has been involved with Mayo, and with Kaiser, intermountain, and Geisinger, in creating a partnership on the supply chain side called the health care transformation group. Vance will maybe talk a little bit about this tomorrow. They've been deriving the adoption of GS1 standards as the basis for a number of things including unique device identifiers. I like that idea of partnership, and I was thinking of bringing another partnership to be here, the American college of cardiology, and maybe the society for cardiovascular angiography intervention, SCAI. That partnership, that clinical partnership, could help us in a meaning clinical of unique identifiers. The HGC partnership could help us in facilitating a discussion with device manufacturers, and form yet another partnership with another key stakeholder. To drive the development of UDIs and to create a shared database that we might put in an item master that would have a key clinical attributes that could be associated back to the unique device identifier. Once we've got that, when we receive coronary stents, in Vance's shop and scan them into the ERP system, there's one of those supply chain things I don't really understand, I just through that in so UDI think I knew what I was talking about. Once we scanned that into the ERP, then all of those device attributes come with it. The ERP would be fully integrated with the epic electronic health record and then, you know, with the attributes and UDI going right into the electronic health record and right into the cath lab software, in the cab-tronics which in this model is fully integrated with the electronic health record. So now you've got this vital information captured in all those places. We do have a real-time messaging hub currently at Mercy that will help us with all of this, and also put it all in to our enterprise data warehouse, from which we will extract the data marks that we will use for purposes of surveillance and comparative effectiveness research. Those data marks could be available to other researchers in other health systems who are working with us in this effort. And they could be available for inquiry by anyone, including the FDA. So that's sort of the grand vision. The cath lab software would also report the information with UDI and attributes directly to the cath PCI registry in the case of coronary stents is the national cardiovascular data registry. So the information would reside there, as well. And we would propose that the registry actually be part of the network that can access the data marks we're creating. So this is a very ambitious sort of vision, but one that I think could be a very dynamic one, in terms of comparative effectiveness research, in terms of postmarket surveillance. We could do this, as I said, passively by allowing inquiries, or we could put proactive monitoring systems on top of this, of the type that Fred Resnic has been developing, his delta system at partners. So that's the kind of thing that gets me excited. And I think if we get the right stakeholders involved in this advice I'm putting out here requires a lot of cooperation, we can put together a very dynamic system that could be national, and it could be international. The technical obstacles are the least of our worries. What the real obstacles are the ones you've already identified as I was talking. First of all we need industry-wide standards like GS 1. We need a generally accepted device attributes we need to figure out how we get to that. We need an organizational infrastructure and support for designing and maintaining a UDI system. An organizational infrastructure has all of the stakeholders involved, not just designing it, but maintaining it over time. And then, finally, we need a business case for all stakeholders, including the manufacturers. I have a sign on my wall at home that my wife hates but it's staying there because it's always held up everywhere I've been. It's not the money, it's the money. So we need to be aware of that, in everything we do. And I thank you. (Applause)

>> Jay Crowley: All right, thank you, Joe. Our next speaker, you won't see his slides, either, Dr. Matthew Emmons, is physician executive and senior director with cerner research division where his -- has been on -- database, his background is in internal medicine and experience as a physician executive in various medical leadership positions, and let's see, try not to break this again.

>> Matthew Emmons: Good afternoon. Cerners electronic health record brand name millennium, has all the fields really to capture the current UDI level data for implantable devices. For example, manufacturer, lot number, catalog number, the serial number, expiration data and there has been a lot of participation in our research division lately with our health facts database in that we're currently mapping the surgical data for addition to that database, so just recently we got our first peek at that data, we did a preliminary query specifically looking at the implant logs, and we found that there's actually quite a bit of variability in how -- in the completeness of how those data are captured. So I think it's interesting to kind of reflect on those findings and how we can potentially improve on the completeness of the capturing these data so we can leverage them for a lot of the purposes we've been talking about. The health facts database is really part of a much more complex data architecture to support it. You consistent see the diagram, but the final stage of that process, these are hospitals that are contributing data from their client systems, and it's both inpatient and out patient, the final step of that process is a de identification process. Where the medical record numbers are actually replaced with a unique identifier, and the treatment dates are actually shifted to be HIPAA compliant. But before that process takes place, there's a couple other things that actually happen and there's actually a narrow stream of data that is pulled off that's used actually for surveillance purposes for public health reporting it's called health century and it's used primarily for state and public health departments to report communicable diseases. And also prior to that de identification process, reports are sent to the contributing hospital, and those have the real treatment dates and the medical records on them, so that there's an identifiable element of that before it kind of comes out of the firewall. When we took a look at the initial dataset for mapping, this is -- this represents the first set of data is about 55 facilities that we took a look at, and it's over 77,000 implants. And the facilities are actually over all doing a very good job in documenting manufacturers, overall 99 percent of the records, the implant logs, had a manufacture. Although this is free text, and so you see all kinds of variation in how the manufacturer is spelled, whether it's abbreviated, whether -- how -- whether there's misspelling or not, so those have to be mapped. But it kind of goes downhill from there. Overall, lot number was 74 percent, but there were a number of them that had zero. Serial number down a little bit more that is three percent, expiration date was 25 percent, but there were a few benchmarks facilities that even with lot number and serial number had 87 to 91 percent capture. So there are some facilities that have worked out a system, and are definitely doing it. Technology is available, currently, at least to help capture the device, an implant in the EHR, but obviously there's collaterals and we've heard some of those. Cerner clients have actually tried using the free standing bar codes in the surgery suite, and because of the lack of a standard system, there's obviously challenges to that. In talking to one of my colleagues in our device area a couple weeks ago, one of the interesting aspects that I have heard about, that I think may be an optimal process currently, is the use of surgical supply cabinets, mobile aspect has one out there that uses an RFI, radio frequency identification. So it's similar to the medication dispensing cabinets where you open the drawer, it knows you opened the drawer, knows when you removed the device, and Cerner's care is aware of connectivity between that surgical supply cabinet and the EMR. So we're at a point where you can enable that communication. But obviously, that comes at a cost, and to supply the cabinet, but it has other advantages too, obviously, with the supply chain. It's worth thinking about how we can provide value to help enhance the data capture, at least certainly while the significant barriers are still around, one way would be for data aggregators in the hospital and outpatient surgery space to supply identifiable data back to the facility, so that those patients could be notified in the event of a device or implant recall. And a lot of it also would potentially give those facilities a reason to maintain a connection to those patients as part of their personal health record, part of their health care community. Obviously we're going to be talking more about enabling participation and device registry that may be one of the reasons why some of those benchmark facilities have very high capture rates, they may already have a reason to work out a system, and then the use of -- we've talked about the use of de-identified data as being valuable in aggregate. Not so much valuable in an individual institution, but if we can work out ways to be able to collect it more in aggregate and use it in observational research in benchmark and across facilities. And that's the challenge, for example, with the identifiable information. I don't want the serial number in our health fact database; I don't want anything that could be linked all the way to the patient. But we definitely obviously need enough to be able to identify the specifics of the device. Thanks.

>> Jay Crowley: Thank you. (Applause). All right, so those are our panel presentations. We have three other members of the panel that I'd like to introduce, and they're here to engage which I hope will take place here in a moment. Going down the order here, Jason colquit with Greenway medical, is director of research services with greenway medical technologies, he's participated in national quality forum with integrating the health care enterprise IHE, HIMSS, and ER social, going down one further, Tamara Syrek Jensen, office of clinical standards and quality at CMS, the coverage group writes Medicare part A and B coverage, overseas determinations coverage policies and is lead for the agency lead for CMS and FDA CMS collaborations which we appreciate. Then on the end Dr. Scott Smith heads a research program, effectiveness studies patient centered research outcomes and research on the health care AHRQ, including cardiac stents, valve replacement and imaging. That is our esteemed panel you've heard some of the background so before I ask questions I would like to open up to the audience, if you have any questions or issues, that you would like of the panel I invite you to one of the four microphones again just introduce yourselves and ask away. Anyone? Please.

>> Is this on? Yeah. Maybe just from anybody in the panel, it seems like the biggest barriers to these very ambitious and idealistic ways of connecting outcomes, devices and better health care, to me is about levels of ascertainment, are you getting 95 percent or more of the data. Knowing what your denominators, so you can actually calculate a rate, and also, the validation of the outcomes in EHR, which are not standardized, which is why we have a parallel clinical research system, in clinical trials. So I just wonder if you can address these issues because they seem to be the elephants in the room to connect the dots between what we have currently is not a system to one as ambitious as all of you have talked about.

>> Jay Crowley: Anyone on the panel like to start?

>> I'll dive in. On the issue of ascertainment, I think I'm the one who mentioned capturing a denominator. Which has to be the -- you know, one of the major impols of what we're trying to do. So that when a system is set up, and what time -- you know, what I was proposing, what we can now do, I think, at Mercy, is each and every device that enters the building is caught in the system. And automatic -- and is you know once it's placed, has to go in the electronic health record with the same sort of scanning technology that captures exactly the same number and puts it in the EHR. So now you've got it, and those data then go into your interprice data warehouse, so that should -- enterprise data warehouse, and we need to test that, that should get your level of ascertainment in our -- at the level of electronic health record at least, to a level that's pretty close to 100 percent. So you can really establish a denominator. Now, when you expand beyond that and you're starting to cooperate with other health systems in creating these datasets, then I think you're starting to get into another level of complexity. We're talking about here in proposing a distributed data network or maybe a health information exchange and the data quality would have to be maintained at each individual institution. So there's a lot of complexity to what I've just said, so we're a long way from I think capturing the denominators. As far as the outcomes go, I tend to agree with you, electronic health records by themselves have prove not to be sufficient to capture outcomes. I think in my own personal view, I'd like to see them married with claims data, and we've heard some mention of that earlier from Tom, and I'm right there, the NCDR right now is looking at hooking to Medicare claims for the ICD registry. So it's starting to migrate the registry to being able to catch the -- the Medicare claims at least and be able to get the outcomes in that population. So what you identified I think are two major areas that need work, but I think you can see how to get there, it's just a matter of being able to do it.

>>Kristine Anderson: I'm going to add to that but I think of absolute quality, fit to purpose. So if your -- one of the main goals is recalls, right, just automating some percentage of that regardless of what capture you have, makes that process a little bit easier, and it can increment up. Then you take to something like something that's been looked at quite a bit lately like patients on ventilators, who are developing ventilator associated pneumonia or other infections and you're able to if you're able to just see the pattern and you're able to isolate which devices are impacted. When you get all the way up to value statements of whether or not a particular device works, right? This is work in health care, and you're trying to make what I call accountability decisions, then the data quality issues go way to the top. And I think in that case, you have to be looking at the system that makes it easy. How do you make it so that, you know, you're bar coding the rest you're bar coding the device it's linked right and you have something that really matches to that. So I think the caution is know what your data quality is and use the fit to the purpose that it's actually good enough for. And then you'll learn a lot. And I think that's how quality improvement has progressed, you know, over decades.

>>Tami Box: Great comments, I feel like saying amen. I just wanted to add that I think fundamentally we have to look at health IT in terms of if it's worth doing, it's worth measuring. That's just a personal philosophy. So this kind of endeavor, when you look at implementing any kind of system, whether it's an EHR, whether it's UDI, anything we're doing in RTLS, any of these things, implementation doesn't stop once the system is installed. It's a continuous process of looking at your levels of adoption, and continuous adoption, and continuously looking at that, and then also looking at data quality across a longitudeial spectrum, and not just at one snapshot in time. Not six months after you install or implement or do something to look at oh, how complete is the data. It is a -- there's a place where I think that as an organization in the VA we've adopted, and then certainly true in a lot of other places, that you really have to embed these questions of data quality directly into operations. So that they're part of your foundational principles that you're going to constantly keep up with, and assess.

>> Jay Crowley: Anyone else on the table. Jim?

>>Jim Keller: Thanks jay I'm Jim Keller ecri institute. I was just at conference last week with Jolene, we were at a conference, connectivity, medical device, business for innovation, did I get that right anyway a lot of hospitals were talking about integrating their medical devices into the EHR, and Dr. Hiatt referred to what you're working on at Kaiser, and a couple of the big challenges that they had was associating the medical device with some kind of identifier, particularly related to keeping up with the firmware, the software revs and other changes to the electronic devices like patient monitors and infusion pumps and so forth. So I just wanted the panelists to provide some perspective on dealing with that challenge. And then the other issue is with Legacy devices, a lot of older -- Jay you may be able to speak to that. There are so many capital devices that are in the hospital inventories for 10, 15 probably I'm sure some hospitals would be ashamed to admit, 20 years. So how does that challenge come up with UDI. So thanks.

>>Joe Hiatt: Yeah so Jim thank you, it really is a nightmare trying to have all of that work, and we do have a lot of Legacy equipment but at one point I think is worth considering is that in the world of biomedical devices that's technology that typically lives in our facilities or in the patient's homes for many years, at least 7 for most things. And most IT kinds of lifecycles are substantially shorter. My kids think I'm a dinosaur because this is the second generation iPhone, and they can't believe that I haven't upgraded. But most software is one to three year max in the IT world. The laptops, IT equipment, much different life cycle. And we're talking about trying to bring these two completely different worlds into sync. And it is really a difficult challenge. So I think that's one significant problem that we tend to overlook, is that they're on very different cycles.

>> Jay Crowley: Let me say we do have a panel tomorrow that will discuss this integration issue in a little bit more detail. But sorry, anyone else on the panel? No?

>> No I was referring to Dr. Vance.

>> Jay Crowley: We'll let Dr. Vance talk about that tomorrow. I will address Jim's point I probably didn't mention this in our opening remarks, UDI does not apply to Legacy devices, devices already on the market, so for all of those zillions of things that are already out there, they will not have a UDI on they will. So this is only prospective. Art?

>> Thanks, Jay. I wanted to continue that discussion about logistics, capturing device information. And then further work you can co do with it. And I really like the question Rick started about this issue of high quality MRs out there, what we have for implementation. In some places we do, in movement countries we probably don't. So that logistics aside also involving commissions to make sure we get high quality data from each individual hospital, at the time of capturing device information, without the very important stakeholder they're at once learning about the outcomes of what they're implanting and they might be the ones ensuring there's a high quality, but at the time of capturing, -- talked about the later stage of classification but I want to go back to the initial stage of capturing device information, involving that stage. This is also why I want to link with the registry at the next section and any comments you have about that.

>>Joe Drozda: I will jump in on that one, too, because what you've talked about is something that's near and dear to my heart. We have this dynamic all the time, it's this -- this between the practicing physician, who really wants life to be simple, and doesn't want to have to enter a lot of data, on the one end. On the other end it's the QI and the researchers who really want a lot of -- you know, discrete data that we can get to for purposes of analysis, and there's this dynamic tension always of keeping the the number of clicks at a minimum that the practicing physician has to do. And actually to me that's the beauty of what we're talking about here. If we can automate the data collection, and that what we're talking about, by scanning in all of these key data elements, very simply, and getting them into the EHR automatically, where there is no physician interaction, and it may just be done by anyone who scans the devices as they come into the operating room, or into the cath lab, you're kind of overcoming that click challenge, and getting the kind of data that you really -- that you really need in your own database and that you're then transmitting to the registry. So that's actually one of the reasons I'm excited about this sort of approach.

>> Jay Crowley: Thanks, anyone else.

>> Before I ask a question I wanted to give an opportunity for the other panel members if you had anything that UDI like to say before we jump into things.

>>Scott Smith: I'm Scott Smith AHRQ, I'm excited about this initiative my day job is patient health care outcome. And I think data improvement is somewhat hampered in not having a UDI, many of the same struggles falls into place at AHRQ we're in a nice place we don't regulate services we don't pay for any services but many of our friends do, so it's really to our interest to have a strong scientific ground and looking at device safety and effectiveness. A couple if I could be so bold to give a couple of suggestions from a government stakeholder perspective, I think that there's a lot that can be learned from the pharma co world where you talk about a NDC code, and some of the attributes that you're seeking, with the UDI to be consistent, unambiguous, standardized unique and global people tend to think NDC code has all these attributes and I think we're close but we're not there yet, and it's taken 20 years to get even to where we are now. So the big advantage that the device world has is that you can start on the right foot to get those characteristics, and I think the road map actually may be at least starting point is what we've learned from NDC, and many of the experts actually at the FDA, who have been involved with NDC, like Randy levins I think are great resources as well as outside the FDA. The other piece that I think that AHRQ would love to be involved with although I'm not here speaking for AHRQ I'm here speaking as a pointy-head epidemiologist, is met a data going around the UDI there's a long road ahead to think about what that looks like and have it readily available in hopefully sort of a centralized source for researchers. So I look forward to thinking about with you, and others, in the audience about what that looks like. Sort of the priorities in research in that area. As Joe said, the researchers will want all kinds of met a data but how do we prioritize what's most important for safety and effectiveness.

>>Jay Crowley: Right, thank you, Scott.

>>Tamara Surjons: Hi, I'm Tamara Surjons and I'm from Medicare, as I listen to this panel it's sort of what we're talking about every day in the Medicare world but one thing I always try to remind everybody I'm your end user, I'm not the person, but Medicare is the one who is going to have to pay for these devices. So as you develop the registry, and I was part of one of the early users of the ICD, NCD registry that you were just talking about, and all the challenges that we had to face to even get it up and running to where it is today, and now taking that registry and using Medicare data to answer some of the questions that Medicare has. And so as we talk about this, I really want you to think about the pare and include us in these discussions, because if you want us to pay for some of this stuff we're going to have to be -- we're going to have to be along for the ride in the beginning. If it doesn't work, I don't want to pay for it. And so I think that's sort of the message that we've come along, at least from my population, and one of the issues that CMS is facing these days is that we're working closer and closer with FDA and we're working very closely with AHRQ, Scott and I work together a lot, so that we can take what they have learned and we can take what FDA has learned and apply it to our world to figure out how we're going to pay for that. Whether it's through registries, for example, what Joe just mentioned with the ICD registry and CDR I think that was one great example and there are other examples as well that we have used registry data, and I think registry data is probably the future for at least coverage determination, it's one way that we can -- you know, make sure that we're paying for the right things

>> Jason: In ambulatory EHR system, I know in patient facilities there's been a lot of emphasis on quality and measurement of quality over time, I know the EHR incentives, meaningful use as we affectionately call it MU, has put a lot of emphasis on measuring quality and one of the questions was how to gather a denominator, numerator type information, I think that, and being in the EHR association as executive committee member we put a lot of emphasis on our products and we talk a lot about how are we going to get the quality and get those denominators and numerators across all of our systems, and there is a big effort and coordination across companies that we see locking arms just trying to figure out standards and there's a whole talk on standards and interoperability tomorrow, but just wanted to let you guys know that there is a lot of emphasis placed on EHR, I've been writing software in the EHR greenway system for 15 years, so I know we didn't capture the data, we needed it 15 years ago, I can tell you as an example,um munizations lot numbers, that type thing, we weren't capturing those 20 years ago they were free text, we need to capture that information if we can make it less clicks, capture it that way, so information from these quiss will flow right into the system I think we'll make a better health care system.

>> I'm from Johnson & Johnson as a big user of the data that all of you are talking about, I'd like to ask you around incentives, obviously claims data exist because people need to get paid generally of good quality and connected. One of the things that happens in claims data which sort of happen almost unnoticed is that laboratory data got incorporated into claims data and that's largely because pares refuse to pay the labs unless -- provide that data. Suddenly claims data has a little bit more richness without, you know, someone really taking -- beating them on the head. So the question for you guys, what do you think are the incentives for health care providers to enter the data, particularly, folks talked about how a subset of their base is adding those data -- do you have some insights of how we take it from where we are today, both in terms of quality and quantity, to where we need to be? And the second related question is what are the incentives you foreseeable there for the institution, not only to fill up the data for their own use, but also make it available more generally? A lot of you up there have data, but it's not available as a wide research resource for everyone to use. So if you can comment about that, also.

>> Great question, thank you.

>> I think that's one of the possibilities of being able to provide value back to contributing facilities, and I think Cerner is not the only data aggregator out there, there are a number of others out there in the industry could be in the same position. I think at the same time, to support the system, UDI have to have either the industry and/or the FDA working together to provide, for example, for the recall of that information back, or sharing the data if it's available for resource -- for research. So I think -- I think that the system could be put in place, but as we've talked about, it's not an easy thing to do, and I think that something has to be put together to help enable that. And registries can be part of it, but I don't know that that's -- I mean, it's cumbersome to put together separate registries for multiple devices and implants.

>> Jay Crowley: Tami?

>> And I can definitely say -- I talked about the meaningful use incentive-wise, just from individual company, we can see a lot of incentive meaningful use. Also, the physician’s quality reporting system, incentive systems, those are driving a lot of effort to get that data in from our providers, personally.

>>Tami Box: I think this is overly simplistic, but it's a great -- my answers really are simplistic I should say but the question was excellent because I think it's very challenging, anytime we're trying to figure out how to get more data and better data into our systems. I think the overly simplistic answer is the best way to get more data into the system is to not ask people to enter it, because we're going to end up with a bunch of bad data. So the better we can work through the hoops of things like RTLS, and health information exchange, and UDI, the better off we will all be.

>> Tami and I had a quick side bar earlier, the VA and Kaiser Permanente are sort of similar in the sense many of our physicians and others came to us initially because they didn't want to deal with coding and entering data, doing stuff like that, because in the prepaid world it isn't particularly relevant. So in our world, exactly that, taking people out of that equation and automating it beyond the point of somebody having to actually scan -- because even that is prone to error, with somebody not necessarily scanning it into the right medical record, the right patient chart. And leaves us really no better off, in fact probably worse off, than we are today in some senses. So as much as we can automate, and I have this vision of kind of like the chip that you can put in your dog or cat that has all that information about what's happened to you that somebody can update periodically, with what devices and things that happen to you.

>>Joe Drozda: So the incentive has to be to build the automated systems. Which aren't cheap. And you heard what was -- what's happening on the EHR side, and that they don't do that for free. So you have to have incentives, I think, in the reimbursement system. That what you get paid, is you have to have a system that can do this. Meaningful use is exact -- is a perfect example of that. Therefore, all of a sudden there's a business case for providers to build a systems to make it automated so they don't have to depend on their providers for data entry. I mean as I said in my closing remarks, it's not the money, it's the money. And I think that's really the key.

>> Jay Crowley: Kristine? Crews Chris I think these are all great comments one thing I'd like to add what I like about your questions these two things I believe are connected the way data is locked today in silos impacts its usefulness. And so my own view is un lock the data, so we can get some more innovation. It is completely technically feasible today to have automatic recalls go right to the iPhone s of the people who have devices, right? I mean, that may -- there are more secure solutions I'm sure as well, but the point being that we don't -- because the data is locked, and not accessible to very many people, including the patients and others, the usefulness of it goes way down because it's not used. And so we need to find ways to do that, and I think we'll see very inexpensive applications pop up that will solve many of our business problems. And then we'll get widespread use.

>> I'll just add that I think patients are going to start demanding that the information is there which is going to provide another level of incentives for all of us.

>> Jay Crowley: Great. Anyone else on the panel? Does the payer want to say anything?

>> Well we always believe that the data, you know within regulatory programs ter and statutory programs should be available, especially CMS data so we'd like it to be more available. And we'd certainly love to have all manufacturer data given to us as well, but that's a challenge.

>> Jay Crowley: Thank you all. Joe Jo --

>> Partners health care my question is an extension of the discussion when I got up here I didn't know the discussion would be so rich so it's now just a extension to the discussion and I think it's probably directed more towards Tamara. So but anyone jump in. The notion that we're providing infrastructure, core capability, plumbing, electricity, for a part of the health care of the future, is obvious, that's really what this discussion is about, enabling capabilities, connecting data, and filling in huge gaps that exist today. And so everyone bubbles up what they could use it for. But it isn't clear to me, when it comes time to up grade infrastructure, and all the co-op tenants complain about having to pay for the new roof, you know, and all these other things that we all wrestle with on infra structure, especially if it isn't clear what the actual benefit will be, financially, because it's the money. How much evidence do you need? Now, doing a bit study on many things like this is nearly impossible. That's the case with a lot of infrastructure, it was very hard to know that Amazon would be Amazon when DARPA was thinking about arpa-net. So how much what's needed how do we really make a business case from your perspective.

>> So I guess just to clarify your question, are you asking me how much evidence you need on a specific device, or how much evidence you need on the infrastructure to --

>> Oh, on the infrastructure, and how much of it is a thought experiment and how much of it is evidence, given how hard it is to produce evidence, before you have infra structure.

>> Right. So I think the infrastructure is a little beyond my role, since what I look at is really the individual device or drug or et cetera, and determine how much evidence is enough evidence to determine that Medicare will pay for it. One of the mechanisms for me to decide whether I'm going to pay for something is the data that you may use to put into a registry or the -- I mean, a UDI I think is something CMS has been looking for, for a long time, and we -- you know, CMS tends to be a very reactive agency. We are the tail end of everything. FDA approves it, you know, and then we decide whether we're going to pay for it or not. But I think with a UDI, we've already looked at our claims system to see how we could add that to our claims system, in a fashion to pay for it when it's ready. But as far as how much evidence I need and whether the infrastructure is good enough or not, I think that's really beyond what CMS would do. My question is the data you enter into it, is what -- are the questions you are asking, are those questions relevant to my population, and whether I should pay for that particular device.

>> Jay Crowley: There are probably going to be a need for entirely new departments and maybe an --

>> and organizations both in companies and in hospitals because the UDI's pointer, and then the databases contain the information, so the information has to be populated. And all the stuff has to be done. Of course, I'm not -- this is just the way it is, this is -- I mean, I didn't say it this way, Jay described it that way it's just the number that points to the other databases, so there's going to be a significant effort required to produce those databases before we really see the benefit of something like this out there. So it may not be an answerable question right now, but I think it does have to be answered. Because someone is going to have to write, you know, quite a few people have to write large checks before this becomes a pervasive reality. And it's been very hard to do that lately with major changes. It's funny, who pays for all the iPhone s that clinicians carry in the hospitals? Who pays for -- does Kaiser pay for the physicians' iPhones?

>> Not this one.

>> You wouldn't have that one.

>> I think with partners, they end up that the expense goes to the individuals who are trying to innovate. And I think that's what has enabled some of these things to happen lately, is that people pick up the cost. But I can't see that happening with UGI. Well, anyway.

>> Good point. Good point. Our last question for the --

>> Great, my name is Pete Cassidy, happy to be here, actually met you guys a lot of you at last December's meeting in Baltimore. One other aspect of this certainly just kind of following the line of discussion right now, about cost, I can tell you as an entrepreneur I thank God every day for UDI because I started a business around it. We're trying to solve problems and create opportunities for people, we're hiring people like crazy, but not to get political but you guys are doing a great job of helping us hire more people, and we appreciate it. My comment really is -- and something I don't know if everybody here is aware of, but we got our start in helping hospitals track tissue grafts. And tissue grafts are required to be tracked by hospitals because of joint commission requirements. And my thought has always been that if UDI, once UDI launches, if it becomes a joint commission requirement, it will happen. And believe me; it's happened with tissue tracking. So I don't know what your thoughts are on that as a panel.

>> Another incentive besides money is regulatory or accreditation requirements, so that's obviously another place to look when you're looking for incentives.

>> But I think it also goes to a business case for patient safety. When you tie the tracking to the outcomes, as we've talked about in a couple other places, when you have a case for improved outcomes through tracking, and being able to facilitate and enable recalls and take care of issues with devices, then I do think that it is a wide open door for an incentive process.

>> Right, and for joint commission, at least in the Medicare world, for joint commission to adopt that UDI have to -- Medicare would have to change their conditions of participation, which as Jo had said that's one more way to incent that you're going to adopt it. But that's a challenge to do, and it would take a -- it's a lengthy process from years to several years. So I'm not sure that that is the best incentives on the table.

>> Great, anyone else? All right. I would like to thank our panel number 1. (Applause) We are going to take a 10 minute break, it is 3:20, and we will start at 3:30 with panel number 2. And I just want to let everyone know the slides will be available on the website afterwards, so for those that wanted to see them and couldn't, and those on the web you will be able to see them. Thank you all, see you in 10 minutes. Okay, I'd like to introduce to you your moderator for panel number 2, Dr. Marinac-Dabic, is head of our division of epidemiology -- is that right? I got it right , okay. So you know, I only work in the office, I can't keep track of everyone. So Danica, please.

>> Danica Marinac-Dabic: Good afternoon and welcome to what I hope is going to be the best session of the workshop. I am the director of the division of epidemiology, and my division is in charge of all mandated postmarket studies that FDA issues, either at the time of the approval or anytime during the post approval phase. If there are unidentified -- either questions that you would like the industry to address, we are also in charge of FDA-sponsored postmarket studies that are designed to build both the infrastructure and the methodologies that FDA utilizes to study the postmarket performance of medical devices. So the registry as a field are very dear to my heart, and increasingly, during the last several years FDA has identified -- actually identified the efforts to explore the capability of the existing registries, not only for mandated postmarket studies but also for the discretionary studies that we utilize, to study performance of medical devices, and for the linking between the registry data and the administrative dealing data. It is my great honor to moderate this panel session, and we have a great group of distinguished panelists with whom I have corroborated personally on many projects. They all bring many different and unique perspectives from the registries, and we are going to tackle important questions on how the UDI and the registries are connected, how we can improve the utility of the registries in the world of the UDI that's coming. We certainly are looking forward to harnessing the value of the registries in the years to come, and to harness the value of the observational data coming from the registries. So with that brief introduction I would like to introduce our first speaker, Dr. Fred Resnic, who comes from bringing hams and women and Harvard University. Harvard as you probably know is one of our medical device epidemiology network sites and has been participating with us on a number of pilot projects, so I'm happy to introduce Dr. Fred Resnic to give the first presentation.

>> Fred Resnic: I'm going to be very careful when I'm touching this. I see that one. Jay is telling me don't press the big blank button. So hopefully this will work. So first, I wanted to thank Danica and CDRH leadership including Dr. Gross and jay Crowley for inviting me to speak and participate in this particular workshop. You know, I am sort of -- have to have I guess two disclosures, one, I'm a practicing cardiologist but like Dr. Drozda, a sort of health outcomes researcher. So I see UDI as an incredible opportunity to solve some of our vexing problems in studying, especially in the postmarket environment, the safety of medical devices. What I was going to speak to today, is where things stand with cardiovascular registries, and device identification. Because there really is not UDI yet, but cardiovascular registries and UDI, and just to put things in perspective again, I'm a cardiologist, cardeologist interventionist in our practice. UDIs have been a chemo for doing research in cardiology for some reason they have not quite the consistency of the claims databases but they have greater depth and probably more consistency than the electronic health records and they've been a natural resource for us to use in device safety surveillance and postmarket studies. So let's just think about the importance of identification in cardiovascular registries what the landscape is in cardiovascular registries at national regional and local level and we're going to hear more about each part of this from the other panel speakers, just to give you some sort of basis, a lot of the registries are really procedural or disease-focused or service- focused, so there's P credit I, which is coronary intervention, we've heard about ICDs and implantable defibrillators, there are ltz VADS and others, none of them were really designed for device safety surveillance, so this is going to be a ep great leap for us if we can get UDIs well incorporated. And again just think about where we stand with device identification and it's quite a spectrum so opportunities for implementing -- and I'm going to develop all of this within the next 6 or 7 minutes, first I'm from Massachusetts that's a little map of Massachusetts up in the northeast somewhere, there's about 6 million residents one thing we have in Massachusetts that only a few states have which is a very rigorous statewide mandated data collection effort, and we have a central registry for angioplasty, interventional cardiology, also for cardiac surgery, we get a lot of good device information because we use the NCDR, the ACCNCDR national cardiovascular device registry format to collect this data and it's been useful as a resource to look at trends in utilization and outcomes for specific devices because we do have device-specific identification. And so one thing we've been able to do with the statewide data repository in Massachusetts, is look at device-to-device comparisons, just as sort of an initial signal sort of identifying exploration, not that any exploration of registry is going to give you a definitive answer about device safety, but what I've shown here is the cumulative experience through the state, between 2004 and 2008, in the use of two different cardiovascular stents, shown in the dots are the actual periprocedural myocardial infarction rates with one device and in the blue range is what the compare tore group, for a propensity match of analysis of about 18,000 stents or the course of this time frame, and how one stent appeared to be performing very differently from another stent and it was worth I think investigating I think why that might be. And it's the power of these registries to accumulate large numbers in a very rigorous and detailed format that allow for proactive, surveillance or performance -- which was who we took about here with the NDIH. There are all kinds of registries mandated registry in Massachusetts the one form but there are single central registries, Brigham has one Duke has one, there are many others there are growing numbers in the times of diseases that are covered we've heard about the Kaiser orthopedic joint registry which is speck tar and a central resource. There's multi -- registries, there's national voluntary registries, the NTDR is technically voluntary, to sum degree although certification, accreditation push it now towards almost mandatory. There are regional mandatory registries such as New York Massachusetts and Pennsylvania registries, and then there are formal post approval studies. Which I think is the highest end of the spectrum of the data reliability quality but also the highest cost. And I would say that we really need to think critically about how to do device identification across this sort of mild range which is where so much data is being collected and there's so much a push in many specialties and many disease areas to create registries, so just speaking about NCDR for a moment, so NCDR is sort of almost a subsidiary or a joint venture between the American college of cardiology which has the leadership role and several other organizations. But they have five major registries, actually six now, cap PI is shown in the middle here, we have 1400 hospitals with 11 million patient records included in this registry, but it's basically fundamentally an implant registry with very little longitudinal linkage although in recent years several of the analytical centers have been able to link the CMS to claims data for long term outcomes. There is ICD registry which has now 1600 records patient care registry used for carotid stenting 170 hospital participating but it's also other registries coming online. What is the current state of registration in cardiovascular registries? There are several registries that really have comprehensive data collection including down to unique device serial numbers, the best example of this is the intermax ventricular assist device registry which is -- it's really an interagency sponsor registry for every patient who is receiving an implanted ventricular assistive device as a destination therapy. And without violating HIPAA, I believe that one of our recent vice-presidents is probably represented in this registry, because he had the implantation of a VAD device. Very labor intensive it takes a tremendous amount of data collection and enters through the web of all this tremendous detail very few centers have done any level of integration with their EHR because the frequency of implanting that at any center is very low. So the most experienced centers may put only 10 VADs a month to do the level of integration that would be required for this would be very difficult and very expensive. The most common and sort of the biggest challenge for us and probably where the greatest advantage of UDI will be is the essentially maintained master device concept. So this is what NCDR does and many of the other registries where basically the owner of the registry creates its own list of what the devices are of interest there's periodic updates that are sent out to the local participants left and right coast to coast but there's tremendous variability in the devices that's covered it's basically the interest over the -- itself, and the granularity of the data, you may not have clinical aspects that Dr. Dozen was speaking of that may be important in associated with an outcome even to do simple risk adjustment. This is done by EDR, Massachusetts registry, certainly by others. And then the most common and sort of lowest level olive device identification is to think about device only at a class self. And so this was common until about 2007, even the NCDR was using this when -- and I think Dr. Gross mentioned this when a product is new to the market and it is the only product on the market doing class identification is good because it's one-to-one match with the original device. But unless the registry matures in its device classification, you end up with the inability to segregate one device to another. Again, the advantage here is you don't really need as frequent updates because device classes come along slowly, but there's a huge lost opportunity for device specific information. And even some of our most established exceptional quality improvement registries, clinical outcome registries, have maintained this strategy, north England is a long standing Registry for interventional cardiology, has not captured to device- specific designations. Cart seal has a blended model and even the older CAP NCR model used this. Just to look -- not to make anyone's eyes sore but this is what a device master loose like -- looks like this was downloaded off NCDR, it looks -- I think it's 231 separate devices. Now, with the launch of ACC version 3, in 2005, I believe, there was a lot of thought put into the how much information is the right amount of information to collect. Again the focus of the registry was not a device-to- device comparison but wanted to think about how maybe a device might influence outcomes or quality. So they do classify devices according to device type, but who actually says what type of device -- you know, how one is allocated is a little unclear right now, the multiple institutes of devices that share a lot of commonalty, so this is looking at for our friends from Medtronic we have sprinter balloons here each one is slightly different but the difference between item 135 and 137 may be a little confusing to me, that's sprinter balloon versus sprinter over the wire balloon because I think the former includes the latter. So you can have less than precise alignment of devices and you may have to think about bundling some of these together, so you need to think through carefully of the limitations of how the data was collected in the first place. Fortunately, NCDR had thought about including some attributes, there are some clinical attributes on this, that include diameters and length of the stent, but again I mentioned it's almost an arbitrary allocation of numbers, there's no relationship between number 135 and number 171, it doesn't mean anything. There's ICD registries, in this there was a further modification which includes the revision of the model with a new number, a new code, a device identification code, for each new revision so you could package multiple revisions together and talk about a sort of single ICD lead that may have three generations of revisions to it or look at each revision separately so that's another level of an attribute that we're going to have to think about as UDI matures, and how it's captured into registries. Similarly, the carotid stent registry includes attributes, but there is gent tremendous nonspecificity. There's a device called the clinical trial device. Fortunately it's divided into some major manufacturers, but that doesn't help us very much if one manufacturer has two different trial devices. I'm not going to mention much about the CART system, because Peter is here and can explain it in much greater detail. The intermax registry which is really sort of the gold standard for clinical device registries, I think, in the United States. For lots of different reasons, includes extraordinary detail on the specific device, because in fact that was one of its design parameters, it meant -- it was intended to look for device-device comparison, device outcome, including the brand and device tracking number which was basically the unique serial number for in device and this was transmitted with a master list that's maintained on a central database. I can mention just quickly, when I look at device- device comparisons I have challenges, we've had identical products, Zion and Promus, and how those are collected in these registries, one has to realize it is in fact the same product, even those two manufacturers, one is distributing it, so it's just the color of the box that's different so we can kind of bunds bundle those two together. Unfortunately some have iterations. I guess the bottom line point here is the unique aggregation of devices into groups, families or classes depends on what question you're asking, and what kind of outcome you're trying to assess or compare, and we really do need a much better approach at the registry level to be able to sort of support this level of investigation. So obviously, just to finish up, future opportunities with UDI within cardiovascular registries, the adoption of UDI will tremendously reduce the burden of maintaining an individual device master list at the registry -- it will make the registry owners life easier I think that's very helpful. It will also make the recipient organization's life easier because they won't have to constantly update their system. It will permit most large registries to begin tracking all high risk devices used, there would be no advantage to coming up with your own modest or slim lined approach of device class registration only. And it will safety surveillance, so we can combine New Orleans with Massachusetts CDR, and have a robust data source and permit more collaboration between FDA and registry, and registry owners. Thank you very much for your attention I look forward to the panel's discussion. (Applause.)

>> Danica Marinac-Dabic: Now I'd like to introduce Dr. Soko Setoguichi, and also remind you that we've taken 7 minutes of your time. Dr. Setoguichi is also epidemiologist and very much involved with in -- development of innovative method logical approaches on device linking or data linking between the region stries that's listed in -- data. So we'll look forward to hearing her talk.

>> Soko Setoguichi: Thank you. So I only have seven minutes I'll go quick. I'm a practicing pharma co epidemiologist, -- working in -- epidemiologist for life. My talk consists of two parts one is to documentation of device using national hospital based registries my experience comes mainly from my experience in leading one of the project funded by AHRQ group and CMS to assess comparative effectiveness in ICDs and stent, by comparing claims data. Current study of nationalized, from NDC, and CDR registries, I think one of the speakers talked about the details of this I'm going to say just a quick thing these are the four variables that are identified used in identifying devices in this registry. And in our project, I only have access to ICD type, which is very complete in this registry, however I can say by linking this data to claims data, we've already identified, in terms of identifying who is getting ICD, you might get different answers, either from registries or claims data, because there is some discrepancy between the two data sources. So this might be -- to the previous talk about maybe manually entering data might be causing some errors in the registry side. Next is the national registries, I'm talking about registries one is ACC cardiovascular device registry, care registry, and SCS, these two registries collect data on stent and as the two data sources have very similar data elements because they actually tried to harmonize data collection here. I cannot speak much about care triage we're just getting access to the data and trying to establish corroboration, but we'll be using SVS data so I can tell you what the missing of these data. Manufacture name and model naming in SVS data is 100 percent complete. We don't have lot number in the SVS data nor ACC, and NCDR care registry, the links we have 100 percent missing however diameter more than 60 percent are missing and the shape of the stent taper this is also 100 percent complete. So you can see again this is to the fact that the data are entered manually and what's available in electronic medical records will probably dictate what's collected in the registry. The next is the hospital based HIPAA knee joint re placement registry. So at Duke we have hospital based region and we have several collaborators that also have hospital based registries, and these collaborate provide means how these devices are identified in these databases. So most databases, collect quality description of each component devices, but the fact is that what's collected might -- is not standardized from substitute to substitute. They also collect -- -- and lot number. In U Cdc they changed to discount number and lot number in 2009, so that's how it is in a hospital based registry. I cannot speak to the missing dmeap registries at this point. In the drug world we have national data code -- national drug code, and if we look at these registries so that three registries I mentioned ICD, cair and -- -- I also added a disease based registry. They do not record any NDCs in these registries they only have generic name of class and some might not have those, but it's optional so there might be a lot of missing data here we can identify quantity we can identify formulation, in terms of collection data appoint that is only related to 3 data points hospital -- or procedure, before and after procedure. As epidemiology we want to know everything, because beforehand we don't know what component or attribute of devices could be safety for safety identification, safe and effectiveness identification. In terms of tracking devices we really need to know lot number and device IDs. Finally, we need to be accessible in electronic health record and building records or claims data or even from patients. So this last point of patients leads to my next talk about our pilot at Duke linking hospital based CD registries to patient portal to create personal health record. So as you know personal health record has been defined as internet based tool to allow patient to access and entering health information, to do that you have to pull all the information to data repository and open that to patients. At duke we have existing patient portal that allows the patient for registration, scheduling and administrative tasks, and in data -- at Duke we have 400 u 1/4 systems, and for this pilot we pulled all these 400 unique clinical system data into one repository, and then linked that to a patient portal. In terms of in that we also involved Duke data bank, collect device information, for cardiovascular devices, and then this is a page that the patient can look at that gives you information about device type, gives the patient information about device types, implant data, device description, manufacture, model number and serial number. So what's the use of this data? I think for all epidemiologic studies we need longitudinal data so I think we can pull data from the system and create longitudinal cohort of patients. But beyond that, I think one of the benefits of this patient portal system is the patient can come and go with concerns of effectiveness issues, so it may lead to early detection of safety issues. This patient may have a tool embedded for surveying patient so you can ask this patient reported outcome such as maybe pain level or functional status after total knee joint replacement that would lead to more comprehensive assessment of safety and effectiveness. Finally, this can be used to educate and communicate with patients about new and old safety and effectiveness information. That leads to education, timely communication, and -- -- process In summary, in terms of current status the registry is designed to capture important features of devices but it's not standardized and not enough detail, if we're targeting postmarket surveillance or tracking devices for the pilot we did at Duke, we completed the pilot for the CD registries, we're thinking about also including (inaudible) patients. And adding new features. Thank you. (Applause.)

>> Danica Marinac-Dabic: Now I'd like to introduce Dr. Sedriakin, who is an epidemiologist by training and has been involved with many projects with the FDA so far, mainly the development of the international consortium of orthopedic region stries, that is an evolving effort and is going to be a great platform for piloting some of the UDI work that we're going to be discussing today. Dr. Sedriakin.

>> Art Sedriakin: Thank you very much DDanica, it's an honor to be here. Its my pleasure to share some thoughts and vision about UDI implementation within registries. I've drawn this slide, and it's a busy slide. What I wanted to capture a little bit of a discussion we had in the first session, and in linking to the registry discussion that we're having now. Jay and Jeff talked about that UDI implementation needs to be within electronic resources; EMR is a critical component of it and potentially the core of it. If you look at the slide on the left you see from the supply chain side to the OR cath lab side there is potential for transfer of that information. And the hospital EHR is cytthat transfer of information. If it's connected to a supply chain side, OR can be for the patient and not entered a second time. If it's not successfully done it can be at the supply side, it can be successfully, at a cath lab. Throughout the cycle on the top there's hospital EHR system and IT systems closely connected Joe was talking about this when he was talking about linking a supply chain to clinical data systems. On the right, there's a bypass path. Most of the country does not have good quality EHRs so you might have to think about alternative paths, and alternative paths can be directly through ORs and cath labs, through clinician participation into device registry building. And that's one example, my colleague, Liz Paxton will talk about, on systems Kaiser built based on that platform. On the left side you'll see that from supply chain side to hospital materials management and billing to also think of an alternative path if those on the right are not really working well. So why put these data entry as critically important component? Because there's a lot of logistical issues that need to be handled at the data entry level for these to be high quality implementation, and be useful for clinical implementation and surveillance studies, device registries come after the information is available, but once you have the UDI within device registry, you've only done half of the job. Because then, UDIs use a number that you've got, you have to classify that, that will be clinically relevant. So becomes a clinical classification issue. That's how we kind of put this together as a vision, and this doesn't capture the entire cycle of UDI implementation, it's just specific to data availability within a clinical registry. Another thought that is important in this vision is that maybe device registry can be a core or a focus, that Julian Was talking about, if there's a targeted investment that needs to be done by FDA, maybe that registry concept, and through EMR is the focused area most needed and also outline the priorities. So there are some advantages to this system, to think about prioritization and structure. So a couple of challenges in the data entry side, and I wanted to thank my colleague, Stan mendhall for providing some of this information. At a level on the top you see that -- I wish I would have had -- if this works. Oh. So see if I have a laser pointer here. Okay, here, so you have information on the device itself, but also a part number in a catalog, and currently in some situations they don't really match. Like in this example you've got two additional digits here that are not on the device itself. So this is a learning lesson for UDI implementation that hopefully all the numbers will match, both on a device, and also in a catalog. In addition, the label, and the package also don't match often. Not often, but there are a lot of cases like this. So this is also another example, a learning case for UDI implementation, making sure all these numbers have the same digits, in terms of UDI. Next important issue, this is an example from orthopedics again, so some of the information like some implants like screws are in a tray, so how do you do successful implementation? Each time you take out a screw you have to bar code a scan here, so you know how many implants you put in? How much information do you need from OR personnel how much time do you need from OR personnel in order this to be captured right if they've done 6 of these screws. That's also important to consider on a data entry level in terms of how complex it can be sometimes. Finally here's another example, hospitals might purchase large quantities of the product, bond cement is an example they might repackage into smaller components or just use a small amount of that product. So now again you have an individual that needs to go back, scan the package or whatever they have in the system, and each time how much information you've got because it's not on a package per se, or individualized or personal level. These are porn logistical issues that are important for any implant information. That's 80 want to emphasize data is pretty much the key, now getting into clinical classification. So here's one example of next Ren gen retaining crucial research. Let's imagine we capture all the UDIs. With 13 footprints 5 thickness levels with two cross link pods and 2 degrees of inflexion, we you get about 160 UDIs associated with this product, which is similar size length and width. Now, do you need all that information or do you need to classify these products? Because having -- you've the lot number in cardiovascular registry and serial number, what are you going to do with that right? It's an option that capture that information is important information, important work that needs to be done to classify these into meaningful attributes. Orthopedics world is the head of the cardiovascular field suddenly in one area is this implant classification. Being able to work with these numbers in a comprehensive way. Maybe I'm being provocative, but -- so. Again, continuing that discussion, sometimes you get minor differences, and you have to make a determination whether those differences are valuable for clinical tracking purposes. Sometime you get these legal -- that you're not sure it would imply the same here in terms of crucial retaining or not. So again important is to have clings opinion and lds a harmonized opinion about how to classify these products. And here is a potential solution that we're proposing, with international consortium of orthopedic registries, move these registries handle one way or another a lot of these implant classification issues there's a lot of learning that can happen. And this year in May we had our first meeting, and all of the registers talked about the same issue, implant classification and harmonization is a key. 20 classifications from -- got into the meeting at the FDA and we talked about a lot of challenges and now the group is ready to tackle important issues, one of them is really comprehensive clinical classification development. We're thinking we might do more than that, once you have that clinical classification it's important to tie that to UDI regulation and G N as well because GMNDN has clinical classification UDM has clinical classification there's important cross mapping that has to happen between clinical and -- classification, who you have to do there is potentially other groups to help us in advance to the next level. We also talked about -- Tom talked about the evidence so I based kind of classification of the future. Now, you need to do studies to make sure what you classify is not just based on engineering but it's based on data. If you can do that we proposed also some pilot studies to showcase that the classification like based on bearing surface is valid how many bearing surfaces do you need to capture, for example hip replacement and same for knee re placement how do you classify 6 versus mobile bearings in order for that to be clinically relevant. That concludes my talk. Thank you. (Applause.)

>> Danica Marinac-Dabic: Now, during the first session we heard one presentation from the Veterans health administration, now it's our chance to beat that presentation with a better one, I'd like to introduce Dr. Paul Varosy, who is going to give a presentation on integration on realtime registry.

>> Paul Varosy: Thank you, I'm going to talk about a few things today, and forgive me if this seems to over lap with what Tami talked about earlier because the fact of the matter is that the concepts of registries being distinct from electronic hilt registries -- or records being distinct from billing and coding being distinct from device surveillance is kind of an artificial concept to us in the VA we've moved to a single model where we think about these as parallel work streams moving to a single model that can accomplish all the goals efficiently without disrupting work flow is really the model we're working to. With regard to registries in particular the concept of the registry is data abstraction from registry enrollment after the completion of clinical documentation, an enormous duplication of effort within the cardiovascular work space I can tell you generations of cardiologists and EP P -- EP fellows complain about having to complete their note and having to go back and finish the exact same information and record it for a second purpose. With the CART program we're moving to a model of integration of data collection in field-specific format directly into the process of care, without reduplication of effort. So the basic idea here is that CART is a clinical tool that improves the efficiency of care by generating all the information that's necessary for clinical documentation with integration, with our electronic health record, the computerized patient record system, and allowing for efficient report generation that's far faster than dictation, with VA-wide standardization and report completion of in real-time. In many cases, before the patient is even off the table, in the catheter EP lab, the note is finalized in the chart. If you think about the standard model of dictation and operating room ports, the fact there is the requirement that physicians have to write the four line brief operative note is an abject acceptance of the reality that the real clinical report is not going to be in the chart dictated transcribed, edited, sent to the attending for cosignature, whatever else, for weeks after the actual procedure, such that it's just not relevant for actual clinical care. We see that as an opportunity for exrofflet. And by integrating field specific data collection into the transaction of health care allows for realtime quality management integrated into the health care transaction, patient safety monitoring, realtime device surveillance, realtime management which we're accomplishing through VA wide implant tracking service called VITAS. And through health services research resource and I would argue a platform for leveraging real world pragmatic randomized trial and we'll get to that in a moment. So the CART system, and this is no mistake that the CART program director and the VA national director for cardiology services and the director, the chief science officer of the national cardiovascular data registry are one and the same in John Rumsfeld so the dead data standards we use through at all documentation we use are firmly grounded in the data standards that have been vetted by the ACC, AHA, Harvard society and clinical work groups that are responsible for these. We're building in addition to our baseline CART CL module that currently documents 30,000 cath reports in the 78 VA cath labs across the medical centers every year we're building additional modules and vetting the module for arrhythmia device implantation. The challenges related for us to device identifier capture are that the important device specific identifiers that would be necessary for doing a lot of things that we could do such as the manufacture, model name and number, lot number, serial numbers, sizes, dates of manufacture, dates of expiration, are incredibly difficult and painful to capture manufacturers -- intuitive nonstandardized worse of all, they're extremely prone to data entry error when human beings are forced to try to capture these data on their own. But on the other hand, they're absolutely critical for relevant device surveillance or even inventory management. So for us, here's a screen shot of our CART and EP module you can see very prominently placed in the milds are the very specific device identifiers such as the pulse generator and lead manufacturers, model numbers, serial numbers, dates of implant, that are entirely relevant for us and we're actually currently capturing for our national cardiac device surveillance programs which monitors 75,000 monitoring a year, maick making it the single largest monitoring program in the world. But it's a great effort and pain, I'll tell you. So where this is particularly relevant for us, and entirely in line with our stream lining of data collection processes we're bringing real time location services technologies to the VA to the tune of several hundred million dollars over the next several years . With a plan for bringing in realtime location services technologies for inventory management. With the rationale being obvious, that we in cardiology use very, very expensive tools, the recall management and device surveillance are entirely critical for what we're doing, and that CART as a field-specific data collection model really allows for unique integrated data solutions to build this effort on top of. So for those of you who are not aware of what real-time locater service systems are, basically these are systems for tracking and locating technology assets in real-time. And many possible technologies have been used to successfully implement this including radiofrequency identification with both active and passive tags, infrared technologies, ultrasound, line of sight, time of flight, any number of different possibilities. Many of you are familiar in California and Colorado we have both the fast track system for electronic toll collection, which is an RFID model and then my ski pass being in Colorado, with the V ail resource group has their system, which basically has a love leeway of telling me each time I pass on lift there's an RFI scanner which records my position and I can see the day how many vertical feet of skiing I did over the day. You can see how if this were done with inventory management that actually would have some real efficiency that it can bring in. For inventory management the current model is really about multiple parallel and duplicative process such as in VA the generic inventory package system that our lodgeis tans use, cath lab staff, hemo, I mentioned VITAS, the inventory package tracking system that tracks implants that go into patients, and our national cardiac device surveillance program. This is information gridlock and it's very difficult for all of us. What we're moving to is the smart cabinet technology system with a data integrated solution, again in light with the CART system to bring in a single point of data entry integrated into the process of care with the idea being this will be the work flow process for data that we're talking about. Where a stent gets pulled off of the shelf, the smart cabinet system knows based on RFI D location that the stent has been pulled out of there, the work station that's associated with that smart cabinet system can then positively identify that the item has been removed, and that in fact it's being used for the patient. Those data flow forward toward CART and then because we have a field specific data repository all of those data than then be distributed in realtime and greatly increasing efficiency of care. Clearly there are enormous benefits for us in the VA for registry efforts including clinical efficiency for tracking work flow, for enhance supply chain management, for device surveillance and recall management for creating enormous resources for health services research and we're actually talking about using and we have a couple of studies in the process of funding now for funding what we're calling the CART access system, the accelerated cardiovascular comparative effectiveness study system, which is essentially leveraging the data collection processes we already have in place as a foundation. Now, clearly for things like clinical outcomes adjudication UDI want to have additional teams on top of that to actually perform adjudication of the data, but we have the data, actually being collected, for conducting real world practicing randomized trials. So in these few instances I talked about the CART concept and why this is relevant for registry processes, where we're going with expansion of new CART modules, what we're doing in terms of being RTLS technologies and why EDI is so important to us. The bottom line we're doing this, but we'd very much like to have to do with this -- this with our systems in a standardized way that brings in technology that brings together regulatory agencies, health care payers and industry, but you can see where we're going with this, we have a timeline that we're actually implementing the first of these RTLS system in this fall in the two regions of the VA with or without a data standard but it would be much easier and better for all of us if we can do this soon. Thank you. (Applause.)

>> Danica Marinac-Dabic: Now I would like to introduce Liz Paxton, who is going to present the perspective from the Kaiser Permanente registry. Liz has worked with the FDA on a number of projects, primarily in the orthopedic arena, as we were trying to explore the capabilities of the national -- Kaiser national registry, in helping us study the performance of orthopedic implants, and postmarket arena, and there are a couple of ongoing collaborative that are still in place, and I'm sure you're going to learn a lot from this national registry effort.

>> Liz Paxton: Thank you very much for the opportunity of sharing our experience in device identification and classification within our registries at Kaiser Permanente. First of all, I'd like to share some background information, about our implant registries, specifically related to the process of implant identification and meaningful attribute classification. I'd also like to share with you some of our current challenges with that method, and discuss opportunities and challenges associated with id (id implementation within registries, then finally share our keys to success with UDI registry based on our experience. Starting out with background we currently track and monitor 30,000 cardiac orthopedic implants within our registries, we have 5 orthopedic registries and we have four cardiac registries. These registries were designed to track and monitor implant re strition, implication, and reoperation rates, and also to identify patients at risk for failures and revisions. The industries were developed to assess postmarket surveillance of implants as well as identify clinical best practices for quality improvement. Most importantly these registries were designed to immediately identify and notify patients with recalled or advisory related implants. The registries in addition provide a foundation for research. In terms of data collection, the registries were designed by standardizing our clinical documentation. Information is collected at the point of care preoperatively, during the procedure, and at every clinical follow-up. This allows us not only to capture information for the registries, but to generate documentation and charting for the particular encounter. In this in turn returns a registry related to gem graphics, surgical techniques and implant outcomes demographics. In terms of the implant themselves, this slide gives you an indication of the lack of standardization, with bar code scanning as well as with lot numbers and cot lag numbers. But this is the point of entry into the registries, the manufacture sticker. Bar code scan these, and they become part of our EHR. As part of our EHR, we have manufacture, model number, lot number, supplier, and serial number. That information is then extracted from our EHR and linked to our registry product master list. This is linked by the catalog number and we have developed an attribute classification system to identify important clinical information such as the type of implant or the material, as displayed here within this slide. In addition we leverage existing databases within our system and create a comprehensive data source. So what are our current challenges? Obviously, the lack of standardized format is an issue in terms of entering information. Also, a key issue is synchronization and maintenance of a master product list. There are constant changes in implant names and catalog numbers, new implants, and this is very resource- intensive to maintain. Not only are we maintaining this for our registry, but other existing registries are simultaneous going through the same process, sometimes coming up with different classification systems, due to that lack of standardizations. In addition to this manual process for classification of meaningful implant characteristics we also have issues transmitting from the EHR to our registries. For example, EHR addendums may not transfer to our SQL registry because it's not real-time, and there's definitely a lack of bidirectionality. Another key challenge for us has been bar code scanning and the accuracy of the input in terms of our EHR. There are missing bar codes, and some are not scan able within our system, in those cases the staff must manually enter the information. There are also multiple competing bar codes on the same package with different formats, which creates decision-making in terms of entry of the information. Linear bar codes are split into two lines, on opposite sides of the packaging sometimes with partial data, again, creating difficulty for entry of the information, even with bar code scanning. It's time consuming and sometimes the staff determines that it's better to manually enter that information. This can then be entered into different fields within our EHR. So what are the opportunities for UDI registry integration? Well, first of all standardized format of the device identifiers would certainly help with registry development and maintenance. A linkage of the catalog number embedded in the UDI to the registry product master list with the detailed implant attributes would also be beneficial. In addition a centralized repos tear and maintenance of UDI master product lists with device attributes would be beneficial, increasing efficiency, and standardizing implant names and attributes. This would allow improved accuracy in EHR documentation of devices, as well as identification for recall situations, and also allow harmonization of device attributes for comparative effectiveness research. Challenges with the UDI and registry integration are, first of all, device attributes need to go beyond identification and provide clinically meaningful classifications. Some examples of the types of classifications that we have within our system include femoral head size, rotating versus fixed implants type of bearing service. In order to identify those classifications there needs to be collaboration between the manufacturers and the clinicians in order to establish those standards. And those standards would be required for implant names as well as attributes. Another challenge associated with UDI registry integration is the need for structural changes to EHR, supply chain, item masters, and registry architecture. A UDI would need to be mapped to existing clinical systems. And there would need to be seamless integration with historical registry implant identification and classification, for products that are no longer on the market but still being tracked within the registry environment. Additional programming would also need to be applied in order to extract key components from the UDI. In addition, EHR transmittal to registries will still be a challenge. Bar code scanning and data entry accuracy, some of this will be resolved with implementation of the UDIs, but there would still be errors associated with it, providing a need for quality checking on those particular implants. The maintenance and quality and linkage to the UDI database master product list is also a challenge as well as need for common language and structure among systems to transact information, so the keys to success for UDI registry integration. We would need an allocation of necessary time and resources to map and adapt existing system architectures. There would need to be integration and collaboration across the supply chain clinical systems, EHRs and registries within hospital systems. There need to be methods to ensure accuracy of the entry of UDI in registries in the clinical systems, potentially with quality checks built into the architectures. The UDI master product database needs to have clinically meaningful attributes, and I had it needs to be updated and reliable. Also, sharing key learning’s across health care systems will improve the integration of UDI within the registry and hospital systems. Finally, global harmonization for international collaboration surveillance and comparative effectiveness research will be necessary. Thank you. (Applause.)

>> Danica Marinac-Dabic: Now I'd like to introduce Dr. Rich Glicklik certainly the national leader in many aspects of the registry work, both infrastructure, and methodology-wise. We had the pleasure working with Dr. Glicklik's group several years ago when we asked the outcome scientists to produce the inventory and evaluation of the existing orthopedic registries. That was the work that set the gr oups for the strategic priorities for CDRH and also to form the central initiative and development of the national registry. So that's just one of the projects we currently have ongoing projects in the ophthalmic arena as well and I'm very happy to hear Dr. Glicklik's update on the UDI and the registries.

>> Richard Glicklik: Thank you, Danica, I try not to shut the machine down before David talks. We were all asked to address just three common questions, and I'll try not to repeat some of the great work that my colleagues have described. Those three questions were to describe the current state of UDI -- of identifiers in registries. The second were to discuss how registries might be enhanced by the UDI, and the third relates to the earlier panel and how EHRs, UDIs and registries might all work together. So I'm going to start the first question on the current state with my conclusions, and then I'll get back to a couple of examples, that -- and nothing here will surprise you. The problem is in the current state, is that consistent device information is critical for registries that ultimately want to aggregate data across multiple sites, settings, and other registries or other data resources. And the problem is that device information is not uniformly or consistently collected across registries, that include procedure device information. That's less of a problem with registries that are single device focused so there are some registries that are mandated and focusing on a single device. And this slide, which kind of reiterates what you heard from Liz and Art and Fred earlier in different examples, this slide is taken from that sentinel contract looking at different potential sources for a national orthopedic-distributed network registry. And the -- what we found were eight registries which we thought were the best and brightest registries, and they're listed here. And even in these cases, what you see are the device identifier types that are collected vary from implant name to using a more sophisticated third party database, and every mixture in between. And also, if you listen carefully to what both Art and Liz presented about bar codes, one bar code is not necessarily the same as another bar code. So it's more of a tower of Babel, than it even appears to be. Now if we move into other types of registries, which again are procedure-based but not necessarily developed for the purpose of surveillance, this is a registry run for the American society of plastic surgeons, which focuses on braes implants. And what you see here -- breast implants. What you see here is some very, very relevant information for the surgeon. But outside of this registry, that data is not going to have a lot of utility for the aggregation or for comparisons. And so by having custom and nonstandardized approaches to collecting data, even in- house databases, as the one Liz described at Kaiser Permanente, that make sense within the institution, they fail when you get to a broader platform. So how could GI improve registries in the future? Just the inverse of what I said before, if you can improve the specificity and consistency of the information, you can then aggregate across different institutions, you can aggregate across different registries, which is what Soko is trying to do you could link to other data sources. And another example is a registry that is being funded by CDRH which is actually a graft on registry. So it's a registry to follow intraocular lens complications, if you will, and it's being grafted on top of a quality improvement registry being run by two specialty societies for their own quality purposes. The problem is that these centers are in the business of ophthalmic care, they're not in the business of data entry. So getting consistent and usable information from them is a challenge. And this is in fact an example of a forum, a support case forum which is not showing the first -- the first data element we have now added as we move forward is the unique device identifier. And what we hope with UDI going forward in this project is that we'll be able to get information that's not only easier to collect for the clinician but ultimately useful from a public health perspective. Third question I'm going to tackle briefly is how could EHRs be used with UDI in registries so they can all live happily together. EHRs can collect standardized device information, routinely via UDI or specifically when needed we've heard that already today. And what I mean by that is that that information needs to go into the continuity of care document, or the credit CD. So that is sort of the common lexicon, that certified EHRs must use, and that we have a meeting of the minds to put that information in. And it may have already been done but I think it's got to happen. And once you do that, then data can be transferred to registries via interoperability mechanisms. And what you see here on the screen -- I won't even try. So what you see is a set of forms that are kind of sitting up there in the cloud, Dan levy is going to speak tomorrow, call them cloud forms. And what happens those are the registry forms, and when you have the EHR, which is sitting there, that form is surfaced in one of these inter operability models called retrieve form for ca data capture, and that data that's already in the CCD, the data that's resident in the CCD can be used to prepopulate that form. So if the UDI is there it can be pulled in. In the example I gave to the American society of plastic surgeons, next tech EMIR currently services their registry form, and in fact 80 percent of the data that's required in that registry is automatically pulled in from the CCD. But the device identifier has to be key stroked in, and obviously it's being key stroked in inaccurately or in a way that's not useful for integration. So we clearly have a path to go forward so in addition to using it for registry, obviously you can use the same mechanism to combine device information, to send the information on to an FDA registry reporting mechanism which is something Terry Reid is working on. Thank you for your attention. (Applause.)

>> Danica Marinac-Dabic: Now I'd like to introduce Dr. David Lewellan from the Mayo clinic, and certainly, spent a lot of years in the development of the national orthopedic registry, and we worked very closely, and continue to work very closely as the FDA leading international consortium of orthopedic registry effort and now we do have the American joint hip replacement registry that just started, along with the AHRQ funded force registry, all these are efforts that we'd like to think of them being complementary and not competing, hopefully the addition of UDI will have all three efforts to bring the best data to the American public. Dr. Lewellan.

>> David Lewellan: Well, thanks very much. I appreciate everyone sticking it out to the end, here, I'll try to make my remarks brief and to the point. I think part of the reason we're all so interested in this is that there's a perception I can tell you in the heart land that the FDA has the power to kill devices with the flick of a finger, it was only until Dade when I really realized that was true, with Jay Crowley. (Laughter) it's pretty important we pay attention to these initiatives, and actually we're very excited about UDI. I think our view of this is that UDI is a tool, a very powerful tool, one that has a lot of potential, but just like a shovel, where I come from, you can use it to shovel snow when you really need to, or hit somebody over the head, so very different effects just swinging it a little bit -- in a little bit different direction. So I think the key is going to be how we take UDI and make it work and support registries, so I think it has the potential to do. Just a few words about the AJ six RR, I'm going to -- AJRR, and talk about our experience and how UDI can help us specifically it was incorporated in 2009, really get rolling until 2010 with our board getting established and I think so and so on. And we're dedicated to a pretty simple concept, and that is we want to improve the quality of arthroplasty care provided to patients. So this is mission driven I'd like to take Joe's comment and maybe twist it a little bit, the sister who was the head of the clinic where I worked for many years. She used to say no money, no mission. So I think we're mission-driven for sure but the money is pretty critical. So as we go through this, I'm going to come back to how we can accomplish these lofty goals that are a way that's practical and workable for the institutions that have to get the data in. Counter status, we've completed a trial of our concept of how a national registry could work, we're talking about 5,000 hospitals and about a million joints in hip and arthroplasty with a minimum dataset, and this will allow us to do survivorship curves, think of this as a tripwire effort. We won't be able to provide really answers about what's going on, but we'll be able to focus attention where there's outlier behavior, either on the part of implants, but also institutions or individual physicians, and provide that information back to those entities so they can take a look at what they're doing and see if they can improve on the care provided. We're interested in higher levels of data but that will come later, as we move along or are in parallel. Publicly available reports; are the way this occurs. But also as we've learned from some of the international registries, feedback loops, letters, that go out to physicians, for example, in Scotland, when their performance is beyond a certain level from the mean, and interesting experience there, the guy that runs that registry got to a chance to sign a letter to himself, on his own data, when parameters fall outside the bond but it has a effect on people looking at how they might improve, with volume, and device specific information. The assumption behind this critical registry is that these entities that provide care will change their behavior when they're presented with credible data about how they're performing compared to a national metric. And the key is that they view the data as credible. And so that's really the challenge. And our approach has been to involve all of them in the organization in the registry, and ultimately the data that's reported if they have any gripes about the data they can help us improve it because they'll be part of it, part of the effort. I think the other thing to realize is that this is a big job, there are a lot of total hips and knees done in this country. Once operational we'll be larger than all the national registries in the world combined in terms of the number of joints recorded per year. So we've organized ourselves as I I've told you and moved forward with these efforts and completed a trial with 8 sites, 3600 arthroplasty, and a lessons learned analysis of that pilot, and I want to tell you about that related to the actual data part of this, and the implants. Realize as was shown well by Art, we're talking about lots of implants. One of the manufacturers I know of has 170 femoral stems that they make. Those are just different designs. And then there are all different sizes. And lengths, and so it really becomes a challenge to track all these, and you go well, does it really matter? You know I mean if they're all sort of the same. But I can tell you we have examples of implants where small changes made a huge different. A femoral component that was very successful and was made slightly differently by the manufacturer, and they thought it would be, you know, nice to add a few things on it and only by anecdotal report at one of the societies did we realize there were some break Jess of these stems occurring, and it was always on the left side, there were no right hips with broken stems, a previously very successful device. It turns out the thing was once in awhile with a little less support, cantilever, it's orthopedics, breaking on the left side because the etched icon of the implant company was on the flexion side of the stem. So little changes can make a big difference in how these devices perform. That's what we have to be able to -- why we have to be able to track them very accurately. That's why we're excited about UDI because it's really going to allow that level of, you know, surveillance. Now, the other thing to know is that during the pilot we learned that the people entering the data, in this case hospitals, as part of how we're organized, you know, need things simple. And with what we still thought was a very straightforward and simple application, the screens were too confusing, some of the times they didn't work, some of the choices weren't obvious to people, because it's people, after all, that are entering the data for you at the point of attack. We've found that there were problems in terms of gathering the data, and the time spent on manual data entry was found to be really unacceptable. The other thing we found is the error rate. Now, with manual data entry in our pilot, these were -- you know, these -- hospitals really wanted to do it, and these were surgeon champions and people really exalted this was the best of the best. It's not the last 20 percent, you know, we're going to have to drag kicking and screaming, you know. And we found with manual data entry, 12 percent error rate. And that was with operatic residents who were being ordered to do it. You know, they're at least ninth grade reading level I can assure you even though it's orthopedic surgery, and motivate sad -- motivated to do it because they're going to be looked at in terms of their performance, even though it's 12 percent error rate. And some of this is related to missing data, in terms of how error is reported even on electronic feeds. This is an issue again points out the fact we need to have some method of ensuring data is inaccurate, even though data is moving along, and entry points back to the data so it can be corrected and brought up to snuff. So more refined data capture and flexibility to match data structure at hospitals is very much needed. Automatic validity checks, a requirement, you know, how we organize the implants. I can just tell you that it's a huge issue, once you get the data in, then to make sense of it. Because even if you have a database with a whole bunch of devices in there, there can be patterns of failure among different kinds of devices, and we're very interested in whether or not it's across a whole class of implants or very specific to a particular manufacturer. Most of you here are familiar with the metal on metal business that's going on, it's obviously an example where there are design related effects and maybe some generic issues, narrowing the tolerances for the surgery, making it harder for people to get it in right, with nieceed wear, with all the designs, when they're put in in a mall positioned way, but it's true for a number of other technologies as well, unless we have them clustered together in ways that sometimes aren't obvious. How about the RA of the implant. That's the surface roughness. Turns out that's pretty important, in some method implants. It's not part of the stuff that's on the box but it could be in a UDI-D, okay, database, so that later we could ask the question, you know, do all implants with an RA over 30 end up loosening at a higher rate. We can find that out. But that's the kind of stuff we have to be able to access in a reliable way somehow with current and emerging data collection systems. So we're looking forward to ways of doing this. There are some existing efforts. We're using one that Stan men den hall developed with some effort and pain over the last decade or more. I'm interested in this German initiative that we've heard of recently, the Germans are very good at organizational schemes and charts, so it may be very elaborate, but it could provide us the sort of unabridged dictionary for orthopedic implants that we put in, sort of a bird book, if you will, you know, field guide to the identification of implants and the tracking of those. So we can tell about all of those with long beaks or a certain song, you know, patterns of performance or behavior that may traps late into actual clinical pertinence. So translate into clinical pertinence. What can UDI do for registries, it will certainly make our job easier in terms of tracking implants, hopefully produce accuracy. And faster easier reporting by entities that report the information. Because in the end the discussion that occurred earlier is very important. We're going to succeed or fail not because of our efforts to start up or ability to raise support for this, we've gon gotten all that. In the end I think it's going to be either carrots or sticks. That get probably hospitals to report this data. Not just for orthopedic implants, but for many others. And then finally, the third key element, besides carrot or sticks, that is protection for entities collecting data, trying to improve patient care. Protection from regulations that are there for good reason, to protect privacy and so on, but we need a safe harbor, someplace to do this as a quality initiative to improve care. Because right now, those hurdles are quite high, and jumping over them is very expensive. In terms of the business associate agreements, and IRB approvals and sort things that can stand in the way of trying to get this done. Thanks very much. (Applause.)

>> Danica Marinac-Dabic: So I would like to thank the panel for great presentations and would like to open the podium for discussion. If you notice in your program there's actually no timing where we should end these sessions. So we can stay here. We just need some good questions. Would you please introduce yourselves

>> I'm from Johnson & Johnson. This is a question for David. How are you looking at documenting loss to follow up and trying to deal with outpatient interaction that didn't happen at the hospital or for that matter revisions that happen elsewhere or things like that.

>> David Lewallen: That's a great question, and if you look at other registries around the world, where they've developed, all of them, going back to the Swedes who kind of got this going on a national registry basis, have started with limited datasets and expanded those as they've gone along and they've got en more mature and collect more and more, and progress to higher levels of data collection to more and more information about comorbidity and patient outcomes which has been -- which has been of interest in the last few years. Currently we're focused on when they go in or when they go out when they come in or when die what that means is survivorship tables curves for particular devices those can be stratified by comorbidity that come up whether it's smoking or whatever that can be extracted from some cases administrative datasets, a lot of that stuff is is reported now, a lot of the comorbidity stuff is easier, because o administrative stu We'll get those survivorship curves to begin w and then move forwards higher levels of data collection, out patient stuff, you know, patient reported outcomes. You know, a lot of this as you know, is moving fast, and it's touch screens and computers and so on, but you know, we have patients in my community that live under bridges, they don't have computers. So we've got to initially get a handle on the whole animal, and then we can move towards the icing on the cake.

>> to interact with some of the EMR data aggregators that we talked about. Synergy, and others who can at least create a small cohort on the side which has returned information that connects a little bit more.

>> David Lewallen: Yeah I agree completely. In fact we've had some conversations already, in my view Utopia would be to have this sort of base line thing with a module construction, the ability to hook on, you know, meat on the bones of the basic thing, with, you know, higher levels of data collection. And then modules for Cerner or epic hospitals or others, so they can -- you know, like the cardiologists, the cardiologists are heroes I hate to say that with them here, but they sort of are, in terms of already done this and having worked with some of the EMR vendors and there are -- you know, there are examples that we can try to copy.

>> There's actually -- not to get into a registry discussion too much but there are really only two good ways to answer your question, which is the one that Dr. Koontz raised earlier which is the ascertainment bias and now it's ascertainment on follow-up that's either go directly to the patient, because they may not come back to the strrks or to go to an administrative database that's complete. And match the two.

>> As to what rich said, in fact it ties very nicely to the incentivize being able to link to registry data, to follow up, There's an important initiative FDA is funding now as part of Sentinel, that an on mustily registered data sources that can help advance the follow up for registries like AGR.

>> Soko Setoguichi: As I said I wouldn't be trying to link registry data to CMS data, the problem is we -- -- for other patients you have to go to multiple sources either commercial, Medicaid stuff like that, pooling those data could be very difficult. Just one caveat.

>> Rick -- Medtronic, this is for Dr. -- your VA model is very inspiring, I think we're starting to see connections between the hope of EHR which is really focused and optimized for day-to-day patient care, taking the typical kind of -- you know, text and handwriting, you know, aspect of medical care to electronic manageable database, so one where I'm more used to, which is a very rigid and well-designed set of questions, you're calling field specific. And I think that they can merge, and I think that you're on to something. But I was jury curious how you solve things like for example, say that you're interested in the outcome of a patient who received a coronary stent and you want to know for chur whether or not this patient had signs of stenosis or may have triggered a silent stent, or one less than slent expur seeing PCP in a clinical study we would have mandated fields asked whether the individuals would be trained to answer the questions in a way to make sure that they capture all aspects. And a PCP office obviously that patient may have been exposed to cancer therapy, maybe to some orthopedic devices and/or drugs and may be on 20 different drugs, how does one make sure that they actually capture events in a clinical care scenario and then translate that into inference about the results of, say, a device, where, you know, one would be -- the gold standard would be obviously a specific registry where all those questions are mandatorily asked and therefore the absence of data does suggest that it's a negative rather than whether the question was asked.

>> The challenges of adequate -- I think it's a great question, and presents a lot of major challenges. What I can say is that within the VA system there are patients who get most of their care in the VA system, and none -- or all their care in the VA system, there are patients who get some of their care in the VA and some outside the VA, and there are patients who get most of their care I'd say at the VA but only a little bit of care in the VA. Each one of those different groups of patients present different sets of challenges in ways to bring these things together. What I can say is that -- just in interest of time won't go into it in a lot of detail, but we make a distinction between our live clinical dataset that we're actually using for clinical work flow and documentation, in the coronary vascular procedures we're doing, and the second analytic dataset that brings in external resources including Medicare data, other administrative data from the VA that do bring in outside information, such as from the VA's corporate data warehouse and the Austin technology information center which is the central data repository for administrative stuff. Beyond that, the other thing I'll say is that the VA -- I think does a pretty good job of tracking things like mortality. And other outcomes. So primarily because every single mortuary in the United States gets $200 if they report the death of a veteran to the VA, a little known fact, but it is true. So for major hard outcomes like mortality I feel fairly confident that we have the ability to capture those. But your points are good ones and this is actually one of the things that we're hoping that the implementation of meaningful use of health information technologies and standardization with a capital F not just for device identifiers but standardization across health records in general, as brought out in the high-tech act, for the -- meaningful use, will ultimately help all of this down the road.

>> Could I just make a comment on that. You know, one of -- fares, the point was excellent but maybe what it relates to is outcomes, and maybe intermediate outcomes as you're get to go baiger one. My only fear about that and I think your comment is great picking up on mortality that sort of thing. We have a big challenge sometimes just to get to those bigger end points. We don't have, you know, $200 incentive for most deaths, but we do have a mortality index we can get to. We have claims, you know, CMS Medicare claims, I agree with you about the lack of commercial claims, and that sort of thing, so we have a big enough challenge to get to these large end points. I think I would not want to freeze our attempts to move ahead because we can't get to the sorts of things we would really like to. We need to move ahead with the challenges in front of us and address those first, and once we get that done, then maybe back up and try to address some of the things he's talking about.

>> If I could just follow up on that. I think to elaborate a little more, from our perspective in the orthopedic side, you know, there's just not enough money around to try to get all the detailed information that we want on the kinds of things that we do where people aren't dying but they affect their day-to-day activity, and thern be able to sort out all the issues folks are interested in. And so we really view this, you know like a smoke alarm or a trip wire like I said before. Set something up that lets us focus our attention and scarce dollars on areas where it's worth some kind of detailed study to try to look into, you know, very subtle information. I just don't think registries for the ner term are going to be able to deliver on everything everybody wants. Now, down the road who knows with EMRs, I mean Facebook didn't exist 10 years ago, for gosh stakes, who knows 10 years from now.

>> Did you want to say anything, Mike

>> Good afternoon Michael Steinbeck Johnson Johnson I want to thank the panel for the interesting presentation, and wanted to address this to anyone who cares to respond. And that relates to if anybody would have comments on the validation procedures that you may have employed in some of the registry data that you've been collecting, I think it would be worthwhile.

>> Fred Resnic: I think it's a freight point and goes to how do you assure the quality of the data that you're analyzing, and obviously there's wide spectrum, just as there's a wide spectrum of the granularity of the data that's incorporated into various registries. There are certain characteristics of certain registries that sort of bring with it, sort of require, higher levels of data adjudication review. So the mandatory registries, one can look at the policies that are enforced at those registries, so Massachusetts, PCI, and cabbage actually all of cardiac surgery registry, there's rigorous adjudication, and case review with clinical review of all adverse outcomes, with exceptional -- you know, appeals, and there's a whole process in place. At the NCDR level, the national level, there's a random sampling of certain number of centers or sort of audited per year, but I think you can assume, and I think NCR would accept that there's a wide variability in the accuracy of adherence to data definitions and the documentation of outcomes. And I think you just need to incorporate that into the types of -- you know, and the limits of the questions you're going to ask of the registries. So, you know, I think as the larger sort of national, international orthopedic registries expand out, the question, or you know how to assure data quality down to the level of the participating hospital or surgeon is not a trivial question people do not have the time to maintain the level of ceation that's necessary -- education that's necessary and not the level of training for perspective clinical trials, On the other hand for many of the big questions one wants to ask, and if you can make the leap that there's no -- if one can accept that there is not a likely bias in how one device is documented versus another device, then comparing devices may be a reasonable top level analysis for public health officials even though it may not be a detailed enough analysis to come to meaningful understand of device failure or not device failure it may be a signal or hint that it requires more in depth analysis than a formal post approval study would require.

>> I want to comment on our valid procedures within the Kaiser Permanente system. First of all we use independent databases to make sure we're capturing all the procedures. And second of all we actually review every adverse event through chart review, and confirm through that validation process. And it's a really critical aspect of a registry in terms of being successful and accurate, we find there's a wide range of errors associated with coding, and as a system that must be incorporated for registry to be successful. So it's a very good question.

>> Can I add to that? Experience from center for education and research -- -- registry. -- Cornell was building the registry has the building of building the registry and collection of serial numbers and bar codes as part of that thinking later on it was going to be easy to transfer that into meaningful attributes. So if the date came when we have to classify. Now we have the software, we have to classify, we realize about 25 percent of the data doesn't match to the data classification software that has specific information as to which digit should match to which part, and how you can later on classify. So we have to go back and correct the errors after that, 20 percent didn't match pull out all those. So what is the error, which digit is missing here or there to match to the catalog number. So that classification is suddenly interesting link to accuracy, because classification software has specific information about product -- if it's UDI it would be UDI, did you capture it correctly.

>> David Lewellan: Could I just say one other thing on accuracy, on validation of this stuff. I was just with folks from the Australian registry and very interesting, they think one of their critical elements to ensuring accuracy is they have a system for physicians to look up their own results. So they do the stuff on the front end to try to get it right. But then they allow surgeons to look up their own individual results to make sure that the adverse outcomes that are being reported in the registry are actually accurate. And they find a few mistakes, but there are very few. They think the big benefit is the surgeons now believe the data, because they realize their own data is accurate, and they start believing nate rest of the information is accurate on particular classes of information -- of implants and so on. And for the work we, do maybe even more so than some others, we think the biggest behavior changes that will improve patient care are going to be among physicians. And so it's critical that they buy into this and believe that the data is accurate, so that they then change their behavior.

>> Dick en son: one of the common themes it seems to me in all the presentations was the desire for more data and attributes in the registry. But I think from my perspective that kind of goes beyond what is currently aspected by industry, what's currently in the global harmonization Taskforce standard on UDI, and I guess I want to know, is that an aspiration at this point, or is it an expectation? -- anybody can handle the question.

>> One thing they realize is we're the consumers of the data, right? I'm not sure we're the policy -- we're not writing the rules. I think the requirements that Jay laid out earlier is for the level of detail to match to basically a specific device. I think that allows for an ongoing evolution about classification and additional attributes. You have to have the unique device, but the met a data that can surround the device can actually mature over time even retrospectively. I actually think it's very important from a device safety surveillance perspective to think above the level of the actual specific device. bawss so many are iterative so many may share principal components for which the outcomes are related to the principle component. In my work, interventional cardiology, the same stent may have completely different quote devices because of the catheter delivery system. Depending on outcome of interest, if I'm looking at long term stenosis as -- I'm interested in the stent itself if I'm interested in the failure of the device itself, I may be interested in both and have to break it down further. I think from the perspective -- I'm thinking about the UDI from perspective of postmarket surveillance in the registries, you have to get it down to the granularity of the unique device or it's not very valuable.

>> For us I think the attributes aspect of UDI and the potential there is the most desirable. Currently we're able to track our devices, we can identify them mplt R, but we're identifying and classifying them in a different way than they are in Australia, Norway, so some sort of standardization would be very desirable The German group that Dr. Lieu Ellen mentioned has been very instrumental in getting the manufacturers to all come together and maintain an attribute database and that would certainly help research and registries in the United States if we could get the manufacturers and clinicians to work together to identify those key variables for postmarket surveillance as well as research.

>> specific industry is going to do country by country wouldn't it be nice to do it once?


>> I think everybody's preference would be to do it once.

>> Right.

>> Soko?

>> Thank you. I look to real-time what Fred said we're on the consumer side we always won't more data but there's a conflict between what needs to be provided there's a cost. But as far as the UDI as long as they capture safety and effectiveness specification I think the only thing that needs to be provided is UDI, aid like to add one caveat, UDI is just a string of numbers, so if we rely on manual entry of the UDIs to the registry it will increase more errors in the data base. So I think automation of the data entry is probably key for the UDI system.

>> If I can add a couple things from the idea per speck I have think the challenge is somewhat different if we go from one device type to one device group to another, I think orthopedic devices in particular especially in light of there are -- -- the systems but they actually have many components many of them are coded in different ways in different countries, some of them are assembled at the operating table, and there are lots of issues, we as the FDA try to be more creative in the ways how we design these mandated -- there are opportunities to go beyond national boarders and look at international registries that have many decades of great experience, and currently the international consortium of orthopedic registries have access to 3.5 million patients for implants so that would definitely be a great way for us to go and ease the burden on industry as a matter of fact to -- not to be in need of designing the new studies but rather go to registries and capture the data. But the problem is that, you know, many stems have different numbers and different -- in different countries, we're interested in how the articulation system works, but as Dr. Lieu Ellen pointed out sometimes a very small tweak or small change can of critical clinical importance so to us from our perspective those challenges have to be tackled somewhat device type specific and working together I think will ensure that we are asking the right questions at the right time. So that would be my perspective on your very valid question. Any other thoughts? Any other thoughts from the panelists? Well, thank you very much, I would like to thank you for staying a little longer than originally planned, and would like to invite Jay Crowley to make some concluding remarks for the first day. Thank you. (Applause.)

>> Jay Crowley: Just quickly, again thank you all for coming today, we're starting at 9 AM tomorrow morning so please try to get here on time. All of the slide presentations will be posted, so I apologize for the problems with panel 1, don't touch this button. And hopefully we'll be okay tomorrow. I think that's it. If you have any questions or concerns, you can find me or Diane Norcutt who was out there by the registration table, again thank you very much, and I'll see you all tomorrow


Day 2

>>Jay Crowley: All right. Good morning, everyone. Welcome to Day 2 of our Public Workshop UDI for Postmarket Surveillance and Compliance. Welcome to everyone in the web cast land. For those who missed yesterday, I am Jay Crowley with FDA Center for Devices and Radiological Health. The slide presentations from yesterday and today will be available on the web in a couple of days. For those of you who missed yesterday or because of our technical glitch, didn't get to see the slides yesterday, they will all be available on the web. Just for those who weren't here yesterday, let me just summarize what we did. There were two panels yesterday and there's four today. The two panels yesterday, the first one was on the adoption implementation and use of UDIs, Unique Devise Identifiers in electronic health. We talked about or the panel talked about current and future use cases using these UDIs, some of the barriers and incentives for actual adoption, and a number of other issues. One that I thought was very interesting and we didn't spend more time talking about, but something we'll have to deal with at some point is how much data associated with the device, how much of the UDI information will actually be carried along in the electronic health record. We touched on that, a couple panelists touched on that, but didn't get into it too much. The second panel was on the use of UDI in registries. We heard from a number of current owners and operators of registries about some of the challenges they have now with device identification and some of the potential uses of UDI in the future in those registries. So that was yesterday. It was a very good day and I appreciate EFRP's participation. We're going to start off day two here with panel on standards of national and local data standards for UDI and your moderator for this panel will be Terri Reed. Terrie and I have been working together on UDI for - what's that? Too long. Too long, for a number of years and I really appreciate Terri Reed's help on this and so, Terri Reed.

<< Terrie Reed: When I go to work in the morning I have two major focuses, pretty much everyday. One is as the business program manager for the UDI database trying to make sure that is moving along and that we are going to have that database up and running and collecting quality data by the time the final rule is out. The other role is of Associate Director of Informatics. The things I think about are how UDI plays in the overall data standards of the big ‘S’ standards that Dr. Verosi talked about yesterday. There are a lot of standards UDI has to sit with, there is a standards landscape. While UDI is a standard, we talked about that a lot yesterday; it has to fit within this whole world of standards. And I am pleased to have assembled for you today a group of experts who spend their lives on data standards panels, people who develop the standards, many of which were discussed yesterday. We have experts on meaningful use; we have people who work on the data standards of electronic health records. There was a mention yesterday of talking about comparing those two, how drugs were implemented in NDC, we have a person talking about that. We have someone who actually did a demonstration project putting UDI information into claims data. So it was very nice yesterday to hear all of these things that people wanted to hear about and here are the people that are going to share that information with you. So to start off with, we have Jamie Ferguson, who is the Vice President of Health IT strategy and policy at Kaiser Permanente. He served on the national level on health IT standards committee and a variety of other committees and he's going to talk about the current state of health IT data standards.

>> Jamie Ferguson: Thank you, Terrie. Let me just find the slides here. Excuse me. Yeah. There we go. Okay. Good morning, everybody. I am going to attempt to set the stage of talking about standards in EHR certification and the EHR standards process overall. I want to start out with the standards that are currently in use and those that are being proposed and discussed related to the meaningful use program. Meaningful use is an incentive program of CMS and related to that is an electronic health record certification program where EHR systems are tested against test scripts that are developed by the National Institute of Standards and Technology. And passing these tests to get certified, then enables an EHR system to be qualified, which is one of the qualification steps that hospitals and eligible professionals then use to qualify for the meaningful use incentive.That is sort of how the pieces fit together. So when I say meaningful use standard, not really meaningful use standards, they are really EHR certification standards that are subsequently required for the meaningful use program. I'm talking about this in terms of timing. So those that are final for the current stage one timing which is the stage that we're in, most of the EHR messaging uses HL 7 version 2 2.5.7 (inaudible) specifically messaging. There are some electronic document standards primarily hl7 continuity of care document or CCD. We have in terms of the terminology and vocabulary requirements in stage 1, the list can use Snomed CT or ICD 9 and for prescription messaging electronic prescribing using (inaudible) script standard. In terms of stage 2, these are currently recommendations; rules are not out yet on these. These are the recommendations of the Federal advisory committee that I sit on. The quality measures, which are in I think 23 different clinical domains, are primarily using SNOMED CT and RX Norm for drugs to identify things that are measured and the quality measures, and so then having implemented that vocabulary for quality measure optionally used for other things in the EHR. Other recommendations include the use of care plans represented in the HL7 continuity of care document standard and problem list which is from Snomed or ICD 9 in current timing to Snomed or ICD 10 based on the change in HIPAA rule for ICD 10. In addition, there are standards under discussion for stage 3 timing. We're not really at the point of even beginning. We haven't held any hearings on stage three recommendations yet, but some of the standards that are under discussion include getting more specific about how terminologies are used in the transaction messaging. So for example, in the prescribing there is a recommendation that the RXnorm semantic drug and package names both specific and generic must be used in the NCPDP script transaction as today alternate vocabulary terminologies are allowed. There is a question also on whether or not claim attachments will be related to meaningful use or EHR certification at all and certainly a new claim attachment rule is required again in current legislation as it was in the original HIPAA, but we don't have that rule yet. But if it does, the timing would be conducive to making it into EHR certification so that potentially there is the potential the same clinical documents that hospitals and clinicians use could be used to provide information in the claim attachments. Then the lock stand other position of the standards committee since inception is problem lists should move to the exclusive use of Snomed CT for meaningful use CT. There is progression of allowing the current administrative classification system otherwise known as the billing codes of icd 9 to be used as an alternative for those who are currently using ICD 9 and ICD 10 in the future. But really there is migration to Snomed CT, and that matches the use of Snomed CT and the quality measures being proposed and developed in CMS for measuring quality and performance for gaining the incentives. So I want to switch from talking about the standards to talking about the timeline for standards and the purpose of this is really just to impress upon everyone the sort of the lengthy timeline and the lengthy cycle time that's required. So we had the Recovery Act back in February of '09, and then very rapidly the standards committee was formed and informed the interim final rule that came out actually in January of 2010, followed by a final rule for the initial EHR standards in July of 2010 and so the standards in that rule then were put into the certification process. The first EHRs were certified just a few months later and we now have well over 300, I think over 350 EHR products that have been certified through that process. We also have made the recommendations that some of which we just reviewed and so we expect the stage 2 standards notice of proposed rule making to come out later this year. Now in terms of timeline, look at all that activity, you know up to a couple of years ago to set the stage for standards, but in fact not all of those stage 1 standards that are in EHR certification are expected to be required for use by CMS until 2014 currently. So there's actually quite a lengthy time cycle there and then sort of the first carrot, then the stick, is the approach of meaningful use and so after 2015, there's the possibility in the legislation for Medicare payment cuts of up to 5% for those who are not meaningful users of certified EHR technology. So now overlaying on to that timeline, just for discussion purposes, where could UDI possibly fit into this, if UDI were to be put into the EHR certification process? So if we had for example just hypothetically later this year for the UDI, then following the previous timeline, it would be reasonable to expect that a future EHR standards rule could potentially include the UDI somewhere between the end of next year and the end of the following year. That would then introduce the UDI into the certification process. It would enable NIST to have the test scripts that would allow the software to be certified and then products could subsequently come to mark NIST implementers, hospitals and provider offices could start to implement the software that included the UDI in the certification process. So then whether the UDI actually became part of a meaningful use measure such as a quality measure related to patient safety, a CMS quality measure or whether it were measured in some other way through compliance mechanism or quality or performance reporting, the timeframe for including the UDI as a standard in any such measure would be later, again, so roughly 2014 to 2016 and so again the purpose of this is to impress on everyone the long time scale and that you can't expect to have a proposed rule this year, final rule next year and everybody just does it, right? It actually takes time and so some of the things, some of the reasons why it takes time are here and this is actually I'm really going to start with second bullet here on the fourth slide. And some of the reasons why the timeline is longer is the transition time is required for testing and evaluation of the new coding system for its incorporation into the certification criteria, and for developers, obviously to include these things in the new systems. And so this also relates to transition plan. So I mentioned earlier that the standards committee has recently recommended the use of exclusive use of Snomed CT for example for problem lists in quality measures in EHR certification and in the meaningful use program. Well, that requires a transition plan because currently most hospitals and physicians don't use Snomed CT for those purposes if CMS requires quality report on that basis then a transition plan is needed which includes actually cross agency support resources to be supplied to those eligible professionals and eligible hospitals in the form of things like cross maps, utilities, tooling and software products that then need to be provided and this actually goes across in the case of the use of Snomed CT, goes across the etc, the NIH, the ONC and a variety of different agencies have to be involved in providing different aspects of support resources that all fit into that transition plan to fit it into that timeline that I just mentioned. So I'm going to I think we're not doing questions for each panelist, we're going to go through the list, so that's what I wanted to present. Thank you. (Applause)

<< Terrie Reed: Our next speaker is Betsy Humphreys, who is Deputy Director of the National Library of Medicine. She's on the vocabulary task force of the health IT standards committee and she's going to talk about the lessons learned from drug identification.

>> Betsy Humphreys: Okay. I gather that I wasn't able to be with the group yesterday and I gather that a number of the points I make might have been made yesterday, too, so I'll underscore them. As I expect everybody in this group knows about four decades ago, the FDA and the pharmaceutical industry partnered in the development of the National Drug Codes or NDCs, which are analogous to the Unique Devise Identifiers UDI. On balance UDI have been good thing and implementation decisions made long ago might well seemed sensible at the time. Nonetheless, NDCs implemented in ways that reduce subsequent utility for things like healthcare billing, electronic health record and clinical decision support and over the past decade the FDA and many of its partners, including the National Library of Medicine have extended considerable time and effort to make up for these deficiency s and to integrate NDCs into a network of standards that provide the functionality needed to support safe, high quality healthcare. The public proposal for the UDI database, as it exists now, shows that FDA and its international regulatory and device industry partners intend to avoid the features that affected the nonregulatory usefulness of NDCs., including national rather than NBL coverage, lack of comprehensive public registry and lack of any standard nomenclature or classification of the drug products. The UDI database is likely to be a great step forward and I have a few friendly suggestions that may help to ensure that it achieves its potential to enable safer, more effective and more efficient healthcare. The view of the desirable future has at least four elements, two of which are shown on the slide. The desirable UDI implementation allow any person or computer system anywhere in the world to easily determine if a UDI is valid and by that I mean that the UDI belongs to a device that is registered and approved for use somewhere in the world. And to allow retrieval of structured information about the product, the UDI is associated with, not only by the UDI, but also by all of the product specific names, alternate IDs, standard nomenclature and various and important characteristics of the device, include anything tests that perform, any drug that delivers, key substances, it includes, etcetera. We are getting close to this goal for drugs approved for use in market in the U.S. through combination of electronic structured public label submitted to the FDA by drug manufacturers, RxNorm clinical drug vocabulary, drug classes, etc. There are still NDCs in wide circulation that cannot be verified and the lack of readily available information about international brand names and the drugs they represent is a significant problem for U.S. healthcare providers everyday. We need to use the UDI to minimize this problem for devices. When a person with an implanted device approved for use in Germany, shows us in the Mayo Clinic, the physicians there really need to be able to get access to information about this device. To underscore the implications of the first two elements of Allen's desirable future, the ability to verify an UDI is valid would be greatly enhance Federal UDIs were assigned as a byproduct of the first registration of a device with one of the world's medical device regulatory bodies and if the information from that first registration was then immediately available around the world. This is relatively easy to do actually today with today's technology and the international assignment immediate exchange of DNA sequence numbers may provide a useful model. The assignment of NDC by manufacturer system one reason it has been so difficult to determine which ones are valid and to obtain standard information about the products they represent. The problems associated with duplicate and invalid NDCs, and lack of any mechanism to verify them, were major factors in their disapproval as a standard for HIPAA billing transactions, although they were otherwise really quite an attractive choice. No doubt manufacturers have many important uses for unique ID prior to registration and approval of the device, but there's nothing to prevent them from assigning their own ID prior to registration and include today as an alternate ID in the UDI database. The UDI database draft proposes the inclusion of a standard name for the type of device, specifically from the global medical device nomenclature, or GMDN, excellent feature as long as we are successful in achieving the goal of making GMDN available under licensing term that support general use in healthcare. I guess I'm happy to report that GMDN health terminology standard organization which owns SNOMED ct were meet burglar this very thing last week in Singapore. We will also need to help users of the universal medical device nomenclature system make the transition to GMDN as Jamie has just referred to. UDIs are definitely necessary, but they are not sufficient to support many healthcare uses. When you need wheelchairs in the emergency room, you may not care too much about the specific products involved, but you might need to know whether they are motorized or not. To move on to the third and fourth elements of NLM's desirable future, it would be great if the information in the UDI database and in the eventual product descriptions I hope will go along with it for approved devices were comp parable to the information used in electronic health record systems. For example, if the device performs a test or is a test kit the UDI database should include standard identifiers and names for the tests involved from LOINC standard for test that is going to be used in EHR systems and electronic health record exchange F. It contains substances that are known allergens it would be great if use the same name from snomed ct, as of target for electronic health records. Comparability with EHR will make the device registry more useful and clinical decision support including generation of alerts and reminders. The UDI database should also allow and I'll give the device manufacturers some hope, through optional data elements, explicit connections to relevant information and other sources such as the NCT numbers for records and clinicaltrials.gov that, have information perhaps about the trials which provided the evidence that led to the approval of the device or even to trials with study comparative effectiveness. In sum, I think the UDI database can and should be a great step forward to a very desirable future in which we improve the quality and safety of healthcare that involves medical devices. NLM hopes that we will implement the UDI in a fashion that reduces our future collective level of effort to achieve that goal. Thank you. (Applause)

<< Terrie Reed: Thank you, Betsy. Our next speaker is Jason Colquitt, he is from Greenway Medical and EHR vendor. He is part Executive Director of Research Services for Greenway and on the Executive Community for HIMSS EHR association and he will be talking about UDI option within EHRs.

>> Jason Colquitt: All right. Thank you very much for having me, Terrie, Jay. Appreciate the opportunity and especially sitting along these esteemed panel members, it's very exciting to see and I think you will see a common theme. I'll try to stay brief, but I think standing up here representing electronic health records, I spoke yesterday, I've been developing software in the EHR space for 15, I know some of these guys have done that a lot longer, but coming to the standards part, I think that is a very important piece of the equation that we need to take into consideration. I know every one of us has a lens that we see UDI and standards through. I just want to clarify these are my lenses that I see; personally I'm working at Greenway Medical Technology developing EHR software. I also am on the advisory board for CDISC, and some comments yesterday definitely seeing use of this for the research aspects. Also as mentioned, 42 companies are represented in the EHRA and we think we represent a large majority of the providers installed and meeting the meaningful use stage 2. So from our standpoint, you know we're very excited about where standards are going, where UDI is going. So another lens that I see things through, as well as IHE. More my standards D-Cat, quality research, public health, I was former co-chair of the QRPH committee within IHE, on the output side, which I'll talk about in a minute, quantifying the data and then sending that out and measuring that on the output and coming up with numerator, denominator on the output. Those are a few of the lenses I'm seeing through. Just to level set that, because I know each of us brings our own lens of how we see this through, I think that is important and everybody's input as was alluded to yesterday in opening all of us are stakeholders in this process. So EHRs state of the union and some has been explained with the meaningful use. But I want to and hopefully you guys are thinking the same EHR that I am. I speak in a lot of audience where they think EHR and it may be a 5 or 10 year old EHR. The EHRs I think of are the 42 and electronic health record association. The floor of what I'm talking about is the meaningful use stage 1 and the ceiling is stage 3 and plus. All these EHRs I'm speaking of are gunning toward where stage three is going. So we at this point, discreet data capture. We're inputting through own user interfaces this discreet data to capture that from physicians and office staff, any staff in the operation. So we're consuming that discreet data by input. We're trying to consume as much as we can through other sources so that there's not error in inputting that data. UDI fits right into that that we want to consume that. Just a couple of examples. We're consuming from health information exchanges discreet data. We're -- I have a whole team that works at Greenway, that's all they do is import from devices, so definitely gets UDI into that aspect of us importing that. And then pharmacy and there is a whole long list of inputs capture that we do as EHRs. Just to make sure we're level set on, we are today pulling data in from many different sources. Once we get that data in, this is kind of my NQF hat. We do data aggregation for different measures and different programs. We talked a little about meaningful use and clinical quality measures that we're churning through; joint commission has their measures that we're churning through, to support their CMS physician quality reporting system that we're churning through and aggregating data to eventually output and that is the last bullet there, discreetly outputting that. I just wanted to let you guys know EHRs are today discreetly outputting so as eluded to by Jamie, the continuity of care document, hl7 v 2, 2.5 is a lot of the messaging out of stage 1. And then also that is kind of the format of which we're exporting those in. There are the mechanisms - we're doing it. We're doing it, you may have heard of the direct project. There is direct project kind of point to point push out that discreet data and then there is a registry repository model. So I'll get acronym heavy XDES - cross document enterprise exchange, a lot of HIEs, that is the model they export. We export in those fashions. So I title the slide the EHR Edge and in the standards work that I do in PROT files that we write, we call a lot of times the EHR the Edge System. So what is Edge in Merriam Webster describes it, area or object begins or ends. What is applicability? I mentioned a few. We definitely have to at that Edge EHR and we have to figure out where does UDI fit? We got to capture that, we got to leverage it within our system and pass it around. We have to export it across systems. And then the last one, output. Definitely output it. Figure out how that fits into standards that are here today. Last slide, so what are the available leverages today? You heard a few from the first few panelists. I know the rest will elude to this, as well. There are mechanisms there today that we need to make sure we leverage. So there's structure product labeling, Hl7 that is already established. We need to make sure UDI is there and we as EHRs are able to consume that. On the output side there is ICSR within HL7, standard to output case safety reports. Those are two things that are in the works and there is a lot more going on. Just to mention two that is already there. That kind of talks to the structure of the data. The last bullet demonstration and pilots, there is standard called retrieve form for data capture and I know this will be discussed in some other panelist discussion so I won't go into detail here, but just to tell you, the DIA conference this year we showed and piloted how we could use that and capture the UDI type information and report that out on adverse events. So these mechanisms are here. My caution at the bottom and I talk across CDC, CMS and FDA, from EHR Edge system standpoint, we are doing a lot of this I thinks, but if we can find synergy between the standards that are in existence, that means a lot and gets things implemented faster rather than doing duplicate work. That is my word of caution at the end; with that I'll hand it over to the other panelists, but thank you very much. (Applause)

<< Terrie Reed: Thank you, Jason. Our next speaker is Sara Rivera, from the California Department of Healthcare Services where she is project manager and has worked on an and will tell us about lessons learn Friday a pilot that added device identification information to the California claims data.

>>Sarah Rivera: Thank you, Terrie Reed and Jay for the invitation to participate in this panel. I started working with California in 2001 to help the Department comply with HIPAA regulations, which includes privacy and security and transactions and code set standards. The Department has some serious concerns about the HIPAA standards for medical supplies and devices. I was told and later convinced through research that HIPAA standards for medical supplies and devices would compromise patient safety, increase broad abuse and debilitate the department's ability to pay providers in a timely and equitable manner. After researching alternatives the Department decided to pursue exception to HIPAA standard to use upon on claims standard. I believe I heard yesterday entities want to use the UDI claim transaction for research purposes, so we'll cover that. The California Medicaid program called Med California cal, largest Medicaid program in the nation with 7 million beneficiaries. It processes hundreds of millions of claims each year; and spends over $40 billion per year in the delivery of healthcare services. Over the next few minutes, or 10 minutes or so, I will speak briefly about the California UPN pilot, but spend majority of the time talking about HIPAA standards impacted by UDI and the process and timeline for modifying the standard to allow for UDI reporting. The California UPN pilot was authorized by the U.S. health and human services secretary to test the feasibility and cost effectiveness of the UPN of the HIPAA coding standard. The UPN standards include G10 inhibit code, but we heard from some manufacturers that the use NDC and NHRIC as unique identifiers. The authorized test period was from July 1, 2009, through June 30, 2011. This is the period in which we process claims with UPNs over 7 million claims were processed result nothing over 600 million dollars in payments to our providers with UDIs. Our trading partners included retail pharmacies, hospital-based pharmacies and durable and medical equipment suppliers. Over 6700 products were included in this pilot and service areas listed on the slide. These are primarily disposable suppliers used by patients in their homes. Over 90 manufacturers and distributors are represented in this pilot, some of which are here or were here yesterday like Johnson and Johnson and (Inaudible) Dixon. We are required by Federal statute to submit a report within 90 days after the test is complete and no later by September 30, 2011, so we have completed this report and are currently rooting through California health and human services secretary en route to the U.S. HHS Secretary. So you may be asking why we had to go through this formality in order to use the UPN or UDI on claims transaction. The administration provision of HIPAA mandate standards for certain electronic transaction between healthcare providers and health plans such as Medicare, Medicaid and commercial payers. So this is the relationship between the providers and the health plans if you want to conduct business such as claims, authorizations or payments, HIPAA adopts certain standards for these transactions and code sets. Code sets include diagnosis, procedures and supplies that HIPAA covers. Covered entities include hospitals, physicians, pharmacies and the health plans. Currently HIPAA standard DOS not support UDI reporting on claim transactions. I've listed on this slide the specific transactions and standards that must be modified in order to allow for UDI reporting? As you can see there are more than just claim transactions as there are other UDI transactions that must or may occur in order to get a claim paid. The ascix-12 standards were adopted for claim transaction primarily used by hospitals, physicians and professional claims and the NCP standards are used by retail pharmacy transactions. There is a specific field on each of the transaction standards that currently allows for NDC reporting and this is the same field that we're proposing to use for UDI reporting. Which I'll discuss more later. The coding standard adopted by HIPAA for medical supplies and device system called the Healthcare Common Procedure Coding system, Hick Pick, which is maintained by the centers for Medicare and Medicaid services. This is a five-digit alpha numeric coding system designed to group like products into a single code and does not specify the manufacturer. The 6700 products included in our pilot map to about 122 hick pick codes. In total there are about 400 hick pick codes that represent all medical supplies covered HIPAA. One hick pick code we highlighted in our report to the Secretary is used for tracheotomy tube N. Our pilot we had 200 codes that match this specific code. The prices for these products range from $23 to $280. The higher cost item generally reflects fittings and materials needed for newborns and young children. Setting single rate for the hick pick code was impossible. Using UPN became extremely valuable to publish the products covered by Med Cal and display the rates the department would pay for the products. Just like it shows an example of where we are proposing to put the UDI on claim transaction, it's called currently in the x-12 transaction called Product or Item Identification currently used only for drugs. It was simply require a change to the segment transaction description and there would need to be a situational rule to identify the UDI language. We valid to add qualifier tow qualify UDI. Currently there is only a qualifier that designates the national drug code. And just to let you know there are already qualifiers in the standards for x-12 and NCPDP that identify g-10 inhibit codes, but we're recommending not using that level of detail because we think that just having one qualifier called UDI is all you need. The less information sometime system better on the claims transactions. This is the HIPAA provision that allows for testing of a proposed HIPAA standard which we used to test the UPN transaction. I'm aware of only one organization that attempted to introduce new HIPAA standard using this provision and it was rejected by the HHS secretary so we have a battle ahead of us. I've listed here the specific areas of criteria that the Secretary uses to consider adopting new standard for HIPAA. I've included the scoring that California used against each of these provisions. Eight of the 10 provisions we scored as met in terms of use in the UDI on claims transactions. Wee truly believe that the UDI can help improve the efficiency and effectiveness of the healthcare system. We believe that it meets the needs of the healthcare data standards community. We believe it has low development cost relative to benefits, both G-10 and HIPAA have timely updating procedures and technologically independent and supported by accredited organizations. They also will help providers minimize data collection and paperwork burdens and incorporate flexibility to adopt changes in healthcare. The two areas where we scored the UDI or UPN as partially met were in the area of uniform and consistent with other HIPAA standards. We compare this to hick pick and national drug code, both of those standards have a central authority to maintain those standards and the place where you can download the codes and use them, integrate them into your systems. We didn't find this to be the case with g-10 or hick pick. We had to go to manufacturers to obtain their codes and probably one of the biggest challenges we had was just terminology, education and training when we asked for a product UPN, most of the individuals that we worked with didn't know what an UPN was or a g-10 or a hick pick. We asked for the bar code number, but sometimes when you see on the bar code isn't really the UPN, it is just a matter of education and training. Also, number eight, precise ambiguous and simple as possible, again for the same reason that education and training that was needed. This is a specific provision that is used for the Secretary to consider PROT posed modification. This is once it has gone through testing and everybody agrees this might be a good thing. It must follow open and public process and there is a place on the web where requests for new standards can be submitted. It must be coordinated with HIPAA designated standard maintenance organization; I will show you on the next slide. With the affordable patient care act or healthcare reform of 2010, there was a process to expedite changes to standards typically this could be a multi-year process through interim rule process where we are hoping we can use this process to actually make the change. In all proposed changes for requests must be submitted to the national committee on vital and healthcare statistics. I've listed here HIPAA designated standard maintenance organization. These are the organizations that all have a voice on whether a new HIPAA standard is adopted such as ascix-12, American Dental Association) health level 7 and UPC and uncc. The most important voice in adopting these standards is the voice of the general public, the healthcare community, hospitals, physicians, pharmacies and health plans. So these are the entities that we need to support the change to the HIPAA standards. I'm concluding this presentation with California's recommendation to the Secretary. In our report we attempt to illustrate how the UPN is helping the Department ensure that only safe products that have met industry quality standards are delivered to our Med Cal patients, (inaudible) used in constant battle of broad abuse and how the UPN is used to promote cost effective and efficient claims processing system. Our recommendation to the Secretary is to modify the HIPAA standards to allow for UPN UDI recording, to allow California and other HIPAA covered ENT IPTs, Healthcare providers to use the UDI on claims transactions and to collaborate with the FDA to establish the mandate for manufacturers to use the designated UDI standard to implement the publicly available UDI database that sports the needs of Medicare and Medicaid and all healthcare providers and to address the UPN and UDI deficiencies identified in the pilot, which are mainly to establish clear labeling requirements, education and training. I've listed two bar codes here, we think that one of the most powerful things that the FDA can do is actually put the UDI kind of like you do the ND.C., where you say UDI with call in and the actual number and part of the reason we think this is important is when you see the numbers on bar codes, you will see characters and numbers that aren't necessarily the actual UDI, so we think it should be very clear, UDI code and then the number next to it. So thank you. (Applause)

<< Terrie Reed: Thank you very much, Sarah. Sarah was out on her own doing this, she is a great resource, we didn't even really pay her to do all this work. It's wonderful. We're going to move from trying to get UDI into these standards to thinking outside the box a little bit on how to use UDI within electronic health records and we will have Dan Levy speak about that. Dan is chief technology officer for outcome Sciences. He's going to talk about the benefits from UDI being in part of the electronic health record and modeling the transfer of that UDI information from the electronic health record to other applications.

>> Dan Levy: That looks familiar. Okay. Yes, I don't want to do that. Good morning. Thanks, Terrie Reed, Jay, for the opportunity to speak. I'm going to cover a couple different topics. I want to touch on something we've talked a little bit about yesterday and that is the issue of manual data entry across the variety of systems that are utilized today. And in reviewing that, we refer to the automation of that process as data automation methods and we'll take a look at some of the popular methods that we see in our work with registries and populating registries with existing data sets and then take a look at some emerging interoperability standards that we're trying to leverage. There's been some discussion already about those, but we're trying to leverage those in creative ways across a variety of different use cases. I'm going to give a couple of examples of those and my lens tends to be registry lens so the examples will be EHR and registry interoperability examples. And then I'm going to close with an idea around another project I'm involved with, which is a project funded by AHRQ called the Registry of Patient Registries and how we might leverage UDIs in that effort. So let's start with data automation methods. What we see in our work with registry and our users asking us to leverage existing data sets, what approach consist we leverage to populate these registries? There appears to be at least three varieties of methods. One, which is still the most popular method, is using simple uploaders and the most popular uploader method is the CSV file format comma separated values. There are a lot of very valuable data sets already existing within environments such as ub-92, x-12 and xml, and certainly we want to be able to leverage those and we do so in uploading existing data sets and reducing the burden of manual data entry. There are other emerging technologies around service oriented architecture and web services and those have tremendous value, as well, and we see those being in use and quite a number of environments. Then within the emergent standards area, we've heard a little about the standards organizations already - IHE and HITSP, providing valuable standards for automation, as well. If we touch on briefly the uploader method, I think everybody is familiar with the method; it's used everywhere, batch transfer method. It's easy to create flat files. You have a lot of flexibility around how to upload them in terms of intervals, if you are uploading data for the joint commission reporting. You may upload quarterly. If you are uploading data for reporting to CMS PQRS, upload annually, hence a lot of flexibility is there. The challenge is somebody has to create these formats, somebody has to create these csc files and typically that falls upon hospital IT staff or other partnering vendors that can create these files and feed them to other health information systems such as registries. We already talked about the different formats. They all have kind of some advantages and disadvantages. If we take a look at a couple formats here I'm just showing csv where you can really identify the types of data you want to upload, a lot of flexibility there and ub 92 below that's a fixed length format. In terms of web services there are some advantages to utilizing web services. This tends to be a real-time transactional model where you can in real-time share information about a particular patient record across multiple systems. You can better tie this into the clinical work flow, so if you're in a system and you're saving a patient record you can use a web service in realtime to transmit that patient record to another system that requires that same data set thereby reducing the burden of data entry. It's called by the application client which means it can be integrated into the clinical work flow. I think in examining the uploader and web server methods you see some limitations and in examining those, what emerges are really two important parts to interoperability. There is the syntactic component or syntactic interoperability which really talks to the transport technology and some of those methods that I talked about prior really address some of the transport issues, how do you move data from system a to system b. There's a lot of ways of doing that. But what they don't address sometimes is the Semantic interoperability component and that really talks to the meaning of the data. What is the definition of each of the data elements? What are the controlled vocabularies that we agree to use from system a to system b, so that when the message arrives we can interpret it easily and clearly and definitively and so we heard a little bit about some of those controlled vocabularies that are being promoted in terms of snomed, loinC and so on. I think there are a few organizations that are doing a great job at addressing these two parts of interoperability, the syntactic and semantic component. Some of the organizations are IHE integrating the healthcare enterprise and HITSP. Specifically the way IHE does it, defines different layers of standards. For example, within the syntactic layer we define integration profile. A great example of such a syntactic integration profile is what some folks have already referred to as RFD, retrieved form for data capture. I want to describe this just a little bit because this is a very powerful way of sharing information across systems. And what that allows TOUS do is for example take a registry and think about a registry as a form library in the cloud. I think Dr. Glicklick referred to this yesterday as cloud forms and what that allows us to do is reach into this form library and grab one of these forms that is applicable within the context of say an EHR and present that form, sometimes we use the form surface that form in the clinical work flow of that EHR. That's tremendously powerful. We'll take a look at a couple examples of how we utilize that. But that defines the syntactic component. What we need to do is build upon that and look at how to share information across those systems that brings back the semantic component. And there we've done work around what we call content profiles and that defines the messages that go across these two systems. A couple of great examples of those profiles are the CRD, the clinical research document and the DSC, the drug safety content profile. That describes the hl7 message or continuity of care document that's relevant in that exchange. I think there's opportunity there to do additional content profile work around device usage and device safety reporting and introducing the UDI as part of that. And that's really the next thought here on the slide is that the UDI is really part of the content. It's part of that semantic element and if we can add that to the data collection process, Jason spoke about the discreet data collection within EHR we can add that there, then add that to the CCD, we can move that data along and leverage that in other use cases. So what is the problem we're trying to solve? I like this next couple of slides because I think it explains that very visually and yesterday a lot of the panelists spoke about the problem we have as an industry in terms of the need to manually enter data and I think that the problem is probably more serious than that in that we have to do that multiple times with the same data. And so what this slide shows is the clinician in the middle and more and more using their electronic health record system, but they're also participating in a number of other efforts whether they're reporting data to public health entities, they are participating in other relevant registries, quality improvement programs or safety reporting and so what's happening across the spectrum is that the clinician is really required to reenter data across those multiple use cases. What we're really trying to do with these standards are crd and dsc, is to reuse that data and really position the clinician here on using the EHR, but through the standards leveraging that data that's been collected, leveraging the HL7 CCD, and being able to reuse that data through the standards for these additional use cases. So taking a look at a couple of different examples in this graphic, we see in the background an EMR called Next Stack, a specialty EMR used quite a lot in plastic surgery and this is a quality improvement form in the forefront that's utilized the RFD standard to take data from the EMR that's already been collected and prepopulate and surface this form so that that same provider does not have to reenter that data and they can also participate in this registry. This is a great example where we've leveraged the standard for the collection of demographics information, but what we see here quite a bit is in this program, this is a surgical registry; we're collecting device information, so we're collecting device name, device manufacturer, model, serial number, lot number. And so it would certainly be very powerful if as part of this process we also were collecting the UDI from the EHR, from the CCD and then we can reuse that information, we can reference that UDI against the National UDI Database and prepopulate all of those additional data elements that are currently being filled in manually, a great opportunity to leverage the reuse concept. This is an example around device safety reporting which sometimes is referenced as asterisk D which builds a project done a few years ago for drug safety reporting and what we see here in the background is an EMR, it's Greenway's EMR, called prime sweep. What we've recently done at drug information showcase in June) demonstrated how from within an EMR we can do device safety reporting by surfacing a Med Watch form and electronic med watch form that prepopulates a majority of the information captured in that form and asks a few additional questions. For example, select all outcomes that apply. Once that data is captured, it can be submitted electronically to the Mod data base. That is powerful scenario; we saw tremendous interest at DIA and around that effort. I want to close with the thought around the concept I introduced called registry of patient registries. This is an AHRQ project that is initiated last fall in 2010 and its goals are to design and develop a registry of patient registries. This will be a database system similar to clinical trials.gov, but focused providing searchable listing services for all registries and will be integrated can clinicaltrials.gov. One of the components we're looking at within the registry of registry system how to capture common data elements. I see here a great opportunity to add UDI into that capture and when we look at Roper, registry of patient registries, we see a couple of different roles within Roper. We see registry holders or registry owners that characterize or profile their registries and make them accessible through the public listing servers, where registry seekers can look for registries. They can look for registries if they wish to collaborate. For example, I think it would be tremendously power FFL registry owners would identify if they are collecting UDI information. And then that would allow registry seekers, such as regulatory or others to identify registries that have captured UDI information. Then these Roper records provide contact information so that a registry seeker can reach out to that registry holder and get more information about that registry. So another example of the potential use cases especially as we transition into the use of UDIs and are looking to identify those registries that are capturing UDIs. Thank you very much. (Applause)

<<Terrie Reed: Thanks, Dan. Our final speaker is Joy Keeler Tobin. She leads the health information technology initiative for the Centers for Transforming Health. She's going to take our brains a little bit further. So hold on. We've talked about data standards this morning and she's going to put a little spin to it.

>>Joy Keeler Tobin: Thank you. Hi, good morning. Interesting to be last on this panel after Terri Reed announced that we were going to think outside of the box, so I think we're going to consider this an Edge presentation for today. I'll go quickly through this notion. Again, my name is Joy Keeler Tobin, I'm with the Mitre HData Corporation and I'm here to talk about an internally funded research initiative that we undertook about 2-1/2 years ago now towards the goal of accelerating health data interoperability. We're going to talk about HData, which is simplified framework for health data exchange. Very briefly, who is Mitre HData and why are we interested? We're independent, not for profit organization, that's chartered to serve in the public interest. We do not compete, so the research that we do is internally funded and we have a fixed amount that we invest in that each year. HData fall INTOS our Center for transforming health research portfolio and one of the broad goals that we have as an organization is to work to address issues of critical, national importance and certainly healthcare is one of those. The challenge that we were addressing was HData as a result of some healthcare systems engineering work that we had done that I'll touch on briefly, was to reduce the barrier of entry to healthcare information exchange. Today's health IT standards are very complex for individuals to learn. So it takes software developers who are coming from other industries, a long time to understand our standards. And as we look to promote interoperability across a wide range of stakeholders we are looking for ways that we could leverage some of the technologies that led to the rapid uptake of the event with healthcare. Very briefly, some is of the work that we did that made us recognize as an organization that our health IT standards are complex, one is a project called Lica, Mitre, in about 2008, used internally funded research initiative to build an open source c-32 testing framework that today's electronic health record certification entities use. Projects like DOT-org. We've also used today's health IT standards to do things like Pop Health which you may or may not have heard of, it is ONC open source tool that allows you to take c32 and ccr, and crank out your 44 stage 1 meaningful use clinical quality measures and we also are part of the query health initiative in the snI framework developing something called Hquery, just as a little bit of understanding of where we're coming from. The philosophical approach that we took in developing HData, how do we take today's complicated standards that are very good. We as an industry are complex, as a former healthcare CIO, I understand that, at the same time, as I said before, we're looking for ways to make it very easy for software developers to utilize tools that are out there that we can't use in today's standards. Some of the notions that we baked into our research years ago have actually been published as part of the Hit standard committee implementation work group. This was published at the end of 2009. Some of their synergies were keep it simple, keep the implementation cost as low as possible, design it for the little guy, don't try to create one size to fit all, separate content from transmission, and I'll address some of these as we go through. One thing I want to emphasize, we're not trying to recreate any of the healthcare standards that have been defined to date. We are standing on the shoulders of giants and appreciate all of the value and the importance of HIPTSP, HL7, ascm, the ccr. The hdata approach is to separate the clinical content from the transmission standards. Let's leave the clinical standards to healthcare. Our systems engineers know they will never have that expertise, that being said, let's leave the technical specification to systems engineers. So I'm only going to point out fortunately only going to point out two technical aspects of hdata. We support restful transport, everything is url, everything can possess the kind of security that we talked about as necessary for HIPAA and confidentiality of pH i. We also support subscription services and that means everybody probably uses rss feedos your desk tops and Adam sees the same thing, open source way to accomplish the same thing. So everything in Hdata can be identified through a url. If you extrapolate the things you have heard even on today's panel, having url makes that very transparent if you think about the way you do things on blackberry and iPhone and Pad. It is departure from tradition. We are moving with our technologies from having today's health records are largely a snapshot in time. If you look at ccd or c-32, it's an image. It's a nice very comprehensive snapshot. But how do we keep that alive? How do we take a subscription service, so if there is a change in electronic health record or your parent's record that the providers notified of that change without being shipped another entire lengthy document because it would be very difficult to pull that out? So in summary, some of the basic premises we undertook were to separate clinical content, to build on proven technologies that have led to the uptake of the internet, make it software developer friendly so that interoperability can be something that engineers can rapidly pick up. It should take a day or two, not three months. Make it simple to learn and to use, support the privacy requirements, leverage open source projects and make it extensible across health IT use cases. If you want to look at where hdata is, we actually this week is the hl-7 draft standard for trial use. Yesterday was the first vote so it's going through the process of acceptance and traditional FDA way and being refined as we go through. We've done several pilots with some of the organizations that are listed here in various approaches. Some are for lab interfaces. Some are for health information exchanges. And then in the handouts, as well I included the standards committee recommendations just so you can map back some of the basic notions they are suggesting to Hdata, as well. Thank you. (Applause)

<< Terrie Reed: Thank you, to all the speakers. I hope we had the right mix of policy and technical to keep you interchanged. So does anyone have questions?

>> Hi, Terri Reed, (inaudible) from Institute. At equity institute we maintain a data base called healthcare comparison system) which is a listing of capital equipment and has side by side features for medical products and it takes tremendous amount of work to put the comparative features of those products into sort of an apples to apples set and maybe Terrie Reed, you can speak to the plans for how this database might be maintained over the long-term particularly putting features that are features described differently by manufacturers into the correct category?

<< Terrie Reed: The UDI database?

>> Correct, the UDI database, particularly any attributes that will be associated with medical products. And then the other more comment I'll bring up is that most of you know that we run the universal medical device nomenclature system and the maintenance of the data that goes into that over time is keeping that up to date, takes tremendous amount of work so one of the panelists could talk to the perspective on what it would take to maintain something like the data that's going to be in the UDI database, particularly the device nomenclature?

<< Terrie Reed: Well, for the UDI database question, we are working on design and development and requirements, so we're in the process of that and considering all those issues. I do have an FDA request for operations and maintenance because I know that's going to be a big deal, as you emphasize. I don't know if the panel can answer or address your other questions.

>> Well, I could just say from the point of view of the maintenance of any standard nomenclature, and maintenance of utility and the healthcare environment, there's no way that it isn't a labor intensive activity. I don't think we know how to eliminate that yet.

>> Yeah. I was just going to add, one of the considerations for maintenance during a transition period for example from the current users of the UDI is the maintenance of cross maps and other support resources look up tooling and so forth that would be available to the current implementers during the transition period. The same as we would look for from the standards committee for other vocabulary transitions.

<< Terrie Reed: Joline.

>> (Inaudible): hi. Interesting. Just turned on. Julian Goldman from Partners Healthcare. The notion of streaming and dynamic data versus static data for approach. At what point in buffering the data, so that one doesn't have to depend upon the availability of a feed to get access to data immediately? That's part of my question.

>> Are they live? Okay. I'm not sure I understand why that would be limited access through rss feed.

>> Well, the more it's similar to the fact that if I use G-mail, I can get my e-mail if I'm not connected to the cloud when I need to read the e-mail and if I use old-fashion client that stores the data on my computer, at least I could get some of my work done and have access to that data. So analogously I'm wondering about the real-time dynamic feed if you use that when you need access to data or if you just use that to populate local databases and store the data locally?

>> I think the intent is not to be dependent on it exclusively, but to have it available so that the use case that I think is the simplest and probably would be hugely valuable is if you are up for primary care physician their patient is seen in the emergency room somewhere else, how do they find out about that? So the notion would be for a patient to have control over who has access to their personal health information and presumably primary care provider would be granted that notification.

>> And then the primary care provider would have to have a mechanism in place to receive those feeds in the timely way before they interacted with the patient again or is there some other trigger, I suppose?

>> They would, yes. I mean, you have to be connected to get the notification.

>> Yeah. And the other part of this I'm wondering about, did you call it Hframework or what was the term for the --

>> For which part?

>> For as you introduced it, I think the overall framework.

>> Oh, well, framework for health interoperability.

>> Yes, that also. Has the VA or DOD been involved in any of that work?

>> Yes.

>> Okay. Thank you.

>> I'd be happy to talk about you about the specifics ever that afterward.

>> Yeah.

>> Without their, you know, it would be inappropriate for me to just discuss that broadly.

>> That's fine. Thank you.

>> Blake Winston: I have a clarification question really this is for Sarah, where you talked about HIPAA codes dependent upon the CMS Hick picks code. Hick picks has run out of numbers or just a couple years ago they have, have they fixed that database system?

>> It's maintained quarterly and there is an annual update, so I'm not aware they have run out of numbers because you know every year there are new numbers added. I did a presentation before CMS and there were a number of us presenting different devices to for reimbursement and we were competing for just a very small number of remaining codes because of the design of their system. And so this troubled me. Since my understanding is they're not going to be able to add any new devices, I was just wondering how they have fixed that.

>> That's why we are recommending a change and use in the UDI, we felt the hick picks system was not adequate for identifying products and so we are recommending going straight to the UDI and also to look into some other classification systems and leveraging hick picks as a foundation, but yeah, we acknowledge early on hick picks was not adequate.

>> Good morning, David Stocks this is (inaudible) life doing software quality and I know how difficult it is to get all these things to work properly. And even with the best defined data standards mechanisms so on, (inaudible) misinterpret them and get them wrong. That's a nightmare when the first time you try to use software to get a life database and registry and so on. Within your organizations responsible for maintaining the registries, developing these things, actually setting up some test systems and test data that developers can actually test new software against? And I'm mindful when pharmaceutical side (inaudible) registry for drug numbers when it went live it crashed in a couple weeks, just because (inaudible) sort of stuff. Anybody in the room who is responsible for registries, anybody doing that, anybody thinking about that?

>> I could comment on that. There is an industry event that takes place annually and it's a very important event in terms of testing some of the interoperability mechanisms that a number of us spoke about today and it's sponsored through IHE, it is called Connect a thon, for those not familiar with that event, what happens there, there is probably now I'm going to say maybe about 80 or so different vendors that come and participate for a week. And there are specific test exercises that those vendors are given and you pair up, you partner up. So for example, as they registry solution provider, we would partner with a number of different EHRs during that exercise and then we're actually tested and either will pass or fail those specific tests. That's also a qualification for going to HIMSS and participating in the interoperability showcase. That is a component of I think what you are asking about and serves as a very important industry wide event making sure that you can exercise the software in the manner in which IHE has design today and you're actually graded for that effort.

>> Sounds very (inaudible).

>> We have a little bit of sorry, Jamie.

>> Go ahead.

>> We have a little bit of different approach from the other end, if you will. It's not necessarily for registries, but you might find it interesting, nonetheless. One of the things that we've looked at is how to ensure when electronic health record or electronic health record module is calculating clinical quality measure how to assure they are doing exactly what you say, they are calculating what was intended. So we're actually building and have built close to releasing a database of it doesn't sound like a lot, but it's really hard to build 250 patients who's data is designed to meet many clinical quality measures so that not only can you go through a testing process, but when you run the data through, you know what the outcome should be when you get there.

>> And I was going to add also, not from registry perspective, but rather from the perspective of the EHR certification process, software publishers who want to have their electronic health record certified run through a number of test scripts that are developed and run by the U.S. department of Commerce national Institute of Standards and Technology that are then applied to the software by a number of different private certification entities, so any time software publisher updates their product THEB they have to run through the test scripts and DPET recertified essentially. So then the certification program matches the standards requirements that are used to qualify the software for the various programs in CMS, for example.

>> Thanks. Mike (inaudible). (Laughter)

>> All right.

>> From Covidien. I have actually two comments. As a medical device manufacturer, this might put you on the spot, I want to ask the question in Betsy's presentation, she talked about I know this is an open forum, we're still flushing out ideas here, but we talked a little bit about the assignment of the UDI not resting with the manufacturer and some potentials there. But as a manufacturer we're moving forward on very specific and investing a fair amount of capital moving forward on these things and we need to make sure we have no ambiguousity on how we apply these sort of things, so by GS1 standard we do apply the UDI and that would be substantial curve ball to us and the direction we're going. So just want to make sure that we have to have these set standards to move forward and on the other comment, it was made by Sarah, we have to maintain within the standard regulations, we're moving forward with GS1 standard and you call out that we would note the UDI itself because it is a little bit confusing, I think we need to focus more on the education of what the standards and how they are to be used. As soon as we start to vary from the set standards, we lose that level of control. So within gs-1 standard nowhere to call out this number is your UDI. We have to educate this is what gs-1 standard or the hick pick standard is and this is where you work within that particular standard for the (inaudible) throw that out there because medical device manufacturers are moving forward with that, we're investing considerable capital right now to prepare for this and if the rules groundwork change halfway through, that is going to be a difficult thing to adapt to. Just want to throw that out there.

>> Can I make a quick comment? I understand your concerns about labeling requirements and education and training and I think these bar codes are very complex. The human readable aspect of UDI is so important, you know, being able to publish the codes and view them and then compare them to what is on the package and I spent years looking at and reading through the GS-1 I guess you are calling it the assignment rules, as well as Hick Pick and I still to this day have a hard time looking at a bar code and trying to extract exactly which component is the UDI. If you have avid user, you know, who when you are in a hospital or a health plan, these people may get some training, but they're going to forget. So having it on the package very clearly labeled UDI: And then the number and that is what we really want is the primary number, the primary structure, that is what is in my mind, what is important for UDI transaction to have it clearly labeled is critical, so that is what we really want to petition to the FDA to adopt that to some point. We know it might take a while to phase that in. And also, we assume that the manufacturers will determine what the codes are and the assignment, not end users, they have that control and it's based on the lowest level of packaging.

>> Speaking of testing, I asked Sara last night if she'd be on our testing team. She is very passionate about this and has a lot of experience. So UDI database to address the testing issue has a lot of plan time for testing with industry testing with consumers, we're very mindful of the importance of that.

>> I am sure there are other ways than the way that is used in other areas to ensure that when you are looking at a product with an UDI on it, in fact it is registered with somebody somewhere as registered and approved product. There are probably other ways to do it, but I would certainly encourage the group that is partnering to develop the system to figure out some way that in effect we don't have bogus UDIs in circulation. That is it is on a device somewhere, but there is no way for us to verify whether that is an approved product or not. If your registry is mandatory and if the device industry follows that and they don't produce any devices that are not registered, then we have the answer and we have an international access to those data then my problem is solved. I see something that looks like it’s an UDI, if I cannot find it in the system, it isn't one. That's the end of it; we will behave as if it is unregistered device. But obviously if very important registered devices ever show up without an entry in the database, then we aren't going to be able to do all the things we need to do with the device s. I think, I encourage all of you to come up with a solution to this problem. It doesn't have to be my solution, but I really think we need to know when we're looking at something that could be an UDI that has to be a way to determine whether it is one or not. And you know almost there now with NDCs, but weed at a different place and finally approved NDCs as code set, but we didn't the first time around and it was because of these other problems.

>> Vance Moore with Mercy Health: Sara, couldn't agree more. I understand the issue, actually with testing, a lot of people are retooling, a lot of manufacturers. The way I look at it, the UDI, hopefully the g10 or (inaudible) standard adopted by market, that is almost an expectation. The identification of the product being UDI, I believe is actually marketing event. That becomes something that it makes my life easier as a provider and if you have ever been on the phone with the cathlab, somebody in the cathlab that wants to set up an item and you say, just tells me the man readable code below the bar code. They say which one, there is six here. That just kind of gets into the well, I think it starts with parenthesis and has 0 1, okay that, is the problem. So that's where I love the idea of positive identification of UDI, draw big red circle around it, whatever the marketing definition that you are going to assign to it, just making our life easy, I can assure you will pay dividend from the financial line in the future. The expectation of a standard code on every product that is out there, especially devices, is almost non-negotiable to us right now.

>> We need you to fight our battle to make this HIPAA compliant standard.

>> Last question.

>> Hi. (Inaudible) from Search (inaudible). Interesting that we're on the manufacturing side and we're all pro-UDI, as so many of us for FDA for guidance. When we talk about bar codes on our side, we use bar codes every single day and we don't even use bar code, my comment, I don't understand why we are talking about bar code, that was developed 50 years ago in which the error rate is not what we want. We are not moving to the bar codes, or rfid. We do need some guidance. You can take any product and you will have six different types of bar codes on it and difference in biology and we don't really understand why we can't get some direction on what is (inaudible) to use. A lot of these are open source, so we're not paying royalties to anyone. But when we use when I look at what we have to do and have to scan three different types of bar codes on a box or if we are going to a hospital and the hospital is asking us to support five, six different symbols, it puts extra strain on us as it does on the hospital, as it would with anyone else and we would just like some guidance, for someone to say, use this bar code. Use this 2 D, it would just be easier for us and easier for some people. Those that are not using that, well, they will face the extra strain. But in the long-term, it's easier to actually have a standardized SIM BOLG for everybody.

>> Thank you. Thanks to all the speakers. We have 15 minutes, I believe. Jay, is that right? 15?

>> Yes.

>> Okay, 15 minutes to be back. (Applause)

>> Jay Crowley: I'm going to introduce him in the hope he will show up when I'm done with his introduction. So your moderator for the fourth panel today is Julian Goldman. Julian is Medical Director of Biomedical Engineering for Partners Healthcare, practicing anesthesiologist in the Massachusetts general hospital's operating room of the future and director of the program on (inaudible) interoperability at SNOMED. Chair of ISO technical committee 121. Here he comes on equipment and PI of $10 million NIH sharp grant on interoperability. I give to you Dr. Julian Goldman. (Applause)

>> Julian Goldman: Thank you, Jay. Well, we have an exciting panel coming up. Hopefully enough to keep people leaving for that beautiful buffet lunch that's been -- oh, there is no lunch set up, is there? There's really no rush in that case, we can just take our time. I think I like this new system. Oh, got it. Jay said he's buying lunch. All right. Well, I'll begin with my presentation and then I will introduce the panel members and we will have -- let's see, who is keeping time for these? Is someone going to have flash card? Jay does thanks. Gotcha. What I'm going to do, we really have I would say presentations in our panel that are synergistic with presentations in a number of the other panels and all together due to the good planning and insight of the FDA in setting up this workshop in the end I think it kind of, the Venn diagram of what gets cover Friday operational to research to small focus projects to end to end data transfer is probably all being covered by the end of the day, which is really wonderful. What I'll be speaking about is how UDI becomes part of the enabler for clinical system integration for device integration and for improving patient safety and for automating some of the routine data collection and clinical care activities that we currently perform. I think that probably would not be much disagreement that significant innovation in patient safety and healthcare efficiency requires innovative systems solutions and these have been elusive. Part of -- some of the barriers, perhaps some of the fundamental barriers are that medical systems cannot be fully integrated due to the lack of effective interoperability between medical devices and the clinical information systems between different systems and we've heard a lot about that today. In the interesting, but sad part of this is that not only can't we today have comprehensive and effective system integration, but even incomplete integration is expensive. So it costs a lot to do a poor job, the worst possible thing. I would propose that in the key, in the solution pathway is the need to develop integrated clinical environment to create not only complete electronic health records, but to start to build error resistance into our systems, to make it harder to have medical errors and of course everyone here, since we're thinking about the UDI and thinking about the benefit of complete data, the connections are kind of obvious. Well, I think UDI is we can see it's a part of a new way of thinking about medical device data. We need complete medical device data and for devices with electronic data interface, the data should be available via that interface. For a medical device that doesn't have electronic medical interface like prosthetics, one wouldn't expect to be available through interface. But it might be available electronically, you might have RFID chip embedded, but with a different set of expectations in terms of sending data, different than for example a pulse oximeter, you expect to stream data or send data when requested. One could think of that data as clinical data, oxygen saturation, pulse rate alarms and things like that from a pulse oximeter, and technical data. Call it what you wish, which could include time measure cemetery taken, device time, serial number of the device, or UDI. And I think of the UDI as fitting into that part of the data set of what we should be thinking of as a complete data set for medical devices. This is a picture to just remind us of what it could look like in high acuity clinical care environment when one is vertical and when one is horizontal, they usually miss everything but the pattern on the KRSHGS eiling. When you are vertical, it looks like this and there are a lot of devices and it takes a lot to get the job done and thank God we can do things like that. But integrating the data is quite challenging. I believe system integration and interoperability should enable error resistance and we don't have the time to go through clinical examples, but certainly can present one of the examples from a repository of examples that we've been collating, collecting, analyzing for the last several years. Typical patient controlled analgesia or pca system, in a system like that, which most are familiar with, a patient pushes a button to receive a dose of narcotic, morphine, typically after surgery. The system is relatively safe. There are limits of how much can be received with each button press and so forth and so on. And if the system doesn't work quite right and the patient is having too much pain, the patient can call the nurse call button and receive more medication if needed. The problem is if the patient receives overdose due to programming error, sensitivity to medication, alteration of sensitivity and time of day or sometimes a family member is kind enough to push the button for them because they hear them groaning, so they say. That might be it. And we probably have, probably the data is pretty hard to get to, probably one death per day in this country from PCA systems. A number of years ago, 2006, the anesthesia patient safety foundation held a workshop to look at these problems and frustrated it was so hard to have a solution and proposed monitors should be integrated with pca systems so that if a patient has a drop in oxygen saturation or respiration rate one can look at the data and stop the infusion and call the nurse. That was in 2006. Five years later, this past July, June, sorry, AP held a similar workshop to ask why the problem hasn't been solved yet. One manufacturer does provide one complete solution of integrated infusion pump and monitors and some decision support algorithms required to stop the infusion, but that's it. Hospitals can't mix and match equipment. One cannot tailor the algorithm to their own patient, one cannot crowd source the development of these kinds of division support algorithms. So what do you need to implement a system like that? You need to combine devices ideally from multiple vendors so hospitals could use thousands of products they have, just as we mix and match other components routinely for personal consumer electronics, for example. You need reliable effective standards based connectivity with complete functional interfaces. Interfaces that give the right time that, give you UDI, for example. So you can track your devices because if we can't, if you can't both be sure you are connecting the appropriate and safe devices and you can't record what you did, then liability concerns come in and one can start to do things like this. One needs API platform to develop the appropriate support algorithms and a device or network log of the system for forensic analysis of network performance and device performance and adverse events. Well, so we all want accurate and complete data capture. So one could just ask a simple question before we get to something as complex as UDI as an indication of how challenging the simple things are in life. What time is it? Yeah, we all know our wristwatches are different, but our cell phones are pretty close. They use network time reference. E-mail and computer time are pretty close, network time reference. Here is preliminary device of time collecting from Mass General Hospital, starting multi institutional study. Out of 337 devices, we have clock time errors on these devices that range from seconds through minutes, through hours, up to five months. (Laughter) Yeah. 97% of the devices are off by more than a second and about 48% are off by a minute. The implications of these clock errors are actually staggering for patient care to medical/legal standpoint. The way the clocks are set, biomed goes around twice a year and is the clock manually using a cell phone or mickey mouse whatever, wristwatch. That's the current standard throughout every hospital, because our devices do not have a complete interface that sends and receives all data needed to be part of intelligent ecosystem. Again, for UDI to be a part of that, we have to think about that picture. Just an example, I won't go into the details, but look at the EMR in this case, looks like 22 minutes elapsed between the administration of heparin, and the activated clotting time and 30 minutes had elapsed, but the erroneous device clock time sent to the EMR. Now going to shift gears and talk about research activity since that will apply to the work we're talking about. And this is the NIH grant we're funded under nine or 10 months into the grant, part of what they call the quantum grant program. Oh, giving me the finger, two fingers. The quantum grant program multi institutional study with collaborators around the country, academic institutions and companies and what we're working on is development of a prototype healthcare intranet for improved health outcomes, that is the name and this is a description of the work. I won't read that to you, but give you flavor of the fact basically working on integrating clinical systems. The grant is also part of the sharp program under area 5, so if you were to look at the NIH sharp program, you could read more about it. Run through at high level, clinical scenarios we're working on. Working on pca safety interlock scenario, I talked about. We're working on scenario for ICU preparedness so one could read the status and information from an operating room of all the data and devices status, medication infusions, UDI comes into play again. In order to ensure the right devices are set up appropriately and automatically where possible in the ICU, to reduce error and improve safety of transportation and admitting of patients to the ICU, naturally many extensions to this. The third is telehealth scenario in which telehealth devices are currently designed to be used at home, instead brought with the patients to the hospital and they are used there. Introduces a lot of interesting complexity of hundreds of these devices in the hospital, how can one be sure who they belong to, which patient is important data and device identification challenge can UDI related. And we're working on project related to FDA regulatory framework for interoperability. There are more slides in the deck that I put in here for study afterwards and I'll show you what they are. The details on the pcan infusion safety interlock, there's details here of moving the patient to the ICD from the OR, and the challenges we plan to address to improve patient safety. There is third scenario on the use of telehealth devices in the hospital and here I want to pause and emphasize that as we think today of telehealth devices the devices don't have alarm capability and so some other layer of the system of the architecture has to address that, as well as the ID, patient ID and device ID challenge in that setting. The fourth scenario, which is based upon FDA workshop in January of 2010 on medical device interoperability we had been looking at a staged level of interoperability and integration of devices working from just remote display to integration of data for decision support to remote control of the device to autonomous and closed loop control, specifically for cessation during colonoscopy. Final thing to show before conclusion is that the report, the PCAST report in December of 2010 entitled Report to the President Realizing Full Potential of Health Information Technology to improve healthcare for Americans, the path forward, to the best of my knowledge doesn't call out UDI specifically and I could be mistaken, but I think this is the notion of what we have to think about in terms of complete data set and I think the report is worth reading and also any gaps are worth identifying because I believe that's what Pcast is interested in. Concluding, UDI should be part of minimum data set to enable safe, reliable, secure medical device integration. We should have certification of device interfaces since this is important for patient safety and UDI can be part of that. We need complete data set for quality improvement, for device management, by biomeds, for device census, any CIO can look at network and tell you the status, no biomed department can do that. We plan to implement UDI in our interoperability lab under the quantum grant. We welcome collaboration from those here or those out in radio land so that we could have a test environment that is nonclinical, but technically rich. So that, here is our website for the research program, mdpnt.org, medical device, plug and play DOT-org. Thank you very much. (Applause) There we go. All right. Next up behind me is Vance Moore, who is senior Vice President of Operations at Mercy and please give me a moment. He was born -- wait a second. (Laughter) He was born. Vance is responsible for corporate oversight of ROI and recognized leader in healthcare supply chain management in the Mercy technology services business unit as well as leading Mercy new initiative to enhance delivery of care and services across the health system. I am looking forward to hearing some of what we discussed this morning. You can tell I'm used to using a Mac, I can't figure out how to operate this machine.

>> Vance Moore: Thank you. Thanks for having me. Vance Moore, Mercy Health, senior vice President of operations. The supply chain and IT infrastructure reports through me and working with clinicians on clinical pathways and things like that to try our best to take variation out of the system. With that, just a little bit about Mercy. This was a slide Joe would have shown you yesterday had they been up, this is Mercy Health in the breadbasket of America in the middle. The interesting thing about Mercy, we're large enough to be noticed, but small enough to get things done. That's a real nice thing. We've got a little bit of everything. We've got thousand beds, major metropolitan hospitals in Santiago, down to the 15 20 bed hospitals literally in very remote places of Arkansas and Kansas. And so that is who we are. We're kind of spread out with 34 hospitals. We've taken this UDI thing a little bit overboard, literally just recently rebranded ourselves to Mercy through all of our hospitals. Before it was St. John's and Saint Edwards and St. Joseph, now it is mercy. Maybe we have taken it too far. I won't say that, it is working out quite well. I am here to tell you about it not about UDI. It is about the patient, about the caregivers and about our ability to afford the care that we want to provide in the future and that's honestly as you roll it out oversimplified, but it's about good patient outcome, about happy caregivers. We're going to be competing for caregivers in the future. If you believe the numbers I continue to hear that patient panelist per physician will grow from maybe as much as three to five times what they are today. How are we going to do that? We got to keep people motivated and engaged and happy so they'll work for our organizations and at the EBD of the day, it doesn't make any difference if we can't afford it. I would tell you, there is a national threat out there today if you look at the entitlements that are out there with Medicare, Medicaid; some is of the types of things that we've come to expect. We're driving a significant amount of the economy right now and many ways in a very challenging way. So anyway, as we look at this or I look at this we look through clinical, operational and financial. Quality outcome DM each one of those is extremely important to us F. We say quality outcome, you think of quality oftentimes in the clinical side and clinical only. Well, we think in terms of operational and financial, as well. If quality is important, we have to turn our head toward the father of quality as we know him, Edward Deming and you know one of the principles of uncontrolled variation, the enemy equality. Pick one. We are either for variation or quality can't be for both. Let's get understanding of which one we are going to be for. Our belief is we have to go with quality. We have to drive variation out. Standards, it's not about standards, the standards in UDI is the foundational element that allows us to enable so much of what we do today. If you go back and look at virtually any of all the industry, you know, like it or not, the auto industry, it's amazing they can deliver a car today that is at the same price almost that it was 20 to 25, 30 years ago with higher quality than we've ever seen before. You also look at retail. It's amazing what we can actually purchase and how quickly we can walk into a grocery store, get our items, walk past. We can check ourselves out today. You know, your iPhone there, is an APp called Red Laser, if you are in a hurry, pick it up and scan the item and it will tell you the different places to purchase the item and at the various prices out there. All these things are readily available and readily enabled. The evolution of most evolved industries can trace their progress back to a single language, a single unifying element around identifying the products and services that are provided, but not healthcare, not so much. So we've got to find a way to get through that. Here is the way I look at it. You know it is almost like pieces of pipe. You know, you can say that inside these pieces of pipe, we do a good job in manufacturing. We have bar codes and run our equipment using these bar codes. That's great. When you hand that off to the next entity in the value chain, all of a sudden that is leakage. Think of them as pipes and if you don't connect these pieces of pipe there, is leakage. The leak age is quality and the ability to process in a quicker fashion, those things that are taking place. I was lucky enough to be a part of mercy and evolution of the supply chain and we basically took that middle section and said, we can create a GPO and put those together and will we see benefit? We did - significant benefit. We took it a step further and said, we can also potentially become a manufacturer and work with manufacturers to integrate the processes across and speed things up and do so in a much more efficient fashion. And so Joe mentioned yesterday or someone did around the press release that KOIM out earlier this year. Working with Dickinson, everything created electronically using standards to take cost out and improve quality. We are able to do that and do that routinely now. That is a big deal for us. If you break the supply chain down in two areas, manufacturer to hospital dock and hospital dock to patient and I'm going to break this down very quickly along those two lines. What I'm showing here is the manufacturer to hospital doc, this created this mediated supply chain, ROI, the supply chain, the division of Mercy and a few other providers that are out there. Well, in each one of these areas we've been able to apply standards and use the standards in daily operations and to see benefit and I won't go through and read these to you. Bottom line, we have been able to process these through. Under the manufacturer item we actually went and created our own line of products called Regard, which are registered products out there and before we launched we actually delayed the launch so we could make sure and get the GS 1 standard bar code on products and get them registered in the appropriate way. We're trying to be a good example to those out there. The important thing, this one is this topic is basically focused on the hospital. So let's take a look at it. I tried to put together in my engineering mind the evolution of step it takes to actually transact business and the top line is really the manufacturer or I'm sorry, the hospital dock, to the patient chain, so in evaluating products, value analysis teams that are out there. Wouldn't it be nice we had standards to pull in various attributes and have understanding which products should be considered as we evaluate the products? How about set up? 100% of our item master, every health system out there has item master, the electronic reference point for products that are used. 100% of the information that is in our item estimate is harvestable out of somebody else's system, but I can't find it. Mercy spends almost a million dollars to have somebody rekey, reenter, harvest, down load whatever is required when it should be automatic transaction. Purchasing - I mentioned it earlier when I spoke. It's amazing how many errors and problems we have to where we'll get a call from a nurse that will say, can you set up and order that blue thing that we always use down here. Well, I need more. You know, you use a lot of blue things, help me out with that. Let's talk about the bar code, the human readable code on that. We need to be able to identify that better, when we receive the product. We order it properly and this is what we learned through the perfect order work. If it is set up properly and it tracks all the way back to the manufacturer, as soon as it comes in, when I scan the receipt, it automatically receives those products because I can now count on a high degree of accuracy to be able to pull this through the system much quicker. If I receive it correctly and set it up and contract for it correctly and have the right price, I can pay for it immediately there is a benefit there to the manufacturer fist we choose to pay in advance fashion. Transport, it's amazing how many times in the healthcare world we'll run out of product and hurry, hurry, expedite it. Wouldn't it be nice if we had understanding of where the product was visually in the supply chain? I buy something off e-bay today, I could almost immediately the next day or whenever go and click and pull up the transaction of where that product is and it will tell me where it is in the channel so I can be either excite body my new golf club showing up or depressed and we'll have to wait until it comes in next week. At least it tells me where it is. Finally, when I stock it on the shelf, it allows me to very rapidly put it on the shelf and confirm I've done that. Also with recalls, it's the growing number of recalls happening out there. Wouldn't it be nice if we at a moment's notice be able to identify every product on the shelf in a recall or expired status to be able to pull those off and refresh that? That is something I would tell you hospitals are not good at today. Then we kick to the bottom of the shelf here where the using charging collecting. We use it, make sure we record it appropriately. It's amazing. Wee have epic as clinical system, it is very important we record the items when they are used in the case and then automatically populates our record. It's amazing that if you enter the wrong number how it is possible that it creates significant problems and rework later. We get it in there correctly; make sure we charge the right amount for it. And tie that dynamically to the charge master so as prices change up or down we're having correct recommend and correct accounting for what takes place. Collection - Less collection and delays we may have if we know that we're accurate on submitting the bill to the payer whomever that may be, the collection process just like the collection process up above, with our payment transaction with vendors, the same thing takes place with us. Transmission - We understand exactly what was used we can transmit it to the appropriate registry. That information can then dynamically be placed out there for referencing for further research. Tracking - Understanding longitudinally. We invested millions of dollars in epic and have longitudinal record with patients, in patient and out patient tracking. Now if we're able to use those UDI standards to be able to identify that device that is in me, I can all of a sudden begin to track the subjective and objective elements of your care as you continue throughout the process. So we have the opportunity there. Recalls - After the fact, sure be nice to be able to notify folks if they have a defective lead we need to address or whatever. We know that, yes, we do know that today because implant records are out there, very manual process to harvest that information. Finally, closing the loop - back to the evaluation step. All right. Let's understand through comparative effectiveness, which products are best. Just Joe mentioned yesterday as supply chain guy, I don't care what we buy N. Fact, I get my care at Mercy, I want us to buy the best. I don't want us to buy the cheapest, I want the best. My belief is today wee buy based on marketing and not based on science. And so marketing defeats science today and that's a shame. We have to understand how we get to the point to where science is the definitive evaluator of the products we use in our care F. We do that, my belief and been able to prove it by studying high volume physicians, they use good products, lowest cost, the highest or best outcomes and patients are more satisfied. We know when you combine those three together it's truly more quality outcome. And for me and my family, which gets their care at Mercy, which is what I want and honestly what I demand. Now with that being said, that is kind of we talked about in the hospital, I would tell you the hospital is the wrong place to look in the future. We're going to as the incentives change and as we look outside of the acute care surroundings, look at new expanded future to where there is self care and primary care and urgent care. Yes, the dollars will be spent in acute care market place. A lot of care takes place in distributed fashion. How do we if we don't address this, all kinds of confusion going on around what was used on you where and is that tied back to a central record? I would just ask you to please reserve a spot in your mind for the future. As well as the current situations that faces us today. Excuse me. So there were some questions or around what are concerns around the UDI adoption? Network devices, things like pharmacy cabinetry or other product cabinetry, printers, all different things like that, that are out there. Well, you know what, a lot and almost in most cases proprietary code can be an issue. Things have been designed specifically for these devices and almost comes in with a solution completely baked there is not a lot of design built in for those devices to be used in other areas. I think there am actually be, this will be a hurdle for us to overcome. I think the market will drive this in the future as standards come out and we continue to influence the market place, you will begin to see architecture open up in a way that is much more beneficial to us. Excuse me. Device interoperability - Things like scanners. I'll use that as the chief example. I was just having a conversation with folks between at the break, linear versus 2 d bar code, data matrix; those are issues in the future. Today in our hospitals it's almost exclusively linear bar codes. What happen fist data matrix comes in and has the very compact design of the code that allows the 27 digits that I need? That is great. I don't have scanners that can read it. This 2300 bucks or whatever the cost is per scanner if I want to do that and replace that. Excuse me. I have thousands of scanners. Can I actually afford to do that? I don't know, but honestly these things in any industry have to evolve, healthcare will, as well, material management information system and real-time location systems. If this is evolving just recently had material management information system is Lawson and it does have the capability of handling the G-10 standard, a great thing for us or GS1 standard, I should say. But not everybody is there yet, but it is being developed. I'm very confident. Rtls, realtime location system and rfid, those are very -- excuse me, these are I believe probably even the best case for making it simple, making it easy to record the devices. There are great examples out there. There are folks in the room who do a good job in this space. I think this is something we have to overcome the infrastructure cost to be able to afford it F. We do good chance there. Finally, how information systems kind of dealing with this and being able to exchange. It is evolving, as well. Use me. There are a lot of health systems today that are working with each other to begin to share information and as we begin to share information, we'll understand how best to treat the information, what information is required in the collection point. There is collaborative taking place with Kaiser Permanente intermountain healthcare, Geisinger, transformation group, I like to mention it, supply chain initiative beginning to evolve into the IT side of the business and the clinical side of the business and I look for great things out of that group. I'll end with these couple slides. Excuse me. Good patient outcome, care giver, bottom line. It's all about that. As we look at key areas effectiveness, tracking so that we make good clinical decisions. Alert. Those are extremely important - Clinical documentation, very highly important, Recall management, patient charging process. All these things that the caregivers can't stand doing, this becomes something that is extremely good for us in the future. Finally, positive bottom line. It's amazing how much money we waste. We've got to find a way to address that and so standards is the enabler for TOUS cut out a lot of cost out there today. With that, if I can live to reach my seat, forgive me, but we'll turn over to the next speaker. (Applause)

>> I thought I was going to have to go to work. Well, our next speaker is Rosina Bierbaum, MPH. Rosalind Parkinson is administrative director of the Ohio state medical center material systems. And here we are. There is the short cut. What is the hot key for this? 5? Oh. Is that the first slide? All right. Thanks for that tip, whoever that was. Great.

>> Rosalind Parkinson: Thank you. Thank you, Julian Goldman and somehow my title slide got dumped, I'm not sure how, but I am with the Ohio State University Medical Center and I'm very pleased to be here today and thank you so much for giving me the opportunity to talk to you about something that is important to me. And I want to just mention about our medical center, we are in CLOUM bus Ohio and small IDN, about six hospitals and a thousand beds about a billion dollars a year in revenue. So it's I think take a page out of Vance’s book, small enough institution we can get things done. We are big enough that we do have to coordinate a lot of these processes that everybody is concern body here today. And another little background item is that one of the things that distinguishes Ohio State from many IDNs, we do have a very centralized support structure, not just for supply chain, but also for our information technology and our financial systems and other support systems. And this is very help envelope sporting new initiatives. And what I really wanted to talk about today is actually a case study. It's a much focused little thing. I'm really pleased to hear the big picture kind of conversations that we've had here today, just so exciting to me to see the context that we're all going to be operating in the next decade. But my contribution is much focused, very small, practical. And going to steal something from Dr. Droza, from yesterday, because when he said, it's not about the money, it's about the money. And I'm going to talk about money at Ohio State relative to the CMS rule to be sure to refund CMS for any devices that we may have credits from our vendors. In other words, if we get an implant from a vendor that is free to Ohio State, CMS also would like to benefit from that. In other words, they don't want me to charge CMS for a device that I got for free. It makes good sense to me, actually. Makes perfect sense. And so they did put in place a rule in 2007 that formalized this. And we needed to really make sure that we had our ducks in a row to refund CMS for any devices that we may have charged them. So this is our problem and we had many hospital systems to track all that we do and we found in this little study that to track implant credits was a challenge. And so I'm going to share with you a little bit about how we uncovered that. So I hope this works. Good. This is the background. We know that we must use modifiers claim when is they receive credit from the manufacturer when we receive credit and the manufacturer, 50% or more for placement device for any service furnished on or after January 1, 2007. Last year the OIG conducted an audit of four New England hospitals to subtract how they were doing with this particular regulation. And they published results in January of 2011 indicating that there were some opportunities for those four hospitals and so at Ohio State our compliance office thought we better check to see we are in compliance with this particular regulation because we knew these New England medical centers were doing things well and we wanted to be certain that we really button this up. So our compliance officer pulled together managers from 10 different departments that she knew would touch data related to implants and charging our patients for their use and decided that we would develop a work flow theoretically showing how the information about accredited device would pass into the hospital and through our billing systems into our claims processing. So that was our initial effort. We ran into some challenges right away. Because we found that there are multiple sources that identify credited devices in our institution. We have OR tracking. We have the system that we use to inform us about the implant recalls, which is commercial system that many hospitals use called Razmus, and we can pull that information and do pull that information in daily. So we know a lot about the recalled implants. But we also know that our vendors send letters to physicians and patients about recalled implants and of course those are the ones that we would assume would get a credit if we were to replace the implant. So these were some of the sources we identified and we found that our clinical systems track a lot of information, but they lack reporting tools for the procedure for Xplant. We of course do record it in the record, but it's not easy to retrieve that information. And in the operating room we found that the OR device tracking logs were in some of our operating rooms were on an information system, but in others, different hospitals in our system, they were still on written logs, which really inhibits automated search obviously for recalled devices. In our revenue cycle, we lacked a process to identify claims where modifiers are required. In other words, we know that we need to put in modifiers for certain procedures, but we didn't have a process that actually identified that, that we could go back and search. And our purchasing and accounts payable systems and I've already mentioned how wonderful we are, very centralized and all that and very information savvy. Nevertheless, we had no way to track specific devices for which a credit was received in our business systems. So this looked very challenging to us, but not a problem because we knew that our implant vendors are required by the FDA to keep track of patient specific records for all procedures involving recalled implants and so what we immediately did was the purchasing department was tasked to solicit from vendors this specific information that we needed in order to initiate these refunds. And so we went to them and asked for this information from 2007 forward and then when we got it, we recalled and credited devices were tracked from purchasing to our billing system to the medical record and claims processing departments. And concurrently, the claims processing people got from the same vendor database; the names of the patients involved and were able to identify the patients that were CMS patients and the dates of service and so forth. So we began to kind of tackle this from two ends, one from the medical record and one from the business systems. We determined after going through this process that obtaining credit data in real-time right now for Ohio State is not practical and we developed procedures instead whereby we would regularly query the manufacturers, the vendors for four credits and then review the medical record as we had done in this project and then we would resubmit the claims to CMS and we will do this process quarterly. And we felt that we achieved something there, it was not exactly smooth and it also revealed so much difficulty within our own, so many silos and so forth within our own processes. Our compliance officer was very happy that we could complete this. We did this within a three month period, but she was very strongly critical of the fact that we needed to use vendor data and that we were dependent upon our vendors for data that was so critical to our largest payer. And so she challenged us to come up with another process where we could use our own data in the future. So we did define a future process and we will be able to implement this actually part of it quite shortly. Like many hospitals in the country, Ohio State University Medical Center will be coming up on our electronic medical record by the deadline so that we can get, have meaningful use and have the incentive rather than the stick from CMS. And that will be online in a couple of weeks and I can tell you that it is all encompassing process. For those who work in hospitals, I'm sure you can imagine. For those who don't, it may be hard to imagine, we are really stopping all sorts of things that we regularly do in the hospital so that we can make this implementation successful one because it's a big cultural change for many of our clinicians. So we're looking forward to this date. This is our little work group requested the IT department to specifically of course the electronic record people to develop a drop down menu for use in our operating rooms once the records live and procedure areas so in the future data entry during the procedures which we are going to be doing now and electronic record can include queryable data about the reason for explants. We need to be able to search our EMR and find the recalled devices. So this is a first step and we do expect that to be online shortly after we go live. Again, we will, the device data will still be separate. I mean, still be look nothing our business systems for the device data. However, when the UDI is available, we look immediately as soon as we possibly can do it technically to use that UDI in our supply chain systems so that we have a way to query the recalled implants in our business systems. So that's what we talked about with our compliance officer in terms of our future process and she was satisfied, if you'd like to see a few more details of course, and but I think the UDI is a key detail to get that implemented. And I mention this is a study and really elaboration on the results in terms of what we found and again it's really just disSINT GRAGZ of the current data we use product description and billing staff use charge codes and everybody has their little way of relating, their little lens as somebody said earlier, to the process that absorbs us all and this is extremely difficult in terms of providing a standard of care and quality as Vance Moore just mentioned. One thing that was distressing thing to me because I'm been the pushing data integration for so long from the supply chain side was bullet point number two here in terms of device data moving between systems. We definitely do have it move based on manufacturer number, things like that. But I tell you, that data even if it passed between systems, full of errors and we couldn't depend on it and had to actually look manually even when we did get the data from the vendors. We had to look at each one of these transactions. So we know that it will still be that way with the UDI for a while, but we're looking forward to future when this becomes more routine. And of course the real challenge that we knew about, but persisted and came to light in this project was the fact that although our billing systems and our business systems could all be well connected and are somewhat there was no connection to the medical record and the reason of course, there is a good reason for that in part due to HIPAA regulations and so forth. We need a key data point; it is going to connect to the two and looking forward to the UDI being this for the devices. Again, results. We had great response from vendors. We have a fairly centralized system, as we said and we only have 10 vendors in this space and they were most responsive, six responded immediately within seven days and then we had people on vacation and so forth and but within three weeks we really had all the data we needed from the vendors, it was very satisfactory process. And we had a pretty complete data set, within a month we knew we had 61 cases for 2010 that we needed to look into the detail and 58 of these met the criteria, CMS criteria for refunds. We were able to process those fairly quickly within about three weeks for 2010. We're continuing to work on the 2007 through '09. If it is more than a year old, it's in a different category. So we wanted to get to the earlier ones first. And again, the challenges identification of our credit worthy event and knowing of the receipt of the credit and the billing department, these were big things that we talked about a lot. Of course most of these people are in our finance area, so these were details they understood. The lessons learn Friday here were very interesting to me be nothing supply chain, is that you really do need to include people from the clinical areas, as well as your financial area in IT to kind of get all the different perspectives on something even as straightforward as this one project. And it was very helpful that our compliance officer was the key leading person in this organization, this project because she assumed responsibility for completing the project. Often when you have many departments involved in something, it's difficult to get a key responsible person who is going to see it through to the end and she offered leadership that made that possible. And our IT people who of course in the middle of implementing the electronic record know and have known and are of course training all our clinicians on the importance of interesting data at the bedside. This project really helped them know the key importance in terms of our billing systems, which I think, you know, was something that was helpful to them. But I think that the key thing that really inspires me to the future here is that when our compliance officer complained that we were relying on vendor data for something so critical to our mission, she insisted that a future process, that the hospital, the healthcare system needed to take an active role in terms of anchoring the data. And I think that's really helped us all take more ownership in the process. In summary, you know, we found that the hospital supply chain is disconnected from the billing and clinical system implant tracking. We were thrilled that our implant vendors were as responsive to our need as they were and we will continue to rely on them in this period when we don't have the data. And we are really looking forward to future where we have electronic processes involving the electronic health record and the UDI and to connect these systems again, the interoperability you have heard about, very important so that we can have real-time billing information to assure our timely compliance to the CMS credit management policies. I appreciate your attention. This has been a real exciting thing for me to share. (Applause)

>> Julian Goldman: Thank you, Rosalind Parkinson. Our next speaker is Natalie Wilson MD, MPH. Natalie Wilson is co director of the Health Sector Supply Chain Research Consortium at Arizona State University School of Business. And let me see if I can -- there you go. I'm getting faster.

>> Natalie Wilson: Hello, everyone and Jay, thank you for asking me to participate in this workshop. I'm going to focus on the clinical value of unique device identification and the context of integrating UDI throughout hospital systems. And the areas of particular focus for clinical value are patient safety, improved clinical process and beyond the point of device use in a patient. That's really a huge area and many have talked about that yesterday and earlier today. And certainly when you improve a clinical process and you're able to capture data from post-market surveillance and do meaningful things with it, that loops back around to enhance patient safety and optimize clinical care. So I like to visualize this as you are moving across a hospital system and really starting in more of a supply chain realm and moving to the point of care for a patient; and then looking beyond the point of view of that device. So the first really important area to consider is UDI is a standard to document devices that are in a hospital. So what's happening currently is there's really a lack of standard for device capture and record across hospital systems. A bar code on packaging may be scanned at receiving, which may or may not be a true UDI. There may be a manual process or some combination of that. So subsequently, there is not necessarily a clear record in the IT system of all devices in the hospital. And as Jay mentioned in his introduction yesterday, there is often use of proprietary numbers, so there is different numbers at the manufacturer, at distribution and then at the hospital level. So certainly an improved process is to capture UDI at receiving and to store that in the IT system, which is that level would be the supply chain for a clinical standpoint, that provides traceability if a device is recalled and of course is very important for patient safety. A second important area to consider is UDI as the standard to facilitate device information at the point of use. And I see this analogous to medication verification and administration at bedside. There was a study done that was published in the New England Journal of Medicine last year, where the researchers looked at a large academic medical center before and after instituting an e-mar system or electronic (inaudible) record. They found a statistically significant reduction of medication error after EMR was instituted. They were looking at proper medicine, dosing and timing. The way that e-mar system works, a physician will write or enter his order, his or her order in CPOE that will go down to pharmacy where the medicine is filled. The medicine with the bar code will go up to the nursing station and when it is time to administer the medicine to the patient, the nurse will go to bedside and they will actually scan the patient wristband and they will scan the bar code on the medication. There is any problem, wrong medicine, wrong patient, wrong dose time that, information will be conveyed. So what is really nice about this is linking all those points, physician order, pharmacy, nursing and the patient. I certainly see this being extended to devices. And what you would hope for is that you are going to use a particular device in a procedure potentially at bedside or another setting in the hospital and that you would take that device. You will scan the patient wristband which could provide information such as patient allergy, latex, metal alloy, titanium, etc. that may preclude you from using a particular device. Then of course scan the UDI of that device and what you would want to find out is if this device has been recalled and maybe not removed from the hospital yet. So again you are starting to link different parts of the hospital there because certainly that recall information would be put in as more of a supply chain level and now you are at the point of care bringing that information together via UDI and IT. So from a clinical standpoint, SFRNL enhances patient safety. Another very important area is thinking about UDI as a standard to document devices implanted in a patient. Currently there is not a standard for documentation across healthcare, across specialties for implantable devices. A bar code on the device package may be scanned at the point of use. The OR, cath lab, IR sweet, etcetera, generally it's not connected to electronic health record. That information may be entered into implant log, which is a manual process. Sometimes labels are taken off the package and actually just stuck in the record. And then physicians will tend to dictate or enter into an electronic system descriptive information for their operating or procedure report and actually in many cases also there are copying the OR record or taking a label to their office. So some specialty, the patient will get a wallet card with information on the device, but that is not the standard across specialties. I want to give you a couple examples as we look at the current process and some potential impact from a clinical standpoint. When we look at orthopedics and revision joint replacement surgeries, once the surgeon has made a determination that the patient is a candidate for revision, they want to obtain the operative report to figure out what are the original components of the original implant. This can be a really time consuming process right now. Records can be paper, they can be electronic records, they may get the records and the information is not complete that they need. The impact of this is certainly in efficiency for the surgeon are preoperative planning and potentially preoperatively and the patient could have a more expensive surgery. Just a second example when we look at interventional cardiology and think about stents, certainly on-call cardiologist may face a patient they don't know that has regional stent. They need to get information about the stent. Is this drug eluding, bear metal, what are diameter and the length? Getting this information is not always straightforward. They may take the patient for additional imaging to help get that information and the impact of this is summer a time factor, what can be urgent circumstances because patients may be having chest pain, they may be he dynamically unstable. The patient may need to go for extra imaging which is time and cost for the healthcare system. This is inefficient for the cardiologist. These were just a couple examples, but there are certainly many other class devices to consider that I've listed here. Very important for initial documentation and of course to be able to go and get that information if one of these devices needs to be revised. And there is also important class 2 devices that are used very frequently in various surgical procedures such as mesh, slings and bands. So an improved process to think about is captures UDI at the point of use, connectivity to the electronic health record and set field in EHR for UDI. And from a clinical standpoint, this improves patient safety, the clinical process and of course physician efficiency. And the last area I want to talk about is UDI as a standard to facilitate efficient and comprehensive recalls. Currently as I touched on earlier, there may not be a clear and comprehensive documentation of devices that are in the hospital. Also, for devices that are in a patient, UDI and electronic health record is not the standard and there is not a standard for documentation. So approved process would be capture UDI at receiving, that would allow trace ability of devices in a hospital, capture UDI at the point of use and you have linked that device to that patient, and then UDI in the (inaudible) field in electronic health record as standard place of documentation. So a hospital could certainly obtain very frequent updates from the FDA device recall database. They can query their IT system using and identify devices in the hospital to remove and patients that have received device to contact, so clinically very important for patients safety and improved clinical process. I just want to make an analogy to retail where product entry into stores is captured via the UPC. Recalled products are generally tracked quickly, removed from the shelves and information is made publicly available; and just one example when we look at warehouse membership such as Costco, or such. Every time you check out with your member card, they are tracking what you are buying. So if there is a recall, they can contact you and let you know you bought that product. They link that to the UPC. So the ability is here, but we're not utilizing it in healthcare. I want to put up this figure because I think it's a really good pickup of once UDI information is electronic health record, all the places, this information can potentially flow. And certainly I've just talked about for advice identification and patient care, very important for electronic transfer of health information containing UDI and we often think hospital to hospital, but there is the whole post acute study and of course the private offices and when you think about orthopedics, where physician guess to different hospitals to do surgery, having comprehensive record in their Office of everyone is really important and having UDI for the devices those patients have implanted. Certainly for patients copy of their health record, we've touched on some of the FDA initiatives, the sentinel system and population database. Course for post-market SUDy and had a whole panel yesterday on clinical registries, so certainly if UDI was the standard for device information input, you potentially link data with other like registries and something I'm actually going to add here after yesterday's panel discussions is link with other data bases. And often registries come adverse event recording that leads to recalls and as I just mentioned, the hospital can access information, loop back around and query their system; really an incredible amount of potential here. So moving forward with integrating UDI throughout hospital systems, number of points I want to make and conclude with. First of all, realization that achieving the full benefit of UDI is much, much more than the manufacturer's UDI. UDI needs to be respected, not altered from manufacturers, through distribution through supply chain to patient care and beyond. Certainly hospital needs to have appropriate bar code scanning technology, needs to be properly programmed, and those using it have to be educated, not to by DLTD pass the system. IT systems need to be capable of storing UDI and there needs to be connectivity. Supply chain, point of view, point of view to EHR and then other areas such as EHR to registry, EHR to outpatient records, etcetera. Thank you. (applause)

>> Julian Goldman: Thank you, Natalie. Our next speaker is Dr. David Stockwell. Dr. Stockwell is executive director of Improvement Science, as well as medical director of Patient Safety in the pediatric intensive care student at children's national medical center in Washington and leading multi-hospital collaborative of Children's Hospitals investigating automated adverse event detection. Sounds quite interesting.

>> David Stockwell: Thanks a lot. Thanks for the opportunity coming and talking to you all about this today and what I'm going to present to you is essentially a case study in an attempt to try as best we can with -- without having all of the terrific connectivity and interoperability that you've heard a lot about from this pan and he will previous panels about how things may work in improving adverse event detection or device failure at a specific individual hospital. The collaborative we have has really focused on medical triggers and some of you may be familiar with the concept of IHI triggers. We focus on them and apply to pediatrics and learn from each other when implemented at each individual hospital and what I'm going to talk about today is collaboration that we had with the FDA to try and extend that work over into device detection or device failure detection. So we've had a little bit of success in using our automated approach and certainly not unique in that. Several hospitals are using their EMRs to try to identify triggers. Those things that might be in a chart that have potential to represent an adverse event and for those of you with somewhat of a medical background, I think the best example is if the medication called Narkan, medication that reverses effects of morphine and (inaudible), if that is present in the chart, good chance the clinical team thought there was an overdose of that kind of medication and so as safety and quality person in the hospital I'd like to find out what was going on with that patient that made the team think they had received too much of that medication while they were in an acute care floor in the ICU. It is a trigger, triggers more investigation. We've done a number of those things for adverse event detection and I said this is expansion of that idea into devices specifically with positive pressure devices. So ventilators were chosen at our hospital because they have a likely frequency and there is certainly a potential for harm. Several other devices were considered. We wanted somewhat of a high level of complexity to make the project tangible and actually represent something that does have real potential for harm. And the use of ecmo, depending on your view of that is not that frequent of an occurrence. It is not frequent enough to really try to test out and the same thing with other complex devices like cdvh or dialysis machines like that. We chose positive pressure devices, we specifically started with ventilators in the beginning and we expand that about halfway through. So I'm just going to walk you through the process and give you a flavor of what we saw, what we did and what we saw and if there are any questions we can take that up letter. But we when we started this process we were not -- we were documenting ventilator ID in the chart. This is a screen shot of a test environment of our own system. This is Cerner EMR if you are curious. You will see that in the center over here is where we asked our respiratory therapist to enter the ventilator ID. What they were doing wasn’t well regulated at our hospital at all SMCHLT places would put the ventilator's own ID and the serial number and some put the biomedical engineering device number in there. It wasn't a consensus process. But we spent a lot of time in the beginning trying to iron out the issues, what numbers do we want in there? We chose the biomedical device ID number, unique children's number to use because it's shorter. It's five digits and actually represents less opportunity for key stroke errors and that is why we chose that and every device in the hospital has them. So if RT will document that there was a previous ventilator ID, and those ID changes, that is our trigger. That device ID may represent that there was a problem with that ventilator so that device ID is self changing. That was the trigger and you will see in our test environment that the RTs would get this alert that is on the screen here. It tells them hey, RT, you have changed or the ID number has changed. If this actually represents something that could be related to device failure, please go to a separate part of the chart and document what was going on with the patient, what was going on with the ventilator and you probably would ask, we certainly asked and beat this question up extensively, why can we just force that function to just ask the RT immediately, is this a ventilator device problem? Yes/no? If yes, describe the clinical situation around that and because of just software limitations we weren't easily able to adapt this alert to be able to have that functionality and I don't think this is unique to our vendor. I being that that ability to be quite fast with answering the questions in the EMR is something all vendors face in some way or another. It's not easy to make big changes in these systems without extensive testing and substantial resources. So this is how we overcame that resource limitation was to provide an e-letter. The RT was asked to go to a different part of the chart; the ID section is what it is called in our EMR again. And then ask, was this event error code? If it was a code, what was it? If it wasn't, what was going on with the patient? What was happen something tells us your story about what happened with the child. If they forget to do that, there is no forcing function here, there were reminders that are sent to their inbox to say there was an ID change that happened before, please go back and make sure if this were related to a device failure or potential device failure, put that in so we can be logged. That then is once there is documentation in that section of the chart that I just showed you, that then would generate an e-mail that would go to several people, but certainly went to biomed and biomed would see there is something that had potential to represent a device failure. The best thing is if there was actually a device already in biomed and they said, that device is right here, it actually had issues last night so we've got our double check mechanism to make sure the device is coming down as opposed to staying in the inventory and going back on another patient. And that was typically the case when we did see this happen. So biomed would get the e-mail. Their team would investigate, is the ventilator here? If not, they would search for it and grab it and bring it down F. They found something was wrong with the ventilator, then we would do what several of us are asked to do is report these device failures to the FDA through the Med Sound System. Just in case anybody is curious, these are ventilators we use at our hospital. I figure any anesthesiologist will want to look at this for a while, I'll keep it here for a second. Just kidding. These are the fields automatically reported to the biomed team. These are things pulled instantly from the EMR, didn't require the RT to document - they were pulled out of the EMR and sent to Biomed in an e-mail. There were a lot of things we would love to be able to do; they weren't discreet data points we were able to identify. And so the results, what did we find? Well, we found actually lower frequency of these events than we anticipated which again depending on how you look at this, good or bad, ultimately good. Take good care of the patients we have in our hospital, but we had a lower volume than we anticipated. The most common reason for ventilator ID changes and probably of no surprise is that in pediatrics common to change from conventional ventilator to oscillatory ventilator and that represents a third of the cases we saw, Escalation or deescalation from those things. There was, there were occasion a small or a quarter of these cases actually did not have any documentation associated with them and there any ventilator that was identified that arrived in Biomed. What we assumed with that is that they were changing them out, but had not documented for reasons that were not associated with a device or potential device failure. Key stroke errors were a large number of the alerts that came, as well. And then the ventilator changed out to rule out the device malfunction is something that happened with some frequency, but most of the time that was actually not the case. There would not be a device malfunction. These are the ones that actually did represent some kind of a device challenge to the team when they saw them. There were technical error codes. There was physical damage to a device. We had OT filter failure; there was encoder failure and a nonreproducible concern with one of the positive pressure devices that we used. The clinicians saw and heard a certain scenario, that was not reproducible in Biomed and the device ultimately checked out and was put back into service. So if any of you follow triggers, most of the time we calk in terms of positive predictive value. The positive predictive value of this intervention was 13%, which is pretty low. But I think what is reassuring to me is that as a hospital safety and quality physician, what I like about doing this is that I knew that we have some holes just relying on the entire process of the therapist taking the ventilator and making sure it goes down the biomed and this does provide a safety check. You can imagine that if we had UDIs associated with this, especially if there was bar coding associated with this process, that it could very much be streamlined so that the real work flow impact is minimized. And that it does what we want it to do, provide that level of safety checks to our organization. So thank you all very much for the opportunity again. (Applause)

>> Julian Goldman: Thank you, David. We have some time for questions and answers and I don't think we need to use -- there we go. Okay. Please step up to the microphone. Yes. And let us know who you are.

>> Dan (inaudible) with Asendia. I saw you yesterday at the medical lab. This is somewhat related to that. You know, as I LCH to most of the presentations, some of the key words were systems and integration and IT and connectivity and so on. And healthcare becomes more and more reliant on automated equipment and information technology and so on, there seems to be some challenges around putting all of these together and also it will probably cause some strain around health information technology later. Now in addition to that, you are also seeing general purpose IT in addition to your connected medical devices and intelligent facilities and now as of yesterday we talked about medical device Apps and I just heard this morning or saw this morning the FTC has absolutely pulled two Apps from the app store that claim to cure acne. You put the phone to your face and the red and green light that were emitted were supposed to cure acne. 3300 downloads of that kind of app. We are seeing this proliferation and seeing the use of these devices, also yesterday there was an announcement by IDM and Wellpoint they plan to use Watson, the computer that beat jeopardy for medical uses to suggest to doctors perhaps some questions. So the question is: How are you addressing or how would you look at ways to address the impact of this convergence technology and proliferation of technology in healthcare to reduce some of the risk associated with all of these devices and technologies?

>> Esteemed panelists?

>> Well, I'll jump out just a little bit. I don't know that this is necessarily the answer that you're looking for, but you know at Mercy we evaluated all the system we have out there. 36,000 co-workers across the Mercy system, over 5000 applications we have to manage. And if you think about it on a ratio basis, that's crazy. But the health system of today because they have been established and proliferrated and everyone buys their own system and there is lack of connectivity.It is a big issue. We have major initiative going on at Mercy today to decommission. I think we've cataloged majority of application, which is best in class of where we are going to go and we're making in many cases tough choices to actually eliminate systems that may be out there and then being able to identify what are the sacrifices we're making in doing this. We may become more effective, but yet to be able to take out some functionality. We will probably have to do custom coding. We don't like that at all. We may have to fill some gaps with either other application uniformly adopted or specifically coded by our internal experts or whomever to do that. I also believe this is going to be -- now that is a very central and focused and IDM type of approach. I think you will also see while that is going on simplification inside health system, you will see the expansion of interoperability in the cloud and with other health systems and things like that and you know, going to be a little messy, be a little sausage making going on there to where we have to understand we try it and we're going to make mistakes and go back and learn from that and try something else and we'll continue to answer our way to I guess a better outcome in the future.

>> Rosalind Parkinson and Natalie Wilson, David, do you want to add anything?

>> Sure. I'll jump in just a little bit. I think that what you have probably heard here over the last day or so is no shortage of ideas, right? There is a lot of good potential here. And just someone in the trenches, that an individual hospital, it is incredibly challenging to find resources to be able to make these things happen. I mean, on our list of things to consider, I'm sure other people have different lists. Are we going to make the investment, bar code something should we spend a couple million on making ventilators talk to monitors to talk to EMRs? Should we do the same thing with smart infusion pump? Should we upgrade operating system in all computers from Windows XP, to Windows 8? These questions, we don't have, they are endless and challenging to make happen. And so I'm not sure how we're going to get out of that, I'm not sure how we are going to get out of that.

>> David, do you send data from your ventilators through anything do you collect that data automatically through the interface? The ventilator alarms are sent to our monitors, so that there -- that goes to central monitoring station.

>> Okay.

>> But we do not send ventilator data to EMR like the monitor guess to the EMR, but it is something we have, there is the ability to do that, it's just the dollars to make it happen.

>> If you did send ventilator data to EMR and UDI was part of that data stream, then you could automatically detect when the ventilator was changed.

>> Absolutely.

>> The data stream would indicate that.

>> Absolutely. And think about the potential for that kind of automatic evaluation that would happen on all kinds of different devices.

>> So in answer, part of the answer to that question, the DataStream that is sent by the medical device, if it is clinical data stream, it's treated one way from a regulatory perspective, for example, the recent medical device data system regulation doesn't clearly differentiate, but implies a (inaudible) from clinical data from the device and nonclinical data from the device. One might think UDI along with serial number and other information would be considered nonclinical data on the surface, but as we see from some of these applications, where it may have implications for patient care, I wonder if it would be considered nonclinical data that would be excluded perhaps under the MDDS analysis? I don't know the answer, but we have no shortage of FDA experts here. (Laughter)

>> Please.

>> So one comment and then one question. Fred Resnic from (inaudible) Harvard, Boston. So the comment is I just think it is really refreshing and spectacular that the diversity of perspective that is represented in this type of panel from hospital system, administrative leadership, all the way down to sort of clinical investigation and tying it in. It's really unusual to see that in almost any forum and I think it is sort of a model for how healthcare improvements have to leap forward rather than sort of inching along, especially with champions and each of the realms that you all represent. I just think it's really testament to the sort of DMFDZ FDA forward-looking leadership on that, but also especially harken back to what Mr. Moore was saying about the opportunity to not only improve the operations and the lives of caregivers by reducing the variation or ability and sanity of multiple systems but actually improve the care and then improve the bottom line. That is where the incentives can get aligned. We are fortunate to bring that together. I thought that was a great panel. The one tiny question is as clinician and interventional cardiologist; sometimes we use devices, but don't use them. People have to think about exception cases like anything in software and systems. So interventional cardiologist, I can open a stent and put in the body and take it back out before deploying it and so while the UDI needs to be tracked and by the way, will be credited for it

>> Oh, yeah.

>> But the patient didn't really receive it, they were exposed to it, so there is almost implant in particular we have to think about the complexity and levels of complexity about what is a full exposure or partial exposure or the economic or tracking devices. I don't know if anyone has thought about these sorts of things and I don't know if people have any thoughts about the nuances of not only opening the package, but what it really means for the patient.

>> I want to make a comment about that. I think one of the things that's been lacking is really enough clinical input and we've hit on that yesterday and today also just about the different specific attributes we may need depending on the specialty and the procedure, but you're hitting on that with your comment. I mean, you -- not even something I thought about and I think that often those who don't actually do some of these clinical procedures aren't necessarily thinking of those nuances that are very important. So I really feel that from the clinical side there needs to be a clinical team that is very involved with this process just held to the questions and nuances.

>> I will say in our organization we do have a classification called Open, not Used that is captured within epic. The problem is it could be utilization issue. I opened it, it is on the back table, the case is finished, I throw it away, versus exposure. Tomorrow I will make a note that we're going to add another classification or something that is a different case.

>> In a sense, we're talking about the UDI as the core enabler and these other things as metadata that will evolve based upon practice patterns, workflow and so forth it sounds like.

>> I have a comment. It seems to me that if you really can get your systems coordinated interoperable, all the words connected. Things like what you just described will be the exception and we will be able to actually analyze a little bit better about what we're doing. I think that unfortunately people mention these exceptions and I don't mean you at all, but you hear, well, from the clinician, what happens when I do this? What happens? It becomes a barrier to progress for putting in the basic platforms that will help all of us and so I just really think about that situation as an opportunity and probably lots of those opportunities out there. I hope there are because our care really has to be variable by patient. Right? It's not really ever supposed to be the same for actually every single patient. It's supposed to be personalized. So that's really our goal is to have standards that we can use, but depart from really to really take care of the individual patient. So I see that as one of these things that pops out and you know, okay, and but it doesn't right now it is just part of static, huge noise out there that includes a lot of standards stuff.

>> Thank you. We have four folks waiting in the wings with questions. So let's keep going.

>> Nick (inaudible). Want to ask a question for Julian Goldman and for Vance Moore and David after the presentation kind of asking how you implemented this, one of the pragmatic issues are the serial numbers and the biomed numbers you put on devices. (Inaudible) we have long UDI serial number as you pointed out. That is not something you want to put in the hands of users. We put our own short code, partners and bring them to the customers bars and go to biomed, they put their own number on there. 50% of customers have biomed department that puts their number on. We're looking at three different numbers out there. What are we going to do in the future? I know for UDI, only for new devices going out, but we have thousands of machines out there already and I don't know what we're going to be doing. I'm looking for guidance, what happens when we have to support or you have to support both where you are looking to go to UDI number, but dropping biomed numbers, how do we support our old devices then and how do you support those old devices?

>> Panelists?

>> Well, I'll jump in. I would say on most reusable medical devices we do assign aliases, so like you are mentioning, most people take your number, that is nice and will record that to the capital equipment register, but we'll assign it our own identifier and keep track of meantime between failure, number of that device or whatever, piece of machinery. That is my understanding how we manage it today. One of the big issues we have are reusable that are single use device reusable. Things like that come in under completely new number and so sending those back out. Only certain numbers of iterations those can go through, those are things we are struggling with today to track them appropriately.

>> What I think of there is transitions. I mean, we've had to bring in new systems for all sorts of things in the hospital. It's always an issue what you do with the old data versus the new data and that type of thing. I see it in that context and basically what we do, let the old system exist and we do whatever we did with that data, we continue to do for a long period of time. We give it a tail of X years and then with the new systems, we do new things. So basically we have to support two different ways of approaching something; four periods of time and sometimes up to two or three years. I think of that situation size being what we would have to do.

>> I agree with that.

>> So I would add that the manual data entry in any part of the system is the thing that has to be eliminated. Multiple databases that automatically correlate are still a problem because errors will creep into the system and there is a cost to it, but getting rid of the manual stuff is the most important step to eliminate if possible. Just a thought. Please, let's move on.

>> Michael (inaudible) Johnson and Johnson. My question relates to practical application usage of UDI and I think it's most directed to Mr. Moore. Now that the Mercy system has gone live with epic across your system, when you consider some of the reality of having to customize some of the hospitals, 34 future hospitals that you mentioned, do you -- how do you anticipate any kind of challenge when it comes to pooling the data around UDI. Natalie Wilson brought out the slide about practical usage of UDI, have you considered what challenges you may be facing as you go to pull that data to make it useable for research or other purpose?

>> Absolutely. I would tell you that don't be seduced into thinking that single EMR clinical system across all of Mercy is anywhere close to being perfect N. Fact, we installed in three different instances just due to the size being able to do that. We are finding all kind of variations that exist. Start times are different. They are populated. Right off the bath, we are finding clean-up effort that needs to take place, each the processes for which we define care today. That is relatively new install. We installed it completely across the system and are refining it. As things come into the system, the nice thing is we built repositories and data warehouses to store the information and associate it once everything is clean and be able to support it to Joe Drozda and his research team to work with that and look from a longitudinal perspective. That is one thing I think we are blessed in having. We can track within the acute care setting and out patient setting. 3 million unique patient encounters last year. Of the 3000, 147,000 actually put their heads on a pillow. We have a lot of transactions taking place as far as care is concerned and clinics and physician offices and things like that. Now we have the ability to take this information and the data warehouses and track this from longitudinal perspective and report back out on that in the future. It's early, though. I anticipate a lot of issues and to the past question, I didn't realize answer. When we use alias’s or things like that in our system it is usually because the IT system do not have the capability of accepting the length of the number or things like that. That is a big issue. So that is a big issue as we transition and new systems are developed it would be important that those systems, providers, be able to accept whatever the unique device identifier is ultimately decided upon.

>> Thank you. Yeah. Jim keller from (inaudible) Institute. Similar question for Vance Moore related to capital equipment. A lot of IDNs add on new hospitals and run into a challenge which is getting capital equipment database consolidated interest whatever system they are using. I was curious what you guys have done at mercy, if anything, to just be consistent across the whole system so you know how many CT scanners you have and which model and that entire stuff. We do. I would tell you, add us to that column of challenged health systems with that and I don't know that anybody if they were speaking to be honestly wouldn't put themselves in that category. About eight years ago we did invest in a single IT system to maintain our equipment to catalog it. I've got to be honest, the things I've seen, and everyday things surprise me. New equipment purchased within the last year is still struggle to have the asset tag registered appropriately and I would say even tacking capital equipment in a uniform way so you can find it is an issue for any health system. I would anticipate we have in excess of 10 to 15% equipment than we actually need because we can't find it. RTLS and other types of systems, rfid, will help hopefully in the future, help in purchasing the correct amount of equipment. Not only can we identify uniquely, we'll know where it is. That is a big issue for us going forward.

>> Thanks. I just want to ask that question about the challenge of tracking configurable devices and how that relates to UDI? So you are anesthesiologist and you have worked with patient monitors and have subcomponents pulled out and so forth.

>> Sure.

>> Like your thoughts on that.

>> That has been a question from the very beginning and one that has I think caught the attention of manufacturers who are very concerned. They have say for example a bed size physiological monitor with multiple components and the UDI is something assigned at the time of manufacturer, what happens when the device is configured? And in a sense part of the answer put forward is that the UDI is a license plate number, pointer, index toward some other place that has the data with the configuration and that is kind of a challenge because we are then depending upon either the hospital or some other entity to help store that data and manage it and so forth. I don't know what that will look like yet. I think it is very important and perhaps it will require some local storage of information in programmable memory on the device. So that configuration is written there and can be read as part of that. I think it is something that we'll explore in more detail in research program, especially if someone has ready to implement proposed solution so that we don't have to work it out ourselves. If we have to, we will and I don't know what that will look like yet, maybe Jay has the answer and keeping it close to his vest. I don't know.

>> Yes, last question?

>> Hi, (inaudible) college of American Pathologist and the discussion thus far today seems to be totally focused on acquired/purchase devices and our members are very passionate about laboratory developed tests and I had -- was interested in whether or not you think UDI applies to laboratory developed tests and how you attract those in your system because they are essential to so many parts of medicine?

>> Thank you. Panelists?

>> Well, I tell you, I'm -- been assigned responsibilities of performance reengineering group taking lab, pharmacy and (inaudible) groups and trying to reorganize in a way across the system. Laboratory is a big deal to us and one thing we're trying to build into it is potential tracking rfid, or other types of assigning unique codes per specimens and tests so they can track it through the entire system. Dr. Sky Sanderson at Mayo, I spoke with him on a couple of occasions. He was one of the people opened my eyes to the rfid tracking of lab specimens and at Mayo. That was something that really there is I have personally great interest in O. A scale of 1 to 10 as far as developed; we are probably minus 3 right now. We have a long way to go to get to the starting point. I personally believe it is going to be a big deal to us. Tracking and the assurance that the right result match the right specimen and test are extremely important to us.

>> Thank you.

>> Like to take a moment to thank our panelists for their hard work and preparing and -- (applause). Also would like to take a moment to acknowledge the hard work by the FDA, by Jay Crowley, Terrie Reed and probably many other folks I'm not aware of to keep this moving forward over a longhaul. Thank you.

>> Thank you, Julian Goldman.

>> Thank you AUM for the morning and now into the afternoon. It is 12:45, time for lunch, I'm sure you are all famished. As was indicated in some of the conference materials, there is lunch available box lunch available for sale for $15 out here. There is a restaurant in the hotel. There is a Starbucks and if you get really AFRNS, maybe you want to leave the hotel, couple restaurants toward the metro station, McDonald's and maybe something else you are into. If we could be back in 1 hour, 1:45, we will get going and try to get you out of here at a reasonable time. Thank you very much and thank you, panel. All right. Good afternoon. Welcome. I'm grad to see. You came back and hopefully all of you and webcast land have also returned. We're going to finish up with our last two panels of the afternoon. This first panel, panel 5, is actually reflects the title of the entire workshop which I think is interesting. So this is the role of UDI in postmarket safety -- no role of UDI in postmarket surveillance and compliance. That's the name of the panel. And our moderator, Dr. Tom Gross who is acting director of CDRH.

>> All right. Good afternoon. I hope you had a nice lunch. I hope you can stay awake. I think these presentations also keep you awake. So we'll talk about UDIs roll in postmarket fields and compliance. I would characterize this session as a potpourri of various applications trying to solve variation aspects of post market surveillance and compliance issues. So to begin with, let's start with Dr. Greg Daniel who is vice-president for government and academic research at health core a research focused independent subsidiary of weapon point. His research utilizes electronic health insurance claims data integrated with clinical data such as laboratory results, electronic hospital data, paper based and electronic medical record data and registries. And he'll be talking about I think primarily claims based data research.

>> Thank you. I'm going to talk a little bit about claims based research and the role that UDI might have in that. Anticipating that the audience might come from very different backgrounds and listen to go the presentations this morning confirms that for me. I thought it might be important to talk a little bit about what's so important about claims data and why would that be important in using for research because I think it's useful to touch on that before I get into then why would UDI have a role in this. Before I begin I just want to give a brief background of health core so you all can identify with where I'm coming from. As Tom indicated health core is an independently owned operating subsidiary of Wellpoint which is a large health insurer in the United States, owning 14 of the Anthem Blue Cross Blue Shield health plans. Hell core is focused on health outcomes comparative effectiveness; safety in (inaudible) most of my experience at health core has been utilizing claims data. Medical claims, integrated with pharmacy claims with enrollment information as well as electronic laboratory results. Health core has been doing research with this data since 1996, and we provide our research capabilities to various external clients including the federal government, pharmaceutical industry as well as health plans and our parent company Wellpoint. So before I begin I want to before I get into the role of UDI, talk a little bit about what I call this cone of evidence. This might be basic for some of you and maybe for others it will be useful to look at it in this light. So from the period of conceptualization of say a new pharmaceutical product we go through clinical trials. A lot of this is very applicable to pharmaceutical products, but to some extent can be strap late today devices as well. So the blue cone represents the medical evidence that's generated during the clinical trials all until FDA approval. At which point the drug is marketed and more and more patients begin using the drug. This cone of evidence continues to develop. Post marketing studies are done, safety, effectiveness; but really within the narrowly defined population usually on label use. So as time goes on from the point of market more and more evidence is developed. However, at the point of marketing, the actual cone of use of the drug is much broader than what we have evidence on. So you have this much broader area of utilization for which drugs are being used and many cases implanted devices and other products, but there's very little evidence on that. Why is that? Well, the little evidence may come from off label indications as I indicated and what actually what happens when the drug is being used. Differing age groups, elderly and pediatrics, race, and gender variances that may not mirror the actual use of the product. Unstudied comorbid conditions at FDA approval, very little evidence on many products out there is instead of in patients with multi comorbidities, in the case of medications, use of many different medications at the same time. So the point of this slide is to indicate that there's an opportunity to use other types of data for research. Once the drug is marketed there are many claims generated every time a patient goes to an outpatient pharmacy and gets a prescription filled there's a claim generated. Health plans have that data. CMS has that data. In addition, if there are any medical events that happen after exposure, a claim for an emergency room visit might be generated; a claim for hospitalization might be generated. There's useful information on those claims such as diagnoses, procedures, and utilizing that information to get an idea of what's happening within this patient population is useful evidence. So I have a slide on advantages of claims for research. For every one slide for the advantages I could probably have five or six slides for the disadvantages. So I won't talk about those today, but there are many of you noted there are many disadvantages. Not having an UDI is one of those. So claims that offer an opportunity to conduct research in a large population with a broad view of health care utilization with regardless of provider. They may into the hospital, they may within 30 days if they have a follow up with their primary care provider, and you have that information. So regardless of the facility or provider, you have a nice broad view of what's happening within this population. Data fields are standardized. And they're generally accurate and reliable for what they're intended to measure. Utilization - Clinical interpretation of what actually happened during a medical encounter is a different story. Claims are maintained in a searchable form and allow the ability to identify exposed and unexposed individuals and it's very important in doing research. If you only have data on exposed, then it's hard to compare to populations that might be using a different exposure. For adverse event reporting, if you only have data on people where there was an adverse event, is makes it impossible to conduct safety epidemiology research to generate (inaudible) within an exposed population. An important part is claims data are linkable to other external data sources. There are limitations. The clinical interpretation of claims are a limitation so there's an opportunity with a claims database, because you have patient identifiers in that database, using HIPAA complaint measures, you can link that data to paper based medical records, electronic medical records, registries, surveys, and other external data sources that might shed more light on what's happening to the patient; the types of research that you can do. Safety - FDA, as you may have heard yesterday, is involved with the sentinel initiative. Health core is a member of the sentinel project which is a pilot project under the SENTINEL initiative and it's demonstrating the value of using large databases like claims data to identify exposures and possible adverse event that might be happening in a population. Within the sentinel initiative in many sentinel pilots data will be used to identify exposures as soon as they happen and eventually to establish safety and risk profiles. Effectiveness is also a research is very important to be able to conduct. Economic analyses, cost effectiveness analyses, payer paid amounts, provider charged amounts, total health plan allowed amounts, all of these fields are in claims data and are useful for doing various types of economic analyses. So the issue with the UDI, in all of the previous examples they rely on accurate and reliable identification of unique product exposures measured at the individual patient level. As the example with drugs, you can identify patients who are on statin medications and which type they're on and then use a cohort design to follow a patient sub group over time and record medical events that have happened or record total health care expenditures. Without an UDI, it's virtually impossible do this so that if you look into the literature at claims based research you find very few studies that were conducted in the area of devices. Going back to my cone of evidence, there may have been you might say that this may not apply to some devices. But if devices are being compared to usual care or a pharmacotherapy alternative to the device, you want to understand which population segment are you looking at only data within that narrow cone to compare the patients with the device to a patient on pharmacotherapy or do you want to look beyond that narrow cone into the full utilization of the product. All of this is important to do. So the logistics is linking to the claims. There's a need to link individual patients to the device used. The ideal situation from a research perspective is that this would parallel with that of drugs. Pharmacy claims. We can identify each unique patient that has a drug and exactly which product that they had, the strength, the dose, and everything. So from a claims data perspective we already have that data from the health plan. We have information on all of those exposures. The ideal situation from a research perspective would be to have the claims transaction systems collect the UDI for each individual exposed to a device. I would say the other end of the spectrum would be to have some database somewhere such as a registry where right now if I want to link to an immunization registry, but state registries actually capture H1N1 exposure. If I want to do that study I can go to each individual state and link my claims data or I should say the claims data that I'm using to that individual registry to identify exposures. If that existed for UDIs, then there could be a possibility to link claims data to individuals that are exposed to UDIs. And then another example would be in the medical record. As electronic medical records become more and more in use, having each patient exposed to a device, and having the UDIs in that record that's linkable and searchable would be very useful for generating medical evidence. Thank you. (Applause)

>> Thomas Gross: Okay. Next we have Dr. Rick Kuntz chief scientific and regulatory office at Medtronic. He was a founder and chief scientific officer of the Harvard clinical research institute and he'll be providing a very important industry perspective.

>> Thanks, Tom. Good afternoon. At Medtronic we're a device company with a broad range of a lot of different devices so a lot of interest in what happens in the post market. About three years ago we initiated a post market network mainly focused on surveillance. And the thesis was that they were not going to be able to get the data we' needed from (inaudible) so we did a parallel system. And some of the comments I made earlier probably reflect that. Our idea was to develop an enterprise operation that could be utilized across the whole company with specific modular information especially in the outcomes could be focused on different devices and applied in an economically scaleable model. Of course to try to utilize a lot of the state of the art especially with respect to observational statistics such as the incorporation of fields to deal with propensity adjustment, to then create a global network to attract hospitals and other groups to participate mainly with the notion that we would try to in addition to performance of product, get relevant outcomes that might be of interest to IDNs and health care providers and also an ownership of the data by the academics so that they could participate and analyze the data anyway they wanted to in a prance apparent way and to create a warehouse so we could create the data required that is embarrassingly absent in the device industry about how our products perform in the years after product release. It's surprisingly deficient that we don't know much about the four or five-year performance of any of our devices in the U.S. or globally. And as we are trying to make some inroads in some of those areas a couple of our devices we had a little bit of data on. We need to have a wholesale and the way we follow data so both providers and patients can be well informed in their decisions to accept a device that we may offer. The advantage that such a network will obviously have a good business case for a company like Medtronic, early detection of any device issues is critical both from a perception of public awareness and our responsibility and reputation in addition to making sure that we can fix any changes the devices or take products off the market that may be harmful to patients as we discover in the postmarket environment. We want to provide an outcome for clinical -- a foundation for clinical outcomes to go forward. I think there's a lot of leverage that could be obtained from a parallel network. We have a lost examples where these are worked in the past, and the application of specific outcomes both in terms of kind of undifferentiated outcomes such as heart attack, stroke, and differentiated product specific outcomes that may serve as surrogates for clinical outcomes such as increase in (inaudible) or early detection of battery drainage for early end of the battery life will be things that we can leverage and have leveraged so far. In addition to the ability to utilize the wireless data that comes from our implantable devices in a more constructive way nor both patient care and also for device performance. To create a way to utilize the variety of IT cloud systems to engage patients in their understanding of what the summary performance of their data is as well as their physicians, and to represent a geographically diverse group as we start to look at this globally applied where there are different needs and different regions and try to understand how we can put boundaries on those regions to address the specific needs that might be important in an emerging market. Finally, probably one of the biggest things of my interest understands how the device is utilized. Some of our products are used anywhere from one percent on label to ten percent on label. And so understanding what the use of that is very critical. We currently are in a little bit of a catch 22 in that it's illegal to promote off label use so to study it sometimes gets viewed as also promotion. We had to be able to do a hands-off partnership with academic understanding of how devices are used so that we see frequent uses in certain areas we can work with our partners at the FDA and understand what appropriate measures we had to go forward to study them or pull them off the market if we think they're way off side the clinical evidence as shown in the previous device. So we look at this network as a former partnership, a way are to us get back into an academic frame of mind. I think that we talked a little bit about this notion of the marketing systems of companies moving to an evidence system. I'm a firm believer of that and this is within way to do that to move to a more evidentiary way of communicating our products and that requires us to have a variety of different networks. The most important thing I think is ultimately to aim towards something like full public access. We have just announced recently that one of our devices will be publicly available to the public through Yale in six to eight months because of our concerns about whether or not the data was analyzed in an appropriate way. It's our view that that when that happens the data should go to the public. (Inaudible) something we'll work with to go forward, but ultimately the idea is to move to an environment where the science and technology wins and the concern about the validity of data is something we can establish public trust with. So the proposition therefore is real world, real time data, long term outcome data, which is surprisingly absent, including in the U.S. a good method for longitudinal follow just doesn't exist in most medicine we work in. To talk about all the things we talked about here using -- taking advantage of automated data and IT and an ability to utilize a variety of the dividends we can get from such a network for darkening quality systems and so on. I think these are all very achievable. The proposition would be to for the regulatory agencies for us to be more appropriate responsible citizens, to be able to own product safety and work with our agencies in a cooperative way, to be able to take action as quick as possible, and to understand how the product should be used as I said earlier which is really critical. We need to better inform patients what was the performance of the devices are, especially iterative products, especially instructions for use so they can understand what the performance of the devices is. Many people feel because of the information isn't there, that these devices are perfect and will not fail and that's wrong. We need to let them know there's going to be a stew to three percent failure so that goes into the calculations they have. We currently don't have all the instructions (inaudible). Now, just a few words about the EDI considerations, based on the topics of this discussion. One issue about as we start to work together is understand what the definitions of the device is. Specifically in orthopedic business where one opens 1500 different devices in the OR and may use up to 30 or 40 major devices, maybe 200 small devices, it becomes like the part list of the Christmas toy that you're going to build. Are you going to give that to the patient at the end? You've got 25 different screws and so on. What becomes a device, how did we actually put a circle around them so we can make inference about a device. That's something that has to be worked out. Thank goodness there aren't too many examples but in orthopedics it's a big example. When if we do identify an identifier by this device, this gets down to the level of specificity and understanding, again, what is in fact a device. One of the consensuses of the product attributes. We know we can look at every permutation and put that as a serial number so that the cornerstone may have a hundred 50 different ones, but that might not be very valuable when you're trying to calculate the impact of No. One therein verse 110. You may want to say what the critical dimensions are. We may know that the material is important, the size is important, it's length may be important, are those the reducibility dimensions we really the should be looking at per se put them in a device code as opposed to looking at every possible permutation going forward. And then we have it on the patient attributes. There's an anatomy that these devices fit into which may or may not make appropriate causal risk for the patient and failure. If you use a stint in an artery that's much larger than that stint it's a risk for stint thrombosis. Not necessarily the stint but an anatomy mismatch. We can assume a bell shaped curve of inaccurate placement but we may want to be specify (inaudible) for this prosthesis and there has to be a way of consensus on that as well. Recalls are often cited as the important use of UDI data but it's facilitated by understanding the lot, the batch, and other product information. We talked a little bit about this production information part and how it will be melded with the device information. We think that should happen. We do know that there's a requirement out there to connect them, but it isn't uniform. And we currently do put information about our serial number and our lot numbers and expiration dates on there but that's not uniform across the industry so far. This slide takes that one step further. It's still an open and voluntary standard. We need to move to a combined standard so we can understand what the appropriate levels are that we can measure in the UDI and the product code per se. And ultimately there has to be harmonization across this so we can all understand how we can compare devices to understand specifically what might be a problem. As you know, many patients get different devices from different manufacturers in the same operation. So there are a lot of needs for uniformity if one wants to understand what happened to a patient that had a bad outcome going forward. So these data and all the other parts are critical. An example is that we have, for example, a pacemaker called the (inaudible) we have a variety of different reference numbers depending on the different batches and lots and products, and we know that a lot of the other competitors use just one for all of their approaches. Again, I think that the level of more detail is much more important going forward. What about linkage? As we talked about, this is probably one of the biggest concerns of EDI and expressed by other speakers throughout this workshop. It really does come down to understanding what the patient’s identifier is. And while we need to know that we won't get maybe all of that level of detail on a product etched in laser, we do have to understand there's a critical component that not only goes standardized on the device but also has to be in the patient record so it can be going forward. So the part of the patient identifier that's on the patient and passes all the privacy and HIPAA rules has to be just as rug rust and standardized as that in the UDI and product to really have an understanding of how we can use this, especially for postmarket surveillance studies going forward. There are a variety of different ways that we can look at collapsing these levels and understanding what level we're talking about. That also has to be something we have to standardize. We had to utilize a tax on my of language to understand what levels we're talking about so we can have an understanding of what the hierarchy and collapsing is. This is something I think that maybe a workgroup can work out and bring back to the public for comments. And there is a lot of devices information that's not UDI specific that really would have a lot of benefit for further standardization. They include, again, linked outcomes and, for example, (inaudible) in the world I've worked in, we tend to adjudicate most of these using art definitions. That's not applied in a lot of different areas. If you want to really understand did this product cause a heart attack it's not only critical to what the product is and how it was defined but you have to also understand how the MI was defined. And that's also a heterogeneous approach right now that we would advocate that if we're going to have standards, these don't require a whole lot of effort. Especially for the big outcomes, that we follow the academic standards that are published in determining these outcomes. They're just as important as everything else. But as most people said the first thing we want to do is measure product performance. It's important to keep it simple but there's a huge potential if we can take these next little steps going forward. And I'll stop there. Thanks. (Applause)

>> Thomas Gross: Okay. The next presenter is Dr. Be Michael Ibara. Head of business innovation worldwide safety regulatory operations at Pfizer. He'll be talking about the ASTER-D project.

>> Thank you, Tom. I think it's -- I was thinking about it this morning. If you remember we got comparison, an analogy between UDI and NDC in a sense. And I thought it was sobering to think about the fact that if we're talking about improving -- what I'm talking about today is improving the reporting of safety reports. If you know about the reporting of drug safety reports, you know that we struggled for years and commented about under reporting, et cetera. So it's sobering to think of assigning the UDI and there's great promise in many different areas, when we talk about of those reports containing that information, I think that thought points us to other areas that we need to address as well. So that's one of the things I'm going to talk about here. I'm talking about ASTER-D, which is Aster for devices. ADE spontaneous triggered electronic reporting for devices. And I have to give credit here. This acronym came from the lead investigator's wife at the Brigham and Women's. She was able to take this word salad and she came with this acronym. So I always have to credit her because the only one I came up with was taser and nobody liked that. (Laughter) So two slides on background basically. This is very simple, but this is really offer the last several years been my simplifying and my unifying assumption. In any safety pursuit that we're in drugs devices, et cetera, I think our system is built on the assumptions of sparse (inaudible) safety data and we have now moved into an era, I used to say we're -- I think we're in the area of abundant easy to get safety data. And so we've got a funny situation where we don't get many reports, but we're concerned about all the potential reports that we could get. And each report could have a lot more data in it. And so we've got a funny problem of we want the information, but how do we use it, what do we do with it about when we get it. And this is a hypothesis that I came up with for aster. It basically says when you look at the history of farm co vigilance it's built on vertical organizations (inaudible) and the data when it was hard to get. And that put the vertical organizations basically as the focal point of the farm co business operations. When you look at it today in safety, both in drugs and devices, two developments are happening now that are going to lower the transaction cost of getting that data or that report. One obviously is that all the information is getting digitized and the second is that we -- this is building on standards that already and this and UDI would be another standard that would contribute to this. So when these two things happen, you know in economic models when you lower the transaction cost, new business models occur. Whether you wanted them to or not really. And I think you're seeing a flattening certainly on the drug safety reporting so you're seeing a flattening of the farm co vigilance model and for ASTER-D for devices I think we should anticipate that flattening in the reporting of device reports to help us going forward. So a few slides on aster and then applications and devices. The genesis was several years ago we were up the Brigham and Women's talking to of David BATES talking about something different and this has been in my head for a while, this thought of how we should be taking advantage of the data in the EHR and digitized data for safety. During a lunch break I asked him what do you think about this idea of taking adverse events directly from the EHR and he said this is a good idea. So aster was born. Brigham and Women's was the hospital. Jeffrin Lynnder was the lead investigator. We had several partners that got involved in it, but this is the basic structure of it. And basically if a patient came in and saw a physician and that physician discontinued a drug in the Brigham and Women's longitudinal medical record they had a box they can check on discontinuing this drug because of an adverse event and that was the trigger. Once that triggered it went out and what's called safety information change, but this is a function it served. We used formation that you heard alert from the presentation of outcome sciences retrieved form for data, rearview mirror FD, and it supplied the information back to the physician. So we called the information out of the EHR for that report. It was September over a secured connection to a third party who rendered it to look like a form and sent the html back to the physician who saw it on his EHR screen as if it was part of the EHR. But it was not an EHR form. They interacted with that form; it went back to the third party, the third party then massaged the data basically to get it ready for the regulator. And I hope this design looks simple. It took quite a bit to make it loom simple and still address the major issues in reporting and that is it needs to decrease the friction between the reporter, between the data transformation and the end user, the regulator and the manufacturer. Reporters don't report because it's too difficult or they don't know about it. Or once they know about it, and they want to try and do it, they don't have the means to do it. So that's the beginning problem. The regulators -- the way they report, the regulators need more done to the data. We need coding around it, we need more information put to it so the regulators to make full use of it need more information. And that's this design basically. And one slide on our results. We ran over a four-month period 200 reports of the system, about 20% serious. Average time of physician interacted with that record was seconds. We believe that's the reason that they reported, because we basically treated it until we could get their interaction where the physician said yes we would do this. Anything over 60 seconds they said No, I'm not going to do it. The (inaudible) was about 20 minutes. Without human interaction intervention at that point, the physician clicked the button, they interacted with the form, automatically coded, business rules run against and then it was sent to FDA. The most startling statistic to me was 91 percent of the physicians had submitted no drug adverse event reports before the previous year on study. On study during the four months of the average five reports per physician. So clearly there's under reporting and we were able to get the reports in. I think this shows our business model is out of whack with what's possible today using digitized data. And this is basically the concept that I want to talk about with ASTER-D. At the same time right at that time we started talking with Terry about why we can’t do this for devices. So there are different wrong ones, but I wanted to go through and explain in concept how we're thinking about this could be done. I want to be clear this is a concept slide. This is not med sum per se; this is showing what could be branded as med sun. Not replacing it. This is not in practice today, but this is basically built on the same theoretical model that aster. We have the first interaction where we need to decrease the friction and that's the reporting. And so -- this is concentrating on the data source and the third party where it's going, and if we separate those two functions, hidden underneath are all of the frictions (inaudible) are there to take care of the patient and to do other clinical systems. You heard the many discussions this morning already about the great challenges that are there. They don't have the time or the wherewithal necessarily the means to take care of what we need to turn it into to make it a regulatory report. They can generate the data. So this is attempting to pull that burden off of them. What we have is we have a little bit of pain up front. We need to map to their system. But once that's done, all they're doing is providing us the data. They don't have to run any other rules; they don't have to be cognizant of anything else. It also allows flexibility triggers. I'm betting there is so much good and active work being done on looking at triggering events both on the drug and device side and finding them in the clinical realm, and it's not -- I think it's pretty easy because when you look at the literature there's a wealth of information there and tremendous work. I'm betting that that's going to evolve on its own and we should take advantage of that. What that does then in this design it allows us to use whatever triggers are available and really to tune what we want to receive by tuning the triggers. And this is the first way you get control over a rampant data stream coming in. Rather than open up the hose and take everything in, you're able to tie trait what you think is most important by using the triggers and let the clinical realm develop those triggers, we're ready to map to them. It allows immediate implementation, the second thing. Because if you look is the designs out there, if you've seen one reporting scheme you've seen one reporting scheme. If you've seen how one EHR uses data currently in our country, you've zone only one EHR use that is data. So it's not possible yet to write a single scheme that connects to all EHRs. Of course we want to get there, but if we want to start doing something today, then with this simple mapping we can go to many EHRs. We demonstrated on aster with about 12 EHRs now because they sit down and map it to their system and then we start running it. So the same would apply here. Secondly, as I said, hosting outside of the EHR or outside of the data source, it's a light footprint for them, and it's not a sexy thing to talk about one of the major impediments in getting something done with a new system is the guys that are running the old system aren't going to do anything that doesn't ask contribute to what they're supposed to be doing and clinical systems are there to treat the patients and improve the care for the patients. So asking them to do anything outside that have gets put in the long term cycle. So the more we can pull from them the need to massage the data, et cetera, and the more we can pull from them the need to develop forms, I think the more amenable they are. And it's been my experience to doing anything then. They all know how to pass html back and forth. That's when we asked them to done on the drug study and that's what we're asking them to do on this design. It takes the non-patient focused work away from the guys that are working on that and obviously that makes it flexibility and scalability. This is basically the idea. And this goes back to the era of abundant data. I think if you accept the fact that device reports are going to come from more places with more data than ever before, and if you look at historically everything else, the curve basically continues to increase. We let the device reports source data remain the source data, we encapsulate and try and do the other functions on the other side of it. So in this basically just reiterates what I just said. It means the source data providers continue to focus on what they do best, it encapsulates the other work away from them and it allows us to adapt many different sources that have data. We're not asking the source data to adapt to something else. So you go back to the overall scheme here, and we can concentrate on the middle function here then. I've called it a safety information exchange. But basically this idea is it's a function that could be as simple as a single vendor or technical function all the way as complex as a vertical stack, you could have cloud services, UDI maintenance organization, you could have business rules run. It's basically a stack. And the point behind this concentrating on this area is it lets that specialize in what it does best, specific processing of the data. With that much data we're going to have to have serious equipment and algorithms to run on it. And that's not something that's going to be pushed out into the -- into each clinical system. It allows more specialization of the data because we've got experts who know what they're doing who do this for a living looking at that data. The clinical focus while it's on safety is often on the safety, and should be, to the patient. This needs to look at safety at large. It also allows the data functions which I think is where we're headed if you put all this under a vertical stack you're able to create a governance function in which all of those would have to run and this moves us out of the realm of trying to push that control out beyond where this should be and also it's adaptable to changing output demands. On the back end you have the folks receiving this data, and their need can change as things evolve as new regulations come in et cetera. And finally it can either feed or it can serve as a device register city. Basically this middle function can be the device registry. On the other hand, this could massage the data, create the reports and then feed that into a registry. And this can be done much more efficiently in this function rather than trying to get the guys on the left-hand side of the equation to do that. And then, finally, the physician, it's basically a portal, this idea is that if you pull these functions apart and encapsulate them, basically it makes it much easier to start creating an interaction between the folks reporting the data and the folks consuming the data. Because the middle function then is transforming that data and mitigating the issues that you have with applying the standards and maintaining the standards, et cetera. And I think this is key here because one thing we've learned on the -- from the business side for drugs, the real ability to determine causality of an event and you've heard this mentioned in Richard's discussion as well, is being able to get more specific data. And I don't think we're ever going to get that on the first report. As CDRH has demonstrated the ability to go back out either broadcast a message or have a discussion with those folks is key to improving your ability to prove that's a safety signal. So that's the signal. And this function would begin to serve that interface where you could broadcast back out, get information back in and it could be handled in a proper way. So it would accommodate rt current design, is maintains flexibility on intake and scalability because it's connected to this modular design already and you could expand the current role into being a true interface role for non-med sun participants as well. So in summary, this is a model that be began on the drug side, was proven out in proof of concept. It seeks to satisfy -- it's a new model that's trying to satisfy device reporting in the era of abundant data. We can implement this now because we can go to a system, we can map to that system and we can begin using this just as we did with drugs. It allows you to map the multiple data sources. So it handles the heterogenerality in the environment, encapsulates the systems function, so I think it increases your chances of success because it doesn't ask EHRs and other clinical systems to do things that they plenty to do right now and don't want to do, and it scales. Thanks very much. (Applause)

>> Thomas Gross: Okay. Next we have Ann Bruns, who's the director of best practices at BJC health care in St. Louis which is responsibility for products selection, utilization and standardization activities for an annual expenditure on medical surgical products of greater than $500 million. She'll be talking about recall issues.

>> Okay. My introduction basically told you a little bit about BJC. 13 hospitals based in St. Louis, Missouri. And so centralized supply chain operations. I'm one of three directors in our supply chain division. I'm responsible for product selection and utilization, and you can see here in the red at the bottom I'm also the point person and usually the first contact for any issues or concerns related to recalls. Recalls can present a challenge for providers. In 2008 BJC deployed a team to focus on redesigning our recall process. Data from 2006 and 2007 revealed a median of ten days from date of the recall release to our documentation that we received it and began to take action. Our project focused on three objectives. Ensuring that we received all notifications, improving the timeliness much our response and tracking and documenting the activities. We accomplished those goals with a subscription to a notification service and implementation of software that assigned the accountability and tracked all the activities. Within the first six months after implementation of our improved redesign, our days to close the recalls dropped to two days. But the number of notifications that we were responding to substantially became greater. In this more recent table we see that the number of many notifications continues to increase each year. I think this is why it's so important providers have a process that provides a competence to us that we have responded thoroughly and accurately. This is for the safety of our patients, after all. I can tell you that BJC was not alone in our quest to improve the recall process. Many of you are familiar with strategic marketplace initiatives. SMI is a network of executives from providers, suppliers, manufacturers and distributors in med surge and pharmacy collaborating to develop and share innovation that improves the health care industry. Here's a list of some of the providers that are members of SMI. I mentioned BJC was not alone in the challenges that we faced to improve the recall process. SMI conducted survey in the fall of 2009. 47 health care providers participated. I chose a few questions to highlight from the survey for today's discussion. Question 7 tells us that recall information is coming directly from the manufacturer in greater than 50 percent of the cases. Question ten, what is not typically included in the recalls? As you can see here in the responses from one to ten are very significant. Not just return instructions but basically purchase order, patient, who the product was used for, which department used the items, quantity and location, and shipments to my organization. Question 12, what actions do we take to respond shows that for almost all the participants, all 47, the very manual laborious intensive search begins. We know that items -- we know that items -- oh, I'm sorry -- we know that items are never moved to secondary locations by our clinicians and we know they're never taken from supplies and then later returned after maybe we've pulled our items off the shelf. Then we have the returned recall items back on the shelf so we have to go back repeatedly and keep checking to be assured we've removed all the items. And question 22 highlights what were the greatest challenges. And I think that here assuring that we've collected all the items that were impacted, secondly, checking every item manually all the way to the patient level, and then third, the timeliness of our activities given the large number of recalls that we receive. So I'd like to now say how UDIs could help us in the recall process. They can assist us in knowing exactly how many products we're looking for and where they are. Are they in kits, when they're not in their original packaging or not at the highest level of packaging that has the information on it, the task can be daunting? We can benefit from better information when UDIs are on the items themselves. Let's remind ourselves that UDIs play a major role in improving patient safety through the visibility to which patients the products have been used on, especially those products outside the implant category. I think this is something that many have spoken to saying what is the definition of device. And I've been purposefully using items or products as opposed to devices because I think sometimes it's in things like staplers, dressings, in things like disposables that come with equipment that are really difficult to track to the patient level. Last, recalls could be produced from trending reported issues and UDIs can assist our industry in identifying those serious product issues quickly and zeroing in on the specific attributes of those products. As many have said the level of attributes included in the UDIs can be critical to this function. Thank you. (Applause)

>> Moderator: Objection. Next up is Dr. Fred Resnic. He was here previously. I believe he's still a practicing interventional cardiologist and he'll be talking about EHR issues in UDIs.

>> Thank you, and to the rest of the panel for a great review of the challenges and opportunities for UDI and postmarket safety surveillance. And this is, again, the area as a practicing interventional cardiologist. It is a mission to try to make sure for many of us that the devices that we use day in and day out are actually perform being the way that we hoped they would, the way we expect they would and the way that we believe they would from randomized clinical trials. So what I was going to mention it the next few minutes was the concept that has been evolving over the past several years of going beyond even triggered spontaneous reports to a real continuous monitoring and automated surveillance model and the real critical need for understanding exposure triggers in the world before UDI becomes available. And so we know that we're entering that world. This is why we're here, but we're not there yet. And what are the challenges. Today in trying to understand how one identifies device exposure in EHRs, as well as registries, which I kind of spoke to yesterday, it's kind of heterogeneous how devices are classified or identified. Recognizing this, we started to -- we undertook a pilot at our institution looking at some informatics tools, natural language processing, to try to help could we crack this code of device exposure identification. And the short answer is not that effectively, but we have some -- we have some interesting insights and it may be somewhat of a complimentary tool we can think using over time. So in terms of automated surveillance, a different model, so having access -- having a monitoring system have access to an accruing set of data that continues to accrue over time to look for those low frequency safety signals and I'm particularly concerned about a class three devices and class three implantable devices, the first point is exposures. You have to know which patient got which specific device. Of course that's why we're here. But to flesh that out, we have to collect a lot of patient level information including clinical coverts in a may not be available in claims based data. We need a list of procedurals about the experiences of the physician to understand their status in terms of learning to use a particular device and understand the post procedural outcomes and this was what Rick was mentioning. Having some rigorous rules about how these things are code as well as now longitudinal outcomes which is certainly a deficiency of many registries really patients out beyond an episode of care, way beyond the initial implantation of a device. And that's where electronic health records and maturation of that technology is becoming so important. Once you have all of this data accruing over time in this sort of perfect world, we then have to think about how we're going to analyze it to look for these triggers of safety signals and alerts, so there's clearly a lot of work that's being done on coming up with the most appropriate risk adjustment methods, signal identification and alerting. We heard a little bit about that in terms of spontaneous triggered reporting (inaudible) how to dive deeply back down into the data and a bi directional way doing sub group analysis, sensitivity analysis, verification probably through prospective or alternative data sources and then synthesizing this evidence for basically a regulators and other stakeholders including the device industry, physicians, patients, how do you interpret a signal that comes out of a sort of reliable data source and how do you provide that back in a meaningful way to all these stakeholders. So the first five of these is really all about the data source, and that data source can be electronic health record systems, a registry, it could be a formal post approval study. The second piece is about the monitoring system. And we'll think just about the first piece of it for now and really focusing on that first component of the first piece which is the exposure identification. So I mentioned this yesterday, that we've done a couple of these explorations in four more on going looking at use automate continuous surveillance on existing and growing data repositories that have detailed medical device information. This is just an example out of state of Massachusetts mandatory data sets for looking at interventional CARDIOLOGY devices. And the way we set this study up, was we picked eight devices in advance out of about 40 that were used in the state, but eight of the higher volume devices, higher risk devices, and associated with each of those devices some adverse event trigger that would -- that we would be concerned about wanting to know whether one device as compared to you will at other devices in a similar class had a higher level or adverse event rate for that outcome. We used an automated prospective propensity matched algorithm so we could, we believe, compare one device against another device in a patient population that were just as likely to get either device basically. And what this slide shows going from the left side to the right side is cumulatively over time the observed event rates for one time of drug eluding stint in the dots as opposed to the blue range which was the observed event rate for the control device, the population who got the alternative stent. We're looking at post procedural heart attack rates in which one device had a higher than expected rate after for controlling for these 38 clinical factors we believed were differentiate or square the propensity of (inaudible) and we did a lot of drill down exercise for that particular case. But I think it was sort of a proof of concept that one can apply prospective, automated safety surveillance to accruing data sets like the Massachusetts registry or now several other example. Here's another quick example look at survival or time to event. This is for the Fidelis lead from four centers. This is submitted for publication with Bob Howser an investigator out of Minneapolis. The green is the control ICD lead. It was a historical control. Patients who had received this lead in the two years prior to the release of the new lead, which is shown primarily in the red, the reason it's red is the system is signaling that there's a higher than expected lead failure rate for the new lead as compared to the control lead, and this is done in actually a somewhat novel way of not only doing a propensity analysis but rematching every month to try to eliminate the possibility of sort of the bias that particular matches or the order of matches might have affected the results. But the impact is dramatic of monitoring prospectively the success or failure rate of a device. And what we can see here is that after about 14 months, there was a clear separation, a statistically significant separation, in the failure rate of the one new lead which was a techno logical advance and make we shouldn't have expected this very, very thin lead, we maybe shut should not have expected that to (inaudible) placement for the control lead. And we can see that after 60 months, five years after the start of this sort of study, there was a voluntary recall by the manufacturer, and the point here is that if one can execute an effective prospective automated surveillance, one can figure out that there might be a problem well before action was subsequently taken in this particular event which took an extra three years from the first statistical evidence if one was watching. And I think the whole model here is can we enable IT (inaudible) in the industry to keep a close eye on what is happening in terms of device safety and device performance. Now, we talked about registries. There are a lot of different kinds from single center, multi center; national, voluntary registries, formal post market surveillance or post approval studies, and I think this is where I focused a lot of my research. But the future is probably a little bit more of a blend or continuum. And I think the folks like Paul and Tamra from the VA yesterday talked about the notion that the distinction between electronic health record and a well constructed electronic health record and a registry is really an arbitrary distinction and we should start thinking more about the electronic health record as being the health management platform. It can support multiple registries if we can appropriately Taylor our electronic health records especially as we get further and further along the meaningful use curve. So I think the richest sort of detailed clinical data is stored in the EHR, there's a lot of work to improve the quality of clinical documentation but ultimately (inaudible) data and longitudinal outcomes is going to provide the most granular information available for safety surveillance, but it's a heck of a job to think about integrating all of these multiple EHR implementations into some kind of super network that would allow us to focus on things as useful as pro specific surveillance. Thinking about one tiny piece of EHR and safety surveillance let's just think about exposure identification. Clearly if we had UDI this would be solved. And so the hope is that if we can effectively implement UDI we won't have to worry as much about this but I would challenge those of us trying to think about device safety surveillance, especially for implantable devices, how do you figure out which device went into which patient right now in the electric electronic health without an explicit registry. It's not simple. So to almost demonstrate this self-evident problem to ourselves we undertook a little bit of an exercise with some informatics checks at Brigham and Women's looking at natural language processing and understand whether NLP could help us identify the specific cardiovascular implants for the exercise we'd already performed at a state level. We're trying to do it at the EHR level so with Brigham and Women's and mass general. What we’re the NLP derived devices with what was actually being submitted to a formal registry. So if we say the registry submission was the gold standard, and I think it is pretty close to what actually went into the patient's body AAL we can worry about transcription and bar coding errors but if we assume that's pretty good. I have a background in inform attic but NLP has changed and there's a tremendous amount. Progress - but there's all levels of sophistication of both the NLP algorithm, etc, but there's a nomenclature that's used about the successful matching. So there's this sort of ontology. What we have to think about for this exercise is the simple match means you got it right and a hundred percent right and what we see a lot of he it's what's called a normal partial match which is basically an example with your matched enough, you can actually grade how well you matched. And so if in the -- if what you were looking forecast cochlear implant subject and you found in the medical record cochlear implant that's probably an adequate match. We'll see that becomes a big question as we moved through our experience here. So we decided to study two different things. And I think the folks who are working on the EHR side of the world here probably know this already, but it was an interesting demonstration. We look at it you different types of sources of information. Discharge summaries and the procedure report. And you would hope that the discharge summary would actually contain useful information about the device that was implant when it's a principal major device we're look at implant many class three type divides and only in those patients in whom had a relatively uncomplicated coarse. Not patients who had a four-month hospitalization. So this is what we found. About 12 percent of cardiovascular devices are actually discernible by NLP from the discharge summary. And that's primarily because the implanting physicians if they have anything to do at all with the discharge summary are often doing it way after the fact. There's no -- this isn't the summary; this is a transcribed from the two institutions. The cardiac cath reports contain a (inaudible) show it's a hundred percent of the devices, but what we can get the device type, which is sort of a family type, but the specific device, and that's in a 70 percent of the cases, but we can only get a piece of the device name. So it's sort of how you break this up as to what is specific enough about a device. So with NLP even during -- even with you can the best source which is the cardiac cath report where a hundred percent of the devices are documents they're documented in way that may not be very useful for specific device safety track being. I can show you some of the examples. So the document detects shown on the left here, so we have folks using the terms cipher des would be in the, again this is only looking at the cath reports -- some people would just comment on cipher and someone would comment on colkis cipher. Those are partial matches because the master list, the actual name would be something more along the lines of what we see on left. Cipher (inaudible) is an over the wire, and but no one is taken the time to transcribe that level of detail. So therefore problems with the matching between what is used and sort of common clinical parlance versus what's enough detail to do specific device level comparisons. So just to summarize it, the two institutions faired similarly. A hundred percent of the devices were available in the cath report but only 19 to 30 percent were full comprehensive complete matches, leaving 70 to 80 percent be partial matches with really tremendously limits your ability to believe that you're comparing the right device to another precisely defined device. So we learned some lessons from this. Standard inpatient discharge summaries (inaudible) and if that is what clinicians are actually relying upon when they look back to hospitalization to figure out what happened to a patient; even the clinical care is being compromised by this lack of documentation of devices. So that's just the nature of health care, I think, is that discharge summaries are inadequate for device description for a particular patient. So (inaudible) include nearly a hundred percent of class three implant nl devices (inaudible) and a results roughly 75 percent non-specific device matching. So nlp is a valuable (inaudible) but is unlikely to match the pro precision of UDI once widely implemented. We do have I think lost tricks still up our sleeve here to sort of improve the algorithmic training of the modules we use to improve the precision of identifying specific devices. We're going to look at larger values of (inaudible) like spinal implants because those -- there may be reasons to believe that the actual transcribed node may be even more precise when there sanity alerts physician already knows is being populated because the physician was aware that the op note is going to be the only repository of this information. So there are reasons to think that NLP may be useful in that realm. So I think obviously as we all have come to appreciate and we're all sort of vested in important stakeholder here, UDI certainly offers the opportunity to identify the exposure to medical devices and that is the first step. And I would say that all of the exercises that we're contemplating right now is challenged today by just identifying which patients get which devices. And almost no pilot project is going to be immune from that challenge except in the most performed registry environment. So the availability of UDI and searchable EHR systems and not restricted purely to billing communication is going to be essential for integrating clinical information systems into routine device surveillance, and likewise adoption incorporating of UDI into structured clinical registries think will support precise exposure identification in that resource that's going to be just so valuable over time and increasing in value to regulators in the FDA and other stakeholders. And finally NLP device identification may be a valuable adjunct tool especially now before UDI is routinely available. And especially when we think about the fact that UDI is going to be a forward looking regulation. So when we think about comparers (inaudible) performing, we are going to be challenged for the next probably decade of wondering what would the device is doing before we actually implemented UDI. So I think there's going to be an enormous role for novel ways of extracting this information of device exposure. I also think NLP for the purposes of just safety surveillance is going to be extraordinarily useful as a complicate to UDI for detecting those other somewhat ambiguous but critical clinical pieces of information such as a medical compliance issues or even outcomes by soft assuring that there is some sort of complimentary support for some clinical documentation. So if someone documents a patient had a myocardial infarction you could use NLP to certainly increase your confidence that that documentation was accurate. So with that, I thank you very much and look forward to the panel's discussion. (Applause)

>> Moderator: Okay. Anybody interested in asking questions, please come to the microphone. Joining us also on the panel is David Stockwell, who is on the previous panel talking about ventilator triggers. David, would you like to make a comment or two or just wait for questions?

>> I'll wait for folks to fire away

>> (Inaudible). I have a couple of questions, actually. One really which is for you in Medtronic. You seem to be creating a super registry, and obviously it's expensive. So how are you going about it? Clearly we do this sort of thing for individual products, and second related question to that is how you would track the follow-up. Obviously these people, if you're tracking over time, could move, they can move away from centers, they could get their post op care elsewhere and what kind of thoughts have you given towards that?

>>(Inaudible) place for about five years in two of our businesses of the eight businesses. (Inaudible) CRDM businesses we do have about 200 hospitals engaged in this process. Outside of a normal registry we might see a post market requirement condition of approval, it's a very thin structure compared to what we would do, say, where we're going to do high level validation and so on. The idea was to be able to construct a very thin serviceable database that would focus on the big end points; and to have a relatively inexpensive method of follow up at the site. Usually a phone call or visit on a yearly basis with an idea that there was no data at all and this would give us a tremendous advantage to get (inaudible) but very, very valuable level. Moving to a larger group, we are starting to utilize some of our current call services centers that we have available for some of our consumer products like the diabetes pump, for example. In some of the leverage scale opportunities we have as a company to be able to do central follow up. And that's something we're just starting to work with now and it's complicated because there are HIPAA issues and other things like that to go along. I think the biggest issue we have is that when trying to make inference about a population, is trying to inform the patients to participate in the process. We have historically in the two (inaudible) we have now achieved close to 95 percent follow up in those patients who want to be followed. But roughly 40% of patients don't want to be followed when you ask them up front before they get a device. And it's important for us to get a consecutive series and all the applications we look obviously at the demographics that we can get without having to worry about HIPAA or privacy, but those who don't participate if we don't see a whole lost difference overall but that's probably the biggest challenge we have.

>> To link it up to claims as well?

>> No, we don't. At this point we're not linking it's to claims because number one, that's a big database connection to make. We do link it with different health care systems. We have purchased a relatively expensive module from oracle to help make some of the connections between existing health care networks to make these connections, but it's expensive. And even if you try to scale it, it's expensive. But the lack of understanding how products work is the motivation.

>> I'd like to continue that conversation. One of the advantages that I see in unique identifiers to have (inaudible) associated with them is the ability to look at devices, look at -- cut my attributes. In other words, there may have been a problem with a lead that was thin. It may be shared by leads (inaudible) of certain thinness. And unless you're able to look at -- unless you're able to look at products from all manufacturers in the same database or the same registry, you're not going to be able to do that sort of analysis. I'm just wondering what your thoughts are about that.

>> Sure. In the case of our fideli lead which was the product that was pulled from the market the compare Terry there was our (inaudible) in which we had a lost data on. So we did see differences overall where we had a sufficient sample size. There was a lot of interest in that lead obviously and there are many multiple different databases that had demonstrated comparers all of which had their problems and strengths. If we look at the next implementation of the database, when we move to a participation that's transparent and open where we share the authority and the decision making with the academic or the providers that are not conflicted like we are then I think we can expand to all device manufacturers. But right now our first goals are to put a (inaudible) curve on the chart to demonstrate, what the survival of a specific product is. That we don't have in many of our device nor does anybody have. That is not totally informative but it does give you some information the soaked thing will be how it compares against the Legacy device. In one of our businesses we have pulled to you products in the market when we noticed that the comparison Legacy with the new product didn't match. One in both cases they were new products that actually out performed the old products gave us an indication to take the Legacy off the market because we actually achieved better performance. So as far as sequential and iterative products, the actual data we have within the company actually is very, very valuable in understanding when in fact we have actually achieved something that was better or worse than what we had previously if we assume that's the established standard of care. The other issue is when one tries to develop what is the gold standard for patients out there, we want to move quickly from a product that never fails which doesn't exist to one that achieves the highest level of technology (inaudible) that requires us number one to identify what that product is, set that bar and (inaudible) that will either make us take the existing product or the new product off the market if it doesn't perform well. All comes down it a simple test. If you have the data available to you and one of your family members is going to achieve one of these -- or is going to have a choice, if you can tell which product is better for them to get then it's time for us to act on that. That's how we're going to look at sequential components. The comparison across different devices has to be done by a third party. It has to be done by somebody else. It would be too conflicted for us to do.

>> One other as I was listening to you talk, you mentioned that we need to have the unique patient identifier as well. And I almost chuckled because we've been on that quest for ten years or so at (inaudible) and other places and we've been told to get a grip, that that's never going to happen. And so we've got to find other ways of going about this. But at least at baseline what you've described is really what it should be done bay good registry in terms of defining that patient and patient characteristics at the time of device implant. That's really the function and role of a good registry.

>> You're right. If you run a registry by itself with a specific hypothesis in goal like most are run, the level of -- the patient level analysis is general relatively simple. If you have the general surveillance system look at a bunch of different products and adverse events that pop up on a patients level connected to a variety of different devices, it's more difficult to understand what the -- (inaudible) somebody has to be able to have some unique identifier to say that when we had 35 adverse events associated with these products in our spine department that they were all the same patient who had the same event multiplied by 35 times because he had 35 products there. So it sounds trivial but becomes problematic if we don't have some linear way of looking at what the patient identifier is. And it's a legal issue and privacy issue and everything else but something that has to be solved.

>> Moderator: How about one more question given the time. Two more, please.

>> (Inaudible) I have a question for Dr. Resnic. It was interesting this concept of using the natural language processing to try to identify whether or not patients had devices. I'm wondering the extent to you use additional information not to decide whether a patient had a device but which patient had devices. Generally speaking you would think within a given hospital you might know the volume of devices that come in and from there maybe an educated guess about (inaudible) the 35 most likely persons that had this device from the notes. So it's a way in which you can say that you should not be considering just the individual granularity of the patient to make the inference but to what extent you can incorporate additional (inaudible).

>> Yeah, that's a good question. You can apply -- we could have designed our inquiry in many different ways. So another way which is kind of what you're asking is we could have looked at the three million individual patient identifiers in the Partners health care system, electronic health record system, and looked to those that seemed to have an exposure to a drug eluting stent in a certain period of time. But that would be addressing a different question. Unfortunately what we did learn was that even if you knew which patients actually got the device because we had the registry so we knew exactly which 3000 patients a year got the device, only 11 percent of them could we figure out what device it was if we went to the sort of standard clinical documentation of the discharge summary from that discharge, from the discharge at which they had it implanted. And we could find a hundred percent every case we could find some information about the implant from going through the procedural record, but it was a little bit diluted or ambiguous in many cases because it was sort of leading the mechanism of documentation up to me, the physician, and I'm not even consistent from one case to the next case or one minute to the next minute let alone across institutions or across physician or over time. So I think there's a lot more we can learn, but we can certainly consider doing population sort of based inquiries. And there's a whole science here on natural language process asking the use for Outcomes Research and clinical effectiveness research that we weren't sort of trying to sort of move the curve to far forward. Just looking at device identification.

>> Moderator: One last question.

>> (Inaudible). One quick comment and one question. I'd like to (inaudible) to start the marketing surveillance. But it's time to start thinking about (inaudible) which is getting the outcome right and getting the -- start looking at some of the biases that affects any of the (inaudible). I think -- so that's one comment. And the question is I think Dr. Kuntz said we might have to think about the (inaudible) attribute for the UDI and to me I think the UDI should address all the unique expects. And it's on the user's side to see if you can collapse beyond that. For example, if you understand the materials or whatever, as long as it's embedded in the UDI -- it's on the user assess side to kind of extract the information and collapse at the larger level. So you're saying that the UDI should not address all the small details but only the larger aspects?

>> Well, gray with you. I think what I meant by consensus is product characteristics are defined by the manufacturing component. And they're defined by the supply chain issues. There may be elements that are better defined clinically. For example, an attention to, say, thickness of a stent. (Inaudible). And would thereby a super set that would only be some smaller set by the clinical side but my guess is that there are some elements of, say, a prosthesis implant where the angle of some component might not be of interest to the manufacturer but great interest to the clinician. That's why one would have to look at the existing literature to understand what are those elements that are specific and could be tested. Otherwise you end up with the factorial permutation and then it's impossible to determine. I'm not aware that there is a system to determine what those attributes are.

>> I guess some of the publicly available (inaudible) all the attributes associated with the UDI and with that I think users can identify the necessary feature using UDI.

>> Moderator: All right. Thank you very much, panel. I appreciate it. (Applause)

>> Jay Crowley: Okay. Good afternoon. We can all the go ahead and start the last panel here so we can finish up on time and get everyone off to their respective next places. Are we set to go? Okay much I would like to introduce Dr. Ed Fotsch. He's our moderator for the last panel. And I think this is going to be a very interesting maybe a little bit different panel that we've seen over the past day and a half, but I think it's going to be very interesting, and I look forward to it. So Dr. Fotsch.

>> Ed Fotsch: Thanks. I wanted to started by thanking Jay for inviting me to moderate this panel. I've known Jay for a while, and still he asks me to do it. I'm not sure if that was brilliance or just raw courage. We've got a great panel today. We're really going to talk about device connectivity, postmarket surveillance UDIs and where the patient fits in. As several of the speakers have mentioned there's real differences between following drugs post prescription and devices particularly implantable devices. This is an issue, by the way, that's near and dear to my heart. A year and a half ago I got a right metal on mental health hip implant. When I was a heard there was a problem with metal to metal help implants I was able to quickly find out, no, it wasn't mine but I think most people are challenged to know what implant they have, what stent they have, what wire or graph they have. And obviously with devices unlike drugs, it's hard to track because you can't track well through claims. You don't have to renew a device. You have it once. So we'll talk about some of those challenges. On the panel are really the folks where the rubber will meet the road. The EHR vendors themselves, manufacturers, and you know Tom Gross from the FDA. I have to same coming to these meetings with a bit of a sense of ground hog day, not because I think that Jay pops up once a year and goes back into (inaudible). Apparently now from a regulatory standpoint, UDIs will be a reality, but the question is so what? What will we be able to do then that we can't do now and if we limit ourselves to all the information except the stuff we could get directly from the patient that is indeed limiting where we can go. So this panel will be a little bit different. There's one set of slides. I've the opportunity ahead of time to share the slides with the panelists so I'm going to be running through these slides, probably take about minutes, giving you a sense of what we perceive to be the problems to bring the patient in both from the standpoint of collecting information from the patient and getting information to the patient. For example, problems with the device recalls, what have u and we've started with a hypothesis. These are things that don't work or don't work well enough. Current post market device communications and assessment of safety signals - Device identification without EHRs and PHRs and I say that because if you had the UDI, if every device had the UDI and maybe soon they will, and tp doesn't go anywhere and it doesn't do anything you haven't accomplished too much. And up one place where you'd want it to go it the EHRs and when I say PHRs and I'll say a little bit more about them and the company I had run prior to (inaudible) had a personal health record that was delivered to patients by their doctors as part of basically filling out the clipboard on line. That functionality we'll discuss and patient connectivity is now a requirement for EHR meaningful use. Therein lies an opportunity for communicating on devices that didn't occur before. So EHRs -- device identification without a place to put the information. The other thing that doesn't work at least market would indicate it doesn't, is PHRs with outers. Why do I say that? If you look at successful stand alone untethered PHR vendors it's a short list and it got shorter earlier this year when Google terminated or announced their termination of Google health. Now I know the people at Google health. I live about 45 minutes north of them. And I don't believe they stopped Google health because they were over loeg the servers at Google with the billions of tera bytes of data from people who are dying to share their most intimate information with Google. I'm not sure that Microsoft health is in a lot better shape f you talk to patients and say do you want a personal health record they won't know what you're talking about. When we talk about PHRs I'm really use using it as shorthand for patient connectivity largely delivered between the provider and the patient and pursuant largely now to EHRs. So those things don't work, what might work? Well, PHRs and patient connectivity via EHRs I'll give you some information about how patients are being connected now to their providers because of meaningful use, and you all will see this with your providers, with your hospitals. You'll see more and more on line services and some of the EHR vendors, they're here today. Those executives will say a little bit about that. Other things that could work, if you could connect to the patient you could send information to them, get information from them. You could do that without UDIs. As Dr. Nagan will comment, they have some experience with this without UDIs so it's not that we need UDIs to have communication with patients about their devices, but it sure helps. And it can help quite a bit. So what's the current status? And this gets to the difference between drugs and devices. This relates to most patients who have a device implanted are simply lost to follow up. And the reason they're lost to follow up, and I can tell you this is the case pour me is I will probably never see my orthopedic surgeon again. And off the top of my head I can't tell you his name. And he was a really nice guy, and I have a great hip. Fact that it works well for me is exactly why I can't remember his name and probably will never talk to him again. So success means one time event. And having a bunch of friends who are surgeons, their focus is on the implant, success, immediate post op period maybe CPT code and moving on. They're bay and large not lug at longitudinal patient relationships. So since you don't needed device replaced and don't need it renewed like a prescription, lost to follow up is often the case except for whatever data is captured by whatever facility where you had your device I am planned or registries, but the patient kind of bounces around. As some of the folks had mentioned, attempts to keep the patient engaged are challenging. They're expensive, and, honestly, if you said to me would you like to be in a registry, it doesn't sound like a very good deal. If you said would you like ongoing communication with physician and be able to email them and if there's ever a problem with your device you'll be notified. You can see the value in that and I'll comment more about that. Because of the relatively short relationship between the provider and frankly the health care system related to and the patients it's difficult to do outcomes aside from sifting through the tea leaves of claims data and whatever information collected from the registry. But the truth of the matter is that neither the hospital where I had my hip nor my surgeon nor my primary care physician could answer a question of me like can I walk up three flights of stairs without pain, and they couldn't answer it anywhere along the way but if anyone asked me I would be able to tell them with some crease of accuracy. So direct patient connectivity that is delivered through the 40 billion or so dollars pursuant to electronic health records and meaningful use is an interesting way of looking at actually collecting information from patients, but as we'll discuss, one of the key is not do you want to get something to or from the patient, we can assume that's the case, the question is what are you going to offer the patient in terms of a service that they're going to want and see value in. Aside from the starting point of I can use this service to communicate with my physician. So if you had that you could do longitudinal device tracking and in theory quality improvement, but you could also notify patients if there's a problem with their devices and we'll give you a use case that our panel will be reacting to. So as I mentioned, EHR meaningful use, is requires a level of patient connectivity. One to let the patient see at least a portion of their record and typically this means online. And secondly, it requires the ability to send reminders to patients AAL it's not clear what the reminders should be. It could be a reminder to come in for a breast exam or a reminder for almost anything. So that's the level of that. But if you look at meaning functionality use 2.0 that's now in development there were clear signals a personal health record would be part of that. And some of you have may know there's an HL7 personal health record working group. I spent a few years on it. So there are more and more standards around that. But suffice to say it's the stuff you would expect. In addition to connectivity with your device, a list of medicines and procedures and providers and of course devices would be including in there. And because of that requirement for connectivity associated with electronic health record, patient connectivity, we're seeing the number of patients who are connected to their providers in a rudimentary online way, but for access to their record and for email grow dramatically. So Tim Mccay is here from Kaiser. I think they're probably the folks writing the book on this right now. Somewhere between two and three million patients that are connected to their record and to their providers. Others, Intuit are examples of this ramp up on connectivity to the patients on line that can be used, one, to continue to engage the patient and their health for their drugs and devices and, two, to collect information or to disseminate information. It's interesting about ramping patient connectivity as a byproduct of electronic health records is if you think about it and data bears this out, you enroll the sickest patients. Why? Because they're the ones going to the doctors and the hospitals so you're not going to get any 21-year-old male college students, you're going to get seniors and people with chronic illness. And just as a note here, so when we say patients or I say patients, I'm really talking about patients and their primary caregiver. So it can be with case of children, children in the case of seniors, but by and large someone connected to the physician or to the hospital that's ramping up through meaningful use. What's interesting about that is the patients actually want it. From our experience in providing patient connectivity and physician websites to 10000 doctors for about five years, once you deliver patient connectivity and the ability to get my lab results on line and not play phone tag and pose a question and make a co-payment automobile the patients really want that. You don't see them opting out of program that are pursuant too that and that's important if you want to use that network for communicating information or for collecting information about devices. So if you believe that patient connectivity is growing you make the assumption that information about a device can be put into that network and then further amplified with the specificity of an UDI, you start seeing potential value for the FDA and the manufacturers. Obviously for the FDA the ability to collect or ask to be collected more information with more specificity, look the longitudinal tracking with outcomes on things like how are the thousand people who have my hip implant dock at one month, one year, and five years out. If there's ever a problem with the device you would be able to connect me because you would have an ongoing relationship with me. And the manufacturers could benefit a number of ways. One is they could get information on their devices that would help them with their design and with their R and D and second would be regulatory complains. Post market surveillance can be very expensive for device manufacturers as it is for drug manufacturers. And the current way you actually get information to the patients can be very definitive and goes down the chain of contact being the provider who tries to contact patients or keeping in touch with patients on sort of a one off basis in case they ever need to get in touch with you -- in case you're ever trying to get information. Again that's not very compelling to patients and lastly, the ability to have ongoing communication with patients who have your device. And some (inaudible) will be able to do tell you a little bit about that for some of work they've done on one of their devices where they have here's your device, but you will also have an on line user's guide or instruction manual. And we'll talk a little bit about that, how that works in a few instances, how it could work more generally. These are just some screen shots of patient connectivity, the kind of thing you'll be seeing. These happen to be frankly former clients of mine who are now clients of Intuit for their patient connectivity or Dr. Or hospital patient connectivity. There's a lot of this out there. They're all or is of the same. They don't send emails to your email, they send an email to you saying you you've got mail and you log into a secure HIPAA compliant network and what can you do with this? You can schedule appointments, get lab reports, pose questions, and on. UDIs and PHRs could be, if they're utilized this way, a real opportunity. An opportunity to utilize this network that's already connected and that has staying power with the patient, ongoing value for the patient to deliver information to them that will allow them to be tracked and to get information when they -- when you need information from them. Those could be patient surveys, an assessment of a sentinel event or something as simple as I'm a manufacturer and my hip implant is better than your hip implant because mine comes with an online service that helps the patient understand their points of rehab, where they are compared to some of their peers of the same age, sex, that kind of thing. Certainly the FDA sentinel system could be enhanced with this kind of connectivity. Several times we've heard about HIPAA and privacy issues and master patient indexes which have been around in concept forever. But if you have direct patient connectivity and they can opt out the HIPAA issues go by the way away because the patient has consent today an ongoing relationship on line and if they want out they leave. Having run a network, we had about a half million patients and we had patients who take a drug, would get a monthly information flow about their drugs and would be told if there are problems with the drugs and as I said before the opt out rate for those kinds of programs is low. One of the reasons is that patients really value the idea that if there's a problem with my drug, if there's a problem with my device, or my kids drug or device there's a system in place that will tell me when and if a problem exists. That's real value that can be delivered and certainly delivered from a device standpoint. What specific functionality do we need? It would have to be entered into some kind of an online service for the patient which is now being rolled out through meaningful use as I mentioned. The patient has to be offered connectivity. They have to know this is coming. If you thought I was just using a network for e-mailing to and from my interest and getting my lab result and suddenly I start getting information about my hip implant that would seem odd to me if I was queried. So you need to put programs in place and have the expectation set with the patients that in fact their new hip, their new graph comes with an online service and as features and function that are in fact patient friendly in addition to being something that would valuable to the manufacturer and to the agency. They would have to be specific messaging, again, that would welcome them, explain the rules of the road, let them opt out if they were interested, and then you'd need a customized disease-specific surveys of course depending on what goal you're trying to accomplish. If you can assume a reasonable portion of the folks who are going to get a device would have connectivity either for them or through their caregiver it certainly opens up a number of possibilities for bi directional communication. Of course this would all need to be done and the manufacturer would need to create these plans programs in way consistent with FDA guidance which they already do. Most of the manufacturers have some kind of patient education materials. Some kind of programs. Unfortunately many of those don't really get much use or not as much as they could. This is a case study. And I think we'll use this as a launch point for our panel to discuss how this could come to light, the pros, cons, costs, who would pay, why, that a copy of thing. So patients scheduled for a hip replacement, you do get to see the surgeon once, sometimes twice. Not including in the OR. And really from my standpoint you don't hear a lot about the device you hear you're going to get a hip implant and it's going to be metal or whatever, but it's not like it's this model and here's why. Frankly even though I think my surgeon did a nice job I didn't know what to expect post op. And some information advance would have been nice. But in our case study example the patient receives primarily here's the hip you're going to get, and with this hip you're going to get an on line program. You can opt out if you want. And what's going to be in it? Well, some information about the specifics, including a unique device identifier and why is that and why is that important, you'll get a regular perhaps monthly maybe more frequently at the beginning and then bi monthly over time message about your hip. You can opt out at any time. You'll be automatically notified if there are problems. You may be surveyed periodically. There will be communities of interest, other people who have to particular device. You may want to pose a question and these are the kind of things and Ted from Medtronic will comment on this. But these kinds are out there for some devices. The question is how you roll it out more broadly so that the patient is pulled into this longitudinal device tracking and post market surveillance system. So our patient now has had the device and UDI is scanned into the ER and we have folks from the electronic health record world here. But obviously you've got challenges with this part. So, for example, my hip, my surgeon now ahead of time which device he was going to use but not which specific one he was going to use because they get into the operating room and sea that femoral head an a little bit bigger than I thought. So you've got to crack that code and then you've got the surgery system that maybe didn't from the hospital's EHR which is obviously different from anything the surgeon has and you have a primary care physician and somehow through that all that information would need to flow to me as the patient. And so we're not going to spend a lost time on that AAL I'm sure some of you are EHR colleagues will have comments about the difficulty of that and the need for standards and maybe attaching it to a CCD type thing. We'll get into that. So the patient is now notified. Again this is their second email. Your UDI is now in your online service. I'm guessing you probably wouldn't want to call it an UDI because no one would know what that is. You're reminded these are the kind of messages you're going to get on an ongoing basis, and what happens. So monthly or obviously it's going to be different for different devices, you get a message, you're told about online services, you can ask an expert and, again, contact other hip folks, manufacturers available, these kinds of things. So this is routine. Now you're on a network. The same network, because of meaningful use, that connects with your doctors and of course you can opt out at any time. Now, in order for this to work, as we'll discuss, the information that's collected in this fashion will need to be accepted by the FDA to fulfill post market surveillance. And I think that's an issue perhaps we can talk about that. I know Tom Gross is up here and would probably be happy to field questions about what the FDA will and won't accept in this venue. But this is a different kind of data. Not stuff that's normally done. So there needs to be clarity on that. The FDA could say now that you have this connectivity here's stuff we want to see. We want to see regular communications. And I see that I have patient connectivity -- I think that's Russian for connectivity. But you get the idea. So the patient is now connected online. Now, an issue will arise post op. So what happens? Well, there's a sentinel event. Something about this device. The question is all the patients experience this, one percent of them? Wouldn't it be neat to ask? So in this case the UDI database allows a sample survey of patients to be contacted and the question is, is it every one of these devises, and based on sample data we had more information on that and the same network can communicate with the patients who have taken the time and stayed on the service to be communicated. And I will add that from the drug and the device standpoint, we do a lot of work with professional liability carriers who insure U.S. physicians and for them this kind of connectivity is a real good thing because right now if you prescribe a drug or implant a device if there's a plan with it, it would be your responsibility as the surgeon or the prescribe be physician to reach out to all the patients who have this and tell them so having some kind of automated system an attractive from a physician liability standpoint. So the UDI combined this patient connectivity allows communication to all the patients who have the impacted device. So if that's it, if it's that simple, what's the gap analysis against this? Well, first not all patients are connected yet. Certainly not all consumers are connected and not all patients are connected. A rough estimate is between 20 and 25 million consumers are now connected to their provider. Many of these are sort of one off provider portals in EHRs, but these growing relatively rapidly. The second thing is the manufacturers would have to have this service program. I said there are some devices that have this program that have been quite successful and we'll talk about those, but not every device. And without the program and the on going connectivity you can assume you're going to loose the patients to follow up the same way they're lot now because you have to have communications. One of the speakers yesterday said wouldn't it be great if when a device is recalled we can just contact their iPhone. That's really neat except there's probably a HIPAA problem right there. But in addition to that, who would you know what their iPhone number is five years later unless you had some reason that the patient was keeping in touch with you and saw some value from their ongoing experience. You need clear find from the FDA to make this thing value, you need EHR to EHR and maybe to EHR PHR communications; again, whether that's from a CCD or a standard. And I know we've talked about that. And then you need a revenue model, someone has to pay for this stuff. I think in this instance someone will pay for it or would pay for it if it did certain things. Who would pay? Well, I would think the manufacturer would pay if it reduced the current cost. If my current cost of postmarket surveillance and you could get it hiechlt that's a reason to pay. If I could use this as a competitive advantage because my device comes with a user's guide that make the patients and surgeons are happier and I'm getting fewer calls. That might be of interest. There's always competition to see who has the better device and then the user's guide clearly could fall into that and the issue of could the data be used internally for research and development which is probably the case. So we now have the stage set for our reactor panel. And I think what we'll do is just take -- this is Joanne will start. She's from G. But go ahead and introduce yourself.

>> (Inaudible) for ambulatory EMRs. I have responsibility for the product strategy around or ambulatory EHR and PHR markets

>> Let me take a few moments. Thank you for inviting us to participate. A few things that you said really resonate with me as I see the EHR and integrated PHR landscape unfold. One is the notion that PHR use is rapidly increasing. It's really changed in the past ten years but particularly the last 18 to 24 months you've seen just a sea change and adoption of PHRs. But the comment around tethered versus untethered couldn't be truer. What we see unfolding and there's some good secondary resource starting to hit the markets right now to support this, is that a PHR as a means to facilitate a relationship and a very locally driven care delivery model between me and my provider is completely different from sort of an anonymous I want to keep everything electronic. That has value but the value is in using that technology to facilitate that patient provider relationship. I couldn't agree more with you on that. I think the way we see EHR adoption rapidly expanding, PHR adoption really growing quickly in the last couple of years on the heels of meaningful use and the potential for that relationship building aspect of PHRs tethered to EHRs to really provide a mechanism to engage patients in their device responsibility going forward I think has real potential. There are probably a few key success metrics that I would throw out there that I think are really valuable to think about as we go forward. Some of those are around aligning some of the UDI requirements with many of the other regulatory environments that providers are faced with right now. So we can start to find ways to pull new device identifiers into the ambulatory EHRs and there's a lot of value to be had from that. At the same time, ambulatory providers right now on the heels of meaningful use is started to go attest right now for meaningful use stage one. They're curious about what's happening with stage two. Some of them don't even realize what ICD10 will do for their practices and trying to get their armed around that. So any extent that we can align and merge those different regulatory paths together, it only serves to engender deeper adoption and more commitment I think from the provider community. And then I was thrilled to see the standards panel this morning really hit on the topic of standards and I couldn't agree more with EHRs being to a very specifically level of communication that effort toward identifying the standards to really identify not only the UDI by the peripheral data points that are important for that and also the transmission mechanisms is incredibly important. In the effort that we take to sort of consolidate that, there are standards being proposed and used right now for communicating between EHRs and for communicating between EHRs and PHRs. So if we can embed and align with those existing standards, depending, you're already one step down that road. And again, I guess I would just say lastly that consistently and widely available content for those patients is going to be critical. And I'm really interested to hear how our device manufacturer colleagues on the panel address some of those types of questions. I know they have great content for these patients that are typically handed out to patients be in print format and that sort of thing. But if we can standardize and make consistent that kind of content that patients can get their hands on, that will again make it easy for the providers to just flip the switch and allow patients to engage directly with those manufacturers. So just a few thoughts on success metrics and I'll pass the ball.

>> Thanks. I'm Doug Gentile. So no big surprise, my comments are going to be pretty much in line with hers since we're in the same industry. Coincidentally, I had the opportunity to participate yesterday in the consumer health IT summit partnered by HHS. So Kathleen (inaudible) and other people spoke, and the gist of the summit was that CMS and ONC are really going to aggressively drive an agenda of engaging consumers in their own health through health IT. And all Scripps is one of many companies pledging to support that initiative by primarily connecting providers and patients. And I mention this because the model that Ed has laid out of connecting electronic health records with personal health records is something we're doing anyway. And I think they'll agree that going forward, working to really drive consumer engagement by electronically connecting providers and patients is just going to be core to our business. So to me it's a no brainer to leverage that platform that's already being put in place to do things like post market surveillance. Don bur wick is fond of saying that the -- he said this yesterday again, that the most under utilized resource in health care is the consumer. So let's use consumers to help do this postmarket surveillance. They're the people with the most interest because the device is in them. I agree with Joann that there are a couple of things we really need to make this work. Standards - So standards for how we represent this data electronically. In today's in (inaudible) EHR to PHR and we need to do that seamlessly and easily. The second thing that we needs is a business model that works. I think this is the part of Ed's proposal that I think is particularly interesting. I'm not looking to make money off this, frankly. Not that I'd mind making money off it, but that's not my goal. But what I can't do is pass the cost of a program like this onto providers or consumers. They're not on going to pay for it. I also can't increase my cost of goods sold. I don't want to be responsible for building the content, maintaining the content, doing the reporting. I don't benefit from that. So I think this model where we provide the platform for connecting and the folks who benefit from provider that information, the device manufacturers providing that content, using our platform as a model that can really work and we've seen it work in other areas. And frankly we'd be delighted to work with companies like J and J and Medtronics on initiatives like this. One other thing, if the FDA really wants to drive this, gets it into meaningful use.

>> Moderator: Okay. Jay's working on that right now.

>> So if you know through the FDA, some opportunities and some limitations, again, reacting to Ed's presentation the other FDA folks are more than welcome to chime in once I make comments. Just a few items. One is the use of the term tracking. That has particular meaning at the FDA so we can mandate companies track certain devices, class two or class three medium and high risk devices. They could be implantable, life sustaining or life supporting. Of we're concerned about failures of the product and being able to contact the patient in case of a recall. So manufacturers have to have standard operating procedures by which they could essentially track their device through the distributor chain, ultimately to the patient in the event of a recall. So that is our particular meaning behind tracking. When we talk about longitudinal follow up, because that was a theme in what Ed presented, we longitudinal follow up tools by which we can mandate manufacturers do post market studies. And when we mandate manufacturers do those studies, they're protocol driven studies and many of those require longer term follow up of patients. Given the fact that we have a protocol, given the fact that we have case report forms, the issue of device identification is really a non-issue because it's collected up front. It's part of the study protocol. So in those instances it's really not an issue. We also can use claims data and EHR data for longitudinal follow up, particularly when we can link registry data with those data sources. And, again, if we leave the registry data to those data sources typically up front we collect device-specific information. So in those scenarios UDI is really not an issue. So what's the up side about using PHRs? I mentioned these mandated post approval studies, postmarket studies where we may want to follow patient’s long term and get simple information. So you have a hip implant. We contact Ed and say five years out, have you gotten the revision in the last year? Yes or no? And hopefully you can respond through your PHR to the manufacturer supplying that information. Typically right now we use simple questionnaires to try to capture that information. But I see that where PHRs could be built into spr data collection along those lines. We're more and more increasing interested in patient reported outcomes as part of some of these studies. So maybe again you could build in patient reported outcomes in the PHR data collection mechanism as part of these mandated studies. Just food for thought. However, FDA will not mandate the use of PHR. We don't mandate the company use any mechanism by which to collect the information. We just mandate the questions that need to be addressed and then they go by whatever means it takes to collect that information and a scientifically meaningful fashion. Another good use of PHRs, and this is in the scenario where you have some connectivity between PHRs and EHRs is in adverse event reporting. Our most valuable adverse event reports come from clinical providers. They know the clinical aspects of the device and the outcomes of interest. The average citizen really doesn't provide us much useful information. Their heart is in the right place, but, again, they don't have -- they don't provide the clinic context we really need. If you had a PHR that was connected to the EHR and the patient could alert the physician that, hey, I have a problem with my hip, and the physician was on the receiving end and maybe had this RFD capability where they could tap the EHR and submit a form to FDA, that's potentially useful connection between the PHR and the EHR. One other potential opportunity here that's already been mentioned is pushing information to the patient. So FDA has recalls or safety alerts and we'd love to push that information to patients who want to receive that information. On the cautionary side, PHRs are really not going to be that useful in active surveillance. You mentioned sentinel. The reason basically is it's really a voluntary sign up at this point. With active surveillance you want a complete accounting of the denominator, the exposure, and a complete accounting of the numerator and also have that outcome validated in some fashion. When a patient reports, it's really not a validated outcome. So there are lapses in using PHRs today for active surveillance purposes. Surveys are limitations for FDA using PHRs to conduct surveys because O and D restrictions that we can only survey up to nine entities of information we're interested in. So nine patients doesn't get you that far. And that's just a practical restriction. PHRs would not be helpful in data mining. We're scomploergt use of data mining in our on spontaneous reported data. Issues there have to do with the underlying quality of the data and the representatives of data. PHR is not a good source in that regard. So, again, lots of opportunities and some cautionary notes as well.

>> I'm Tim mckay (inaudible) and I've had the privilege of working on all things internet since 1994. So you can imagine kind of the trends that we've seen over time. And I'd like to share a few of those trends with you today with where I see some limitations in the use of PHRs in you'd related use cases and then also some things to think about with honing to be able hone the use cases and to make this type of monitoring and reporting and research more effective. So a couple of caveats is that PHRs are all over the board as has been mentioned. And when you look at tethered models you have models that are tethered to EHRs and ones that are tethered to claims based systems, you have stand alones, wellness focused, information focused. Transactional focused and plus they are linked to different care delivery systems which are going to have different models for deliver care. So I would warn against a one size fits all model for integrating UDIs, that there are some things that will make perfect sense in one system not in another. What Ed was describing I think would work really well within the Kaiser system. We look at how we can integrate these types of services with our population care and outreach systems and there are some very promising things there. But another caveat in the use of PHRs is that the use is increasing but it's far from universal. So as mentioned at Kaiser wove one of the more developed systems. We currently have 3.6 million active use accounts out of a population of nine million members. We're adding between 50 and a hundred thousand new accounts each month. We have two million plus secure sessions that are initiated by our members each month. One million messages go from patients to providers through security messaging. Our patients view approximately two and a half to three million lab test results online each month. So sounds really good. But 22 percent of our population has no effective internet connectivity u and when you look at that population, it skews more to the very old, and it skews to disadvantaged populations. So if you're looking to monitor sentinel events and you're looking to do population based research, you're not going to get your population if you're just looking at PHRs. And that's where the use of EHR data is likely going to be way more effective. There are five recommendations that I would have for things to look at in this space. So the first is how can we simplify the data capture of UDI and related information? And the recommendation would be look at the use cases that we're trying to fill and how can we bundle information, say, in one scan, one product with the use of two d bar codes you can get a lot of information in one scan. It could encompass things like serial number, expiration date, narrative product information, and that those scanners are built into devices that you likely have in your pocket right now. So a quick response code is going to be available, free downloadable software for both generating codes and scanning codes on any smart phone that's available. I think there's something in establishing a data model and taxonomy for information so when the information is received it's received one way regardless of channel. So if you're scanning the via bar code or RFID tag or you connect a device in a certain way to a system and it automatically downloads the data stream, the system should be receiving the data in one format so they know how to expect it and not expecting the system to extensively parse information which can be one of the ways that you start getting more error into the system. When you take a direct feed rather than have to manipulate it, it's going to work much better. Second idea is in a PHR view of devices, what should show in a patient list? You probably do want devices that persist in some way, certainly devices that are implanted. But how about things like CPAP machines which are going to be with someone for a very long time? Test strips that are going to be in a package but have an expiration date and you might want to let people know it's about time to go out and get new once. But other things I may or may not want, like are there devices that someone has been exposed to in a hospital setting that are important if there's a problem with a device, but it's really a transient relationship someone has with that device. There's also signal noise. So if you have too many things in a list your patients will stop attending to that list, they're eyes will glaze over and they won't pay attention to it. So what's important to have in a list and then what are the work flows that would be generated off the information in that list. A third idea is that patients are going to get devices directly into their own hands. They're going to go out and buy blood pressure cuffs and buy blood sugar instruments in the next few years we're going to see increasing connectivity to mobile devices so is that an a person will hook up a device to a mobile app and be able to securely transmit that information back to a PHR or EHR system. So how do you get the data in those cases? And I think that's another thing to look at, uniformity of packaging and instructions. So if there is a 2D bar code on that package can the person download an app or have that can get that information into the record effectively. Fourth area is transmission problems. Data is hard enough to move from one system to another reliably. But what about work flow moving from one system to another? If you have an established way of reaching out to patients to contact them for an adverse event, will that work flow transfer if those records go from system A to system B. And there's something to think about how can you not have the illusion of having helpful data but truly have helpful data that follows a person through their transfer between health plans. And then, finally, what is possible versus what is wise. Today there are certain lab test results that will not show electronically. So if you have an HIV test you're going to get those results in the context of an interpersonal conversation. Now, if I had a CPAP machine, needs software update, maybe that is just a fine thing to have come as a message into my PHR inbox. If I have a pacemaker that's going to imminently fail, do you really want that news through a rather anonymous message or do you want it delivered in a more effective way through your system that is compliant with your work flow and compliant with your ethics? So going back, again, to Ed's scenario, I think it's a great one. It's probably a model that if we look three years down the road, or perhaps at the time when UDI is more fully affected in the standardization is there, it has ever possibility of being fulfilled in this bringing very good things in terms of increased patient safety, monitoring the effectiveness of products, and just generally contributing to an ecosystem that works well with patients being involved in their own health care.

>> (Inaudible) I'm vice-president for health care inform attics (inaudible) and Johnson and Johnson. So great comments and I think I can follow up on a lot of those. Ed raised the issue of some of our experience, and very clearly patient engagement helps and a great example of that is in our bariatric surgery franchise (inaudible) has a bariatric surgery product, and a few years ago we created a portal, a patient interaction portal which is called realize my success. It allows patients to engage with their surgeons ahead of time, during the surgery and after the surgery. And now quite rigorously we've shown that people who are engaged in that manner clearly achieve significantly better outcomes than the ones who don't get that support. And we have other examples not as large in size in other parts of Johnson San Johnson and clearly it's becoming clear that we'll have to be engaged and not be just the provider of widgets but providers of solutions. And one way to do that and perhaps the only practical way to do that is using this type of engagement. So whether you call it PHRs or some other term, a means to engage with the patient is critical for delivering better outcomes. And there's just no way around it. It's the key differentiator. Also the definition of PHR itself needs some thought, right? When you look at Google health which you put in whatever data you want and really was not very successful and we talked about other examples, I look at PHRs as a to be tracks of EMR. It should have all the data so it should not suffer from all the bias that is comptroller in but it should offer a channel to get to that patient so that when you five years from now when you have a doubt about the safety, there's a channel available to get to that patient. One of the biggest frustrations we feel in medical device industry is when reports go up in (inaudible) database or some meta study that's done and suddenly there's a sense of a signal. We really -- we're completely unable to respond to it because the data doesn't exist. This is where we invest a lot of money. We talked to Medtronic. They have this big active surveillance network their building. J and J is investing a lot. So we do invest real money in databases and registries, all things available to get to that data. But still it's very hard in my world, the biggest frustration is that we have pretty much every database that we can license, but we can rarely find what product was used so we can do procedural (inaudible) studies much just to give you an example I think we talked about natural language processing and I just wanted to add, a few months ago we did a study looking at outcomes for (inaudible) sutures and this was not in discharge summaries, this was just in charge master detail that accidentally get added to databases sometimes so you could go in and try to mine those. And there were 750 days which (inaudible) sutures were mentioned. And so to find them and then find a cohort that you could be sure about, this is our world. We have no clue what's been used. So I look at UDI and I say well, that would be heaven. But someone said why the bar code. The bar code information is not making it in. If one could just make sure that that -- forget about anything else, just give me the manufacturer and some name of the manufacturer and some other detail, and that itself will take me from a completely data-poor situation that we are in today to where we want to be. There are leads to really terrible behaviors both on the part of manufacturers and regulators. In the absence of information, regulators are likely to take the most conservative stance. Go to a trial, right? And what are we going to do? We'll have to make an economic decision around that, right? And is it even worth it? By the time five years later that trial shows up, if magically you are able to get the full 80 percent follow up and so forth, technology will be done already. Everybody would forget about it. So in some ways in the absence of this type of data, we really do things that are really not good for public health. And that's something that we really need to focus on. A colleague not too long ago as we were discussing this colleague worked on the human genome project and he wasn't quite familiar with what we do. And he said, well, what you guys are trying to is human genome project. Why is it not getting that attention? Human genome project has Nobel Prizes have been given and companies have been launched. When I just look at even in our limited world with the data we have with all of its limitations, whether it's claims data, hospital data, EHR data from GE, from explorers, you know, variety of scripts, even with that, we're finding a huge top line advantage. I mean, 70 to 80 percent of questions that I get are not about (inaudible) products but about R and D. People trying to find out where the unmet medical need is. How should we design or clinical trials? What are the best places to do the trial? Does this even make sense? How will this fit into standard of care? I think enormous top line advantages can come out if such data created. And that story is completely getting lost. We're still talking about defensively looking at safety of this and that. Of course that's very, very important. But just the economic value that countries are going to gain by creating this will be just enormous. And far exceed what human genome project ever did. So I think that's a message that somehow has to go. I've always been interested in -- and I've asked a couple of questions around incentives and why would people do. And thing there was one -- I'm trying to remember -- one of the hospital examples where they had really made is seamless for that bar code information to get in. But yet it's not getting in. The surgeon has the incentive to call something and even take a few seconds that would be necessary to code that in. So you need to look at incentive. And what Ed described from his very personal story, I think is right on the mark. A patient has incentive. If a patient has class three devices they absolutely have incentive. Yes, maybe there are people who -- my Mormon grandma who may not go there, but their family has the incentive. So I truly believe that you have to see who are you helping, and that's very important. I think hospitals have incentive now. If they can reduce their 30-day readmit, they have an incentive. If they can -- if you go around route one or New Jersey turnpike, there's just a number of billboards with hospitals touting how good their quality is just tells you why they have an incentive. This type of data can help them not only improve their quality but also get better reimbursement, better patient pool and all of that. So I do think that it's a problem that's far bigger than just solving the safety issue. In fact, it has probably profound impact on our economy. Mackenzi talks about big data delivering almost a trillion dollars of value and a big chunk of that actually comes from health care. And I think -- these numbers are what they are. Rand predicted 75 billion or whatever. But they do allow you to think. That's the key. They allow you to think where you should take this entire thing. And I do feel that this is how research will be done. It used to be that we would get requests for one trial here, one trial there. Now routinely complex trials that are being designed within J and J, one of the first stops is to or shop to try to see, well, let's figure out what the standard of care is because published information tends to be spotty and variable and it tends to be dated. So clearly you'll have published information, but you want to try to figure out what's happening in 2009 and what's happening in that particular sub groups. So I think we need to kind of keep that in mind. We've spent a lost time talking about longitudinal follow up. Anyone the absence of device information we're left to do the type of studies that we can usually do which is a procedure level and claims database and is that tends to be about 70 to 80 percent of what we do and publish. Even in that, by the time you get a particular cohort with comorbidity background and the people that got that procedure between 2005 to 2007, by the time you figure out how many people do you have four-year follow up information on you're bound to a tiny population and often unless it's a high volume procedure, you just are unable to get enough of a population to do any decent study. So I can't emphasize that whereas everyone can come up with their solution, they all have to merge somewhere to create a larger cohort to be able to do this study. And PHRs offer an interesting option there. This is the place where data is likely to aggregate in the end. A patient control record should be able to collect this data, particularly if it's backed by appropriate education campaigning how it will help the patient, but it's also a national resource. And some of the issues have to be talked about. So I'm actually quite hopeful that this discussion can lead to things which even in advance of UDI coming in place, so under best circumstances what we're looking at based on Jay's plan, it's at least two years from now when UDIs will show up actually in live for class three devices. And the question is could we do certain pilots today? There are a lot of people on this table who have a chunk of the solution, someone has an EHR which is great in inpatient and others are strong in ambulatory and we have our colleagues who are manufacturers. Could we take a couple of examples that are sort of above board, you know, something that we're already studying like orthopedic outcomes or something like that, and at least allocate a part of those resources to doing it smartly, doing it via electronic means and actually tracking what that shows us. And it's perfect controlled experiment, right? Three years from now you'll able to figure out whether this approach actually gave you better follow up or not. And it will be in parallel with Jay's timeline. So right at that time that he will go out he will be able to talk about how great it could be. So I think there are some opportunities and if we all were to work together it could actually be a great thin.

>> I'm the lead corporate bio statistician with Medtronic (inaudible). And as a statistician I have a different view on a lot of these things. I tend to think a lot about design and analysis type issues. And I'd just like to thank Ed for inviting me to participate and the fellow panelists for great comments so I'll try to be somewhat short because I think a lost great points have already been touched upon. There's a comment earlier about using from Tom Gross about you can the patient report outcomes. And I think one attraction of using the PHRs in the context of doing active surveillance is it allows for an increased frequency of data reporting. So you can get at information that's relevant perhaps also reduce the amount of recall bias that you might have from a patient by being able to ask questions more close in time to when the relevant event had occurred. And there was also this comment about the use of adverse event information coming from a patient. And I actually think that that's an opportunity to perhaps get some good information. Not on a very specific level, but more on the level of along the lines of if you can have access to the patient more frequently and sooner than the hospital system, then you can find out more quickly if they've been hospitalized recently, for instance, if your interaction with patient happens faster than with the hospital. But you would have to build into that a certain level of trust so you would get an initial report from the patient that gives you a sense certain a information and until it's over written by more precise information, you using that information. But with the additional information then you would over write with the more precise information you're given. But the advantage about that is it could allow you to short earn the time window to pick up things that might take longer to find out about. A lot of these issues are transitional issues that when these are up and running but the transition is going to take a long time. Another comment had to do with paying for the system the manufacturers paying for the system. I think early on one thing that will help actually is that the manufacturers could see paying for a system as good in that the system itself will provide an incentive to participate for both the scomopts patients. So the manufacturers have an interest in seeing good quality data come through and how can you get that data to come through. Well, if there's availability of a good system. And so but it could be that by providing the system, then the manufacturers could use that as a carrot for the hospital or patient to participate because bay virtue of participating in they get access to the system. It could be the case that the manufacturer is going to the extra work to provide the relevant content to do the analysis they want to do then fill out that more full record that could be taken advantage of by the patient and hospital. That could be a possible incentive to get increased participation in the studies we do. Right now we have a situation where EHRs are not necessarily a single neatly organized unit of information. It can be that a patient has electronic records for imaging in a certain format with regards to their drug dispensing information and different form with regards to their primary physician and the manufacturer by putting this information together can say that this organized electronic health record is then more relevant to you and and distill it to a relevant sense for the patient to work with. Now, another comment, we're going back again to this concept about device information and production information. And this is very relevant for safety signals. It's come up time and time again. We want to be able to do recalls and detect when there are problems. This analysis of safety signals could be done via hospitals, manufacturer, by an agency, and there you get into the question again as to what exactly the UDI will constitute. Because in order to do a lot of those recall type of information you need utilization and that's not part of the current UDI specification. But I do think there's a great need for that type of information. So one thing to keep in mind is we're talking about postmarket surveillance, talking about PHRs, talking about UDIs, and these are all great things we need to focus on, but we should consider what aspects of them are separate and we can handle. So (inaudible) is useful, but it's separate from the UDI and I think it makes sense to put bounds on what exactly we need to do with the UDI and how to implement that so we can get something done of the there's just the very simple question of what is a device in are an orthopedic space that's a non-trivial question. And we talked about uniquely identifying a device. Define unique. Define device. Defining identification. When you have to defy two out of three words for a simple term it's kind of a problem. I think we need to keep in mind that we're dressing a lot of very important questions. But we need to make certain that we can address some of them, not just talk about them over coffee table for a long time and actually make some achievable goals.

>> (Inaudible) just a few points that I want to make. I'm keeping it short. One I think that clearly there's patients that it would work develop for now and I think that having that additional connectivity could be helpful, that follow up, that ability to be able to connect to them. One thing I like is -- rather than pushing too much information to them, I almost like giving them the reminder that if you have questions, you can go here. I like the idea of kind of information on demand and then patients can go as far as they want. If they just have some question or if they really want to go deep, they can go a little bit further and then that information will be there, that content would be available to them. I do think the idea of having a community of interest team, AAL I think it would need to be monitored by the manufacturer, because there may be some things that may come out in the discussions that they may need to follow up on, I do share some of Tim's skepticism that I don't know that we're there yet. And I think part of it may be that -- I think -- I do think that things are probably headed there. And I love the concept of a PHR that literally follows the patient everywhere, but I think right now the burden of switching is so much lower for patients compared to providers. And if the newest and greatest thing comes out, they don't have -- it's just very easy for them to switch. I think the other thing is even if at (inaudible), as much as it's an employer encourages its associates to use their PHR, we know that the use is not nearly as high as we like. A lot of patients (inaudible) more schedule appointments at the clinic on site than anything else. I think, again, that will change and I think as we get better at populating that information, I think that's where the problem is that patients are not going to be good at updating that information. At the very least, even now, though, PHRs need to have that my device section. There's no reason that that can't be there even now. The PRO issue, I think is fascinating because I think it could be of relatively low cost way to collect PRO data. But I do think you may have a difficult time controlling for some of the other factors that were discussed today that you're just not going to know about without having it linked to other data. But one thing that I think could come out that would be interesting would be patient satisfaction. And I think the manufacturers may be interested in that, particularly for those devices that involve some kind of functional aspect. Just to know are they happy with their device. And that's a simple question that you could ask periodically and find out what their thoughts are.

>> Moderator: Thank you very much. We have a little less than ten minutes. So if you have questions, please queue up and I'm going to take the moderator's prerogative here and make a comment and then pose a question much the first has to do -- the comment has to do with patient reported information versus physician reported information. And because I went to medical school and practiced for ten years, I had that physician frame of mind, what I now refer to as the reverse (inaudible) where everyone sees the world revolving around them and particularly those of us that have M.D. behind their name so anything that came from the patient is sort of questionable and anything that comes from the doctor is right. I'm reminded when I was running a 250 physician IPA in northern kaflt and managed care was coming and so is he surveyed our doctors saying what do you think patient see fgs levels are because it's going to cost your patients more to stay with us. We're not signing up for the new manage care plan. Not surprisingly we all thought our satisfaction level was here, but when we actually surveyed it it was here, which gets to Matt's comment about patient satisfaction. So there are some things probably better to get from the and other things and even some that don't have a functional component that you would think of, various kind of implantables, but there could be annoying little things about devices, I can told you, I have one, annoying little things, or questions that nobody answered them and you're sort of irritated and wondering how long is this thing going to last. My question actually has to do with the fact that -- so I run this company and we publish a book called the physician's desk reference and have a lost electronic systems and one of the things we've done is created services that are rolled out inside of electronic health records. In working with the EHR vendors, the bottom line is if there isn't an up-front payment to get on this going and if there's an ongoing revenue stream, it's not going to happen. Because they have to deal with the realities of the clients they serve, the hospitals and the doctors and the nurses and other folks who constantly are raising the bar in terms of functionality and the federal government coming in saying meaningful use one and two. So if there's not up-front payment and there's not revenue, you you're not going to have anything. At the same time we talked about the current cost to the manufacturers of these post market studies. So I wanted to pick on (inaudible). Can you give as you sense of the kinds of -- what it's really taking for you to do post market surveillance, what are the costs involved, do you ever just walk away from a product because it's just going to be too difficult to fulfill a market analysis?

>>: Hard to go into specifics of any one of those. But clearly there are huge costs. So as we talked about before, an average registry takes a million dollars or more per year to run. I mean, this is not -- I'm creating just a ballpark number and so these things can all add up; a billion here and a billion there as they say. So clearly the regulatory burden is going up, and we have to respond, and right now where we are is an extraordinarily inefficient place for us to be tracking device safety, twice outcomes, even health economic issues, et cetera. And you did raise a point that if a product is small, and let's say there's a product that makes a million dollars, and at some point an issue comes up which can only be solved by agreeing to a fairly expensive long term surveillance program, then the manufacturer may have to think as to how are they going to continue on with that. So I do believe that there is an issue. I mean, it really is something we have to work together to create efficient means. We are always looking, we've talked about it over the years, and with most of our colleagues here, always looking for efficient means of getting this data in. And we have exhausted or partners to try to get the device data in one way or another, going back to (inaudible), three or four years ago, I think it was, and even before UDI. So we've asked for it. But it's been hard. And we definitely would support it because that's a business end.

>> I'm going to ask one more question. It goes to the EHR vendors if you could each comment. There's a mean full use two coming and ONC has something with defining that. Yesterday as I think everyone in the room knows, if you didn't now you do, as Doug mentioned there was a big push from ONC saying we have to make EHRs relevant to consumers. I think sun at ONC realized that consumers and patients are also voters so if you're going to spend $40 billion on something it would nice if it was relevant to voters so you're seeing a big push for that and there's probably an understanding that patients have a dog in the fight in terms of their outcomes. So my question to you is, is there anything that you can see that the FDA could or should ask for from ONC in terms of meaningful use that will help bring this vision to life?

>> I'll start with that one. I think Doug and I both pretty much I have a lewd today this before, but the more that the guidelines and measures and outcomes are aligned together, the more likely they are to be adopted by the very busy sort of overburdened provider out there. So UDI tracking and a longitudinal record of that all the way from device insertion through a post acute care ambulatory long-term patient engaged scenario is high on the priority list, then the extent to which that's aligned in MU stage two guidelines, the better, the more likely it is to be fully adopted.

>> I think a couple of the panelists commented that we're not there yet. We do have lost competing priorities. This little thing called Icd10 coming that's going to be triple the impact of meaningful use, which was pretty big, closely followed by meaningful use stage two. So things like this that aren't included in those packages are going to get pushed just as a practical reality.

>> Matt, anything? We pretty much nailed it? Great. Thank you. Well, I would like to thank our panelists very much, the FDA, Jay, Tom Gross for inviting me and our panelists to participate. Thank you very much. (Applause)

>> Jay Crowley: A couple of closing remarks. Thank you all for coming. I want to very much thank all of the panel members that have participated; the moderators who helped organize this. Thank you to our wonderful webcasting staff, thank you very much. And thank you to everyone in webcast land. We will post everything that we can on our website. Our website is www.fda.gov back slash udi. You'll find the presentation and is a link to the archived version of the webcast as well as a transcript. It won't be up tomorrow but it will be up soon. As I believe Dr. Gross mentioning in his opening remarks, this is a first step for us in a lot of this space. So expect to see a lot more activity around what are we going to do with UDI, how are we going to drive adoption, implementation and use, much more quickly than might happen organically. So if you have any thoughts on this going forward, you've met all of us from FDA, and feel free to contact any of us. Particularly Terrie. With that, I thank you all, and have a wonderful day. (Applause)