• 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

Public Workshop - Mobile Medical Applications Draft Guidance, Transcript for September 12, 2011




+ + +


+ + +


+ + +

September 12, 2011

8:00 a.m.

FDA White Oak Campus

10903 New Hampshire Avenue

The Great Room (Room 1503)

White Oak Conference Center, Building 31

Silver Spring, Maryland 20903


Deputy Center Director for Science, CDRH, FDA







KERRY McDERMOTT, West Wireless Health Institute

DAVE EICHLER, Psilos Group

DANE STOUT, Anson Group

BRIAN DOLAN, MobiHealth News



ANAND K. IYER, Ph.D., M.B.A., WellDoc Inc.

DAVID S. HIRSCHORN, M.D., American College of Radiology

ROBERT JARRIN, Qualcomm, Inc.


KENT DICKS, MedApps, Inc.

SCOTT THIEL, Anson Group



BRADLEY THOMPSON, Epstein, Becker & Green

CHUCK PARKER, Continua Health Alliance


NEAL SIKKA, M.D., George Washington University

MARC ANDERSON, Juvenile Diabetes Research Foundation (JDRF)



BRADLEY THOMPSON, Epstein, Becker & Green

CHUCK PARKER, Continua Health Alliance

JOSEPH SMITH, M.D., Ph.D., West Wireless Health Institute

DONNA-BEA TILLMAN, Ph.D., Microsoft Health Solutions Group

JOHN LaLONDE, Boston Scientific


JULIAN M. GOLDMAN, Ph.D., Partners HealthCare


JOVIANNA DiCARLO, International mHealth Standards Consortium

JASON BROOK, Epstein, Becker & Green

AARON KAUFMAN, Massive Health

SUTHA KAMAL, Agamatrix





Bakul Patel, CDRH, FDA


William Maisel, M.D., M.P.H., Deputy Center Director for

Science, CDRH, FDA



PANEL 1 - "Mobile Medical App" Definition - 20 Bakul Patel, CDRH, FDA, Moderator

Q/A Audience Interaction 66

PANEL 2 - Level of Oversight and Proposed Approach - 78

Following Current Classifications and Oversight

Controls - Anthony Watson, CDRH, FDA, Moderator

Q/A Audience Interaction 118


Julian M. Goldman, Ph.D. 133

Dean Kross, M.D. 136

Jovianna DiCarlo 141



PANEL 3 - Current and Future Trends in 149

Connecting Accessories to Medical Devices -

Bryan Benesch, CDRH, FDA, Moderator

Q/A Audience Interaction 178

PANEL 4 - Approach and Level of Oversight for 192

Mobile Medical Apps Which Become

Accessories to Multiple Medical Devices -

Bakul Patel, CDRH, FDA, Moderator

Q/A Audience Interaction 226




Jason Brook 233

Aaron Kaufman 235

Sutha Kamal 238

ADJOURNMENT - Bakul Patel, CDRH, FDA 242



(8:12 a.m.)

MR. PATEL: Good morning. I think we're going to get started now. There are folks still coming in, but we'll go ahead and get started. So hopefully if we end up on time or we end up before time, we can let you guys go at the end of the day.

Good morning. Welcome to the public meeting on Mobile Medical Apps Draft Guidance. My name is Bakul Patel, on behalf of FDA and Center for Devices and Radiological Health. I really appreciate your participation and willingness to be here and provide input in finalizing the draft guidance.

We arranged this meeting to collect input and feedback and get your reaction to the guidance we published a couple of months ago. We timed this at this time especially before the draft guidance docket closes on October 19, 2011. So, please, I urge you and encourage you to provide your feedback by that date on the docket.

Before we start the meeting, I'd like to go over a few logistics. As you may have noticed already, people have only access to this building coming into FDA, and in order to get to 31, you do need to get through Building 1. Georgia's pointed that out to me right now. So I apologize in advance for having to have that direction not listed.

However, it's important that if you decide to leave the venue for any case or any reason, you have to go through that process again. So just be aware of that and allow enough time for you to get here.

Now, some brief points about the workshop. We have set up five Panels discussing various topics related to the draft guidance. Each Panel discussion will be focused on a particular topic area, and I'll introduce that topic area and moderators will actually take that to the next level and get in-depth of understanding that issue, creating dialogue and making sure that the Agency hears from not only the Panelists but also from the audience. I encourage you guys to participate in this process.

During the Panel session, I think we're going to have audience participate in two ways. During the session itself, while the Panel is going on, you can write down notes on a piece of paper, bring it up to the front. One of my FDA colleagues will bring it to the moderator for the moderator to consider those questions and comments as part of the Panel discussions.

Another way of doing it would be we have allotted special time right after the Panel discussion, it's right after every Panel discussion, you can walk up to the microphone, ask a question to the Panel. People on the web will be given hashtags for Twitter that you can tweet your questions. There will be persons sitting here watching the tweet feeds and will bring those questions up to the moderator or for the Panel for their consideration.

Just a key point to now here, that as you see, there may be many FDA folks in the room, and as you go through and discuss your products or other items that you may ask those people, make sure that you understand that these are only informal discussions, and they're not to be taken as final determinations for your product or your question itself. So just very informal.

We are here especially to collect your input. So I think that's the most important key point here is to get input to help us finalize the guidance.

This workshop is webcasted, and the webcast will be recorded and will be made available on the meeting page after the meeting is done, and the transcripts and the webcast will be used as input in the finalizing process.

Without further adieu, I would like to welcome Dr. William Maisel, Deputy Center Director for Science at the Center for Devices to give his key remarks.

DR. MAISEL: Good morning. I'd like to add my welcome and our appreciation for you being here today.

Over the weekend with all the 10th anniversary of the 9/11 events, I was really struck by how recently 9/11 seems to have occurred, and it was about 10 years ago that the first commercialization of 3G networks was introduced, and it really speaks to the rapid evolution, and I don't know if we were standing here -- well, I do know if we were standing here 10 years ago, that we couldn't have seen the revolution that's in front of us with mobile apps for healthcare uses.

One of the amazing things about the mobile app market is that it's one of the few areas that continues to expand despite the downturn in the economy. In 2009, healthcare applications comprised about 1.5 percent of the total mobile application market. The actual sales figures doubled from 2009 to 2010, and I think many people expect exponential growth in this area, and by 2015, it's estimated that there will be 500 million smartphone users with healthcare applications.

Clearly this is a burgeoning area, and it really is also emblematic of the challenges that we at FDA face with regard to innovative technologies and anticipating what's coming and making sure that we're striking the right balance between promoting public health and patient safety, but also fostering innovation and making sure that the innovators and the smart people like those of you in the room continue to develop important products that will help revolutionize the delivery of healthcare.

It's clear I think that these type of products will revolutionize the way we deliver healthcare, and when we tend to talk about them, we talk about two general groups.

One group are patients and how they will care for themselves, the type of applications that they'll use, the way they'll monitor their healthcare, the way healthcare will be delivered to them. We talk about healthcare providers and how they will deliver healthcare, how they will receive information, but it's clear that there are many other stakeholders. There are mobile app developers. There's conventional medical device makers, computer software, large companies and small companies, investors, third party insurers. There's really a whole community, a number of stakeholders that care about this space, and one of the goals of this public meeting, but also in developing the mobile app field, will certainly be to tie together all these stakeholders and not just focus on patients and healthcare providers which are clearly the two important areas.

One of the challenges is that while mobile medical applications can provide valuable health information and certainly will serve an important role in healthcare delivery, as is the case with more traditional medical devices, in some cases, mobile apps may present healthcare risks to patients, and we need to figure out a way of striking that right balance and protecting the public health.

We clearly at FDA believe we have an important role to play in both fostering innovation and encouraging the development of new applications that will help make healthcare delivery better.

We also have a responsibility to oversee the mobile medical applications that present these risks to patients, and as I'll discuss in a moment, our focus is really on a very small subset of mobile medical applications, and obviously this is purposeful so that we can try to strike that right balance.

One of the ways we strike this balance is trying to be clear in areas that we are not going to regulate. We have clearly stated that we do not regulate the sale of general consumer use of communication products like smartphones or tablets that are capable of hosting health-related apps.

In our approach, if you've read the guidance, you see it does not affect the majority of mobile medical applications, and we believe that this is the right approach for continuing to foster innovation in this area.

As Bakul mentioned, we issued draft guidance about two months ago. We have a 90-day comment period, and we're hoping that the guidance will provide clarity about which mobile medical apps will require oversight. The guidance was really issued after months and months of extensive discussions, feedback from industry and other stakeholders, mobile medical app users, and we're certainly continuing that process by having you here today.

We recognize that a mobile medical app may not reside in or on a handheld device, at least not in the traditional way that software resides on a computer. So we've defined a mobile application or a mobile app at least for the purposes of our guidance document as a software application that can be executed on a mobile platform that is handheld in nature or a web-based software application that's tailored to a mobile platform but is executed on a server, and certainly we'll be soliciting your input on that definition in that scope of the document.

The other important thing to consider when looking at your own mobile app, if you're developing one, is that the intended use of the mobile app determines whether it meets the definition of a medical device. And so when the intended use of a mobile app is for the diagnosis of a disease or other condition, or if the intended use is for the cure, mitigation, treatment, or prevention of disease, or if the intended use is to affect the structure or any function of the body of a man or a woman, then that meets the definition of a medical device, and the mobile app would be viewed as a medical device.

To provide a clear understanding of which mobile medical applications will require our oversight, we've defined a small subset of these mobile medical applications that may impact the performance or functionality of currently regulated medical devices, and this is the focus of our guidance document, and this includes two general categories of mobile medical applications.

The first are those used as an accessory to a medical device that's already regulated by FDA, and the second are those that transform a mobile communications device into a regulated medical device, by using attachments, sensors, or other devices.

So the first category, which was the app is used as an accessory to a medical device already regulated by FDA, an example of that would be one that we've already approved. A healthcare professional makes a specific diagnosis by viewing a medical image from a picture archiving and communication system, a PAC system on a smartphone or on a mobile tablet. In this case, the interpretation of the radiological images on the mobile device could be adversely affected by the smaller size of the device, by the contrast ratio on the device, uncontrolled ambient light on the mobile platform. There are factors related to the use of that mobile app that could have an adverse impact on the interpretation of those images, and clearly there's a potential risk to health if the device does not perform as it's intended.

The second category that we talked about was an app that transforms a mobile communications device into a regulated medical device by using attachments, sensors, or other devices, and the example that we've given are applications that turns a smartphone into an ECG machine or into an EEG machine, devices that would then detect an abnormal heart rhythm for example or determine whether a patient was suffering from a heart attack. Again, clearly there's a potential risk to health if this mobile app did not work as it was intended.

There are many different types obviously of mobile medical apps, and there are many ideas. Examples include mobile apps that could provide the ability to control inflation or deflation of a blood pressure cuff through a mobile platform or control the delivery of insulin to an insulin pump remotely. A mobile app could use the attachment of a transducer to transform a device into a stethoscope or an EEG machine or an ECG machine, an attachment that could serve as a blood glucose strip reader to turn a device into a glucose meter. Clearly there's really an unlimited number of possible uses. We can all imagine different uses, and we're trying to strike the right balance.

There are also clearly mobile health applications that we do not think we need to regulate and will not regulate, mobile apps that are electronic copies of medical handbooks or textbooks, mobile apps that are used to log or track decisions or suggestions relating to maintaining general health or wellness, dietary records, things like that, mobile apps that are used for billing or inventory, really not related to the specific healthcare of a patient, and mobile apps that are more generic aids that assist users but are not commercially identified as used for medical reasons like audio recorders or magnifying glasses that might be used.

So again the message obviously, and you'll hear it over and over and over the next two days, is we're trying to strike that right balance.

For the subset of mobile medical apps that are subject to regulatory oversight, manufacturers must meet the requirements associated with the applicable device classification, and if the mobile medical app on its own falls within a medical device classification, its manufacturer is subject to the requirements associated with that classification.

What we are not doing, however, is regulating entities that exclusively distribute mobile medical apps without engaging in manufacturing functions, and so owners and operators of some of the distribution areas like iTunes or Android Market or BlackBerry App World are not regulated by FDA under this guidance.

A mobile medical app like other devices may be classified as Class I in which case it would require only general controls, Class II where they'd require general and specific controls, or Class III where they'd require premarket approval, and that will really depend on the function and use and intended use of the mobile app.

So I think it's clear, and I know many of you in the room certainly appreciate that mobile health is transforming the healthcare industry. We're seeking to strike the right balance by providing a risk-based, focused approach to the oversight of this small portion of mobile medical applications, and we certainly are glad that you're here today, and we look forward to getting more of your input over the next two days.

Thank you and welcome.


MR. PATEL: Thank you, Bill. That was great. It was a great overview on the guidance itself.

What I'd like to do next is, you know, start off with our sessions. I'll give you a brief overview on the session itself.

The first session is focused on the guidance. The guidance calls out two main aspects. One is the scope as Bill pointed out, have we defined it right? That's what Panel 1's going to be about.

Panel 2 is going to be about do we have the right oversight? Are we looking at these applications in a way that we need to look at? Are we providing the same level of confidence that a regulated medical device would have? That's the questions for Panel 2.

Panel 1 is talking about have the guidance done enough justice for folks to identify their apps to be considered part of the definition or not? And also, are there anything in the gray areas, that we may not have considered, should be included or should not be included?

I'm sure as you guys look at the definition and go, you know, what about my app? Is it part of the definition? What about app X that I saw on 19 Stories? Is it part of the definition or not? That's the discussion we are going to have in Panel 1. One is to identify that, that gap. Two is to ask the question, are we at the right level of oversight, in Panel 2.

So having said that, I'm going to run through a brief presentation just to drive it home graphically.

So as Bill talked about fundamental apps, we have seen reports of this come by. We also seen that not only us as users, us as regulators, us as manufacturers of the apps, there's interest from consumers as well as from people who are using these. Various reports have pointed that out. It's not novelty that this world's going to change.

Some apps have tried to capture metrics in terms of how many healthcare and fitness. This is scope that we're talking about. We're talking about 9,000, and that was, you know, in May. I don't know what it is today. I'm sure that the number's different or changed from that time. Healthcare and fitness, about 9,000; medical, about 6800.

We have not only been requested to provide clarity on FDA's role and what the expectations are, but we've also been asked to provide that line where we can say definitely what apps will be considered as part of FDA's preview at least at this time, so there is this clarity to many stakeholders like app developers like yourself, healthcare market entrants. As you can see today, there are a lot more new market entrants in this space as it's so easy to make an app.

How do we provide the level of guidance? People are going to investors and asking for funding. How can we provide the level of guidance to them?

And, last, I didn't mention the traditional device manufacturers. They're also affected because people are taking information from traditional medical devices and using them, and as we strike the balance between policies and goals, we are most importantly trying to protect public health, at the same time promote public health.

So how do we start? I'm going to provide you a little bit of background on how this guidance came about so you understand how it impacts you and help you sort of frame the questions in the Panel discussions.

This is the definition of a device. I'm not going to read it all, but the key point highlighted is if a contrivance, in this case software or medical app, is intended in the use of diagnosis for disease and other conditions, or in cure, mitigation, or treatment, that's right out of Section 201(h) of the Act, it can be considered as a medical device.

Now let's look at that. This is the world of mobile apps especially in the healthcare world. The tip of the pyramid is where we're talking about. We're talking about a very small subset. We have identified apps like Bill pointed out, don't have any regulatory requirements, and there are apps that exist today that fall outside the definition of the mobile medical app in the graph guide in the proposed guidance. They are under enforcement discussion, which means that we will not take any action at this time until we figure out what the market looks like or the risks for those apps are considered in the mobile medical apps space.

So this is the definition as we describe as an accessory or it transforms.

To give you sort of a pictorial view of the apps, I picked like three examples. This has been done a long time ago using a mobile handheld phone to monitor wound measurement and documentation. We just talked about this. Bill just talked about the mobile medical application. We also talked about there are applications that can connect to a smartphone and become an ultrasound machine. There are many other applications, like as you can imagine, there's -- I tried to do justice by having as many examples as possible in the guidance to help you guys sort out when you read the guidance to understand where this world is going.

There are other apps that are currently regulated or registered, Medco Pharmacy apps. It's a Class I device.

So when we use the word "oversight," we also mean that it does not necessarily mean premarket clearance or approval. It means that they may fall into the classification of Class I, Class II, Class III, which may only need registering and listing with FDA.

This is the bottom of the pyramid. Informational apps are not considered to be part of the definition. This (top of the pyramid) is what we're talking about, things that monitor bedside and things that take bedside monitoring information and displays it are considered part of that. Things we talk about, blood pressure, controlling the blood pressure cuff would be considered as part of the definition.

Let's look at a couple of other things that we have exclusively said that would not be applied right now which fall outside the definition. Patient self-management apps, simple tracking and trending apps that replaces a diary in your home and you can just log your information onto the app are not considered part of the mobile medical apps.

So that's the scope. That's what we talked about in the scope section. Panel 1 is going to talk about have we defined the boundaries by the definition appropriately? If not, tell us why it's not appropriate. Suggest to us, provide us feedback and how can we improve that definition, one, and is there things that we need to consider that should be part of it or things that we should spell out that should not be part of it? We're really looking for that feedback.

We asked three specific questions in the Notice of Public Workshop in the Federal Register.

The first question is about the scope and aspects of the guidance itself.

Two, we have not addressed the question of accessory, when a mobile medical app gets connected to more than one class of devices, what do we do with that? We have not addressed that specifically, and we have said in the guidance that we want to address that. Session 2 will focus on that.

And then the big question, all these apps today we're looking at eventually get into the role of some sort of support in clinical decision making. How can we demark that area? How can we provide that level of assurance that users, patients, as well as other stakeholders need to make sure that the apps that provide that level of support or -- in support will provide that same assurance that you have for medical devices.

We are looking for comments, and this meeting is an attempt to solicit that help. October 19th is when the docket closes. I would urge you to go and provide that input.

So Panel 1 is about mobile medical app definition, the scope. Can we identify in versus out of the definition?

Panel 2 is the level of oversight and the proposed approach in the guidance.

And having said that, I would like to invite the Panel, the Panel 1 Panelists to the front, and we'll get started with our discussion.

So Grant Elliott from Voxiva and Leslie Kelly Hall from Healthwise, Kerry McDermott from West Wireless Institute, Dave Eichler from Psilos Group, Dane Stout from Anson, Brian Dolan from MobiHealth News. If I can ask a couple of folks to come on this side so we don't get all crowded.

As the Panelists settle themselves in, I would urge everyone of you to start thinking about questions to throw at the Panel at the time the Q&A starts. So please bear with us.

I'm going to ask the Panel to go around and give us a one to two minute introduction, tell the audience who you are, what prospective you're providing, and give us a two minute or one to two minute perspective on the scope of the mobile medical app definition. So we can start with you, Kerry.

MS. McDERMOTT: Good morning. I'm Kerry -- am I on? Good morning. I'm Kerry McDermott. I'm the --

MR. PATEL: Keep it pressed.

MS. McDERMOTT: Note to Panel, push and hold. Let me try this again. Good morning. I'm still Kerry McDermott. I'm the Senior Policy Director of the West Wireless Health Institute.

For those of you not familiar with the Institute, we are an independently funded, nonprofit medical research organization, and our mission is to lower the cost of healthcare through innovation and technology. So anything that can be done to bring clarity and predictability to the regulatory regime we obviously think is a good thing. So it's been a pleasure to work with Bakul and partners at the FDA on this so far.

I think that one of my two messages for the day are going to be, one, I should be able to interact with the Government without the help of a lawyer. So we want to make sense of all of this guidance without actually having to get regulatory counsel to even answer those first few questions.

And I think a second area for a lot of opportunity is around populating the pyramid. So as we consider the three tranches that Bakul articulated for us, I think the middle section around enforcement discretion in particular, that's where I'd say we could focus a little bit more on. Talking about the factors that might change that enforcement discretion going forward, and to the extent the FDA can go ahead and signal its intended use to us, then the investment community can understand that.

And I guess the last point is that if it is all about the claims, that's something very difficult for the layperson to understand, you know. Until I started meeting with the FDA, I didn't know what intended use was. Does it have something to do with my day? Who knows? So I think there's another opportunity to really educate there. Thank you.

MR. EICHLER: Good morning. I'm Dave Eichler. I'm a partner with Psilos Group in New York. We are a healthcare-focused venture capital and growth equity firm. So I guess I'm here to bring the investor's perspective.

We have a very specific investment strategy in our firm. We were founded about 13 years ago, and even at our founding, we kind of looked out in the future, and like I'm sure most everybody in this room realized, that the rate of healthcare costs, inflation, was going to be an unsustainable trend, and I guess we're testing how far we can push that, but it feels like we've pushed about as far as we can go.

So we have been investing for over a dozen years in companies that have a direct story around lowering the cost of healthcare, improving the quality of healthcare in the U.S. healthcare system, and aligning incentives across all the stakeholders, you know, the entire healthcare constituency, the payers, providers, and patients, and that's really all we do. We're very, very focused. We invest about half of our money and half of our effort in healthcare IT and IT enabled services and about half in medical devices which includes diagnostic imaging.

As far as perspective on the guidance goes, I'm certainly not an expert in FDA matters. We typically invest in a somewhat later stage of investment, post-FDA, but I think, you know, my two thoughts are, one, you know, I applaud the efforts of the group here today to try to create, you know, condition of, you know, kind of better clarity and predictability. That's obviously important for the investor community. There's, you know, very rapid innovation in mobile health and telehealth and health IT application generally, and we're in the business of risk but, you know, in any areas where we can look to help mitigate risk and create more clarity and predictability, I think that's a good thing.

I think more specifically, as we have a discussion on the Panel today, I think my comments are going to be geared toward the area where this continuum of clinical decision support and care management and care coordination, you know, kind of where in that spectrum are these guidelines going to either fit or clash, you know, I think that was a part of the guidelines where I didn't find them to be as clear. So rather than ramble on now, we'll just leave it to the body of the Panel. Thank you.

MR. ELLIOTT: Hi there. My name is Grant Elliott. I'm with Voxiva. Voxiva has been pervading mobile health apps for about 10 years now, predominantly initially in developing countries and lastly in the last 2 or 3 years in the U.S. Most of our applications, certainly the U.S. ones, have been predominantly health and wellness apps, and some of you might be familiar with Text4Baby, and we recently launched a Text2Quit application this year, and as we start moving into the field of more specific disease states, like diabetes, clearly FDA guidance around this field directly impacts us.

In the U.S. alone, some 8 percent of people have type 2 diabetes, and approximately 35 percent of adults over the age of 20 have pre-diabetes. So clearly there's a real problem going out there, and we believe mobile health has a unique opportunity to help many of those people, particularly the understaffed part of the communities who don't necessarily have the access to the medical care that many of us take for granted.

And as I look at the guidance that's been offered so far, I think it's a great start. I think it is very clear with regards to some very specific use cases, some of which have already been given by Bakul, but I think there is definitely a gray area there around the definition of health and wellness and where does health and wellness go a little bit further into interacting with the user, interacting with the patient, and giving the patient a direct ability to get advice and guidance through their mobile medical device, particularly in situations where the risk is low in terms of what can go wrong.

And so I think, you know, the initial reaction for myself is that there needs to be a focus more on the actual risk and the risk model associated with this, and how we actually approach identifying whether or not regulatory oversight is appropriate.

So I'll be very interested as we talk to hear people's perspectives on that.

MS. HALL: Good morning. I'm hand challenged today because --

MR. PATEL: Move closer to it.

MS. HALL: Thank you very much. Hi. I'm Leslie Kelly Hall. I'm with Healthwise. Healthwise is a nonprofit of 35 years, and we provide patient education materials to help people make better health decisions. We've been used over a billion times and are prevalent inside most health websites today for the major content under WebMD. We are with every Kaiser Permanente Group Health, Mercy Health and many other health systems. Every patient visit includes our information.

I'm a former Chief Information Officer of a health system that included responsibilities of teleradiology, telemedicine, HIT, LIS systems, PAC systems, robotics in the operating room, robotics remotely, mobile NICU as well. So interoperability is key to some of our concerns as well as patient access.

In my comments today, I'll be focusing around the patient as a source of truth and how that should or should not be regulated, the liberation of data coming from mobile apps and how that should be regulated and used in the definition that accommodates that.

Really, the ultimate patient safety tool of a mobile application is dialing 911, and nothing should be done to get in the way of that.

I will also be commenting on the use of interoperability of data and accessories with regard to regulated applications. Thank you.

MR. STOUT: Good morning. My name is Dane Stout. I'm the Director of the Connected Health Practice for the Anson Group. Anson has been around for 15 years helping drug, device, biologic companies get their markets successfully on the market through the commercialization process and deal with any compliance issues.

I came into the practice to start this practice about two years ago, and I really come from a very different background. I spent 25 years mainly with Silicon Valley based companies in the technology industry. Most recently, before Sun was acquired for Oracle, I was manager of the market segment for healthcare and life sciences, and I saw this convergence sort of heading at us a few years ago, and we decided that we wanted to get in. We knew there would be a lot of new market entrants here.

So from the perspective of the definition of the mobile medical apps, I think FDA is on the right track with the modularization of this guidance document to acknowledge that software is just too big and pervasive and complex to be dealt with in sort of a general way.

However, I do think we're going to have to start thinking about an architectural approach to this where we can have some modularization and linkages between the different guidance documents that are going to need to come out and be published. So I think we'll talk about that in terms of clinical decision support so that organization about clarity as to what guidances and how they interact with each other. So I think modularization is key.

The second piece I would highlight is the tightening of the definitions for an audience that's coming in that's new to this face, and I think there's a lot of companies, as Kerry well pointed out, the intended use is something that's a little bit of a different concept. They have a piece of technology. It can do multiple things. It can treat multiple diseases, and they really don't have an appreciation for that approach. So I think the tightening of those definitions and expansion.

So as we're tightening this, I think expanding for clarity purposes around some of those definitions, for example, what interoperability standards might be applicable? And so I think the real goal here is to avoid, you know, surprise regulation for companies, and that will be sort of the topics that I want to talk about on this Panel.

MR. DOLAN: Good morning. My name is Brian Dolan. I'm the editor and co-founder of a publication called MobiHealth News. We've been around since 2008, focused squarely on mobile technology in healthcare. So this is really a topic. The regulation of these apps have been a topic we've been writing around since February of 2009.

One of the things we do every year is actually take a look at the specific apps, individual apps in each of the app stores in the healthcare, fitness, and medical categories, really to see which of those are actually health related, which are miscategorized, which are for, you know, patients with diabetes as an example, and really break it down in different subcategories.

So one thing we've done recently since the publishing of these guidelines is to take a look in our estimate how many of these applications actually fall under the guidelines or how many you can make a good case that they would fall under.

So if you look at the Apps Store, Apple specifically last year in 2010, we believe there's about 800 apps that would fall under this very small subset of apps. So that again is between 10 and 15 percent of the apps in the Apps Store as of last summer. This summer it's closer to 2,000. That's out of about 12 to 14 thousand applications that are health related for Apple devices. So although it's a small subset, it's still a pretty big group of applications just for the iOS platform.

So in terms of the definition and where there can be some improvement, I think there's a lot of great discussion going on, on some of the lines between fitness, you know, and health applications and where the lines should be in terms of which ones are fine for just patient logs and that kind of thing and which are going to affect care and pose some risk.

But on the more technical side of the definition in terms of what an app is, I think there should be some more clarity around a mobile website. So a piece of software that's tailored for the mobile platform to me sounds like language written in 2010-2011, and I'm not sure that's really the way we're going to speak a couple of years from now. Some people believe that in just two or three years most web browsing will be through a mobile device. So a website that's tailored for mobile application really wouldn't make much sense. It really in two, three years time, that sort of website, a website that's not tailored for mobile application would really just be viewed as a poorly designed website.

So I think as stated, the guidelines really say is any website that falls within the guidelines, any website that really has these functionalities, not any mobile website, and I think that could have some serious considerations for us in a couple of years time.

MR. PATEL: Thank you, everybody. I think this is really a great start. As you guys can see, the Panel comes from a very broad perspective in terms of their impact and their stake into the definition.

So I'd like to tee up the very first thing that I think I've heard a common theme about intended use. How clear is it or is it not in the guidance and what would you suggest?

So I can start with you, Brian. You've been sort of following this industry for a while and squarely focusing on this area. How did it come across to you or have you been converted over to the intended use world?

MR. DOLAN: Yeah, I would say again in terms of those -- so those devices that are connecting to an already regulated medical device, I think that's very clear, you know, I think it's really just a handful of applications out there that fall into that.

But on the other side, the ones that transform a mobile device or this application into a medical device, on the intended use question, the biggest clarity issue still or around, you know, an application that really is around prevention, fitness applications, that mention specifically chronic conditions. So say if you use this fitness application, it may help you prevent diabetes, you know, it may be good for pre-diabetics, that kind of thing.

So I think, you know, are these fitness applications that specifically call out conditions going to fall into the apps mentioned in these guidelines or are those going to get a pass? I think some clarity there would be great because it would be a real shame to not, you know, get the word out that these applications can actually help prevent these different conditions and, you know, I think we're just starting this trend of preventative medicine through mobile apps.

So to already so soon kind of nip that trend in the butt by making it difficult to have to go through this regulatory process for a fitness application, I think that would be a real shame.

MR. PATEL: Okay. Dane, do you want to react to that?

MR. STOUT: Yeah. No, I think, you know, certainly intended use as FDA defines it is pretty clear, but I think what we're faced with, I think to play off on what Brian said, is the fact that there's some areas where some technology could clearly fall into the intended use category.

Perhaps the risk factor to the patient is minimal, and so we think maybe there's a way to actually define some of those by risk categories, what devices might fit the intended use space but actually still be able to have regulatory discretion by FDA applied to that.

So I think it's clear. It's a good start, but I think maybe we could take that a little bit further if we use the risk-based approach to enable some of that innovation.

MR. PATEL: So, Leslie, I'm going to ask you a slightly different question on the same topic though, and my question is going to be from a patient perspective. How would you take the intended use and protect patients from taking a suggestion or hoping to help you in a certain area of disease to actually helping you? Can you mark the distinction between? FDA traditionally has been very focused towards if you claim that you're going to help me or protect or secure a disease or treat a disease, you need to prove that or you need to be sure about that.

In cases as you can see in the mobile apps world, I think people are going to suggest that you do this or we suggest that you do that, and it's not actually getting to the full level of claims that typical medical devices would do but sort of supports in that process. How do you react to that and what kind of assurance that patients are looking for from that perspective?

MS. HALL: Well, I think the question you asked is a question that irregardless of whether it's a mobile or website, that conundrum exists today. So today I can go to many websites and get completely false information, and it could be advice that's not true.

At Healthwise, we spend a lot of time in medical review, spend a lot of time being compliant with URAC and other standards, but would not advocate that a symptom checker written for a patient be a regulated application. They're simply not at the level or the depth of action required. Most symptom checkers, for instance, that a patient facing, result in a disposition that is, seek care immediately, call your doctor. It's not diagnosing that you have otitis media. It's simply stating that you might need to seek your doctor.

So there is already precedent set in the web world that takes consumer-facing applications and allows them to suggest next steps or dispositions that are not specifically related to calling out the disease that you may have. So I would not encourage regulation beyond what you currently see in other modalities like the web.

However, that said, there will be increasingly more applications available on the phone. We know that 93 percent of the care that's done today is actually done in the home, either preventative, chronic, self-care, and the rest of the care that takes place is happening in an actual medical setting.

Over the last 50 years, we've seen hospitalization change dramatically. Something that could be done, well, what I had last week would have been 40 years ago a 10-day hospitalization stay. Today it was a three-hour outpatient visit, and a six-month home recovery with applications that could help me on my phone that demonstrate exercise and prevention and maintenance. We also believe, as you have defined, those are not regulated apps.

However, as the phone becomes a more integral part of that self-care, and monitoring is available on regulated applications, the output of those applications once validated by the consumer should be able to be liberated and used in any way that the consumer sees fit, whether it's graphing or importing that data into an unregulated device or a regulated application. The liberation of the data needs to be at the consumer's use and definition. This would be consistent with the electronic medical record applications in a hospital that can receive information from bio and telemedicine devices without any regulation for the way that is used today. So we would encourage that the definition be consistent with the risk level of a home user versus the risk level of a hospital user.

It is difficult to define that bright line because the use cases are often I am a person, I might be a physician, and I also might be a patient all at the same time, and do I have different needs given that use case.

So an example would be a radiology image. A radiology image that's used by a radiologist for clinical review is likely today, and I say today, not able to have a clinical quality review on a phone. However, that same radiology image could be sent and be very useful illustratively to a patient or a referring physician.

So we would encourage that use cases define use for the clinical interpretation differently from use for clinical distribution or informative distribution. So there is some lines that you have to -- it's very difficult.

But largely, we think that trying to first look where this exists today in the industry, agnostic of device, and then say how do we make sure that that now on a mobile device is also regulated in the same spirit as it is in a non-mobile device.

MR. PATEL: Thank you very much. Grant, do you want to take a stab at the intended use question?

MR. ELLIOTT: Sure. I think, you know, as I said in my introduction, I think in some cases it's very clear. I mean, you know, as Brian said, where you have an accessory to an existing device, many of the examples included in the document are very clean, and I don't think anyone would argue with them.

I think the challenge falls in this gray area and, you know, this linkage between, you know, health and wellness and then what actually constitutes as being, you know, responding to a disease state. The reason I used diabetes in my opening entry was because I think it's a great example of the type of disease that out there can really benefit from additional support.

I think the challenge with not getting the regulation exactly right is really twofold. It can go one of either way.

Either in one hand the danger is that you limit innovation by, you know, small organizations who simply are scared away by the concept of regulatory oversight and, you know, the mHealth space is a very innovative rich space. I mean there's lots of companies in here. It's an easy start-up for the most part, and I think there's great benefit from what they can do. So on one hand you potentially, you know, risk that, you know, and point to the innovation.

The flip side to that is, you know, you potentially get into a situation whereby if you don't innovate, sorry, if you're actually innovating yourself, if you're actually put in the compliance zone as well, you potentially get to the sticker shock whereby someone may physically see that they're getting a FDA compliant application, and people will then trust the application simply because it's got the FDA seal of approval, and that may or may not necessarily be any recommendation that the application is actually working like it's supposed to actually work.

So I think from our perspective, really more clarification on those gray areas, more clarification, and I'll give you maybe a couple of examples from some of the applications we have.

If we take the Text4Baby application which is a mobile health application or smoking cessation application, they're predominantly within the confines of health and wellness, but both, you know, pregnancy can obviously lead to diabetes. Smoking obviously is a contributing factor to diabetes. The moment you start enhancing those applications to start taking into account those states or interacting based on those states, certainly you move over the health and wellness state into potentially the ground that we're talking about here, and I think that's very difficult for people to follow and very difficult for people to understand that you're necessarily making that leap.

And so trying to find more clarification allows those people to understand, you know, what is that cross-section? And, you know, as I mentioned and has been mentioned a couple of times here, what is the risk associated with, you know, actually, you know, having a disease state being managed through a mobile application?

So I think really more emphasis on understanding the risk rather than simply just, you know, this is the intended use. I think there's many intended uses that would, within the comm classification, be a disease state, but the risk is such that I don't think that the risk associated with, you know, the regulatory component is so low. In fact, it may actually be impactful because again, as I mentioned, the current situation out there requires action, and if there's an impact or some sort of impediment towards pervading these types of solutions, actually you could argue that that's a higher risk than the converse.

MR. PATEL: So I'm going to skip Dave for a second and just break the rhythm here a little bit, and the only reason I'm doing that is, Dave, I want you to take your investor hat and put it on and look at these comments and say -- I'd like to hear your overall reaction to how the investor community would look at the different perspectives these folks are coming from, the disease state and informational liberation, the intended use clarification, the gray area.

So I'm going to go to Kerry and ask a question about, which you started off with talking about, making it clear what this gray area is and is not. How would you propose doing that?

MS. McDERMOTT: So first of all, I do want to say that everyone's brought up some really good points, and I like where you are going with, you know, making these decisions around intended use.

So one of the keys is then how when the FDA decides something, how do you communicate that out so everyone learns? So that, you know, five investors might have the same question. I think there's an opportunity to drive more transparency through your website.

So if I did a rewind and said I don't understand intended use -- I needed Intended Use 101. I would love to go to the FDA's website and find a two-minute video of Bakul explaining to me what exactly that means. I mean I say that partially in jest but, you know, there's so many documents and so much printed material, that's great from a legalese perspective, but I know that, you know, when I sift through this, it's easy for me to pick up the phone and in 90 seconds be, oh, I get it.

So I think that you guys have an opportunity to really leverage yourselves better by using a different type of media to say, here's a little snippet on how we can explain what intended use is. And then as you've had conversations with different companies and investors, innovators, so, you know, we have seen, you know, these five similarities across these apps, and here's what we decided, you know, and I think it can be done in a manner that doesn't give away anything proprietary to a company but to say here is a common question, and here's a common answer platform.

And then in going back to the basics of simple tools, you know, if I'm a new innovator and as we brought up the point, in the mobile space, that's where innovation is really fresh and potentially folks less familiar with healthcare and certainly the FDA, you know, as simple checklist would help me. You know, can you actually map out a decision tree that helps me say, if I answer no to this question, then I don't have to, you know, continue. I know I'm not a mobile medical app. If I say yes here, and then what are each of the steps so that I finally understand, you know, at the end, no, I'm safe. Yes, I'm definitely under regulation and, you know, here maybe this is where I do need to actually get some follow-up expertise.

So I think by just revisiting the basic tools could be tremendously helpful.

MR. PATEL: Thank you. So back to you, Dave, in terms of an investor's perspective. We heard disease state. We heard informational. We heard the clarity on intended use, and then we heard about how from Kerry and how to make and communicate that better. Brian talked about this world growing tremendously.

Are you seeing that? Are you seeing the demand for investor dollars to go to folks in this perspective? Is there a way we can consider that as part of the definition ultimately with the goal of clarifying the definition or establishing the right scope? So could you comment on that?

MR. EICHLER: Well, I'll certainly try. First of all, all the comments have been great.

I would say, you know, some of what you read in the guidelines, you know, may be interpreted as, you know, there are applications that are more sort of, you know, consumer oriented. There are applications that are more provider oriented and, you know, at least from Psilos' perspective and from my perspective, you know, we don't really look at the world in that way. So we're investing in technologies that enable, you know, a platform that will, you know, promote consumer engagement but also involve the provider, also involve the payer. It's more of a, you know, care coordination, care management platform kind of approach.

So the areas that, you know, we would want to get more clarity around is, you know, when you're integrating data from, you know, electronic health records or personal medical records, to enable that kind of a platform and, you know, where do you sort of hit the tripwire of, you know, now you're sort of over the line of diagnosing something or you're over the line of making some kind of therapeutic decision.

And when I said in my earlier introductory comments, you know, in terms of the continuum of this, you know, spectrum, you know, that's where I think the guidelines are not as clear as they could be.

You know, I'm not answering your question directly. Your question is, you know, are investors seeing a lot of this innovation? Yes, we're seeing a lot of innovation in the mobile health and telehealth area, most of which is not investable right now. They're not, you know, particularly a lot of the applications that are aimed, you know, purely at consumers don't really have business models around them that would sort of meet our criteria as far as, you know, an investment case would go. But the important ideas in healthcare reform, accountable care organizations, patient centered medical homes, you know, these ideas are going to require innovation that includes, you know, mobile health and telehealth component in terms of care delivery, care coordination.

So those are going to be important ideas, and those are going to be important investments for healthcare IT focused investors like us. So, you know, I'm not sure if that answers the question directly, but --

MR. PATEL: I think it does, yeah. So I'm going to do one more thing, a discussion with you in terms of I want get your feeling for the current definition as is defined as narrow as it is, and I'm sure there's some fringes of gray areas around it. Does that help you as an investor?

MR. EICHLER: Well, I mean conceptually it does. I mean I think the concern is that, you know, the potential for this kind of mission creep by the FDA, in that you're holding this event to sort of define a "tip of the pyramid" kind of approach, but I think, you know, all of us on the Panel would agree that this is an area that's going to innovate very, very rapidly and, you know, what we might have predicted two years ago or what we might predict two years from now is, you know, pretty unknowable. I think it's going to be a very rapidly developing space.

So, you know, there is some language in the guidance that sort of acknowledged the attempt to include regulation around medical software that was ultimately aborted because it just was developing way too rapidly for regulators to keep up, and I think we have a potential that the same thing could happen in the mobile space. I'm not sure.

MR. PATEL: Right, right. So, Brian, going back to you in terms of what Dave was talking about, being able to capture the future trends on this marketplace, what could we do differently in terms of scoping it right that will allow us to be scalable, not just, you know, two years from now but have the flexibility while taking into consideration the mission creep that Dave just talked about and I think Leslie alluded to as well, and the mission creep is a question that I'm going to get back to you, Dane, on that in terms of getting us back to the definition of a medical device. So you can chew on that a little bit.

So before we do that, Brian, how would you react to that?

MR. DOLAN: Yeah, I mean that's a tough question for me. I guess just two things first is that in terms of the growth that we're seeing, we're seeing linear growth right now. Every category or subcategory we can come up with for the last three years that we've tracked the Apps Store, it's doubling every year.

I would say that the issue I alluded to before is the biggest one that I see in terms of the definition as I read it, two years out is going to read like any website. So I'm not as familiar with the guidelines as they apply to websites in general, but the way I read this is these guidelines are now bleeding into how you would regulate any website that would have say a medical calculator on it because I'm now, I can use that on my iPhone, and whether or not it's tailored for the web I think is a distinction that's not going to make very much sense in a few years' time.

So, you know, to solve that issue I guess is a tough one. I'm not really sure. I guess that would really depend a lot on what the regulations look like for just regular websites and how those are different from mobile medical apps.

MR. PATEL: So going back to the definition there, Dane, I mean since you're the most familiar of all of us, maybe Grant, too, reacting to Leslie's comments, liberation, considering the discussions we were having about the trajectory of this thing, heading into direction, and really the guidance is skirted on the issue of it's a website or not a website or mobile. It did skirt on the issue, and I can acknowledge to that. We didn't come out and say it's for all applications, for all websites. By definition of law it would probably explain to us.

How do you see that going? How would you react to Leslie and how would you react to Brian's comment and Dave's comment and Grant's comment for that example? Because it does involve texting as well. At some point in time, there's a trip point where good things can spill over into the whole benefits/risk discussion of patient care at some point. So how do you define that line of saying when does it cross over from benefits to be overshadowing the risk and when does that tip over to becoming risky than more beneficial? So can you sort of react to that?

MR. STOUT: Sure, you know, I'll make my best effort to respond to that, Bakul, but, you know, I think you're absolutely correct on the intended use.

I guess as a bit of a side note, we've been working as part of the mHealth Regulatory Coalition which is an organization, a broad group of industry collaborators trying to help provide feedback to FDA on some of these challenges, and I think what we're really looking at here is the acknowledgment of the insertion of a network into, you know, the traditional medical technology space. That's been around for a while, but it's moved at a very rapid pace.

I think to put it into context, if you go back, you know, even three years ago for the MDDS draft guidance, the idea of an Apps Store didn't even really exist, right. There was no Android platform which is now being rolled out at a half a million units a day into the consumers' hands, and they're going to be looking for apps that include some with medical technology.

The monetization mechanism in 2006 for smartphone technology as it existed then was ring tones. I don't hear anybody talking about ring tones anymore. It's pretty passé.

So looking out four to five years, it's difficult. So I think it's really this -- the approach, I really applaud this modularization and the speed of getting this guidance out is a great start. I think the challenges will be, I think the accessory role also sort of complicates the intended use piece because now you've got people kind of wondering, well, you know, am I the orchestrator of a multitude of medical devices that could connect to my phone, if I'm a phone manufacturer?

So I think, and I'll go back to sort of my key points that I'd like to make sure I communicate is this idea of the modularization and defining this, and then tightening up some of the definition for folks that are coming in from a different perspective.

So a technology audience, and I get a lot of questions about, well, when we talk about web service or web support, what does that mean? What standards is FDA referring to? You know, how do I know where those boundaries are?

And I think, you know, kind of working back from an objective, if we were to say whether the guidance was successful or not, I think we would determine that by saying nobody would be surprised that they become regulated as a medical device. I think it would be clear enough, right, and I know that's your goal, that nobody say, gee, I had no idea that I would be, and I think to Kerry's point, I think it's going to require some additional, you know, training and thought process.

And my last comment on that is I think we look at this to say there's a definite need for some additional product classification, and I'll hold up the MDDS final rule as a good example of that where, you know, it's actually a medical device classification. It's certainly low risk. So you put it into the Class I, but it actually provides some means and mechanisms to provide interoperability and communication between devices.

So I think that's kind of the right approach and perhaps trying to leverage that model inside the mobile medical app space and looking at some, how do we classify some supporting -- here?

And then one last thought I'd like to comment on that. I think, you know, really embedding a lot more of the information science space into the regulatory science initiatives that FDA has in place, to say we're going to acknowledge some of the sophistication and quality service capabilities that, you know, the new technologies particularly in the mobile space are going to bring to bear on this space and, you know, really incorporating industry standards and that kind of approach and doing this more for a technology audience will be certainly helpful, and I would again acknowledge the need for more clearer intended use definitions and training for audiences that aren't familiar with it.

MR. PATEL: So, Leslie, I'm going to ask you, Grant's purview, he's been involved with Text4Baby, how does that fit into your thinking in terms of, and taking us back to the guidance itself and helping us sort of define that because I have specifically in the guidance not mentioned about texting? So how would we sort of feel that out? Should we provide the clarity, Grant? Let's have Leslie respond and then kind of have you sort of follow up for that.

MR. ELLIOTT: Maybe we can split it?


MS. HALL: Hear, hear on that. I think that there is maybe a layer missing in the definition, and that's the interoperability layer, which is not necessarily regulatory based but standards based. So that as we look at an application being used, for instance, I might have a regulated device that is an insulin pump and provides information out of that pump. It states that I am now in a critical range. That information then can be going to an interoperability layer that would immediately do many things. It could trigger a text event that texted my caregiver, my home caregiver, my loved one, whoever I designate, or I might send it to an application that now provides new information to me because it's gathered information from multiple applications. I have my insulin pump. I have my thermometer. I might have weight. I might have the water that I consumed in the last day, anything that might be material to my care coming from several different devices, that once combined, could trigger new events, a text, an appointment, a map location to tell me where the nearest emergency room is.

There are many different applications that would be dependent upon the data coming from regulated devices. So that interoperability layer needs to be consistent and coordinated but perhaps not regulated.

An example might be the Office of the National Coordinator is now defining the interoperability of information using the continued care architecture or the CCD, the document architecture that allows for context to be shared across multiple applications in a common way.

So as a patient, my source of truth is who I am, what I am, my current condition, my preferences, my values, my current decision-making. I might have a bias that says I am pro-surgery. I might have a bias that I've stated that I'm pro-nutritional approaches. I might have a document in my phone that is my advanced directive, that is considered now secure and authenticated through other standards that are included out of the IT side of the world. I'd like that to accompany now the information coming from that insulin pump. It gets sent to my doctor with my appointment. I'm at a critical level, and it indicates that the doctor should have my advanced directives attached to that appointment request.

These are all real world examples of what's done today. So I would encourage interoperability to be focused on standards, and the data once coming from a regulated device can be authenticated by the consumer or the user that says, yes, I agree that is true. Once that takes place, it should be able to be moved, so that triggering events like texts can be outside the realm of the regulation, obviously should be secure but not prohibited or regulated.

So I think that bright line becomes much clearer when you add an interoperability layer. When you do not have that, I think it's opportunity to be overzealous in the regulation of the devices, again many things that are used in a hospital today, inside an electronic medical record coming from devices. Although today the FDA could regulate or enforce the regulations inside an EHR, today in general that is not done. So look to how things are being done currently and try to stay within that purview.

So I would encourage an interoperability focus and definition that states how data can be used so that things like innovation -- the Text4Baby has done amazing things in the third world and all over the world, and it is very difficult to do here because of HIPAA regulations, because of other things, and so we've lost an opportunity to use a highly innovative tool to keep some of the most needy patients healthy in their prenatal care. So it's not consistent with good medical practice to prohibit consumers from being informed due to overzealous regulation.

So I guess that's a long-winded answer to your question. I'll turn it over to Grant.

MR. ELLIOTT: Yeah, thank you. I think the, you know, I was looking through some of the comments that were submitted prior to today's session, and one of them struck me as interesting. It said that if you do a Google search for a BMI calculator, you get something like over 9,000 hits, and going to the point that Brian mentioned earlier on, I mean that's just the website. It's an unregulated tool that's in many, many websites and, you know, technically you can access that through any mobile device today, and that's only going to increase.

I think one of the challenges that we have is that the more focus on regulation of some of these gray areas as we talked about impacting innovation, the danger is that if you set those rules out there and so many people aren't following them, they become unenforceable, and therefore the regulation itself becomes, you know, ineffective, and I think that's the challenge here.

And for me, I think one of the premises that maybe could be changed within the current guidelines is there's a default to regulate approach in the way that the regulations are written.

And as I said, you know, like for 90 percent of the use cases are defined, I think it's very clear that that regulation has to be in place and has to be effective.

But as we've talked about consistently, there's this risk model that we need to seriously look at, as to what is the risk of allowing something to remain free of regulation versus the need for it to be regulated? And, you know, my perspective is that that default should be to, you know, take it on a case-by-case basis rather than have this blanket as we define it, it falls under the jurisdiction until we prove otherwise or list it as otherwise; as opposed to, you know, having a very clear risk statement that sets some clear guidance and says anything within these guidelines should actually default and not be regulated; however, we reserve the right to come back to that at some point in the future if we subsequently find that there's an issue or a problem.

As I said, you know, risk is not even. If you start the risk conversation is that there's no risk to begin with, then I can understand why you, you know, would maybe want to be conservative in your approach, but you know with that, you know, 35 percent of Americans as I said, you know, are in the pre-diabetes stage. We don't have time to be waiting for, you know, regulations to be basically cleared. We need many, many companies innovating to try and help that situation, and I think it can unfairly penalize organizations who try and play things the right way, who try and go through the right steps, who try and make sure they're compliant with, have power with FDA, et cetera, versus, you know, many of those -- and websites out there that are basically either pervading some sort of risk assessment, some sort of calculator. I mean, you know, as we've mentioned already, you know, advice and guidance itself can have inherent risk if it's not distilled properly.

So I think, you know, my takeaway and, you know, what I would certainly propose is, instead of this default that's regulated until we see otherwise, there needs to be a new classification around risk and that if, you know, there are certain risk conditions that we believe that again pervades the greater good to the population and the population's health, then I think the default should be that until proven otherwise, they don't need clearance or they don't need regulatory oversight, and then obviously on a case-by-case example where we see, you know, misuse or abuse of those situations, then we step in. Otherwise, I think, you know, as I said, putting those guidelines in place I think is simply unenforceable given the technology challenges that we've already outlined and, you know, the effect of proliferation of those types of solutions already.

MR. PATEL: Absolutely. Thank you.

MR. EICHLER: Let me give another real world example because I think, you know, these are great examples in terms of kind of a care management, you know, population disease management, these kind of applications.

We also have a company that has a patient safety platform in a hospital setting that has been repurposed on an iPod Touch and a tablet platform and, you know, maybe this touches on some of the intended use discussion from earlier but, you know, really the device, if you will, the platform, I would call it a platform, not a device, but the platform, you know, is really almost like a middleware kind of application, that it's more, you know, a repository and, you know, it's an interpretation of kind of various, you know, sources of data around the patient so that, you know, providers can avoid frankly avoidable errors in the hospital, which is a big problem. We know medication errors, hospital acquired infection, all of these things that fall under the "never events" that have, you know, that have really become a big issue in the last couple of years.

So for this particular company, the handheld, part of the platform, the iPod Touch device, a big part of the utility of that device lies in the fact that it's a barcode reader, and one of the applications, you know, in addition to ensuring that medications aren't given in error, whether it's, you know, you want to make sure it's the right patient, the right drug, the right dose, the right time of day, all these things, there's also an application in the platform that involves ensuring that if you're transfusing blood, that the blood matches the patient, and the way that's done is through this barcode reader.

Now, it may surprise many of you in this room, because it certainly surprised me, that the FDA is giving guidance that they want to regulate this as a Class II medical device because the barcode reader is basically reading the barcode on the blood pack and trying to match it up with the patient.

My response to that was, you know, well maybe, you know, should my eyeglasses be regulated as a Class II medical device because it's, you know, the same kind of idea which is it's not -- the barcode isn't intending to impact, you know, anything mechanical or anything sort of physical in terms of the administration of the blood. It's simply a check that, you know, this type of blood matches this type of patient.

So these are the kinds of things that create, you know, confusion and uncertainty in the investor world because it's something that seems to me as a layperson, you know, kind of improbable that the FDA would take that position with respect to this specific application of the platform.

MR. ELLIOTT: Can I just add? I think that's a great example of how looking at the risk profile as being, you know, does that inherently increase risk or decrease risk? And I think having that second check, I think everyone would agree, inherently decreases the risk of something going wrong.

To regulate that type of application on the basis of the fact that there may be something that goes wrong with the reader, I mean I can understand that perspective, but again it's there as a check and it's basically, you know, going to actually reduce the risk of probably doing this manually, and I think that whole risk assessment has to be done and it really has to be done not just from a blank sheet. It has to be a basic understanding of inherent risk of the current process.

MR. PATEL: Okay. I'll let you respond to this, but how would one look at the use of a mobile app or a website or anything else and determine to Grant's point in terms of determining that risk level or the use level or, you know, to Dave's point about is it similar to eyeglass? By the way, that is, some parts of it are regulated as medical devices today.

So, yeah, I surprise myself every time I look at some of the regulations and products that go through FDA and things that, you know, I use the example of tongue depressors all the time. Tongue depressors are regulated as medical devices.

So having said that, it's difficult to sort of understand, take the risk problem out that you were talking about Grant, and coming up with a generalized rule to say, if they are this risk level, you're X device. So let's hear your reactions, Kerry. You've been thinking about this for a while.

MS. McDERMOTT: I have to say I think it's not fair that everyone else got time to think about their questions and then mine just come direct. So anyway, moderator complaint. Just kidding.

No, these are great and very important questions, and I think on a lot of levels there's kind of a bit of a -- we can put a common sense filter on a lot of these things. What I find, and I will sort of answer your question.

When our discussion started, we were very much anchored in what is intended use and what's the definition of that, and how do we know whether we are inside or out of that box of regulation, you know, putting the fear of death, you know, of being inside the box of regulation. And then as our discussion has morphed, it's really been more about risk and a risk-based paradigm and thinking about different types of classification which would actually imply that there are potentially a lot of things inside this box, but a big piece of that box is that area for enforcement discretion.

So as we think about these applications, you have to look back and say, is a person going to, you know, what is the risk of malfunction of this? So how much harm is coming to the individual?

And I think that, by and large, there's a real opportunity here for the FDA to say that all of these things relate to health, they relate to very prevalent conditions today like diabetes, obesity, you know, if someone had an app to cure, you know, sleep disorder, I'd be all over it, right. And you have an opportunity to say we get how these things work. We just want to know that they exist, and we're kind of hands off, you know, we're just going to let the market decide what effective apps are or not, and the only way that that's going to change is if something really bad happens, you know, or something appropriate to that. You know, we've looked at the risk profile and, you know, if I miss, you know, a weight calculation day, chances are I'm not going to go to a hospital, right. Whereas something, you know, and I think we also kind of sometimes forget that for these apps related to health and wellness, we always think about the most dire consequences. If I am that critically ill, I am probably not the consumer using the health and wellness style app, and so we could focus our resources elsewhere.

MR. PATEL: That's great. So one of the things that guidance does is sort of, and you saw my pyramid, it talks about the tip of the pyramid and enforcement discussion, and then intent for the enforcement discussion was purely to talk about if things go bad, we will take an action. So referring to your, Dave, your suggestion, when things will change. I think that's what we did. Maybe that needs to be more clearer in sort of pointing out, too. I think I'm hearing consistently that what is enforcement discretion needs to be answered more directly. I think you've done that in a very, like two sentences, but I'm not sure that -- I'm sure lawyers in the room and maybe definitely not on the Panel here I think, but lawyers in the room would probably agree that, yes, that is very clear, but on the other hand, I think it needs to be clearer for the common folks. So, Leslie, you have --

MS. HALL: I just want to comment also, when you look at risk, there are many types of risk that are already inherent in the health system. If I'm a physician, I have risk associated with malpractice. I have risk associated with my clinical judgment. I have risk associated with work I do every single day. And so those risks I choose how to mitigate, and that type of assessment needs to be considered.

So if the risk of regulating this device is what happens if this goes bad, well, if it's also part of other areas that risk covers, is it really part of that application?

So, for instance, if a radiologist reads an image on a phone that's not a high level DICOM quality image, and makes an assessment from that, he or she has a lot of other risk layers on top of it, that would preclude that person doing that. However, if they're in a situation where that is the only available resource to read a radiology image and the risk is greater to the patient to not -- inaction is greater risk, then perhaps it's useful.

So remember there's risk associated beyond just the application that helps to mitigate control and somewhat temper application usage.

MR. PATEL: I would like to just give you a little flavor of what discussions goes on inside FDA. We talk about this day in and day out, and that's exactly the discussion we talk about is, when is it beneficial? When is it not beneficial, and is it risk? And some of the discussions I've been part of and have heard people talk about goes to your point, Leslie. I think it's very well taken in terms of can it actually provide more benefits to the patient in the end? And it's all about patient safety. It's not about regulating. It's all about patient safety at the end of the day.

MS. HALL: But the biggest safety we have on the phone is dialing 911. So we would not want overburden of regulation prohibit, for instance, if I had an application that was clearly biomedical that was monitoring my heart and that application found a critical event, we'd like that information to leave the application and trigger a 911 event call if that data warranted it without intervention by the person, but the 911 call and the movement of that data should not be regulated. So it's very difficult, and I commend you for asking all of these hard questions.

MR. PATEL: All right. Thank you. I just want to remind the audience here that if you have questions or comments for the Panel here, I encourage you to just write them down, and one of my colleagues here can take that and bring it to me and we can go ahead and discuss that as a part of the Panel discussion as well. Do I see anything going on there? No.

That's good. So I'll continue with my questions then. I have a lot of them you can tell. (Laughter.)

So I think I want to take us back to the definition itself. I think there's two big areas; what we have defined at the top of the pyramid fits into those two criteria that we have defined. Enforcement discretion is things that don't connect to or don't become an accessory or transform.

Is there any clarity we can provide to those two parts, the accessory, when they connect? I know we think about this all the time. So it's very clear to me, but I want to hear reaction to is it clear especially from Brian who sees all these apps and sometimes even reviews them I think, to say is that clear its connecting? Are we leaving some fringes out there that people have a question in their mind that the connection is not there implicitly or even the transforming part because some people may think transforming a screen to do, you know, a psychological evaluation which happens to be a touch screen or even using the microphone on the smartphone to do some other evaluation is part of the device. So it should not be transforming. So is that something that you see that needs further clarity?

Because the stethoscope example that Dr. Maisel gave is exactly that. If you take a microphone which is what a stethoscope does and listen to your heartbeat, that transforms whatever device is on the other end, whether a computer is on the other end of the microphone, into some sort of stethoscope because you're using it as a stethoscope.

Is there something there we could do as part of this definition to provide that clarity or have more verbiage afterwards or have some other examples that would provide that clarity? And I'll probably just -- anybody who wants to respond to that, that's fine.

MR. DOLAN: I would just say I find that part to be very straightforward. I think if it's using any part of the device, any functionality and in affecting the body or it seems like -- I can't -- it's hard for me to come up with examples where it's doing that, and it doesn't fall into the guidelines. So, you know, if you have any examples where it doesn't actually fall in, I'd actually be curious.

MR. PATEL: Yeah, I'm looking for that. When I hear Leslie and I hear some other folks who ask me questions, it seems that there's some confusion, and I'm not able to put a finger on it.

MS. HALL: But that microphone is not being used solely as a stethoscope. So if the regulation of the use as a stethoscope prohibited that microphone now to be used in any other application that isn't medically related, or new features came out for that consumer that enhanced the use of that microphone, and those are not medical applications, how does that help?

So perhaps what's regulated should be the device that receives that information to validate is that, in fact, a valid signal, is it truly readable as a stethoscope and some sort of authentication mechanism that goes back and forth rather than having the microphone itself, which will be used again. It's a phone first. It will be used by many other applications, and we don't want to prohibit innovation in other areas as well.

So I guess I would challenge that the microphone isn't as obvious as we might think because it's not solely used as a biomedical device.

MR. PATEL: Dane, do you want to respond to that?

MR. STOUT: Yeah. No, I think, you know, Leslie brings up a good point, that we're going to have these devices in the future. So the best example right now is let's look at the vast majority of digital photos stored on Flicker now don't come from cameras. They come from cell phones with cameras.

You know, the GPS market is in disarray because GPS has become a function, and there are a few folks out there predicting that medical technology will become a function of a phone, but I do think, you know, I do agree with Brian that I think back to the intended use, Bakul, if somebody knows that they want to make a stethoscope and utilize one of these features that's inherently built into multipurpose device, then that's a pretty clear statement.

I think the bigger challenge is the accessory rule and, you know, as we move towards this time where everything's going to be networked together, I think there could be some delineation between, you know, what I think was the initial intent was, you know, if you think about a catheter tube and an infusion pump, it makes sense that you want a high quality accessory connected to a device that's delivering that kind of treatment capability.

On the other hand, you know, if you reverse that and you have a device that connects out through phones and networks, it becomes very complicated very quickly. So I think the accessory rule is definitely a challenge in this space why I think, you know, given how long it takes and how quickly things move in the technology space, perhaps some product classification definition would be more helpful.

And I also think, I like your idea of expanded clarity around the enforcement discretion, perhaps some explanation of what that means. It doesn't mean that, you know, hey, you can do whatever you want. It's not the same as unregulated, right, but it really says that FDA's watching this and is choosing not to do anything at this time. It could help provide a lot of clarity.

MR. EICHLER: It's interesting. I think for me, you know, I'm sort of in the third bucket. I didn't necessarily have a problem with the idea about regulating mobile apps as a medical device if they're trying to replicate a medical device. I didn't have a lot of issue with language with respect to extension or extension of a medical device.

I think where I find the most uncertainty in the guidance is with respect to the intention around electronic health record and other, you know, patient data and how that, you know, just, you know, my perspective is that, you know, leveraging that data in care management platforms is going to have both a near term and a large impact on healthcare delivery and, you know, our ability to lower costs and improve quality across the healthcare system. And on the one hand, there seems to be explicit language in the guidance that says that you do not intend to, you know, to regulate the EHR functions with respect to mobile apps.

On the other hand, you know, my perspective is that, you know, EHR and patient medical record data is going to be, you know, a part of these mobile applications, these telehealth applications, in terms of these care delivery models going forward.

So that's where I have the most confusion about the guidelines, and when I said at the very beginning, this sort of, you know, continuum along the spectrum, you know, where that line is is very unclear because there seems to be conflicting statements in the guidelines with respect to, you know, patient data.

MR. PATEL: Interesting. Okay.

MS. HALL: Also patient data that's generated by the patient as a source of truth, they are the source of truth. There is no regulation required.

MR. PATEL: Anybody? Kerry, Grant.

MS. McDERMOTT: I think that, you know, we're kind of covering a lot of those same themes here, but I would say that obviously, you know, the more we can do around enforcement discretion and in that simple, you know, give me a video. What does that mean? And I think it's okay for the FDA to really start to socialize the concept that you don't have to be fearful of regulation, and the more you can say, we just want to know what you're doing because that's our job, and it helps keep patients just like you everyday safe, and we're only worried about it when you reach this level and, you know, whatever instance it is, we're worried that these things might happen. And let people know how they can alleviate your concerns. So just be clear about, you know, the FDA's intended use.

MR. PATEL: Sure. That's a great -- putting it back as intended use, right. Awesome.

MR. EICHLER: Yeah, I mean just to add to that point. I mean you made a comment earlier on about enforcement discretion, you felt that most lawyers were aligned with the concept and idea. I'm not sure what lawyers you're dealing with because I'm not aware of any lawyers that like the word "discretion" in any language or text.

You know, I look at the enforcement discretion and it goes some way towards I think, you know, a proposal of having a non-regulated until proven, but I think the language needs to be a little clearer. I mean the way I take it is, you know, a bit like, you know, you done 55 miles an hour around the Beltway. That's the law. That's how you have to drive it, but most people are driving at 65, 70, and for the most part, you know, if a patrol car or a police car sees them, they basically have the discretion not to pull them off. That's great until suddenly you just decide you'll get one police officer who's bored and wants to pull you off for three miles an hour slower than everyone else is going which, you know, when you drive a Prius can be quite embarrassing. (Laughter.)

So I think enforcement discretion as it's listed at the moment is a nice like -- in terms of the fact that, well, we're not necessarily going to say we're going to regulate. However, we might. I think you have to bear in mind that, you know, the business cycle is such that, you know, a company can be quite a way down a business cycle, have invested a lot of R&D dollars and gone through a very comprehensive product launch, and I think, you know, investors would probably agree to go down there and then risk the possibility that FDA at some point are just going to come in and say, well, we're now going to exercise the discretion, that's regulated now, I think is a significant risk from a business perspective.

Again, I really do want to reiterate the point that's been made by many people. I mean really this is from the advocate of the patient perspective, and so I think, you know, the discretion that should be given should really again go back to this concept, and I keep saying the point about the risk model, you know, if we think that something increases a patient's risk, then clearly it needs some insight, some looking after, but if we think it actually reduces the risk, then, you know, I think just having the caveat of enforcement discretion has to be a little bit clearer. I think it really, from my perspective, should be a far more blanket that, you know, unless there's specific evidence to suggest that it needs to be regulated -- I think these things at the low risk should be fully carved out and then only if an instance or situation occur should it be revisited rather than we just have the right to regulate this at any certain point, and if you happen to be the one that gets caught, then tough.

MR. PATEL: I'm worried about the guy who goes in a Prius zigzagging through traffic on 495. So --

UNIDENTIFIED SPEAKER: At 55 miles an hour.

MR. PATEL: At 55 miles an hour. We're at the end of our Panel, and I'm going to officially open up for Q&A from the audience as well as from the Twitter feed. The hashtag for this Panel is going to be FDAmHDef, and that stands for mHealth Definition, as we call it. So again, that's #FDAmHDef. Please go ahead on Twitter. I do have -- I was waiting for one to come, but I got like five at the same time. So we'll just go ahead and use these questions.

And this is for anybody on the Panel to respond to. So the question is when does a self-management app go from being under enforcement discretion to being a regulated mobile app? What if self-management is intended to manage a specific condition?

So one thing I could say here very clearly is I don't want to be the only one answering these questions. This is for the Panel to sort of respond to get a perspective. Hopefully we'll get to the point where we'll glean from this the confusion that's out there and help us sort of get to the clarity that we need to be in the definition. So go ahead. Brian.

MR. DOLAN: Yeah, I can probably just get the easy -- the duality there between a chronic condition management app that offers some sort of guidance from the app developer and also there's a lot of apps that are really just logs. So use an app where you just enter in your blood pressure data or enter in other information. The way I read it, a lot of that just simply hears the data, doesn't fall under the guidelines, but if there's any other sort of information in there, then we start to get into potentially under the guidelines, yeah.

MR. PATEL: You mean directing somebody to take an action or something?

MR. DOLAN: Yeah, anything beyond just your logging.

MR. PATEL: Anybody else want to respond to that?

MR. STOUT: I would just say, you know, Bakul, what we're seeing is another quickly emerging phenomenon. Folks on the West Coast probably in particular would be familiar with this notion. There's actually an organization called the Quantified Self where people are really measuring a lot of their, you know, biometric data and other, you know, all of the sleep patterns, everything, because they can, all right, and they're really not sure how they're going to use that data.

So I think at this point, you know, we'll circle back to the self-use. If it's for your own edification and it's like I want to see how possibly long I can live, great. If it's, you know, the manufacturer of that product starts to move towards, well, now you can take this data and share this with your caregiver to help you with a specific disease state, I think we're back into the, you know, the intended use definition. So I don't think we waver too far from that but, you know, there's certainly this emerging phenomenon that we have to take into account.

MS. McDERMOTT: And I would somewhat disagree with data going back to the physician needing to be regulated because if a patient -- that question has defined it under self-management, meaning it's data that I've received or created as I manage myself, in care that I manage, either by myself or in conjunction with others. When I send data from my phone to others, I am that source, even if I'm compiling it from multiple medical devices. So I think there is some gray area there.

But self-management will soon be collaborative care as we have information available between clinicians and patients and all participants of care. Collaborative care should be encouraged through mobile applications.

Today the patient's voice is largely unheard, and if we are going to move into improving costs and quality, the patient has to be considered, and the phone is the most intimate and immediate device that we use, and having that information to be able to be shared is going to be very important to ongoing care management or collaborative care. So the flow of information, again back and forth, has many different parties involved and should be encouraged.

MR. PATEL: Sure. Sure. So I would request just to keep our comments back to small. I'm getting inundated with -- I mean it's only five here, but I'm getting inundated.

So there's one comment. I'll just go over that real quick, and then there's a question, and I'll just follow up with that.

One comment here is, for medical device manufacturers, intended use is very clear. It appears that companies entering regulated software environment are confused and may just be inexperienced. Companies have to clearly understand the nature of the claims they are making. That was just a comment.

Here's a question. As we shift from -- medical -- to modular or point solutions integrated into a solution, who should be responsible for compliance? Is it the hospital or healthcare provider, the MDDS manufacturers, medical device app maker, or the phone maker, or all of the above?

This is actually interesting. I should have brought this up before. I've been getting some calls regarding this in terms of why is the phone not regulated? Why is the phone that I use as part of providing solution for medical purposes not regulated? How come they don't have to meet any standards?

What's your reaction to that? We'll start with Kerry and then we'll walk our way down here.

MS. McDERMOTT: And so there is the big debate around, you know, general communications platforms, and I think that you have to take these almost on a system-by-system basis. So that's a great question and it, you know, teases out a lot of the issues, and I think that, you know, one of the things that almost actually scares me about that question is it sounds like an argument against interoperability, which is so important to the healthcare system moving forward and having better care coordination and treatment of patients.

But, you know, no secret is that the liability is the 800 pound gorilla, you know, consideration when things do, you know, go wrong, when it's a system. So to the extent you can break that system into modules, and I think it's more about understanding the physical layers of systems, so as we think about how data is actually transferred, and then, you know, in terms of the infrastructure for it as well as the digital layer. So what is the actual data that we're trying to move from one endpoint to another?

But, you know, I want to harken back to something about the need for collaborative care because I think this relates to that. That definitely has to be the way of the future, but I think we also have to remember that all of these things are just becoming more data points that the clinician can ultimately use as far as, you know, patient data and patient submitted data, and again, you know, the treatment decision will be made together but, you know, the source of data is something that the doctor has to take under consideration as well, whether it's from the patient or from the device, and they will then, you know, work to make the care decision.

MR. DOLAN: Yeah, I would say that the phone in certain circumstances, we discussed those circumstances, is regulated, I mean as pieces of it are.

MR. PATEL: Right.

MR. DOLAN: So I mean when it's relevant, the actual hardware, the actual offerings, the light, the microphone is regulated under these guidelines. So I don't -- I mean I think the answer is it already is.

MR. PATEL: Right. So I guess it's not clear enough for people who have not been sort of looking into the details of it. It's a very dense document, I acknowledge that, and somebody has to really read into it to understand that.

MR. STOUT: Just very quickly, Bakul. I think, you know, that's a great example of the different components, the different suppliers, the infrastructure, that Kerry's referring to. Regulating infrastructure would be extremely challenging.

So, you know, from our perspective, we think it really gets back to this idea of claim substantiation. So whoever's making this claim that it might be a medical device, really needs to understand, you know, what phone devices they're going to support, not necessarily the phone manufacturer. If they're not involved, if they're just selling phones and somebody's providing device utility through that phone, that's not their responsibility. It remains the responsibility of the person making that claim. And I think that's, you know, the only reasonable way to go forward.

MR. PATEL: Right. We have a question.

UNIDENTIFIED SPEAKER: I actually wanted to comment. I can speak loudly. So I actually asked that question, and I'm not making an argument against interoperability but actually for interoperability, but the challenge is when you have all these different components that are stacking on each other, if we're talking about standardization and modulization and so on, I have little kids, they play with Legos and Duplos, right. They're standard. They're interoperable. You can stack them any way you want, but you can make a very stable tower or a very unstable tower with standardized and interoperable devices, and the challenge is, who is ultimately responsible for making sure that that tower that you made is actually safe and effective and it works as appropriate, when you're using all these components which include health information, technology and phones and applications, and so on? Somebody needs to be ultimately responsible, and that was the question, that there seems to be lack of clarity in the ecosystem as to who's ultimately responsible for that.

MS. HALL: The user is ultimately responsible for that because we cannot predetermine infinite use of applications, and so if you regulate that interoperability for fear that your Lego model is going to fall, that's like regulating common sense. It doesn't really work. So we have to be careful about I think over-regulating that tower and making sure that the interoperability exists so that a tower can be made and defined by any user. Its stability will still be based upon the competence of the user. I don't know otherwise how to do that.

MR. PATEL: I have one other question, and then I have one from the feed here. So go ahead.

UNIDENTIFIED SPEAKER: Great Panel today. Thank you. I'd like to add that I think to some degree patients have already voted on this. You know, patients know the difference between the WebMD and Wikipedia and Men's Health Magazine, and when they talk to their doctor, and I think to some degree we should acknowledge that.

And so if, you know, thinking about the Text4Baby example, if Text4Baby is sitting on information that can help pre-diabetic moms to not develop diabetes, and they can send that out, we should encourage them to do that, and let the patients, they know, you know. If they get a text from Text4Baby saying if you do X, Y, and Z, this thing may not happen, they know they're not talking to their doctor. They can weigh that information.

So instead of FDA saying we shouldn't send that out, I think maybe to some degree we can trust that in certain circumstances patients not only can they figure it out, but we've already run the experiment on the web with patient information. It doesn't mean you send everything out, but there's a line, but the voice has already been set to some degree. So that's my comment.

MR. PATEL: Thank you. I think we're at the top of the hour, and we're due for a break.

I have one other question. If the audience has the patience, I will just go ahead and ask that and see if the Panel can respond in really brief, and I'll have maybe 15-second comments.

Since one of the goals of regulation is to establish minimal standards for safety and effectiveness, largely through design, can the Panelists comment on or suggest ways in which an app developer could achieve and be able to demonstrate higher reliability, effectiveness, relatively error-free design of these apps in the absence of regulations?

UNIDENTIFIED SPEAKER: It's a long-winded question.

MR. PATEL: Basically asking, how can -- what other options are out there for folks to assure, have the same level of confidence when regulations provide that or doesn't provide that?

MR. ELLIOTT: I think for the most part, the mechanism already exists. I mean, and again, where there's a high risk here, then I think clearly there needs to be an independent arbitrator who basically meets the assessment. Where the risk is relatively more, I mean simple adoption I think in itself dictates whether things are being successful or not.

I mean some of, you know, Text4Baby, as an example has been given out here. The success of Text4Baby is predominantly due to adoption, due to people talking to each other, people telling each other the value of it.

That doesn't happen for things that don't work. When you go to the Apps Store, or you go to any web environment these days, you can basically see user reviews on whether something works or not. I think, you know, you look at the applications within the Apple Apps Store, and I think I read some statistic that says something like, I don't know, 60 percent are basically deleted from someone's phone within 30 days.

People are self-regulating already today and, therefore, you know, from my perspective, you know, again as long as the risk profile is correct, then people will self-regulate, and people will only use an application that's useful and that's been recommended to them by others and their peers around them.

MR. PATEL: Great.

MS. McDERMOTT: I would just add from a different perspective, the question around what standards to use or not use, I think, really illustrates the point that there are a lot of different standards bodies working on different types of standards out there today, and it would helpful to sort of get our arms around that which is something I know FDA is working to do, especially through the lens of interoperability but understanding how all these different pieces of the ecosystem fit together and the specific challenges they're aiming to solve.

MR. EICHLER: Real quickly to piggyback. So, you know, acknowledging we don't really concern ourselves too much today with, you know, business models that are addressing the consumer directly, but I would suggest that, you know, the market is sophisticated enough for healthcare IT and, you know, mobile applications that are marketed toward more payer-centric or provider-centric models. You've got a fairly sophisticated buyer universe out there that are going to understand, you know, the software development standards, the manufacturing standards, and I think, you know, I hate, as the private equity guys sort of say, oh, let the market figure it out, but I think in this case that the market is sophisticated enough to apply the right standards with respect to those criteria and that question.

MR. PATEL: Okay.

MR. DOLAN: Yes, a quick thought. Sorry, Dane.

MR. STOUT: Very quickly as you said. I think, you know, FDA could help encourage companies to continue to move to the good design software principles. I think those would go a long way, and we can define those fairly clearly, right. Those are pretty well published and understood. The acceptance of that would be a huge benefit.

MR. DOLAN: Yeah, I would just following up on what Grant said, in terms of, you know, what's in the market today, the way that consumers can get their apps validated by outside parties. I don't think the comments in the Apps Store today are really as valuable as they could be, but there are efforts underway to, you know, get groups of healthcare providers together to say, take a look at some of the health apps out there for consumers and validate them that way.

And also just kind of to that same point, I'm not really sure what the process was, but this morning, Apple launched a new section of apps at the point of care. So now they're starting to get a little more granular. It's not just as a medical apps. It's a fitness app. They're starting to feature specific health and medical apps as well. So I think there are a lot of ways that consumers can get increased validation in vetted apps out there.

MR. PATEL: Great. Okay. I think we're on top of the hour. We'll take a 15-minute break. We'll come back at 10:15. That leaves you only 10 minutes, and we'll start with Panel 2 right after we come back. Thanks.

(Off the record.)

(On the record.)

MR. PATEL: If you would take your seats, we're going to start our second Panel, talking about the approach that the guidance has outlined in terms of identifying whether you fit into the definition and then following the current regulations that are currently in place for currently regulated medical devices.

So I'm going to have Tony Watson, Division Director for, I can't even say the whole division's name, but he will do a fine job doing that. So take it away from here. Thank you, guys.

MR. WATSON: Thank you, and welcome to the second Panel. What I'd like to do very briefly is we have everybody's bios in the package, but I'd like to go around and just do brief introductions, and what I'd like you to do is to please give your name and your organization and why this Panel is particularly important to you, and I'll go ahead and start off.

As Bakul said, at least partially, I'm Anthony Watson. I'm the Director of the Division of Anesthesiology, General Hospital Infection Control and Dental Devices, and basically what that means is we have a lot of products that deal with a lot of various software platforms, and we do a lot of products that have to deal with mobile and/or other types of hardware platforms.

DR. HIRSCHORN: I'm Dr. David Hirschorn. I'm the Director of Radiology Informatics at Staten Island University Hospital. My background, I understand the physical side of displays and things. I've dealt with JNDs for digital driving level, but I'm also a radiologist and also understand what you need to read an x-ray or look to find a calcification or pneumothorax and those kinds of things.

I'm here today on behalf of the American College of Radiology's IT and Informatics Committee. The ACR is a professional organization serving more than 34,000 radiologists, radiation oncologists, interventional radiologists, nuclear medicine physicians, and medical physicists.

It is our hope to continue to work with FDA, industry, and other stakeholders to ensure the safety of these innovative tools while also balancing the need for continued progress in the fast-moving world of the mobile marketplace.

In radiology, there are additional considerations related to the use of mobile medical applications, such as mobile image viewers, that are not explored in great detail within the draft guidance. Examples of additional considerations for us include various external viewing conditions, primary diagnosis versus secondary consultation, display size, and others.

It will be a difficult task for regulators to draw a definitive line where FDA purview over mobile apps should end and where the responsible practice of medicine should begin.

FDA staff should be commended for their efforts to try to bring some clarity to this question, yet we all still have work to do.

For our part, ACR is engaged in the review of our own guidelines and standards from the standpoint of mobile devices and applications, and on the topics more for tomorrow, we also develop imaging appropriateness criteria guidelines used in both standalone and mobile clinical decision support software for referring physicians. We look forward to a rich discussion. Thank you.

MR. LIEBLER: Bernie Liebler. I'm Director of Technology and Regulatory Affairs at AdvaMed, which stands for the Advanced Medical Technology Association. We're the largest trade association representing manufacturers of medical devices and healthcare IT and diagnostics in the world, and my areas of expertise are or involvement I guess are standards particularly of software issues and most things related to electromedical devices.

I have to say that this is the first guidance -- I want to compliment the people that wrote this. This is the first guidance that's ever come out that I had to deal with where I've had at least two companies come back and say no comments, it's fine.

My other members, I don't have their drafts yet and their information yet. They all wanted more time until after the meeting to finish their comments, but their response has been we need some clarifications, but they don't have any real objection to what was published.

I think that the first session sort of explains that to some extent, and as I expressed to Tony during the break, you know, if you're a football fan, you really understand all the jargon of which there's plenty. If you're not, you haven't a clue. If you're a medical device company, what is a medical device and those distinctions makes perfect sense. If you're not, it doesn't make any sense at all, and I think those are the people that are really the target of this guidance, and I'll leave it at that.

MR. THIEL: My name is Scott Thiel. I am Senior Regulatory Consultant at Anson Corporation. Just prior to Anson, I spent nearly 23 years in Roche Diagnostics, about 10 or 11 of that within their Global Regulatory Health area. I've also been involved with Continua Health Alliance, which is about a 240-plus coalition that's interested in interoperability of medical devices and wellness devices, and I'm also involved with the mHealth Regulatory Coalition, or MRC, which is supported by Continua and has a lot of crossover membership, and they are interested specifically in mobile health and how those pieces get regulated, specifically with three proposed draft guidance documents that they are putting together at this point on accessory and intended use and how to assess software.

From my perspective, the area of interest, and Bernie touched on this just a little bit, is that this draft guidance document for mobile apps has been written specifically for smaller companies and companies that have not been within the regulated space, and we're keenly interested in how this will impact some of those companies and moving forward with those.

DR. IYER: Good morning. Anand Iyer, President and Chief Operating Officer of WellDoc. First I'd like to thank Bakul and Tony and really the Administration because I think this public/private discussion couldn't come at a better time and perhaps more important time as we look at the need for us in our healthcare system to improve outcomes, decrease healthcare costs, and certainly improve our own global competitive advantage if you would.

WellDoc, by way of background, we are a healthcare technology company, and we focus on helping patients who suffer from chronic conditions such as diabetes, asthma, et cetera, leverage judiciously the technologies that they have access at their side, be it mobile, be it web, be it other things, to help them really do what I said, improve their outcomes and decrease their overall cost that they incur to the system.

The company itself, if you think about from a platform perspective, really provides three fundamental building blocks, that is, a patient virtual coach, that is, the coach that enables the patient to do the things that they have to do against their physician's regimen, their prescribed regimen throughout the day. It's an expert system that actually watches for all the longitudinal patterns and, of course, it's the taking of all of that data that's collected and, if you would, converting that data into information, knowledge, and action that can then provide a basis to enable a provider through clinical decision support to improve, if you would, their management. So it's really intended to bring the patient and the physician closer together.

By way of accomplishments, we've really done I think four amazing things, and that is, first and foremost, outcomes in the realm of diabetes management, a two point reduction in A1c, which is, you know, three to four X what you would get from a leading drug alone.

We are a Class II medical device. So we've actually lived through this process as a mobile system and mobile app, if you would, organization. So we have a 510(k) for our efforts and pursuits, but we've also done this in a manner that scales across multiple, if you would, technology platforms. Let them use the device of choice. Let them use the operating system. Let them use what's convenient for them at the point of consumption, the point of care.

And I think lastly integrating these outcomes and integrating these platforms into clinical workflow, again if you ask an overpaid -- or underpaid, overworked doctor -- I got that wrong, Kent -- if you ask an overworked and underpaid doctor to do anything extra, that's orthogonal to their workflow, it's not going to work. It's not going to sustain if you would adoption and the outcomes that are desired.

I think this is a very important session for us because in many ways, this is the future. We're not going to call it mHealth in three years. It's just going to be health and technology is going to be the implicit part of it, and I think that if we can -- we shouldn't think of regulation as the end. Regulation is a means to the end. It can support and it can also inhibit.

So we have to find the right balance that allows us to continue to innovate, that allows us to remain agile as it relates to how we solve these ever-evolving chronic disease problems that multitudes of patients in the system face, and we have to do it in a manner that, of course, endorses and balances patient safety, which is something that I think everybody should aspire to do. So I think it's from those vantage points and understanding, you know, kind of order of things we can do with regulation that exist today on a go-forward basis is the basis of what I'm going to be discussing later.

MR. DICKS: My name is Kent Dicks, and I'm CEO and founder of MedApps out of Scottsdale, Arizona. I kind of believe a little bit in science from God and the universe, and if you look at the slide up there with Mobile Health, we're either going to go next and make this work or at the bottom, we're going to go end of show, you know, on this.

We need to make this work. You know it's out there, and one of the things that we're seeing from three or four years ago, that people are looking for, you know, cost-effective solutions that almost became somewhat of a rhetoric out there in saying who's got the best cost-effective solution. I need to get more data, you know, for more people in a cost-effective manner, but then they started going into a lot of ROIs, a lot of pilots, you know, you know, phases out there in looking and saying, well, we think that, you know, this is something we want to do, but who's going to pay for it and how are we going to integrate it into our process?

Come forward four years, come forward to today. We now have a list of people now saying, I can't afford to go through ROIs anymore. I can't afford to go through pilots anymore. I need to start implementing today with this stuff, and it's large, large corporations that we're seeing in five areas that I'll go into during future comments, but the areas that there are an immediate need for this type of technology to be able to get more data. It almost sounds like a dirty word, but it's what we're looking for, data in a timely manner to try to be able to intervene, you know, with the patient, you know, now and look for symptoms to try to keep them out of the hospital instead of getting the data from claims data 60 to 90 days down the road when the event's already occurred.

So one of the things that we're trying to do among all of us here is trying to get, you know, data that's out there, systems that are out there that are cost-effective, to try to get that linkage between a patient and their caregiver, and in a cost-effective manner to get that data, and that's what we're trying to do on a regular basis. By the way, that's my introduction, but my name is Kent Dicks. We're out of Scottsdale, Arizona, but now to Jarrin.

MR. JARRIN: Thanks, Kent. Okay. So my name is Robert Jarrin. I'm Senior Director of Government Affairs for Qualcomm, Incorporated. You have my bio. So I'll skip that.

So I'd like to talk about three things, and two of them really need context, the enormity of them. It may sound rhetorical, but I'm going to bring some things up that I'm sure you heard earlier and you're going to hear the rest of the day. So why mobile? Why health? And then, of course, a little bit about Qualcomm.

Why mobile? 5.7 billion people in the world have access to a mobile subscription, and I say that because some people have more than one mobile phone like myself. I've got five. I work for a mobile company. Therefore, you know, the number sounds a little misleading but still, 5.7 billion. That's an enormous figure, and that's the reality. Okay. 4.4 billion people in the world have access to sanitation. In the U.S. alone, we have 303 mobile subscribers. Okay. That encompasses all of the operators. Installed smartphones will surpass PCs in 2012. Those are the figures that I've been given. Okay.

Why health? According to the CDC, all right, 7 out of 10 deaths in the U.S. are caused by a chronic disease. A 2005 figure, this is a criticism on the CDC, the latest number is a 2005 figure on their website for how many adults have chronic disease in America. Almost one out of two is what the figure says. One out of three adults is obese, okay, and really if you look at the number of people that are sick, not just in the U.S., but globally, and the number of people that have a phone, okay, now you understand the enormity of two very complex things. One is industry driven, which has become the most proliferated technology in mankind's history, and the other is just sickness that we may have or may not have done ourselves.

Then Qualcomm. Okay. So why am I here? We are the world's largest fabless producer of chips. We accounted for about 7 billion chips in the company's history so far. We're closing in on 8 billion. We're the market leader for smartphone application processors currently, and our contracted foundries are producing about 1 million chips a day. If you're looking at the 5.7 billion that have a mobile subscription, we account for about 1.3 billion of them, meaning our technologies. So we're obviously involved.

Health, big deal. Technology, big deal. Qualcomm hopefully will be considered part of that deal. So that's why I'm here, and I'd like to talk about things that are important to us in the context of mobile medical applications, and again, I'm very contextual, and I think context is a big, big part of things, and some of that might be missing in the current applications guidance.

Clarity, a lot of people talked about that. Some specifics about clarity, and then if context could be a part of that, then, you know, I think it'll look a little bit better.

I think the FDA has done a wonderful job of getting this out quickly. I think it can go further, and it will, and I look forward to today's discussion. Thank you.

MR. WATSON: Thank you, everyone, and I think it's very apparent that we have quite a diverse group of folks up here.

This presentation, I mean this Panel, I would like to bring some context to the questions that were out there. I'm going to refer to some of those questions, but I'd like to get the -- I'm going to ask some questions behind the questions, if you will.

I think it's really important to understand, we hear the word "regulation" used kind of loosely, and we're all highly regulated, I mean the most invasive of which is every year the Government reaches into your pocket and takes money out. We're not going to do that, but I think it's important to understand that there's a range of regulation, and what we're trying to do here is, you know, try to find that right balance. What is the right balance based on what we know of the marketplace and based on what we have historically done?

Along those lines, I would like to sort of discuss the range of regulation dealing from we have the most stringent, which is our premarket approval process which obviously requires quite a deal of resources, a PMA, clinical trials, lots of money, all the way down to enforcement discretion which is brought up quite frequently in this particular venue, which basically means we just watch essentially. We don't really do much in that arena, but one thing is what's in the box, what do we do with what's in the box? And it's not really so much about jurisdiction.

Now, having said that, the Government does try to parse out jurisdiction. There are certain organizations that deal with medical devices like FDA, and there are certain people who deal with claims and things of that sort like FTC, and then there's other areas like, for example, I think Kerry will agree, FTC has a role in this area, too, as well, from her former life.

I would like to ask, open up the questioning by getting to the issue of what is that range of what's right because we could have enforcement discretion, which means we let the development happen and what happens, happens. Enforcement discretion, when we typically do enforcement discretion, it's very, very difficult for us to get involved if there is a problem later. It's a lot. We have to go back to the regulatory side and start making it very public we're getting involved, and it's very time-intensive.

The other level is ensuring something like what we do with the other medical devices, quality systems. Having a quality system in place or design control or the equivalent, and I guess I'd like to open the questioning by asking, is there a similar process in place for these types of products in the mobile medical place, the mobile medical space, that gives people comfort or assurance that there is a system in place to handle any problems that occur? And the other corollary question is, based on some of the comments that happened earlier, should we even care for some of these products in that arena?

So I'd like to start off by asking Kent actually if he would comment on that first.

MR. DICKS: Yeah, thanks. Actually, you know, there's one thing we need to point out with this is that, you know, mobile health or telehealth or telemedicine, you know, is not new. Mobile health is new, you know, from that standpoint, but when we look at the market, we have to look at the market two ways, I think several different ways. One of the things we always say is one solution doesn't fit all, right. So to try to come in here with a broad brush and say that, you know, this is the solution, it's going to fix healthcare out there, it's just not going to be the case.

You know, I look at the market today as a tier 1 market and a tier 2 market. A tier 1 are the guys that are doing great. They've already had FDA clearances out there for 10 or 15 years like, you know, the Philips and Boschs and, you know, the Honeywells and the Viterians (ph.). They're more point-of-care systems that are typically plugging into a POTS line, you know, that's out there or ethernet or DSL, and now it's going to GSM as well, but what the solution the people are looking for is now -- I mean let's just step back. That was a big statement when they started to come out 10 or 15 years ago to start getting patients monitored from the hospital and now to a point of care. Now, what's happening in the evolution is we want to go mobile with it. We want to go away from the point, not necessarily just the point of care, but we want to get to a bigger group of individuals out there as well and be mobile with it.

If you look at the tier 1 solutions that are out there, they're probably, and I talk with them, you know, on a regular basis, they're probably monitoring 100, 120 thousand patients per day in the U.S. between six and eight companies that are out there.

The market that we're looking for to go after is probably a market that's into the millions, and if you look at that market, you've got to segment it again because specifically the market that Anand might be going after may be a different market than I'm going after. I'm going after the 10 percent of the market that's consuming 70 to 80 percent of the healthcare costs.

It's a different business model. Sorry, I used a dirty word, but you've got to know what the business model is behind the technology. You just can't create it, you know. You've got to understand who's going to pay for it, how it's going to be implemented, you know, and how it's going to be used out there. We're not going after right now the 90 percent that consumed the other 20 or 30 percent of healthcare costs. We're not doing that.

We started with a smartphone and then went from a smartphone over to end-to-end technology, and that's one thing I need to know, need the FDA to know, too, is that we're not just talking about smartphones. We're talking about devices like the Kindle model. We'll talking about the devices like OnStar. We're talking about devices like ADT Security and things like that, that already have cellular technology built into them, are very, very cost-effective, very invisible, lay in the background and collect data and send it to the cloud, and where we see that this is going to be a major, major undertaking is that the devices are going to be controlled from the cloud.

What we've learned from tier 1 is that devices were harder to deploy, maintain in the field, give far more updates, I'm crossing a line here, far more updates through the cloud to be able to give new features, new functionalities, whatever needs to be done. Instead of having to recall that device, you can do it from the cloud instead. You can also send the data in EHRs and PHRs as well.

The other thing that we're looking at with regulation is where does it start and stop. I mean we, you know, we interface. We want to be able, and the healthcare organizations want to be able to save costs, and they want to be able to get access to consumer-priced devices that are out there but have them into their healthcare system.

So can we? You know, there's a lot of the consumer devices out there that are pulse oximeters, blood pressure meters, and scales. Scales are a Class I device, but some of those don't require to have the FDA scrutiny that a Class II device does because they're used for wellness. They're used for collecting data. They're being put into a PHR. What happens when that data now, and you don't know it up front, goes into a PHR and then all of a sudden goes in -- you can now link it to clinical systems out there that's being used in a clinical way as well?

So, you know, there's some things that we need to go through and look at as far as regulation is concerned with this. We want to make sure because that event could occur, you know, in the marketplace, and those demands are being made from a business model perspective, that we want to make sure that the quality is there, that the -- I'm not saying everybody has to have ISO 1345 or ISO 9001 or ISO 14 whatever that's out there to be able to do it, but we need to have some type of oversight, you know, with it to be able to let us know that the FDA is comfortable with what we're doing.

If you're going to see, and I agree with the investors in the room as well, if you're going to see investors start coming into this space, they're going to have to have some level of assurance that the FDA is comfortable with me and with the industry, that they're not going to be able to shut us down at any time because a regulation has changed.

Just going through and doing the MDDS is a big step, but I just had a FDA review. I think you just had a FDA review, and when we sat down with the reviewer, I said this independently, sat down with the reviewer, I asked him, okay, let's go over the MDDS because it went into effect in the April timeframe. He said what's the MDDS? Right. Then right before that he was at a fertility clinic, right.

The first two FDA clearances that we had, the first one, the reviewer thought that I was actually killing a patient, you know, by everything we were trying to do with it, and when would the nurse run in and turn off the alarm and be able to reset it because that's what they're used to in a hospital setting. This is for home.

The next FDA clearance we got was reviewed by a nuclear physicist that I had to go through and retrain them all on mHealth and everything else they were trying to do. One of my biggest things, I want to look with this, when we talk about it, is can we have consistency, you know, from the Agency? Can we have somebody that knows about mHealth and they're always reviewing mHealth applications if we go that direction?

MR. WATSON: Thank you. And I just want to allow some other folks to have an opportunity to comment on it. I'd like to hear what Dr. Hirschorn thinks about that.

DR. HIRSCHORN: In radiology, we've seen the FDA take different measures in different parts of our profession. Mammography has been picked out as special case, and we can't practice mammography unless we use the FDA-cleared monitors.

When it comes to the rest of radiology, we find that there are medically marketed monitors, and in order for those companies to produce those monitors for us to use and market them for medical use, they have to go through the Class III, they have to go through pre-market approval.

However, there is nothing to preclude me as a radiologist saying I want to view these images on some other monitor, and as long as it's not mammography, if I understand correctly, the FDA doesn't tell me that you as a doctor can't go up to a nursing station and take the, you know, commercial off-the-shelf monitor that's up there, that's being used to look at lab values and didn't go through any PMA or anything. It's just off-the-shelf equipment, and look at a chest x-ray on that and decide whether or not I deem it appropriate to make an interpretation of an image off that display in that system or not.

What this has led to is on the non-mammography side of the house, if you will, an ability to make tradeoffs, the ability to look to see, well, do I need to go out and spend, you know, many thousands of dollars on a piece of equipment? Well, it's one thing if I'm going to put it on-site in the hospital. What if I wanted to put it in a doctor's home to increase access to subspecialty expertise to get it out there in a more cost-effective way? Can I do that or not? I have that freedom when it's not mammography. When it is mammography, I can't.

And it's quite an interesting interplay such that what I've seen out there, not just in my institution, in many institutions, is that the mammography monitors, because they have to be blessed by the FDA, end up sometimes being the worst monitors in the department because they're constrained to a standard that doesn't keep up with the times, and so they're "5 megapixel" CRTs that they haven't put out 5 megapixels in many, many years, but on paper, they're 5 megapixel and they're the dimmest monitors in my department, but they meet minimum guidelines and they're constrained to using those. Meanwhile, I've got some commercial off-the-shelf monitors that perform much better, but they don't meet FDA guidelines and therefore they can't be used.

And so sometimes the regulation, if it doesn't keep up, can actually make things worse.

In a related vein, when it comes to the software that displays medical images, from PACS, Picture Archiving Communication System. So there was a time when some of these software vendors had to pay attention to how they were delivering the data, particularly if they're using lossy compression, to say, hey, I know I'm not delivering all that data to you, I know I'm summarizing it, and therefore they put a disclaimer on it, saying not for primary diagnosis.

Well, that's changed pretty much because that's not really necessary as much anymore, and so from the software perspective, they can deliver "full fidelity images" and not have an issue on the software side, but they obviously can't control, going back to what I said earlier, can't control what display you use. That's up to you as the physician to decide whether what you're using is proper equipment or not, and again if it's not mammography, then I can make a decision. Am I going to use a medically marketed display or am I going to use something that's off the shelf?

And for a number of years, the FDA seemed to step back and let that happen, but when an application was marketed for a mobile device, they said, no, something's different here because before you didn't know what the platform was going to be. And so you didn't take responsibility for it. You left it up to the discretion of the physician to decide whether it was adequate or not, but now that it's on a mobile device, now it's different and now we say something's different here.

I mean, yes, the devices, they're smaller, and there is no such thing as a medically marketed mobile device, a medically marketed mobile display to my knowledge. There's certainly not one, I mean unless they're -- mobile, something that's really huge, you know, but your standard mobile devices that are out there, these are not made by medical device manufacturers. As we said, that's what the whole draft is about, saying it's the recognition of that, is that the companies that make these mobile devices, for all the things that they do, they're not making the hardware for medical use, and therefore the FDA seems to have taken a different approach when it comes to software that's designed for these devices than the ones that are just made for web.

And as we said earlier, well, those lines are going to blur pretty soon if they haven't already. You know, what's mobile? What's not mobile? You know, what's -- these lines are blurring, and so we would appreciate some clarification, some clarity on what's the difference between making software that's designed specifically for mobile and one that isn't, if it's web, and it could be both, and then what's the difference?

MR. WATSON: Thank you. And I think I'd like to get a little bit of the industry perspective on that. Bernie.

MR. LIEBLER: My view is large -- well, the question of whether you can -- how you use a particular piece of hardware is one the FDA can't address, I mean because they're constrained by the law. The law says that it has to have an intended use, and if I have a general purpose monitor that I decided to attach to the imaging system that I've gotten, they don't have any control. It's the old story of not regulating the practice of medicine, and I'm not sure most of us want the FDA to do that. So --

But going back to Tony's initial question, what do you have in place to guarantee the quality of the software? And software quality is an incredibly difficult issue. It's very, very hard to monitor. It's the old story that anyone that writes complex software will admit to you that even after validation, when it's released, it's buggy. No one's ever really eliminated all of the bugs out of a piece of complex software. Admittedly, a lot of this will not be that complex.

But there is -- I know there is an IEC standard, 62304, for the development of medical device software, and certainly it would not be terribly unreasonable to expect that someone would either run a quality system or develop software according to the standard, a recognized standard, also 12207 which is not specifically medical devices. And most of the industry does that because that's one of the better routes and one of the more effective routes to getting your product approved around the world, and again industry is usually looking for a universal approval or universally approvable product.

App developers, I think, when they look and specifically are going to develop medical apps, are entering a new universe, and they're going to have to learn a little bit of new rules.

MR. WATSON: I would like to shift the focus slightly based on something you said, and it has to do with choosing the platform for which you're going to treat a patient or look at results. That model that you described works really well when there's a physician in the loop, but as we talked about earlier, there's users that are going to be home-based.

So how do we handle that dichotomy between someone who can look and see this is not the right platform for looking at this versus someone who may not be able to do that, and we understand there are very well-educated patients. Diabetics happen to be in that group, but there are some that will just take what they see as gospel. So how does that help us and, you know, what factors should we consider in oversight when we're dealing with those type of apps? And I'd like to start with Anand.

DR. IYER: It's a good question. Let me step out of health for a second and then me bring it back to health. I'd actually like to put a taxonomy on the table for us to consider.

When the United States Department of Defense endeavored to track their supply material shipment around the world, it was around the same time that Wal-Mart was thinking about how do we track inventory, and so it's the joke, of course, is that, you know, you ask Wal-Mart why they invested in a RFID, and they said, oh, because the military is, and you ask the military why they're using RFID and they said because Wal-Mart is. Neither of them actually knew what they wanted to get out of it and how to configure it.

Well, what was interesting about RFID was that it was tantamount to a classroom of 20 kids with an edict saying we're going to play sports. You know, so the first kid shows up with a baseball bat and a glove. The second kid shows up with a lacrosse stick and hockey stick, and fourth kid has a basketball, and they kind of played sports but really didn't get to the intent that they wanted. And the solution that they ultimately ended up adopting was they parsed their trade space into a bunch of layers, okay.

So imagine a framework. My colleagues who know me here, if I had a whiteboard, I'd jump up and actually draw this, but anyway, but imagine if you would, a layered construct that says, I have at the very top, a layer of users. That user layer could include different types of patients. I could subsegment even within a layer. There's a patient who actually is literate about their disease or who understands medication titration or whatever. Maybe there's a patient who doesn't or who's uncomfortable with the disease or scared of the disease. So you have a patient, you have a physician, you have an educator, you have a caregiver, you have a pharmacist, you have all these people in that layer, okay.

At the next layer down, you have applications. The applications could be I want to track and record my weight, and the application could actually be one of titrate my insulin to help me manage my blood glucose fluctuations throughout the day.

The third layer down is environment, and environment is interesting because they talked about it in the last panel which is what happens if I change the illumination in the room or what happens if there's distraction or are they going to do things the same way or not? Am I going to incur new sources of patient risk because I'm fluctuating those environmental parameters?

The next layer down is devices. Now, I introduce like the others existing medical devices, but now I'm introducing a plethora of new devices, an Android phone, an iPhone, an iPad, et cetera.

Then there's a layer called network, which is the communications fabric. It's the A to B. How do you get data from here to there? In the past it may have been down through I write it down and I fax it into my doctor. Now, it's going through some electronic medium.

The next layer is services. What services am I going to provide? Either service that take that data and interpret it and provide some actionable feedback, to whoever that user may be.

So now play the game. I now have these layers defined, and I now create permutations in these layers, and I define, for example, me, layer one. Two, I want to track my weight. Three, I'm at home. Four, I'm going to use my iPhone. Five, I'm going to have this transmitted into a repository. Six, I'm going to graph it and see how I did versus the week before.

In that case, you don't need a lot of regulation, right. So when you actually go through this exercise, which is what the military did and it actually was a grand success, Wal-Mart ended up following the same thing, is you start to create families of these permutations, and it becomes very evident at that level of granularity what needs additional regulation, what may need additional risk analysis and perhaps no regulation, but the answer becomes so much clearer than do we need regulation or not or what's the degree?

And I think the way to answer that question is to parse this, and they talked about it in the previous panel, is to parse this. It's what you said. It's not a one size fits all. If you can parse it into these building blocks and judiciously ask these, am I incurring any new sources of patient risk, whether it's the severity of the risk or the probability of the risk and, of course, the product of the two is what you're interested in, if I can do that by -- and there's not an infinite number. It's actually a fairly straightforward exercise. Then I think you get to the answer of there's going to be a very well-defined class of things that need to be perhaps new regulation. There's a class of things for which you can do a delta analysis and say, we already have good software controls and design controls and quality systems in place. What differently might I need to do? And then there may be stuff that just, you know what? It's fine the way it is. Go ahead and innovate, and I think maybe that's an approach to get us to a finer answer as to what's the right range and, you know.

MR. WATSON: I'd like to give Scott a chance to comment on that. Scott, I know from your background, you've dealt quite intimately with users that would be in the home from your past experience. I'd like to hear your perspective on this as well.

MR. THIEL: I think that, you're right, that you need to have a different approach to these things as the one size fits all is not going to be what we're going to be able to see here. But what I have seen in my past life are groups of individuals that are very well versed in what they need to do and that seems to be -- I dealt primarily in the diabetes area. And you're right, Tony, those folks tend to be very well versed in what they need to do.

But there's a small percentage of individuals that are out there that simply don't get it, and sometimes they need to be taken into account when you're doing these kinds of usability considerations.

So there are some instances where there are platforms where I think you do need to have a basic study or basic level of usability with the individuals to understand, first of all, how the product is going to be interpreted by them, so that they can, you know, back to Jarrin's point on context. It's important to understand the context of what's going on with these products when you put it in the hands of the end user.

So I think that there -- but, again, you can't have a hammer to do the job for every single thing. You need to be able to have a more refined toolbox available to you so that you can go in and you can do these things and parse them out based upon, as we said before in the first Panel, the risk and the intended use that's associated with these products.

MR. WATSON: Robert.

MR. JARRIN: So a couple of things. If we're talking about protecting the consumer, I know that that's part of obviously what the FDA does, safety and efficacy, you know. Enforcement discretion falls also upon FTC based on claims, et cetera. You know, and I think those are important things to consider, but if we're talking about, you know, within the context of this mobile medical application guidance document, you know, part of the issue that you heard this morning, and I definitely want to hit upon again, is clarity and clarity contextually.

So I take that guidance document, I read it. It made sense to me. I've been immersed in this area for nearly five years.

I had so many other manufacturers that are atypical of health, who are beginning to get into this area because they're adding some kind of connectivity or they're involved in one way or another, contact me because they didn't really understand it, and they thought that the guidance document was saying we're going to go in there and regulate everything, and I know that it's clear and clearly written, but if you don't have the context of understanding the law and the way that the FDA applies that law, I think it's a little tough for some people that are not used to it to really kind of see where you're going.

Now, that's just a very minor comment, but having said that, if we actually -- if I stepped back and looked at it and said, okay, contextually speaking, do I understand this guidance document? Sure, I do but, you know, it talks about things like intended use. It mentions, you know, in a cursory, passing, things like the accessory rule, and it obviously talks about software and fields about software but, you know, it also said we're going to leave certain things out of here like EHRs and PHRs and, you know, certain kinds of trending and tracking, et cetera.

If I were to step back, you know, how do we actually define intended use. I know what the law says. I understand that. I know that you have CDRH Learn. I can go there and try to figure out what it's saying, but there are so many ambiguous terms within intended use, and whether or not one actually triggers classification I think is a deep problem.

So one of the things that the Mobile Health Regulatory Commission, which obviously Qualcomm is a founding member of, has been grappling with for the last year is actually coming up with a way of defining certain things in the context of intended use, accessories, and software. You know, one of the things that we were actually grappling with were certain ambiguous terms where those that are actually socially beneficial and, you know, what we did was come up with a framework of let's look at the existing regulation. We don't want to change that. We don't want to ask the FDA to change how they regulate, but maybe look at different parameters within those regulations, and there are certain low risk issues, low risk things that are either socially beneficial or ambiguously defined, that they should really kind of be exempt or be considered to be exempt. You know, things like, you know, you hear terms, right. We're talking about intended use. So things like health and wellness, okay, those are obvious because they're not really defined.

But how about stress or stress management or chronically fat, overweight? Hospitalization. It's not really a defined term. Sleep deprivation, sleep dysfunction, and patient satisfaction, if I were to use any of those, I think some people would say those trigger because, you know, there's a lack of clarity on, you know, the intended use, and we can't talk about software if we don't talk about all of the intended use, accessory rule, et cetera.

So, you know, one of the things I would propose to the FDA is to really look at the work that the MRC has done. There have been a number of people, stakeholders, that are both within industry and outside of industry that have been part of this, and, you know, we will be submitting our comments as part of our filing, and we'd like the FDA to look at that and actually, you know, consider it for good guidance practices. That's one thing.

Another thing is though that I really want to mention, and I'm not going to hog the mic that much longer, you know, when you're a company and you're not used to these kinds of legal frameworks, there's the issue of how do we actually get something to market, and then there's the issue of size. If I were a software developer that's working out of a garage, Bill Gates 30 years ago, 40 years ago, if I were to come up with something that's, you know, I'm going to come up with an app that's going to do coaching to avoid getting lung disease, okay, so right there I triggered, to involving your social network.

Now, depending on where it falls in the classification paradigm, I might have to institute a quality system regulation based on good manufacturing practices. How can someone that works out of their garage go and get ISO certified, institute a quality systems regulation to make sure that this thing which is obviously ambiguously defined or, you know, of a great social benefit, how can I get that to market? And remember when I read the MDDS rule, it mentioned at the end of it, you know, to institute some of the quality practices and procedures, it's going to cost, you know, the typical company I think $25,000 or $50,000. That's not realistic. It really is not realistic, and when we're talking about an age of trying to foster innovation and, you know, I think the President's mandate is to actually look at regulations that, you know, may or may not be helpful, this, you know, clearly for something that has, you know, a socially beneficial outcome, that should be factored in.

MR. WATSON: Kent, did you have something to add to that?

MR. DICKS: Yeah, I think you're off by just a factor. Most people say that it takes about 90 days to get a FDA clearance, 90 days and about $4 million in about four years in advance, maybe two years in advance, to get that because if you're going to do it right, you're going to set up the quality systems. You're going to have to have everything, verification, validation, everything that's there to be able to get there. It's just not writing a piece of paper and submitting it to the FDA and hope you get a clearance after that.

The other thing on, you know, on the ISO, the 1345, you know, we didn't start literally out of a garage, but we're a startup that's now progressed, but for us to be able to progress, we had to go down, we had to go down the line of getting ISO 1345, FDA, you know, see Mark, ISO 9001, to be able to get the investment into the company, to be able to do that, and to know then that we're doing it right.

The comment I was going to make just before when Anand was talking was, you know, in looking at his platforms that are there, you know, or his levels that are there, he's really looking at creating the platform, all the way from the patient clear through to the service, and that's what a lot of us are trying to do with our CloudCare platform, creating interoperability, whether it's using Continua or non-Continua devices that are out there, driver models, maintaining all that kind of stuff in the field.

But the issue is, if you start at one level and you say, okay, this is just wellness, and I'm going to use this S pO 2 device that costs $39, you know, that's made in Taiwan or whatever, it costs 39 bucks, it's not regulated, it doesn't need to be very good. It's just going into, you know, into a personal wellness setting versus a $4,000 one that's out there. What happens when that S pO 2 model starts migrating over its data into more clinical settings? Does that now have to go back and get, you know, FDA clearance, or can people start using that in their "systems" that are out there, and that's where a lot of the pressure's coming on the marketplace today as saying, I just want to go to Walgreen's. This is large healthcare organizations. I just want to go to Walgreen's, be able to have plug and play interoperability to be able to take medical health devices that are already on the shelves at CVS and Walgreen's and such and bring the data back into the system and let it flow into our clinical system.

So is that device not FDA cleared that's 39 bucks that's out there, but the system is FDA cleared? That's where the ambiguity comes in.

MR. WATSON: So this highlights the complexity of the space we're dealing in and, you know, the folks in this room are dealing with a, you know, the prospect of various levels of regulation which can be scary, but I also point out that the questions and the issues that you brought up are exactly the ones that we're grappling with internally and, you know, this is not going to draw many tears from the audience, but it's tough to be a regulator, too. (Laughter.) We've got to figure out where the right line is there.

And along those lines, I hear checking the risk, looking at the risk of different layers perhaps, looking at how does someone -- I love your example of the guy in the garage because actually we have people in the medical device world who build things out of garages, and they do, in fact, have to come up with some type of quality system as minimal as it is to actually do that.

And this brings me to my next point right before we get to the Q&A, which is when we talk about innovation, that question, that word raises a lot of images in people's minds, and the guidance is based on mobile apps, but clearly there are other areas that have the same underlying issues and regulations that cross over into other areas into what we might call traditional medical device areas. And the question becomes if we deal with one particular area which is sort of platform based, separately from another traditional area, how do we make sure that that other area isn't suffering in their innovation, and I guess I would like to bring that question first to Bernie and see what his thoughts are on that.

MR. LIEBLER: Can I say I don't have a clue? I'm really not sure about that. In fact, what I was thinking of and I wanted to add to what we were saying before is that to be fair, the guidance is not using the one size fits all. It's saying that depending on the risk, just like in the overall scheme, there will be a difference in the layer of regulation or no regulation. And, you know, I'm not sure that FDA can really look at, I'm not sure you have the crystal ball or any of us do, to say that if you facilitate innovation in one area, and innovation's a word that I'm really not fond of, that you're either impeding it in another area or actually accelerating it in another area without, I hate to say it, without experimental -- which means you've got to do it and you see where things go. But a priori, I can't imagine how anybody could make a legitimate and valid prediction on that.

MR. WATSON: Anand, do you have a comment on that? I'll make sure I get everybody around, but I'd like to ask that you keep your comments fairly brief because we are -- I do want to get the Q&A in as well.

DR. IYER: Yeah, I think it's what Bernie said, and I think that if I were to use a real example for us, what you're doing is you're mixing different clock speeds of innovation. There's a clock speed of the guy in the garage who's doing this with the software, and he has a release every 30 days, and then you've got the clock speed of this, whether it's a $39 device or it's the $4,000 device, that comes out like perhaps every 5 years. And then the question is if you want to mix the two and claim that that's your offer, or if somebody actually takes the initiative to mix the two.

So I think one possibility and certainly one of the things we've done is if I look for example at mixing a cellular device with this software to manage diabetes, the question we had to ask ourselves is you're using a new device that has its own innovation cycle, but let's ask it from a patient risk analysis and let's ask it from a human factors analysis and say are there new sources of risk that I'm incurring in the way they interface, because the way they interface with the QWERTY keyboard on the BlackBerry and the way they interface with the touchscreen on an Android or iPhone are arguably different, but if I can show demonstrably that they get to the same point with the same level of instructions, then I've addressed that risk and I've, in fact, smoothed over those difference in clock speeds, and so for us that's a real example of how we actually deal with the problem that you raised.

MR. WATSON: I'm just going to go right down the line. Kent, do you have something?

MR. DICKS: Yeah. The only thing I wanted to kind of put out there as well as kind of looking at, along the same line, it's not easy, you know, this is a very complex, you know, subject, you know. Where do you draw the line? Where does data, you know, go at the end? And do you have to know up front when you're regulating a device where the data's going to end up in the end, if it's going to go into a PHR, an EHR, or into somebody else's private repository.

The other thing is looking at, you know, when we're using -- my viewpoint's going to come from embedded cellular technology, not from smartphones. Yours is coming from smartphones right now, today. So embedded cellular technology is beneficial in our product model that's out there, but because we create our device, the HealthPAL or the HealthAir, and we embed cellular technology in it, we're under the scrutiny of 60601. We have to go through electrical immunity. We have to go through everything else that's out there, but if I put the application on a smartphone or a PC, just like you said, there's no PC or smartphone out there that's compliant with 60601, right.

So, you know, do we go through and say that you shouldn't be using PCs and smartphones for medical applications because it's not compliant with 60601 or is that, you know, a waiver? There's some ambiguity in there about why do I have to go through 60601 and why the smartphones and PCs don't.

The other thing to kind of look at is intended use on this as well is we found, you know, with this that, I described the tier 1's and the tier 2's, there is a gaping discrepancy between intended use as my intended use says that I have to go through and we interface to a scale, a blood pressure, a pulse ox, and a glucose meter, and if I want to add glucose meters to that, I have to do special 510(k)s to do that. The tier 1's that are out there, with intended use, and have been out there for 5, 10 years, say to interface with home healthcare devices or devices that are intended for home. So they don't have to submit 510(k)s or special 510(k)s as often as we do in the marketplace that's out there.

So we've brought this up before, and when I was on the FCC/FDA meeting last year, you know, when we met. We've also covered it with FDA as well, but it's still an issue that the discrepancies of intended uses really, you know, really need to be covered as well.

The only other comment I'm going to make on this, too, is that really working with the FDA comes down to two things. From our standpoint, industry standpoint, is assuring you that we have patient safety as the utmost in mind, you know, for our patients, and the other one is trust. We have to build a level of trust with you, the FDA, or whoever's going to be our governing body, whether it's you all working on behalf of the FDA to certify our devices, that we've got the quality system in place to be able to do that.

One of the things, and I'll leave this as the last, one of the things that we have to look at is who's going to ensure that when you take that smartphone and you decide to make a smart cable for it and plug it into a glucose meter, and then plug it into the charger at the same time, and plug it into the wall outlet and take your glucose from it, who's going to ensure that there's isolation from the wall outlet to that glucose meter so you do not have an electrical shock hazard to the patient, and that, and I'm bringing this up at the end, but those are some very complicated things that we need to think about.

MR. WATSON: Robert.

MR. JARRIN: So I guess what I would like to add to this, because I'm not going to beat a dead horse, is I think that there's -- the FDA, they're at this edge of really doing a great thing. You guys are poised to bring that clarity that we're talking about, and I don't mean just through this guidance because I think that this is applicable to this conversation. So the FDA has taken on something called the Medical Device Home Use Initiative where they had a workshop here in Silver Spring, and they had a breakout session that was half a day long on wireless. You know, comments were supposed to be taken, and then some kind of a guidance document would come out of that and, you know, we haven't seen anything yet, but that's something that you have embarked on.

Then you've got the Innovation Pathway where it specifically says that, you know, they're looking at innovative things and creating Centers of Excellence for innovative technologies, and I believe they even mention wireless in there.

The IOM, Institute of Medicine, report came out. They specifically talk about smartphones and using them for adverse events, but they were unclear as to whether or not it would actually do something to intended uses of what was being looked at.

The draft Radiofrequency from 2007, which is a pretty dated document, there have been rumblings that you've been looking at those to try to, you know, come up with something, something better to really make it a final document.

The FDA/FTC initiative last year that was kicked off with the Memorandum of Understanding, to really look at innovative converged medical devices, and then finally the Continua-CIMIT-FDA Interoperability workshop from a couple of years ago.

They're all looking at the same issue, and now this, the Mobile Medical Applications guidance document. So there's a lot of interest from the Agency, but it's who is leading the charge, which one is really the one that's going to dictate how it's done or offer the best guidance because, you know, even that is really unclear and is causing, you know, misunderstandings and the industry to not really understand that we're talking about venture capital. I think one of the things that scares a lot of small investors is they're not sure how to bring their product to market because they're scared that they're going to get the wrath of the FDA. And it's unfortunate because the FDA is actually extremely helpful, and that is the one thing I would say. It's a great agency. I like working with you guys.

MR. WATSON: Wow. Thank you. I'm glad that's on the transcript. (Laughter.)

Okay. I'm going to allow one very brief comment, and then I really do have to get to these questions because I think I only have 10 minutes. I'm sorry.

DR. HIRSCHORN: I'd just like to add, I think the draft does a great job defining what is and what is not considered on the proposal as mobile medical app. I think what's less clear is what classification they would fall under. It kind of says, well, we'll look at it and see.

But, you know, in terms of the intended use case, the distinction between what is, you know, control by physician, what is not. Well, that itself is also very unclear. There's images viewed by radiologists, there's images reviewed by a referring clinician with the patient, and then there's images that a patient views on their own.

The draft document mentions images that come directly from a PACS. Well, I know what directly means. I mean images can go, you know, from system A to system B. Is that therefore indirect? You know, it's unclear. I think the part that's lacking clarity the most in this regard is how does a manufacturer know how their application will be classified given the fact that it will be under FDA's purview which classification it will fall into. That's what's missing to me the most from the draft.

MR. WATSON: Thank you. I have two comments which I'll leave for the instance. There doesn't need to be any, I don't think any discussion around them, but I will go through these two questions.

So the first one is from a marketing perspective, we heard in the last Panel that logging apps are pretty sound and that self-management apps start to enter the gray area we've been talking about. But what if logging was facilitated by apps that are for technology such as side effects, trackers, and severity ratings, and is this the same as keeping this info in a more traditional way such as a journal or doctor discussion guide?

Scott, do you have any thoughts along this line?

MR. THIEL: Yeah, thanks, Tony.

MR. WATSON: I can see you're thinking deeply. So --

MR. THIEL: Yeah, yeah, yeah. I'm trying to figure out exactly what all of that meant. Again, I go back to what's the severity of the harm to the end user of the information that's being tracked and how that information is being used and analyzed. It's difficult to do the high level overview of some of these things, and unfortunately I think you're almost forced to have to get down into the granularity of it. You know, we talked about going through the layers and, you know, that's really building a use case if you will to go through that, and we're at a point now where the price point and the ease in changing some of these things has dropped to a point where, you know, my kids could be doing this on the computer at home or on their iPhone in the middle of school, and they could be developing some of these things very quickly and very easily and getting it out into the marketplace almost at zero cost to them and then going out and making those changes. But putting that out there like that, without understanding what the risks are to the end user and those types of things, there's just too many permutations, and you almost have to look at these things on a case-by-case basis to build what is the risk that's associated with that.

So it's very difficult to answer a generic question of, if we do this type of thing, is that going to have an impact on the end user?

MR. WATSON: Bernie, did you want to say something?

MR. LIEBLER: Yeah, it brings up a thought that I had earlier, and that is that we can have a logging device that displays something when it sees a certain number, and there is some parallel to having a logging notebook that has a list of these things going down the side of each page, as a reminder each person.

And I thought of it earlier because we have -- and we speak with great concern about websites that carry useless medical information or not very good medical information as opposed to the things that have very good information. You can do the same thing with printed books. Historically people have always published books with really bad advice in them. People read them, and people follow them often with very poor results. The web is more immediate, but when you're simply displaying information to people to read and interpret on their own, it's the same kind of thing, and some of that flows into this at the very lowest levels.

MR. WATSON: I forgot to mention that the hashtag for tweeting is FDAmHTrend if you have anything to tweet.

Another question, living in an ever-developing global economy during a time of high U.S. unemployment and recognition that the most prolific engine for job growth is coming from entrepreneurial innovation, does or should the FDA consider the fact that some innovators are now going to Europe to develop and obtaining regulatory approval and first market their mobile health solutions and create jobs?

So that sounds like a question for FDA, but I'm going to ask our Panel (laughter) to give their perspective on this, and I think I'd like to start off with Robert, please.

MR. JARRIN: Sure, Tony. Thanks. This is actually a pressing issue right now. There have been a number of congressional hearings from the Energy and Commerce Committee where I believe Dr. Shuren has come and testified himself on two separate occasions, and I may be wrong, on this issue where they've brought in entrepreneurs and medium-sized companies to talk about their problems on trying to get their medical devices to market, and they've gone to Europe as a result of finding an unfavorable regulatory atmosphere here in the U.S.

I can't speak to what those specific companies have gone through. We're not partners, and I just happened to be at the hearing to listen, but I can tell that some of the questions that we have, meaning companies like Qualcomm and our partners, on again the issues of intended use, the issues of the accessory rule, how does it apply, how does it not, and software, you know, really are recognized and the same types of things that I heard at those hearings. Whether or not I completely agree with what those people were saying, you know, is a different story, but I just see commonality there.

So I think that that may be an issue. You know, I understand that it is a little bit easier, it seems to be a little bit easier and, you know, I have no firsthand knowledge of it, of getting them on market or marketing a medical device in Europe. You know, whether or not that's how that impacts the safety and efficacy of such, you know, devices here, I think, is something that really needs to be, you know, monitored closely.

By saying what I've said, I hope people don't take away that I'm trying to say, you know, everything should be exempt and be considered and ambiguously defined or substantially good for the public good and should therefore be exempt of FDA regulatory applications. That's not what I'm saying. If it's an obvious medical device, whether it comes by way of a medical application or a hard piece of equipment, then it needs to be regulated. You know, the safety and efficacy is the paramount concern for everyone, including the industry.

MR. WATSON: Okay. Some brief comments from Kent.

MR. DICKS: You know, probably when we're looking at our leads that come in, we probably have 80 percent of our leads come in from offshore, off the U.S., you know, from China to Japan to Europe to wherever.

We made a decision years ago to be able to go through, put ourselves through FDA, and I can tell you that with FDA clearance, ISO 9001, 1345, CE mark, you know, Health Canada, everything else that we've done right out there, we still, and I'm talking about the industry, because there's others around here that do the same thing, we still are not attracting the investment dollar, you know, and to make this flourish as an industry, to be able to go.

So I'm going to sit back and say that we have to have as a check mark, just like we have to have Continua compliance, you know, as a check mark, integration to HIEs or EHRs that's out there and FDA clearance and 1345, you know, as a check mark, but right now one of the things that could help us a lot in the U.S. is stimulating the capital markets for this healthcare.

DR. IYER: I think we took a very similar approach to what Kent said. Oddly enough, we got FDA clearance first, and we're marketing in the U.S. first, and we've created 80-plus jobs, high value jobs in Baltimore as a result of that. Right, wrong, or indifferent, I mean we were in Saudi Arabia recently, and the King of Saudi Arabia thought this was a great thing because, you know, 42 percent of people in Saudi Arabia have diabetes, and he's like, I could roll this out to all of my citizens. Oh, by the way, are you FDA-cleared?

So right, wrong, or indifferent, it's still the compass, not because of the three letter stamp. The way we interpret, it's still the compass that shows (a) that you took patient safety into consideration, you built and thoughtfully built a product, (b) you have a quality system in place that ensures repeatability, scalability of your product in a manner that's, you know, congruent with all the best guidelines and policies and practices, quality systems and software development, and so I think people should, I think there should be more, you know, capital here in the United States where we can take these concepts, build them out, not just deploy them here because we've got a trillion plus dollar market known as health problems here, but we can also export these elsewhere.

So I think people should -- to Bakul's triangle, if you stay in that bottom layer, in Bakul's triangle, it's interesting, but there's no economic value and there's no health outcomes from that bottom layer. It's just the fun app layer. It's that middle layer that everybody should strive to conquer. Don't be afraid of it. Enter that middle layer. To all the app developers and system developers, that work with the FDA, I think you guys have done a great job echoing all the sentiments of at least, you know -- in many ways you're playing catch up, in a very fast moving mobile industry. That's awesome, but I think I would encourage people to work in that middle layer and push the envelope of what they can do because the dialogue is already there and people are succeeding.

MR. DICKS: Just real quickly. If companies out there want to get higher status to be more ubiquitous in the U.S. and throughout the world as well, it's a check mark that has to be done. When we're working with the big payers or big providers out there, they're going to say, are you Continua? Are you FDA-cleared? Are you CE mark? Are you 1345? Those are the check marks to do before you even get to go in because they have two little guys inside the corporations that help out, legal and finance, that say if somebody's going to get sued here, it's going to be them that gets sued, with the deep pockets, and they want a level of security to make sure that that device has gone through and its system has gone through scrutiny and goes to a level that FDA considers appropriate.

MR. WATSON: I'm going to incur the wrath of Bakul here by indulging about five more minutes of people's breaks. I probably incurred everybody's wrath on that. But I want to get some comments out, and I do want to have this last question, end on this last question, which I think is an interesting one. So I think we've got a couple of comments and I think a rhetorical question. I'll start with this one.

How about some clarification on definition of mobile devices or platforms? For example, would an application on a TV fall under the category of a mobile app? And there are app stores specifically for notebooks, for netbooks. Okay. So we'll just keep that. We have had some discussion around that type of thing. I won't ask for any comment from the Panel on that one.

The importance of including hospitals and healthcare systems within this discussion, unlike medical devices in EHRs, they are building their own apps without FDA on their radar, need decision, path, or checklist at very basic level to address this population. Okay.

Another comment. Innovative software companies from the garage to Apple, for example, the person in the garage to Apple and Google, don't use the kind of waterfall development process that the ISO standards require. If you're to drive real innovation in health software, regulations need to adapt to how software is really built. There's a thought.

A comment on awareness. Training and awareness needs to be more public and applied to regulators and industry. Otherwise, you will end up with many warning letters from a reviewer surfing the Apple Store that is doubling every year. This is much bigger and crosses many different devices than may be FDA or industry realizes. Okay. So we have that awareness comment.

And this one is very interesting. And I guess it covers a broader swath than mobile apps, but it's specifically addressed to mobile apps here, and the question is what role does FDA play in regulating the security of a mobile health app device or accessory to assure that it won't be subject to hacking attack? There's pretty of press around that, and this again gets to assurance of safety, and it's a bigger issue than just mobile apps. I'm not even sure I should even throw it out there for the Panel, but I will ask, does anyone have any thoughts on this particular topic? Kent definitely does.

MR. DICKS: Yeah. Sorry about that. The way that we address security on it is through abstinence. I mean we go through and make sure that the data, the HIPAA-related data is not stored on the device outside of the cloud. So if you have data that's being brought in like a glucose reading that's, you know, a glucose reading, a date and time, you're going to get a 17 digit number that the only person who knows what the relationship is to that patient is behind the cloud from that standpoint. The other part is we go through and do, you know, SSLs, you know, security layers, encryption, everything we need to be able to do that to encrypt a small amount of data. So the amount of data that we try to do outside of the cloud or the internet area, the back office, is very, very, very small.

DR. IYER: I think maybe just to add to that, that realm I think NIST has done a great job of providing guidelines in terms of authentication, encryption and non-repudiation of data, whether it's on a device, whether it's on a link or it's in a server, or in the cloud, and I think those guidelines are available. We follow them. People should follow them. It's a little bit of extra work. It's a little bit of overhead, and you have to fundamentally change your architecture. So, for example, you can't use SMS to send PHI data because SMS is hackable. You have to figure out another way to actually embed that functionality in your application, but those guidelines are well established by NIST, and we should all follow them.

MR. WATSON: Before Bernie comments, I just want to say if you have a question, please come to the microphone.

MR. LIEBLER: This is a subject I debated bringing up and decided not to because I mean, for example, encryption is inappropriate for certain devices. You can't do it because of the power consumption factors, but it's an area that we need to address and we probably need to address under the FDA/FCC MOU and something that we're going to be talking about, you know, at another venue fairly soon, not publicly, but I think we all have to get together on it.

DR. HIRSCHORN: What I've seen historically, I've seen medical applications that perform certain functions that had no thought at all to security because they were meant to be used within the confines of a hospital or department, but some of them were web-based, you know, and so meaning they were to be used on an intranet but not on an extranet, and when you ask the company, they say, well, we want to put this out there because, you know, there are people that are not within the confines of our institution or our on land that need to be able to access this information, and the vendor would turn around and say, gee, we hadn't really thought about that. Why don't you slap on some external, you know, security onto it, you know, some kind of firewall that they have to jump through first in order to get into your land and then use it, and we tried that, and we found that that wasn't going to work very well. Basically the doctors said forget it. It's too much of a hassle, carrying a key file, whatever it is to try to jump through that first hoop and then to have a second layer of application of security to get in. If any bank would have done that, they would have been out of business in two days if not less. It's not workable.

What we'd like to see from industry is the recognition that, and I think industry pretty much already sees this, but it takes some time for medical software manufacturers to catch up to this is that we need all these applications to have security built in, that it can't be an afterthought, it can't be something that is someone else's problem. No. The same way that the patient, you know, that a person dying to get online to reserve my airline tickets, a patient needs to be able to get in to see their health information, and their doctor needs to be able to get in to see their health information in a secure manner. It can't be an afterthought. It can't be someone else's headache. It needs to be part of the application that is meant for an end user to see. You can't just assume that someone else is going to take care of security because it gets in the way. The manufacturer can't come back and say, let someone else harden that server, I don't know how to do it. Too bad. No. That needs to be something that is thought about by every manufacturer who is putting a system out there that's going to put information out there that people are going to access. It's no longer just within the safety net, the safety walls of a local intranet, work behind a firewall.

MR. WATSON: I don't see anybody coming up to the microphone at this point to ask questions. I'm just double-checking that this gentleman -- maybe I'm wrong. We have one question. Okay.

UNIDENTIFIED SPEAKER: One question. I'm probably -- I'm from Telecare, probably one of the most newly minted 510(k) recipients in the medical device world, and I want to echo what my colleagues just said, but I want to stress at the risk of being somewhat redundant, that there's a division. AdvaMed and the other medical device association industries represent decades of experience and affinity for the FDA process.

I come from a hybrid experience. Silicon Valley, they don't know from 13485 and they don't know from 60601, and the kids in the garage are not developing to a quality system. It is not happening, and so as we talk about innovation and trying to integrate accessories and applications which, you know, we did it all, just like these gentlemen did, and Telecare was more than comfortable with making the investment however remarkable it was, but we're going to see a shift where capital will not come into the accessories applications area in healthcare because of this uncertainty or the incremental cost which I think is being understated as Kent said by one order of magnitude, and if you're developing little applications, we have guys on our team that are on the iStore and have developed apps, and the cost to do this is orders of magnitude less than what we do in the medical device arena.

That dichotomy has got to be figured out by the FDA with more certainty, and frankly I think the quality system side of the regulations and the guidance has got to be more nuanced because if it's not, I think some friends of mine in the private equity world here that I've had as investors would say I'm not writing that check because I can go into the smart grid for the same money and have a higher return. And so you're going to see their boundaries get less for their ideas, or we're not going to see the innovation come in or companies like ours have to make a lot more investment to carry the apps and the accessories. I don't think that's what we want with the cloud and the current Administration's policies. So those are my comments.

MR. WATSON: Thank you. Scott, Bakul told me he would cut me off when it's time. So I'm going to continue going until he tells me otherwise.

MR. THIEL: I'll incur his wrath, and it's just a brief comment.

MR. WATSON: Last comment. I'm sorry. Scott's going to be the last comment. I got the cutoff right now.

MR. THIEL: All right. To follow up on the gentleman that just spoke, I think that one of the things that FDA should take into account is they've got a new audience that they're writing to, and I think that they tried to do that with this latest guidance document because the appendices that were in the back of that, that's the first time I've seen lists of the CFRs in a guidance document like that.

So I think that there was some thought to that, but historically FDA has been writing to people that spoke the same language, people that have been immersed in the healthcare industry for a long time, and right now you're writing to an audience that doesn't necessarily speak that same language.

And so I think there needs to be a realization for that and maybe push the envelope a little bit further even to say, all right, let's makes sure we get this into their hands and that they understand these kinds of things.

Again, I think that there's been efforts that have been made in doing that in this guidance document, and I think it's a great first step, and these open forums like this are a wonderful way to draw more comments in, but I think that you might need to go one step further with that and put it in their hands.

MR. WATSON: I want to thank the Panel this morning. Thank you very much every one of you, and I think what's up now, Bakul?

MR. PATEL: Thank you once again, Panel. It's a great discussion. I think we can go on for a whole day just talking about this. Unfortunately there's like other interesting topics that we could probably continue working on, and I have to just say, this is not the end all, these two days and day and a half is not the end. They intend for this discussion, the two-day discussion is purely to stimulate thoughts so you can actually provide comments, written comments to the public docket.

A few folks I forgot to mention this morning, a few folks. We had open public comment sessions set up where three of the, is one going to happen right now, right after I'm done speaking, and then there's one in the afternoon and one tomorrow. People who had indicated that they would like to present and make public comments have already signed up, and we allotted some slots for them. People who have not indicated that they want to make public comments during these sessions, please go to the registration desk and sign up your name so you can actually do those, and once you've done that, right now as I'm going to do, I'm going to call up the presenters to come up and give a five minute oral presentation.

Unfortunately, we won't be able to provide any video or audiovisual support to that. So it's just remarks without visuals would be better.

So with that, I'm going to start off with Dr. Julian Goldman from Mass General Hospital, Partners Healthcare.

DR. GOLDMAN: Thank you, Bakul. Wow, this has been an exciting morning. I will jump right into the comments that I have prepared. I'm not used to reading comments, but there's always a first time.

My name is Julian Goldman, and I'm the Medical Director of Biomedical Engineering for Partners Healthcare, Director of the Medical Device Interoperability Program at CIMIT and Mass General Hospital, and the principal investigator of a 5 year, $10 million, NIH-sponsored grant on the development of a healthcare intranet for improved health outcomes. CIMIT is a Boston-based nonprofit consortium of hospitals, research entities, and academic institutions.

The NIH grant is also part of the ONC SHARP Grant Program. That's the Strategic Health IT Advanced Research Project, a grant program, where in that program it's listed as medical device SHARP, if you look on the ONC website, and we are focusing on medical device interoperability to enable innovation and means to innovate throughout the ecosystem of medical devices.

The future will see interoperable medical devices acting as sensors and actuators for applications that are from third or fourth or fifth parties. Much of that was discussed today.

How will we as healthcare delivery organizations develop systems to optimize the health of our patients, assure systems work as intended and capture adverse events, adverse events to patients or perhaps device failures for reporting, as well as for analysis, such a root cause analysis, in view of the increasing complexity of the system and the indefinite intended uses of the system?

In preparation for these comments, we held meetings of both the collaborators of the medical device SHARP grant and members of a Medical Device Interoperability Safety Working Group, a group that has met regularly since the January 2010 FDA Interoperability Workshop that was co-sponsored by the Continua Health Alliance and CIMIT, and we have met to characterize levels of interoperability, the hazards that derive specifically from interoperability and various means to mitigate those hazards. Of course, the purpose of that is to identify and facilitate a pathway for regulation.

We are working on implementing four very rich clinical scenarios over the remaining four years of this five-year grant. One of these scenarios I'll mention briefly because it's especially relevant to today's workshop.

In that scenario, it involves the use of telehealth devices that are brought to the hospital with a patient. So imagine in the not too distant future, a patient is brought by ambulance to the hospital wearing multiple sensors, EKG strip, MIBP, continuous glucose monitor perhaps, and you can make up the rest, and actuators, such as an insulin infusion pump.

So what happens when the patient's home health hub, that device that carries the patient ID, remains at home when the patient and device are moved to the hospital? Can these devices be left attached to the patient in the hospital and used for monitoring while the patient is in the emergency department or perhaps while they stay in the hospital?

Well, since most telehealth devices don't have alarms, another part of the health IT system architecture may have to supply those functions.

So these and some of these other questions are what we're dealing with within our grant and that we are implementing. In order to address these areas, we're working on the functional and safety requirements for this scenario, including addressing patient ID management, device ID management, security of clinical data, and an implementation of clinical and technical alarms for the devices.

We're working on a suitable system architecture based on the standard, ASTM standard F2761, which is a standard for the integrated clinical environment. Our deliverables will include publicly shared use cases, workflows, reference implementation of interface software, some of it based on the work of the Continua Health Alliance, and verification and validation tools.

We'll be sharing our results publicly for use by the FDA, manufacturers, and academic researchers, and we invite those with a similar interest to collaborate on any or all of our projects, including pilot research implementations in our interoperability lab in Cambridge. My e-mail address is jmgoldman@partners.org. That's five minutes. Thank you.

MR. PATEL: I'm learning as I go along. I should have just announced all of the presenters up front so they can be ready for the next time. Dr. Dean Kross is next, Jovianna DiCarlo after that, Jeffrey Dygert, Mark Richert, and Saurabh Aggarwal. If you guys can come right up when your session's here.

DR. KROSS: Thank you, Bakul. Great presentations this morning. Great discussion. I may run over by about two minutes. That may sound longer to some of you depending on your viewpoint.

I thank the FDA for its actions, this guidance, and appreciate all you're doing to protect the safety of my patients. As a physician user of HIT, I have observed, researched, studied its unintended consequences, defects, and role of medical errors, adverse events and never events. They are primarily due to flawed design, defective code of devices, interoperability inefficiencies, and derivatively due to poor use of usability human factors that provoke new errors.

In my work, I've come across several confirmatory websites that have information on HIT difficulties. One in particular is www.tinyurl.com/marcuswelby that might be of interest to you folks.

Until now, no one with authority to do something has asked if maybe some of the problems and risks of HIT devices require closer scrutiny before deployment. The draft guidance is an important step because the FDA is taking a hard look at the impact on patient safety from at least some components of HIT. However, in my opinion, this guidance is not stringent enough and that quality will like improve and be more useful with more stringent regulation.

The medical community, HIT marketers, and politicians have high expectations and that mobile medical applications will transform healthcare and will provide safe and efficacious enhancements to the diagnosis and treatment of disease but, in fact, we don't know that.

We as physicians need to be sure that the medical devices we use are safe, usable, and efficacious. As with any medical drug or device, we need to know the incidence of adverse events. Like a lot of things in medicine, when you actually test it in a randomized control trial, you may find out it doesn't work.

As a brief digression, for example, the New England Journal of Medicine and front page media recently reported that contrary to widespread expectations, intracranial arterial stents used to treat stroke caused more harm than good.

Optimism is not a substitute for rigorous trials. This could be the case for MMA devices, more harm than good. We don't know.

For this reason, the FDA needs to close an enormous loophole in the draft guidance. As drafted, it excludes from its scope those apps that "perform the functionality" of an HER, or electronic health record, or PHR, personal health record. These terms are not defined and all too easily can be stretched to include apps that are directly involved in diagnosing and mitigating disease.

A device performing solely the function of an electronic library of records is distinctly different from the electronic ordering devices called CPOEs. This is demonstrable insofar as CPOE functionality is isolated and CPOE is activated separately and independently from the EHR. Clinical decision support is similarly unique.

The draft guidance needs a precise boundary between the excluded EHR, that is the electronic library of records, and the electronic ordering and clinical decision-making support devices. Unlike EHR, those

MMAs that will be involved in electronic ordering and decision making will be directly affecting patient care and should be stringently regulated as the risks to the patient are high if they fail.

Of additional relevance to the CPOE issues, pertaining to MMAs, a recent study showed a greater than 300 percent increase in errors consisting of medication duplication orders after the CPOE device was activated, and another study of computer-generated prescriptions showed a 12 percent error rate comparable to handwritten prescriptions. That error rate could well be higher with MMA devices with that functionality. We do not know.

We know that with this loophole or suspect that with this loophole, some vendors will strive mightily to squeeze their apps in to the apparent non-categories of electronic health or personal health records, but that's not how it works in the real world. If an app is used to support either real time decision-making or ordering, they must not be excluded from federal oversight.

Thus, the draft guidance must exclude only the apps displaying the historical records and PHR but not the apps that are used for ordering and decision support that affect real-life outcomes.

As to whether oversight stifles innovation, I believe not. There have been decades of unfettered deployment of EHRs and CPOE devices, but still believe us, there is not even a basic search functionality on the EHR applications with which I have worked to determine if the patient ever had received the particular medication or tests. Instead, these devices are ancient, hostile. For instance, they force laborious scrolling through silos of data and progress notes to find and sort information. This is but one of many examples that the absence of regulation and oversight does not stimulate or increase innovation and vice versa.

Finally, the FDA has asked for recommendations about how best to oversee MMA devices. I submit that the model used by Medicare, CMS for investigating stents in intracranial arteries of stroke patients may be relevant to MMAs to foster recruitment. CMS would only pay for the stents if the patients were enrolled in the study. Here the FDA could say to the MMA vendors, okay, we'll let you sell your app, we'll approve it, but every patient whose care is affected by it must be part of a study of the app, say a comparative effectiveness study.

Additionally, these apps should make available audit trails and results data sheets, and there should be meaningful and specific identification of the vendor that should be readily available to the user to report adverse events. An editorial in the New England Journal about the stent study and the CMS policy concluded that, "The FDA and CMS must be consistent gatekeepers for the distribution and diffusion into clinical practice of technology that affects quality and cost of clinical care." I agree with that statement. There is much this Agency and the medical community has learned from the decade of unregulated and experimental HIT.

With this draft guidance, the FDA has taken a very important step to assure that HIT is safe and efficacious. Thank you.


MS. DiCARLO: Hello. I'm Jovianna DiCarlo. I'm the CIO and CEO of the International mHealth Standards Consortium. My background is 20-plus years of medical device and direct development, and for the past 7 years, the executive level for start-up of clinical informatics companies, and a lot of the comments that I've heard consistently this morning about, if you're in the medical device industry, and you've been developing medical devices, to us, there's a lot of information that is already existing here that can be relatively mapped over to the mHealth environment. In fact, so much so to where there's not many gaps.

So, you know, one of the things that I wanted to echo on the earlier panels, and they talked about how important it would be to define sort of like the mHealth product development life cycle, if you -- that's what they do currently with clinical trials, clinical investigations, computerized systems utilized in clinical trials.

The SDLC is currently laid out and mapped, and all of the applicable requirements are mapped to the product life cycle in development.

So I really echo and feel strongly that if the mHealth product development life cycle were defined, and then existing current guidance is then mapped to this, to the definitions, and also the user definition, and the relevant guidance, there really are not many gaps, and I think that this would be really helpful and a nice starting place to start certainly.

I also wanted to talk about the current industry and PHR with the EHR systems and mapping to clinical informatic systems, which we think of as data collected for human subjects' protection, which falls under FDA guidance. So anything with a medical device or clinical trial falls into electronic data capture systems or what we call clinical informatics. This data is regulated by FDA, and we have very clear guidelines. We are very familiar in the industry, and it's completely applicable and maps over to mHealth software systems, and even the security, safety, how things also can be configured.

With regard to the EHR systems and having FDA jurisdiction over EHR systems, the reason why that this has to and is going to be very important is that the interoperability between these EHR systems are -- the information is collected and will go eventually into electronic data capture and clinical informatic systems. So in order for any data to go into the highly regulated clinical informatics or electronic data capture for clinical trials, there is, you know, specific regulations and guidelines that have to be in place in order for that data to be recognized and that system to be compliant.

So if you take that a step further, and you look at some of these mHealth applications, that the consumer is populating their own medical information, their own PHI, whether it's medication that they're taking currently or some test results or even blood pressure readings, potentially they can provide access to physicians, and if they're in an emergency medical situation, maybe first responders, and so potentially that information is consumer populated information, would actually be conveyed to hospital emergency situations and be added into the electronic medical record. So we have to make sure that that is, how do we, you know, ascertain if that information is correct if the patient has upgraded their information of what medicines they're taking and that sort of thing.

So everything falls certainly down-cycle, but since interoperability is going to happen, it is happening, the PHR and electronic data capture, clinical informatic systems, they are combining. And so with the FDA jurisdiction over the electronic data capture and certainly for clinical trials, that information is available; if we just map it to PHI and also mHealth applications, it will become very clear.

So those are some of the comments that I wanted to make today.

I think also from a, you know, funding perspective, we're going to see more and more, you know, we're going to see more and more venture capitalists providing monies and being very selective about what companies have, you know, chief regulatory officers or chief quality system officers because all of this is paramount to the commercial viability of their products.

And so I think as investor education comes along, I think they're going to be a lot more savvy and they're going to be really looking at companies that have these quality systems in place and that are familiar with the regulatory landscape.

But, you know, Bakul, I think this is a fantastic that you've held today and certainly look forward to more industry collaboration with FDA and certainly would offer to help facilitate any sort of platform with regard to mapping over the current regulations in defining a mHealth product development life cycle that would also map users and functional specifications so that we can further define on a granular level, you know, what the direction would be as far as addressing any regulatory gaps. Okay. Thank you.


MR. PATEL: So the next speaker, Jeffrey bowed out. He said he's not going to present. Mark Richert, if you're in the room, please come up to the podium and give your remarks.

If you're not, Saurabh Aggarwal, if you're in the room.

No. I don't see anybody standing up.

Well, if those folks are not here, we have another five minutes. This is an opportunity if somebody really wanted to come up here and provide remarks towards either the session we had this morning, please stand up now, or else we'll just break for lunch at this time.

Going. Gone.

All right. We'll break for lunch and we'll be back at 1:00. Thank you.

(Whereupon, at 12:06 p.m., a luncheon recess was taken.)


(1:05 p.m.)

MR. PATEL: Welcome back, everybody. Hopefully we'll have an equally interesting Panel this afternoon. We're about to start Session 2, talking about accessories.

So as part of the notice for -- we actually put out a couple of questions. One of those questions is when a mobile app connects to multiple devices or different classifications, what classifications does the mobile app take? The purposed approach, the general purpose approach that was used in mobile apps was if you make a device that is stethoscope, you follow the classification role and the risk associated with that stethoscope. Same thing, if your mobile app becomes an EKG or ECG, you follow the risk classification, which means you follow the validation and follow the controls associated with those, and for people who are not familiar with FDA's lingo, there are classification buckets or classification numbers that are associated with each device.

One of the things so far we've been doing, or we have been following and as you may have heard about the accessory rule, the accessory rule basically boils down to the simple way of explaining is if you connect or if you become an accessory to an ECG or MRI machine or an EKG machine, you follow the same level of classifications because you have the same level of risk associated for that particular type of treatment or use condition. So that's a very broad general rule.

The question on the table for Session 2 is when a mobile app in this case could attach itself to more than one medical device and could be of Class I, Class II, Class III, what's the right approach to take in terms of classification? What is the right level of controls need to be in place for such a mobile app who is doing different things?

So I'm going to read off the three -- we propose an approach. I'm going to read off the outline, and Panel 2, Panel 3, I'm sorry, is going to talk about where this is heading. We described the tip of the iceberg by saying that you may connect to multiple device, but maybe there's other things going on in the commercial world that we need to explore, and Panel 3 is going to explore that, the future trends, how accessories to mobile medical apps fits or does not fit the traditional definition of an accessory, trying to figure that out and to get ahead of the curve in understanding how commercialization using off-the-shelf computers, off-the-shelf devices, off-the-shelf parts, getting assembled at the end user or at the patient's level is changing. How people -- as interoperability we talked about all morning, how interoperability changes the level of accessory because you're connecting, either by collecting data or you're controlling that particular functionality on a remote traditional medical device.

So taking all of that into consideration, we proposed an approach, and it's again based on the intended use. If an accessory that does not change the intended use of the original medical device that it's connecting to, it would be considered or becomes just an aid, we propose that it could be considered as a Class I, which is just information-gathering accessory.

So part 2 of the proposal was if an accessory that extends the intended use of the original medical device it's connecting to, then it would need a different level of classification depending on how much it extends. Again, the risk-based classification, the risk-based intended use comes into play there.

And the third part to that would be an accessory that creates a totally new intended use. That would be no different than what we classify today for medical devices coming on the market and says here's a new intended use, is classified as and we look at the risk of it, and so using that paradigm, we propose the three PACS so to speak for accessories.

Panel 5, Panel 4 is going to discuss that approach, and I've gathered in that Panel, folks have been thinking about this for a while, to sort these out, the approach that we propose is, is it appropriate? Are there other alternative ways?

So I'm going to go back to Panel 3. Bryan's going to lead that discussion on current and future trends in connecting accessories to medical devices, and if I can ask the Panel to focus on not only in general medical devices accessories but also try to focus around in finalizing the guidance about how mobile apps fit into that picture and how they are changing the world of accessories.

With that, I'm going to go ahead and call Bryan to the Panel, Bryan Benesch from the Office of Compliance at CDRH. Brad Thompson is here. I saw him. Chuck Parker, Jorge Valdes, Dr. Sikka, Neal Sikka, Marc Anderson from JDRF. So I think this will be a great discussion and look forward to this.

You know, the half day is done, and somebody gave me to announce this earlier, and I totally missed it. WiFi access is available here, and, sorry about that, and somebody reminded me again. So I have to do this now. Otherwise, it'll be too late in the evening. The password is guestaccess, all lower case, g u e s t a c c e s s. So I'm sure you guys are already on there. You didn't wait for my announcement.

People who have not signed up for public presentations or public comment, open public comment period which is at 3:30 to 3:45, please go ahead and do that out at the registration desk and I'll pick up the list before that session, but having said that.

MR. BENESCH: My name is Bryan Benesch. I'm in the Office of Compliance, and one of the roles that I play within FDA is to make determinations as to whether or not products that inventors come up with are medical devices or not. So I act as an arbitrator for a lot of these decisions that Bakul has been coming up with for mobile apps.

So as he said, we want to focus on what is the future trend for accessories associated with mobile medical applications?

So traditionally an accessory just physically connects to a medical device. As we heard earlier this morning, there may be situations where you have many products tied in a string until it ultimately gets to the device, and that's not a situation that we generally see or that we generally regulate.

So I want to start off by asking each of the Panel members to just begin by telling us what they think the future will bring in the next few years regarding what we should consider an accessory, and I'll throw one out.

In the automobile, there are mobile apps that are now available when you get in your Ford motorcar that can tell you if you need to take an insulin shot or things of that nature. So that's an interesting platform that we might need to consider.

So why don't we start with Marc at the end.

MR. ANDERSON: I'm Marc Anderson from the Juvenile Diabetes Research Foundation. I think we're pretty excited about this draft guidance. I think it starts to get to the heart of the matter for type 1 diabetes. This is a mobile therapy to begin with. It's something that a person deals with daily on an ongoing basis, and by being able to use a mobile device to coordinate their multiple regulated devices starts to actually prove beneficial to quality of life and to compliance and adherence to their therapy.

I think one of the things we're going to talk about a little bit today is, you know, where do we go from there with mobile devices in this connectivity. I don't think that I'm ready to talk about the car being part of that, but I think when we start to take, you know, an insulin pump, a continuous glucose monitor, and a blood glucose monitor, and start having those interacting in an integrated fashion with a cell phone, we start to make things possible like artificial pancreas systems, also remote monitoring for caregivers, you know, that usually ends up being a parent that's caring for a child with diabetes, but allowing, you know, caregivers to be a larger part of that therapy on a daily basis when they're arguably remote from the person in their life with diabetes.

So I think, you know, hopefully we'll be talking a little bit more about that in this Panel.


DR. SIKKA: My name is Neal Sikka. I'm an emergency physician at GW. I see two roles in my daily practice. One is we do a lot of telemedicine services, and we're part of a multispecialty group practice. So we have pressure to start improving outcomes for our patients. So that means a lot of home monitoring, remote monitoring types of services which crosses over into our telemedicine services and into our ER discharge patients and hospital discharge patients. How are we going to reduce their readmissions?

So I think it's a lot of the extension of devices that people are going to have in the home as well as in the facility and how are we going to centrally operationalize an efficient mechanism to monitor those patients and interact with the data that we can receive now and improve patients' outcomes over time?

MR. BENESCH: Let me just make one -- for those people that are using Twitter, they're reusing the one that we used this morning, FDAmhTrend, T R E N D. Okay. Jorge.

MR. VALDES: My name is Jorge Valdes, and I'm the Chief Technical Officer at Dexcom, and we make a continuous glucose monitor. For people that don't know what that is, it's a blood glucose monitor that gives you a reading every five minutes, and today the product's wireless but it really goes to a proprietary handheld and, you know, I work with Marc a lot, and when you look at all the studies that JDRF has performed and all, one of the biggest factors to determine how well the product works and how much of an impact it makes in someone's life is how often they use it.

So when you look at both discretion and use of a product, obviously connecting to something like a smartphone will make a big improvement in people's lives because from a privacy point of view, you can be looking at your blood glucose and no one else knows that you're looking at it. You will use it more often, and I think then it opens up an entire world of possibilities of what you can do because when you look at the entire ecosystem that's available on a smartphone, it's a huge improvement for what a company our size could ever develop on their own. And you take even the simple case is the biggest fear with a diabetic, which is really going into a coma at night and never waking up. You have your alerts on a smartphone, and somebody's not acknowledging those alerts, you could actually start sending out messages that something's wrong, and that's something that today without a lot of gear, that I haven't seen readily available, you wouldn't have that functionality.

So that's one set of accessories we're very interested in, and the other one is the one that's been coming up, that I think everyone sees as the most complicated and is already coming up in our area, which is having data from multiple devices going into one app, and in fact, that app may not be even the traditional model where it's an app that a device company makes for their own device. It could be a third party, and the exact example right now would be an insulin pump and a continuous glucose monitor and a third party coming and wanting to take both that glucose data and the insulin data to try to provide some information about how a diabetic is doing and what they should do going forward.

So, yes, that does present a complication probably in the regulatory side, but I do see a lot of value in that, and I do see things headed in that way because we get those requests all the time.


MR. THOMPSON: Well, I'm Brad Thompson with a firm called Epstein, Becker and Green. I really wear a couple of hats that are relevant to this meeting. I'm the FDA counsel to the Continua Health Alliance, and I'm also the general counsel to the mHealth Regulatory Coalition. And I am the least sophisticated person in the room when it comes to technology. I mean I'm the liberal arts guy. I'm just thankful I have a job frankly. (Laughter.) Latin seemed a lot more useful 30 years ago than it seems today.

So I'm not going to so much focus on the specific technologies. These guys know far more about it than I probably ever will, but I did want to offer a couple of remarks.

One is that on behalf of the Coalition, we spent the second half of 2010, so last year, really going out to a lot of these meetings and trying to meet with as many people as possible to find out where the technology was going, and we wrote a paper summarizing at least what we were hearing at that point. That's 9 months, so it might as well be 10 years ago, but in a paper that's on the mHealth Regulatory Coalition website called "A Call for Clarity." And basically we outline in the accessory space a variety of scenarios that get very complicated, and we tried to group the accessories into a few conceptual bundles so that we could deal with it when we got to the policy place, and we grouped them in generally four different categories. We have the medical devices themselves, those things that are recognized, have been recognized as medical devices and kind of serve as the parent device to a lot of these other things. And then we grouped the remainder into three additional buckets, communications technologies, those things which are really just for getting bits and bytes from Point A to Point B, networking technologies that seem so important to supporting mHealth, and then software which we put into a general category and then subdivided it. I'm not going to go through all of that. If you wanted to look in the website, you could see it there.

I wanted to take just a moment, though, in response to your question really about, you know, whether a car can be an accessory, and I want to pick up on a point that Kerry asked about this morning which is, you know, really getting a good understanding of intended use, and so I'm going to explain it. Even though she slammed lawyers this morning, I'm going to help her out. (Laughter.)

I teach a class at Columbia Law School on this, just part of the class, and I go into the room and I walk in with this thing, and I put it on the desk and I say, I make these things. Are they regulated by FDA?

Well, those of you in the back can't possibly see this. This is a stick about five inches long, and about, you know, a quarter to a half inch wide, and so I put it on the desk, and they've got to ask me questions to figure out whether or not this stick is regulated, and their initial reaction is, well, you dope, that's a popsicle stick, maybe it's food or connected to food, but that's it. But they just started asking me all sorts of questions about as a businessperson, well, how do I position it in the market? What do I say about it? What claims do I make about it? What do I do? Maybe do I sterilize it? Do I add design features that only have one unique reason for even existing, right, and what do I know? What's my knowledge?

So it all comes down to three things. My words, how do I describe it? My actions, what do I do to position it in the marketplace? And my knowledge, what do I know about how it's being used in the marketplace?

All those things together are what form intended use. Don't confuse use, that is how it's actually used, with intended use because intended use is the concept that decides whether or not it gets regulated. What does the manufacturer, the one selling it, intend for it to be used for? If I intend for it to be a tongue depressor, then it gets regulated that way. If I intended it to be a popsicle stick, it gets regulated that way. All right.

That's really important to this area because it goes to what the person selling the product intends for it to be used for. So take the car, for example. I'm not going to pick on a specific brand, but pick your brand. If they go out on a market campaign to say this car will improve your health because it can be used to deliver all these kinds of care through devices that you can add to it, they've made it a regulated accessory medical device to whatever parent devices then get put in that car pursuant to their promotion.

And you've got to dig deeper to find out exactly what their intent is because as I said, it's words, it's deeds. What design features are in it? Do they go into that car and create a power system that somehow is uniquely capable of supporting medical devices? Do they use other elements of the computer technology with protocols that make it uniquely suitable for medical devices? What have they done to tailor it? What standards do they declare conformance to? If they're declaring conformance to certain medical standards that serve no other purpose other than delivering medical care through a medical device, what does that say about their intent for that car?

So these are very complicated issues, and so my little role on this Panel is going to be, I'm going to be sort of harping on let's not just say it's a stick. How do we regulate it? We need to get to the level of, well, what are they doing to promote it? What are they saying about it and so forth before we know the answer to that question?

MR. BENESCH: I just want to clarify one thing. The definition for intended use also indicates that even in the absence of any declaration as to what the intent of the product is, if it's clear by how it's being marketed, then FDA can assert jurisdiction. So if you're just selling tongue depressors but not calling them tongue depressors, but you're only selling them to medical professionals, then FDA can say, based on the activities, that that is a medical device. It clearly is helpful when there is actual labeling or advertising or other promotional literature because then it makes it much easier on the Agency to make a decision.

Okay. Chuck.

MR. PARKER: Hi, I'm Chuck Parker, the Executive Director of the Continua Health Alliance, and Continua, in and of itself, has a significant interest in this area, specifically because as a trade association, we represent 245 member companies throughout the world that are really focused on this area and bringing products to the market space. So there's a significant interest in understanding what does it mean by the mobile medical apps, how are we going to connect these devices with the accessories because really the manufacturers, these 245 companies, that's primarily their business is in that area and specifically to getting to the device architecture themselves.

So we take a look at this, too, from an importation aspect of it. So what does it mean to bring devices in from outside the U.S. into this area and understanding what the rules and regulations are, and specifically though, how do we make sure that the interoperability of those devices doesn't become so complex that it actually potentially can stifle the innovation.

I do welcome these discussions. I do welcome this discussion on the mobile medical apps overall because it has opened up this area for us to have a clear discussion with the FDA on how we can actually bring and potentially address these open issues.

To some of the things that you asked a question about, what are we seeing in the future beyond the cars? Some of the things that we're seeing on an international basis is transdermal applications. These measurement devices are truly starting to become either at the skin or just under the skin. We're seeing the wearables that are becoming more and more light to the point where they can be almost permanently worn by an individual or basically, you know, without taking a shower. You want to take them off every now and then. But you can wear them on an ongoing basis. They're so light now that the power consumptions are that they can last a year to two years at a time.

And I think this is something that we're going to want to see and understand how these devices are passing information into systems where the end user may never see them. In essence, there's no user interface. They're going directly into the cloud, and it's reporting back and coming back in a different fashion at least in these cases.

So there's some complex systems that are out there today that are starting to show and be demonstrated. So I think we're very well attuned to that and are very interested in having this discussion on how we can address those, not only the current applications but also that we see in the immediate future.

MR. BENESCH: All right. So I've got a few questions to start out with that we had in the agenda, and then we can open it up for additional questions and additional discussion.

So one of the issues that somebody said we were, in the last Panel, is that FDA tends to be behind the curve in a lot of instances, and in this case, we really would like to be able to project out further because it's very difficult to make policy in this area and then to change it, you know. There's this large bucket that everybody wants us to put enforcement discretion into, and there's an uncertainty associated with when new things come out of that bucket, and I think that from my standpoint, as one of the decision makers in this area, knowing where we're going with regards to future connectivity of these applications with the hardware or even up into the cloud and from the cloud down the hardware is going to make it easier for us to decide what areas are we comfortable with, assigning low risk to, versus ones that because of how many layers it's going to pass through, or how many products, you have daisy chain until you get to the device or to the patient. So that's where we want to understand. What is the risk associated with connectivity? Okay. And where do you see that risk going in the future?

So I think Jorge had some issues and some other people had said that if I have an insulin pump that hooks up to some other application that then sends data to a third application which then puts it into some kind of graphing function, et cetera, until it finally gets to an EHR, okay, how are we going to, you know, where's the accessory there? Where's the connected accessory that FDA should regulate and who owns it? Who's responsible for ensuring that those accessories will, in fact, work with one another?

So I think to open up the discussion first on that issue, and I'd like to start with Neal.

DR. SIKKA: Tough one for me. I want it to work, and I want to make sure that the data I get at the end is accurate and reliable and useful. So, you know, all those steps have to have fidelity to them, and I'm not sure exactly who's going to own each of those processes, but when I purchase a product from a vendor and put it in my practice, like I said, the end result has to be accurate and reliable. So that has to be followed up the chain.


MR. VALDES: Okay. So let me try a couple of different layers to your complicated question and, first, let me make one comment. I think, and I'll help you guys out on this one. I think that people are requesting a level of specificity from the FDA that's going to be very difficult to achieve because this area is moving forward so fast that for you to try to get ahead of every issue is going to be a very difficult task, but that being said, I think there's probably some simpler areas if you look at it.

So when I look at accessory devices, and I think the first level of an accessory would be just taking data, for example, for a glucose meter like ours and moving it up to the cloud and then bringing it back down from the cloud and viewing it on an iPhone or tablet or an Android phone, I think you can break that up into certain portions of it because there are some portions that I think are more contained.

For example, moving data unaltered from Point A to Point B, I think is the simplest of all those that we can try to make sure, at least the regulation is pretty clear on that one.

I think where it starts to get more complicated is when you start doing analysis of the actual data and manipulating either the graphics of how you view it or actually the analysis that you do on the data. When you look at, for example, on our product line today, we do that on a PC platform, and when that gets done, that actually is a filing for our current product, and I actually don't necessarily disagree with that because we are providing -- we are changing the way someone views the data and you want to make sure that's being done correctly.

Where I think it starts getting more complicated now in this level is the one I was bringing up. For example, when you take the data from the insulin pump and from our product, you then put that together. You then want to run analysis on that, and I have questions as to even who owns the filing for something like that because, for example, today when we work together with an insulin pump, an insulin pump is a 510(k) device, and we're a PMA device. We are the parent, and we own that filing. Now, I don't know what happens when a third party comes in and wants to take the data from those two devices and do something with it, and I can see that going further up the chain as there are more and more value-add companies that want to do more with even broader ranges of data.

But I think where the regulation really should sit is a place where analysis is being done of the data and not just Point A to B, and let me just give you one last example of that I can see. I can easily see a system where you're uploading data from body-worn sensors, and I do think that body-worn sensors are going to become more common. Glucose is just one of the things that you can actually monitor. There's a whole slew, and you're going to see them coming out to market more and more. I think the moving of the data is the simplest one because you're moving data from Point A to Point B.

Like I said, the analysis, where it ever gets done, whether it gets done up on a web server or whether it gets done locally on a tablet or a phone, those are the areas you want to regulate. I think there are simpler models that you can try to get to where you can do most of the analysis up on the web, when a lot of the analysis on either the tablet or the phone, to try to keep that part out of as much regulation as possible.

But I think that's the simplest model where it's going, and I think the model of how you layer on more complex things, I think you guys in the draft did make a good point that you may be grabbing data from enough individual devices that the actual regulation or category that the end product may get may be higher than any of the individual medical devices or components it's connecting to, and I don't know any way to handle that today other than a case-by-case basis. It would be very difficult to try to anticipate every single version of this.

So I think you could be a little bit more clarity in some places. I think unfortunately a lot of it you're going to have to handle case-by-case going forward.

MR. PARKER: I think the first thing that we'd like to talk a little bit about is understanding, too, the difference between a mobile app controlling a device as opposed to a device that has a current, clear, sort of certification model today.

So where you have a mobile medical app -- let's take it for example, there's a couple of ways that you can look at it. So the device passes information to a mobile medical app which takes the data untransformed and passes it onto a service on the back end for medical decision-making. You have also the medical device app which actually will present the information, maybe some analytics as Jorge actually mentioned to that, to provide some feedback. And there's a third category where the mobile medical app then actually controls the device. In essence, it may reset it. It may actually tell the device to do something along those processes. I think those are three different levels of risk that you have to take out from the mobile medical app perspective itself.

In each one of those cases, there's a different parent-child relationship in that at some point it starts to change it in its model as to which one should have a higher regulation aspect perhaps to it from a risk model perspective.

The second component of that is that I think it's not about daisy chaining. I think it's more of a pinwheeling if you will. So if you put together several devices, in essence, you know, you may have a glucose meter, continuous glucose meter, that's going to also potentially have an insulin pump attached to it. Well, the doctor or facility who is actually monitoring this individual may also want to know something about their weight and their blood pressure. So you're going to start combining additional devices into that collection mechanism, and it may be still one single collection mechanism, whether it be the cell phone or PC or whatever the hub is that's collecting that data in a pinwheel fashion. And so I think we get very quickly to that level of how do you define interoperability, and at what point when it gets passed into that chain, where is the responsible activity?

What you don't want to have happen is, for example, that weight scale to potentially inherit a much higher level of classification than it did intentionally because it's now part of a system that's used to monitor an individual who has diabetes.

MR. BENESCH: Okay. And so that's one of the issues to consider is that, you know, in the guidance document, we have three levels of regulatory scheme for the accessories. So I want to make sure that you guys comment on that since that is contrary to our current policy where it's just sort of one size fits all.

And so in the case of the weight scale, which we do, in fact, regulate as a Class I medical device in many cases, would its connection to a mobile medical app cause it to be unclassified for some reason, or should it retain its Class I or, you know, what is going to be the determining factor for accessories, okay, in the future when you look at the risk?

Okay. Interoperability is the next panel, so I don't want to get into that in this session. What we're looking at here is, what kind of accessories do we expect to see and whether or not that regulatory level of three that Bakul provided is something that sort of fits with what the future may bring, okay, because that's what the guidance is going to be. We need to be able to move forward because as people may know, I mean a lot of people said that that guidance came out very quickly, and I had to kind of chuckle at that since I don't know how many versions of it I've seen. But once it's out, it's not going to be renewed very easily. The process just works against any kind of quick turnaround time on updating the guidance once it's out. So --

MR. THOMPSON: I'd like to start by saying that conceptually I really like the direction FDA is going in trying to develop a more nuanced approach in coming up with the three different levels of accessories. I really like that thinking.

That said, I have a couple of comments about maybe ways to enhance it. One way that I think is terribly important is that there needs to be a fourth level. There needs to be a level below the first one that you've identified as supporting a medical device. There needs to be a level of not an accessory, and maybe that's just too intuitive to state, but there's a lot of ambiguity about what's not even a regulated accessory, and I think it's incumbent on the guidance document to say, so these are all not accessories. They don't even trigger that first tier.

And I would ask you frankly to again be creative as you were in this, what you came up with, but be creative and not hold the industry to the old intended use standard of you say anything about a medical application and it's regulated. Because I think there is benefit to a car company, to a cell phone company, to any number of folks who make what might be platforms, to at least be able to identify that it is compatible with a certain class of medical technology. That on its face would look like a claim, a medical claim, but I think it's incumbent on FDA to say there's value in doing that. We don't want to raise the bar on them so much that they won't make that statement because then otherwise you end up with people, users trying to figure out what actually works together without that baseline information being provided, you know.

I tried to set up a home WiFi network, and I really needed more information about compatibility, and I wished some of the vendors had been more forthcoming with me about what that compatibility was. You don't want to discourage people from stating this can be used with this just because that one statement will trigger FDA. So I'm asking you to consider a fourth level of actually non-accessory.

I think then your lowest level is a good concept which basically correlates to Class I. I would just ask you to be a little more precise in how you characterize it because I've read it a few times, and I don't fully understand. I get the big picture what you're looking for, but then I think about all the technologies that come across my desk, and I get a lot of questions in my own mind.

One of the things you have to deal with is so much of this stuff is movable. Proximity to the parent medical device can't be the defining characteristic of whether something is used and therefore regulated. Whenever I talk to somebody about what their mHealth system is, they say, well, we can put this bit of software on the parent medical device or we can put it over here on the computer that the user is using. We can put it up in the cloud. We can put it on the cell phone. I mean you can move functionality throughout the system. So proximity within the system really shouldn't be the determinant of what gets treated as a Class I in this scenario and what doesn't. I would ask that we focus much more on functionality.

With that said, I really like the direction you're going. I like the thought about using, stratifying the different purposes for which it can serve and changing the classification on that basis.


MR. ANDERSON: Well, I think one of the things you just mentioned was that where let's say the decision capabilities of a system of devices or accessories would be located shouldn't be the underpinning of what the device ends up being, but I think that might essentially be how things are going to be classified.

We'll just take a simple example of a continuous glucose monitor. Currently a continuous glucose sensor determines, you know, some type of metric underneath the skin, turns that into a CGM reading, and then delivers that number in some way to some type of a display device.

I think one of the things that would determine whether the cell phone would be an accessory or not to that medical device is if that raw data is transferred to that phone and the phone makes a decision as to what the actual CGM or blood glucose level is at that point, as opposed to that approved medical device sensor worn on the body making that decision and then just blindly sending out and communicating a number. I think that's the nuance here as to how that would end up being classified.

So I do actually think that, you know, where that decision is being made will probably be significant to that, and I also think that, you know, when we think about multiple devices connected in some type of a system, it's ultimately going to be viewed as to what the expected or intended outcome of that information on the actual health of the patient or person is going to be. I think that in a lot of ways we can imagine very simple, you know, what we'll call risk, low risk, you know, therapies or situations, and then we could think of like in an artificial pancreas situation, where you're taking multiple information from multiple devices making a decision that actually feed back into that loop, and you end up with a completely different type of a device than let's say the first device started with.

MR. BENESCH: Let's get back to, you know, we're looking for information on where's the data that the app is going to create going to show up? Somebody commented in something I got sent that maybe it'll be in your wristwatch that you'll look down at your watch, and there will be a display there, you know, virtual reality. Maybe while you're sitting there playing WiFi, it's going to pop up that, you know, your blood pressure's too high on the screen.

So those are the kinds of things that we need, you know, sort of the crystal ball look, okay, because these are all commercial consumer technologies that we generally don't regulate although the Wii has certain applications that would make it a medical device.

So that's really what we're trying to understand is that if you have any insight in the kinds of things that, you know, everybody will be wearing shifts that have sensors in them, okay. But is that going to mean that when you look up at the TV screen that's on your wall, that it's going to have all that data on it? Or is it only going to go to the doctor's office and show up in some app, you know, that they do or is it just going to go to an EHR?

So we really need to understand because there may be intermediate products that we decide aren't accessories as Brad is asking. So you may skip a couple in the interim, or maybe they'll be in MDDS, and then you've got the final one that's actually doing the analysis and we may say, well, okay, that's the accessory and the intermediary steps aren't. Okay.

So that's what we're really looking for. If you don't know the answer, that's fine, but we're just hoping that, you know, you may be able to give us a clue as to where we're going. Let me start with Jorge.

MR. VALDES: Okay. So let me take the simplest one since he's kind of started going down that path, because I actually do like the fourth option that was being discussed about compatibility because take the simple one of looking at your glucose value on a watch because I actually think that's actually a pretty useful product back to, you know, being discreet about the fact that you have diabetes. I would really look at applying the regulation at the place that the calculations are being done, and I think that one works really well even when you're doing one of these daisy chains, because if you go back to what Marc was explaining, and let's say on the body-worn sensor, the complete glucose calculation is being done, so all you're getting is a time stamp and a glucose value. If a watch is really just taking that data and displaying it, even if it's connecting dots on a graph, I think that's a very low risk.

Now, if the watch starts doing anything with that data and starting to present it in a different way, I think that puts it in a different category, but it would be really nice to have that kind of display, unaltered data mode, even on a smartphone to be exact, too, because it would be nice if there was an option on a smartphone that all it did was just connect to a medical device, display the data unaltered, to have a very low regulatory path. I could see the versions beyond that, if you do any control of the device or any more fancy communications, yes, it goes up, but I think there's a lot of value in having that low regulated path.

I think, look, you want this industry to develop. You don't want to get pulled into the middle of 100,000 filings on this either. So having some low-level path, and I think a lot of this still should be done under, you know, a quality system and all that's acceptable. I'm not just saying to make it a free for all either, but I'm kind of liking having a fourth option with some tight restrictions about it, around it.

MR. PARKER: You know, so to that point, I think there's several things that we talk about, and hopefully that there's some limit to the regulation, too, because as you mentioned, you start off talking about the Wii, and I think that there's a personal level of interaction which is consumer health in and of itself, which is a fairly large area that typically today has been somewhat unregulated or at least been -- the FDA has deemed it as not a significant risk at this time. Probably there will be as we start to see the use of these devices grow and integrated into gaming consoles, for example. I perhaps already see them already integrated into TVs.

So basically you have devices that can talk to a Java language. So literally anywhere that you can run Java coding, you literally have the ability now to have this medical data show up. So whether that would be a TV, whether that be on your handset that you use for your phone, you know, or any basically device that has a capability. Tablets are another area where I think you're going to see significant growth in the near future as well as a device.

But you're going to start to see this capability of growing, the information coming out of these devices from a consumer perspective, whether they be games themselves.

So one of the things that we've seen from a research perspective is that games are the way to keep people engaged in the management of their health personally, not from a medical perspective, you know, my doctor has prescribed this. I need to go do this or I have to follow it from a compliance perspective for my medical treatment. That's one section. I'm talking about keeping people engaged in actually doing things that are good for their health overall. That's one area where I think that we're going to see potentially even some more complexity from a perspective of capturing data, whether it be blood pressure, weight, from a simple perspective, blood pressure, weight, temperature. We've already seen, for example, Wii consoles that have the capability of taking glucose metering directly in the device itself.

So that's an area where I think that you're going to see growth from a future perspective that you may not be seeing currently on your horizon scans is around the gaming area.

I think that there's a potential area, too, that we take a look at from how we integrate that data, and here again when we talk about the device itself, how do we make sure that we integrate them appropriately? So you may be taking a medical device that has the capability of capturing a certain high level of information, and potentially it can now link to something else in the future, and as we pass that through the mobile medical app, what does that actually mean when I start to integrate multiple devices? And so that's something that we have to take a look at because that device information may be more important when it's combined with other data than it is today when it uses a single stream of data.

MR. BENESCH: So let's take the example of the Wii. The reason why I said that that can be a medical device is that we've gotten requests from medical professionals that are doing clinical studies for physical therapy, and they want to know whether or not they needed an investigational device exemption if they're going to use a Wii, and depending on how they structure the study, the answer can be yes.

So let's just say suppose that somebody uses a Wii. It collects their exercise data, you know, how many minutes they've spent playing a particular game, that converts to some kind of calorie burn or activity level, that ports it over to some other application, like the pinwheel kind of a model. The doctor sees that and says, okay, your glucose was controlled much better on the day that you did exercise. I think you need to do a half an hour of this every day, and just make sure that the data is provided, you know, collected, so that I can monitor that.

So would you consider the Wii now to be an accessory, or is it just what it was before, a game?



MR. THOMPSON: It's all going to depend on whether the person, to get technical, who introduces it into commerce makes claims about whether it can be used in that way, right. The practice of medicine is unregulated by FDA. It's regulated by state boards of health instead. So as long as they're operating within those confines, and as along as the person putting this device into interstate commerce isn't making any health-related claims, then it's not an accessory.

Now, say you have a big institution, a major hospital, and they say, well, we're going to use this and we're going to systematically use it through the hospital on a variety of patients. So you get into complexities around when it actually is introduced into commerce and who's doing that introduction, and that's where some of the complexities occur.

So I just want to really get us focused on the intent element of intended use, and what the implications are for the accessory status.

One of the issues, and Bakul will probably remember this, back in the spring, we had a meeting, it was at Food and Drug Law Institute, and we were talking about Class III medical devices, cardiovascular, cardiology medical devices, and there was an issue of how you connect them ultimately so that the data flows to the caregiver. And we showed linearly how the data flows, and at one point in the delivery of it, we had, I don't even know what you call them, a splitter, basically that plugs into a telephone jack in the wall and instead of having one outlet, you have two outlets. That's all it is, 25 cents at a hardware store.

And the question was, is that a regulated article or not, and there were a whole bunch of people in the room, some from FDA, some from -- this is the medical device industry. So these people really live and breathe this stuff. A number of people felt it was a Class III medical device if the company supplied it along with the device. So just the commercial operation, how was it provided to the customer?

So we came up with three scenarios. The medical device company supplies it just as a toss-in, in the kit, with the pacemaker, let's say -- I know you don't get a pacemaker kit but -- secondly, they simply say, go to Ace Hardware and buy such and such brand. We've tested it and it works. Or, they say nothing and let the elderly person figure out, well, I really want to use my phone in addition. So maybe I'll get a splitter and put it on there, right.

So all sorts of different scenarios in terms of how someone would become aware of it, how it would be delivered, how they would procure it, and all of those things had major implications on whether or not it was a Class III device, subject to a premarket approval application or a Class I, general purpose device or unregulated.

What I would love is for FDA to address the intended use questions. How does commerce and the manner in which products are delivered affect whether it's regulated? How do the claims affect how it's regulated? Because you know what? It's the same amount of risk. It's a splitter. It just splits the telephone signal. So functionality doesn't really tell you a lot, but the circumstances around the intent meant everything in terms of how it was regulated.

MR. PATEL: Okay. Now I've gone over. I haven't been paying attention to my watch. Are there questions from the audience? Anyone that wants to come up to the mic, or does anyone have any piece of paper for me? Here comes Morgan.

DR. HIRSCHORN: Just a quick comment about interoperability. In the medical imaging world, in radiology, there is from the Radiological Society of North America, there's an initiative called IHE, which is Integrated Healthcare Enterprise, where from the professional society it tried to get vendors to follow integration profiles to make their stuff actually work to produce a desired result such as, you know, patient came in as a John Doe, was a trauma, and later on his name gets changed. How do we make sure that the name change gets percolated downstream through multiple systems. It's just one system that's involved. But the end result is one end result, that we fix the patient's name in all the downstream systems which is by way of example.

So that's one that's initiated by our RSNA. It's by the professional community, but I don't know that that's regulated, and I don't know if the FDA would want to or should play a role in things like that.

MR. BENESCH: Well, the only thing that we regulate with regards to patient information is to make sure that particularly in radiology stuff, that there aren't bugs in the system where the wrong patient's name ends up on the wrong record because the record wasn't saved and the next person who comes in the room name's then appears on the prior person's record. And so those are the only sort of bug stuff that we look into, but that's just a matter of what the product is intended to do, not anything else.

Yes, sir.

DR. KROSS: Thank you. I'm glad you brought up the subject of misidentifications because they have become rather common, and there's nobody keeping a record of them.

MR. BENESCH: All right. So someone is asking, termination of what is or is not medical device data influences whether an article is a medical device and/or an accessory. When is audiovisual data alone used for a remote patient exam considered medical device data?

And then, two, how is this changed if used on a use case requiring immediate clinical response? Example, stroke assessment.

So we've had systems come in where basically it's telemedicine where, you know, you're in South Dakota and the doctor's at GW downtown and you're looking at the patient on the screen and you're talking, and you may have another screen that's pulling up data from there, an electronic health record or out of the patient's Microsoft Health Vault or something of that nature, and what part of that is a regulated product?

Well, we have classifications for telemedicine products. So -- but if it's just sort of that you're talking to the patient using Skype or something like that, we're not going to suddenly say Skype is a medical device. If the data is brought in and there is diagnostic graphing done or analysis done, we may regulate that part of the software that does the analysis, but we again wouldn't at this point regulate the actual repository, the record of it.

If you're going to make a diagnosis based on what you're seeing, then the question's going to be, is there enough clarity, enough resolution in order to be able to do that, and that may actually be something that we would regulate. So I don't know if you -- comments from Neal on the use of telemedicine for diagnosis purposes?

DR. SIKKA: Yeah, that's exactly what you mentioned is the clarity issues and, you know, is the video high def enough for us to make a diagnostic decision or if an image is transferred in a store and forward manner, is it? I think what we've done is left it up to the physician's judgment just like they would make a judgment in real life. Is my examination accurate enough? Is the data good enough that I'm seeing in person to make that decision? So I mean we've been leaving that to clinical judgment and using, you know, within the guidelines of our licensure to do that diagnosis of the patients in the right state, where I'm licensed, et cetera. All those components go into it, but really, you know, when you're providing services, you're providing services that are best available to that patient.

Usually in telemedicine situations, the patients often don't have any other alternative. So you're comparing it to them getting no specialty care or no care at all, and if you are making a decision with the best available data, with the best intentions, that's kind of been our viewpoint of it.

MR. BENESCH: So I want to ask, how does this guidance address remote control? This likely does not affect intended use but presents major risks, alarms, especially high priority alarms.

I'm assuming that we're talking about maybe using an accessory to actually reprogram the device remotely, which is being done right now with some infusion pumps I believe.

Jorge. Jorge can answer that.

MR. VALDES: Okay. So we've definitely looked at this area because as I mentioned, when we look at accessories, we can see multiple levels of accessory there. There's accessories that provide only display, and then there's accessories that provide control functions.

I do believe that when you get to the control function, you do need regulation. I think there are completely safe ways to do that today with off-the-shelf standards, but I do believe that area applies because think about it. Even a remote control that's controlling an insulin pump, you're delivering a drug, and there may be some, you know, some regulation in that process. I don't think you'd be comfortable with somebody in a garage developing an app to be able to do that.

MR. BENESCH: Does anyone else have comments?

MR. PARKER: Yeah. So I think from a perspective of developing the app itself and developing the architecture, I think that we have to consider a broader spectrum of where these devices are going -- where the information's going to come from and how it's going to control the overall aspect of the device itself.

So, you know, we are seeing specifically that question about, you know, control of the device itself, and what potentially can happen, you know. You're going to have simple things like, okay, I need to update the device. Is that going to fall in -- what's the regulatory aspect of that when we take a look at it. So if I have to simply send an update to the device itself, I'm controlling the device, but is that a risk? Well, it does present some level of risk that we have to be inherent and understand what that actually means. So I mean upstream, sending data down to that device.

A second component of this overall, and it's kind of going back to the second comment about the one right prior to that, is that we're also dealing with what is called non-linear communication in these terms as well. So we're gathering data, and it may actually reside or sit for a period of time before it's actually interacted with as opposed to a true telemedicine component, which is typically a realtime interaction and exchange. So we have to evaluate and understand what does that actually mean?

If we're not assuming that there's a high level of risk with that data, what does it actually mean from that perspective if I'm capturing that data in a longer-term environment as well?

MR. BENESCH: Someone's asking me a question about a subject we're going to talk about tomorrow, which is decision support. So I'm going to defer that for tomorrow's discussion.

And most wireless carriers offer -- this is a question for Bakul. Okay. Most wireless carriers offer healthcare networks. Are they regulated by FDA? Does the guidance deal with EV News basically?

MR. PATEL: Sensory?

MR. BENESCH: Well, that's not it. Well, if the -- well, I could see that news streams could be routed to a device as an accessory, let's say --

MR. PATEL: What do you guys think of that?

MR. PARKER: Actually, I was going to say, that's one of the things I think we're going to have more complexity to the system overall as we begin to move forward because one of the things is that ONC has been very forceful, and currently the PACA, the Patient Accountable Care Act, was very clear about was development of health information exchanges, and so you're going to see an explosion of data elements that are going to be shared as a requirement of these new standards that are being, or not standards, but legislation that's being pushed out there. There's been funding that's been put out there.

So when you get to these healthcare information exchanges, I think that's a question you're going to have to have because does the FDA regulate those or does the FDA need to take a look at regulating that health information exchange because in essence that's where data's going to be flowing into.

So we look at it from that standard, that same standpoint is that we're flowing information into it. We'll be passing information into it could be an electronic medical record. It could be a personal health record, which is something that's controlled by the individual, or it could be going into a much more nebulous healthcare information exchange in the future. So it's a way where data is going, and so are telecos going to be involved in that? Without a doubt, they're doing to be involved in that. They are the primary providers of those types of pipes in the future.

MR. BENESCH: Well, let me ask Marc. Marc, would you see your organization pushing data out to a smartphone app that's connected to someone's insulin pump based on what their daily readings are, you know, if somebody subscribed?

MR. ANDERSON: Well, I mean I think that again if a person subscribes to some type of, you know, health network that is able to help them better understand their personal data that's coming off their equipment, it may make recommendations, but now we have to think about the person making that decision on their end or if we're going to actually elicit control of the device based on that information coming in.

I think that one of the benefits and strengths here of being able to take information from these on-body networks and getting them off the body is allowing to, you know, warehouse and analyze all of this data to get a better understanding of diseases and health. So I think, you know, I think actually hopefully in a short run, but in the long run, I think we will see information being used in that way and coming back to the patient either with recommendations or possibly control, most likely recommendations.

MR. THOMPSON: May I comment on that one? Here's a perfect opportunity for the Agency to add to its guidance and add quite a bit of clarity in an area where it's sorely needed.

Data management and data manipulation are fairly general generic concepts, and a company might say, you know, our systems are really good at crunching large volumes of data, and there may be, you know, half a dozen applications out there where you have to deal with large volumes of data that need to be crunched. Maybe some of them are in defense. Some of them are in, you know, energy. Some of them are in medical, and so if a company simply targets medical from a marketing standpoint to say we can help you crunch your data and we have the hardware and software necessary to really help communicate and move data around efficiently and so forth, and it's ideally suited for large volume data such as medical data, currently that would be a real ambiguity because they've mentioned the medical use that creates at least the appearance that it might be regulated, but I think it's a great place for FDA to step in and say, no, fundamentally all they're saying is it's really good at large volume data manipulation, and they're just giving healthcare as an example of where that is useful to do.

So I think, whether you agree with me or not, whatever you would choose to say would bring clarity to that situation.

MR. BENESCH: Well, it's kind of ironic. At lunchtime, somebody sent me an e-mail that on WTOP News which is a local news station, they had a big story about Wellpoint working with IBM, Mr. Watson, and incorporating Watson into crunching data to provide medical diagnoses within the Wellpoint system. So the question to me was is Watson now a medical device? Okay. Which actually came up after Jeopardy!

So I would have to say that I'm not sure that there aren't situations where something like a Watson is, in fact, going to be something that has to be regulated by FDA. I'm not saying that we're going to. I'm just saying that, you know, if it's going to be using all this knowledge that's been programmed into it, to potentially come out with diagnoses, then the question is do you have competent, you know, medical intervention, doctors review it, or does somebody just say, oh, you know, it must be right since it did win Jeopardy! and move forward.

So that's another one of those areas where you can't necessarily carve out an answer that's going to apply to all cases.

MR. THOMPSON: I agree, but the point of this Panel was to identify areas of technology that need clarification, and I think you've hit on one.

MR. PARKER: If I can --

UNIDENTIFIED SPEAKER: I have a question along that line in terms of regulating the software and not the hardware, and as you would with the Watson, I presume the Watson software, that when the iPhone 4 was introduced by Steve Jobs, the first demo was a radiology app displaying x-ray images, and together with that, the iPhone 4 and iPad now are the dominant platforms preferred by physicians.

My question is why regulate apps and not the platforms when the apps sell for just a few dollars or even free and the platform sells for $500 or more so that Apple holds the internal processing as trade secrets and doesn't divulge that information. The hardware and internals control the functioning of the applications at least as much as the software, particularly on the display of medical images, and so my question is, why not regulate the hardware when it is integral to the application? I own no Apple stock.

MR. BENESCH: I used to.

MR. PARKER: I think this goes back to Brad's initial intent of what was the intended manufacturing purpose of the device? But I know in this case they've actually showed the radiological image, and I think this is where Brad, I'm going to connect another one of his points where he made as well, which is, you know, when he was talking about the car manufacturers and allowing them to at least say, hey, you know, these are of interest. You might want to take a look at these in the future. We're not making a medical claim that you can use this for diagnostic purposes but, hey, wouldn't it be great, you know, one of the manufacturers in the future may be able to show that type of activity in the future.

MR. THOMPSON: I'd just like to add. I mean this is an example of where FDA can do a real service to the IT industry. We talked about this in the morning, that you've got an industry that isn't accustomed to FDA rules and so forth trying to navigate them, and maybe not being completely familiar with what the implications are of what they're doing. So here are a lot of companies out there that don't know what triggers FDA jurisdiction. They're doing all sorts of things that seem sensible and so forth, and clarifying it in the guidance would do those folks a real service.

MR. VALDES: Let me make a comment, too. Going back to your Wii example at the beginning. I don't really think that a third party should be able to make a product that wasn't marketed as a medical device a medical device. I think, for example, back at your -- if it was going to be used for that kind of purpose, whoever's using it for that kind of purpose is responsible for -- and that you can validate the whole system and that applies to the phone, too.

MR. BENESCH: Okay. Let me clarify. I didn't mean to intend that the Wii globally would become a medical device. Okay. That particular physician made it a medical device based on his intention, but that's just like these monitors down here don't become a medical device globally just because somebody incorporated it into their clinical imaging system. So -- okay.

DR. HIRSCHORN: I mean just to comment, I mean we don't regulate computers. We don't say that's a medical computer or that's a medical, you know, like you said, that monitor there. So why should a, you know, desktop computer be any different, be treated any differently than or a mobile computer be treated any differently than a desktop computer in that regard? It's a generic machine.

UNIDENTIFIED SPEAKER: I can answer. But you do regulate computers and you do regulate networks and you do regulate Wiis and you do regulate Windows if it's used in a medical device or if it's used as part of a medical device or if it's recommended by the manufacturer, if it's been tested by the manufacturer to load for use with medical software.

So I think one of the big challenges is, we talked this morning about the fact that we're compartmentalizing, but we can't lose sight of the fact that what makes the medical device is the whole system. It's the hardware, the software, the network, everything that goes into that medical device is the medical device, not, you know, the components, to your point, in and of themselves; a display is not a medical device, but if you use that display to display medical data as part of a medical device, then that display becomes a medical device or part of a medical device.

So we can't lose sight of the fact that you need to look at the whole system, not just at each one of the components separately.

MR. BENESCH: Right, and to further address your question, there are cases where we have regulated the phones, you know, like there's a particular patient monitoring system that specified for primary alarm use only a particular vendor's phones had been tested and were sold with the system. So those cellular phones became part of the medical device and were, in fact, FDA regulated and, in fact, when that company decided to sell the phones as an accessory, as a replacement, we said that, well, no, you know, you've got to manufacture those within GMPs.

So it goes back to how are they being used with the product. We're not going to -- I'll be honest with you. We're not going to address your question. Your question has been discussed internally for a very long time. My personal opinion is to agree with you but that's not -- but I mean the guidance explains the approach that we took, and the guidance says that we're not going to regulate the phones at this time, and that was just a decision that was made.

UNIDENTIFIED SPEAKER: All right. But just since the door isn't going to be closed until October 19th, let me just answer your position that you mentioned about the computers being regulated and the like, and that part of what makes iPhones looks good are all of the internals which are not released that make changes to the appearance of the images that may not be conducive to, you know, diagnosis, and we don't know what's going on there, and let me just go on.

One specific example that I have measured, and that is that the pixel substructure of the iPhones, say symmetric, you have a column of things and then a gap, and if you look at it landscape versus portrait, the diagnostic detail which is almost universally bunched to the high frequencies is going to be modified. I'd like to know how that is and relate that to the diagnostic details so then I can be confident in the judgments I make based upon looking at the images. So there's a lot to be looked at with the iPhone.

MR. BENESCH: All right. Our time is up through this session. So we'll take a 15-minute break and then come back for the last Panel of the day. Thank you.

(Off the record.)

(On the record.)

MR. PATEL: We've got the Panel. It looks like the Panel's more excited to be on the Panel, and they're up here just talking through the issues. So welcome back. I know it's the last Panel of the day, and I've asked my Panelists to make it exciting enough to keep you guys awake and engaged. And they're up for it. I tell you, they're up for it. I can count on these fine people to keep that promise, right, Brad?

MR. THOMPSON: You bet.

MR. PATEL: Okay.

MR. THOMPSON: You bet.

MR. PATEL: So it looks like people are settling in. Let's do that. Interesting discussion in the previous Panel. We went from trends to what could happen now. It's kind of a trend, isn't it? Yeah.

So let's take it to the next level. We talked about the proposed approach on accessories. How do we parse this out? And the question is how do we parse it out? How do we make sense out of this? I think we touched upon those kind of issues in the last Panel, and we talked a little bit, and we're going to dive a little bit deeper into that. The proposal in the NOA, and Donna-Bea just reminded me that not many people read the NOA because it's not part of the guidance document; people focused on the guidance document. That's something that we definitely need to improve on, and we'll see if we can or we cannot, and the lawyers will tell me one way or the other.

But regardless of the fact, I'm going to just briefly state that one way of thinking to accessories, as they connect to different things, is intended use. When the person makes an accessory, and we're talking about mobile apps being developed, other folks who are not actually making the original medical device. That's one aspect, and there may be benefits for people who are making their own medical device, to think about accessories slightly differently.

So having said that, I'm going to just jump right in and get the discussion going. I do have to apologize about the timing on the agenda. The timing for this Panel was lost in the printing somewhere or between making of this. I'm not going to claim any more than that. So we'll go from 2:30, we'll do an hour on this Panel. So we'll go to 3:30, and then we'll do a 15 minute Q&A after this session, and then we'll have opportunity up for an hour for public comments, and during that public comments, I think we have about six people signed up to comment during the public comment period. If there are slots, please go ahead and sign up now or just wait for a turn and we'll call you to speak.

So having said that, let's just get started.

Here, hold it down.

DR. TILLMAN: I've got to hold it. Ah, so I guess we're doing ladies first. Thank you, Bakul. So I'm going to keep my remarks brief.

I guess I'm going to diverge slightly from the idea of intended use and just briefly mentioned something I think I just said to Bakul, and that is that we're entering into an era where wireless communication is just going to be part of how we live, and if you think about where we were 15 years ago with the Internet, in some ways we're in that same place with wireless technology.

Back 15 years ago, many people would not be comfortable giving their credit card information over the Internet, wouldn't shop over the Internet. There were just so many different things that we sort of were uncertain about and were unknown, and I think we're in some ways at that same place with wireless technology today, and I think what we have to recognize is that it is the future, and we have to have a regulatory approach for that, that doesn't stifle the same innovation that we can expect to see for wireless technology.

So, you know, my sense is where FDA has a lot of value to add here is in looking at things like intended use and making sure that the products that come out as wireless mobile medical apps are able to do what they say they do, but I think that at some point in time, we have to sort of get beyond treating these things as special simply because they're wireless and rely on standards that exist and basic understanding of the technology in order to deal with those issues.

So I think FDA's approach of treating these things sort of similarly to the way they've treated MDDS is very rational in my mind.

MR. PATEL: And that was Donna-Bea Tillman from Microsoft.

DR. TILLMAN: That's right.

MR. PATEL: Chuck, do you just want to introduce yourself?

MR. PARKER: Sure. I am Chuck Parker, the Executive Director of the Continua Alliance. We represent 245 international companies throughout the world as a trade association as well as a guidance body that creates sets of standards or not -- we don't create standards, but we create a set of guidance documents that instill upon how we create a set of interoperability in the market space.

And I think to that point, I think this is something that we're very interested in, this discussion, on this Panel, is a little bit more about the interoperability of these devices and what it actually means from an overall connectivity perspective. What is, you know, when you take a look at that from the last Panel discussion, that pinwheel cushion if you will, of devices that connect into a single monitoring and how information is assimilated and passed along the chain to the back end systems that it needs to go to, whether that be to the medical management facilities or to the personal health record, maybe wellness coaches, maybe employers.

How does this information flow effectively and gets passed along so that it has the appropriate level of guidance applied to it, meaning that, you know, is there risk associated with that data? What is the risk of the decision-making that's going to take place with that design architecture where you're putting multiple devices together along with these applications as well, and what does it mean to, what Donna just mentioned, what does it mean to have the right appropriations of standards in place to ensure that we have that and can define that level of interoperability?

MR. THOMPSON: I'm Brad Thompson, the same Brad Thompson as the last Panel. (Laughter.)

The purpose of this Panel discussion is to focus on solutions to the problems that we identified in the last Panel, and I think FDA's proposed solution has a lot of merit, a lot of potential with the couple of nuances that I suggested in the prior Panel, but I would go a couple of steps further.

The first is, and those of you from the medical device industry will appreciate this more, when it comes to regulating accessories, the clearest, cleanest way to do it is by classifying them, by going through a rulemaking procedure that results in a specific classification, and when I say specific, it doesn't have to be narrow. It just has to define the general category of technology, and classifications based on functionality more so than the particular uniqueness of whatever the technology might be at the moment would be a good investment of FDA time and resources because that would free up the industry and avoid over-regulation, even with the rules of thumb that FDA is proposing for, you know, different tiering of accessories. I think there's some measure of classification that has to accompany it in order to get that clarity.

The other is just to note that there is an obligation on manufacturers that we shouldn't lose track of, and this is why the concept of intended use is so important is because not only does it say when something's regulated, but it also points to who has the responsibility to make sure that the product performs as claimed. It is the one who makes the claim. So, you know, I have here a common cell phone and a bluetooth earpiece, right, and they're compatible. I use them. They're both to a bluetooth standard, and they both say that they're bluetooth compatible, all right.

So, number one, whoever sells this, I'm not going to tell you who it is, I don't want to be partisan, but has to be able to show that they do, in fact, conform to that standard and that's important. They control their claims, and if they go a step further and say and it's great for medical applications, too, then they've got to back that up, but not in the form of a submission to FDA for clearance or approval, but substantiation, and there's a big difference in those concepts, right.

When you submit to FDA, it's for Class II and Class III devices, a few Class I, you have to go through the submission process, which is a burdensome process. There's no two ways around it. But simply requiring that manufacturers have data on hand to back up claims that they make is a very practical way to assure the safety and effectiveness of this product because then I won't sell it unless I have data on hand that shows it'll do what I say it will do, and there's a certain amount of justice there that you should be held accountable for what you say. You market it voluntarily. You determine the nature of your claims, and when you determine the claim, it ought to be on the basis of data that you have in your files to prove that claim.

So quite apart from -- let's just not think about FDA submissions, but let's think about substantiation and what companies have to have, and we see then that there is a level of regulatory control for those sorts of claims.

MR. LaLONDE: Hello, everyone. My name is John LaLonde. I'm the Vice President of Product Development at Boston Scientific in their cardiovascular division. I hope today to provide some real world perspective on just the kind of systems we're talking about. We remotely monitor implantable devices, pacemakers, defibrillators, heart failure devices, all of which are Class III implantable devices, and we have a communications device that resides in a patient's home. That information is transmitted to a physician website whereby a number of clinics and hospitals utilize that for the care of patients.

Interoperability in the accessory role traverse our system in many different ways with the implantable device being Class III, our communications device in the home being Class III. We also collect information from blood pressure monitors and weight scales, which are a different class, Class II because it's a heart failure management system. We integrate with EHRs, and so it becomes somewhat complicated when you look at the accessory rule in a chain link nature to provide the overall system.

As Brad was mentioning, we are the company that makes the claims for this heart failure patient management system, and so we have to provide the evidence in our submission or our filing for what this system can do and cannot do. The edge cases that are difficult for us right now, and I think Brad mentioned this earlier, about the phone splitter, this is a real world example for us because while it's seemingly obvious that it just splits a telephone signal, when it's attached to a Class III medical device, and you are making claims or you are the company responsible for the overall performance and functionality, then there's a lot of debate as to what is really the responsibility and then the designation for safety and efficacy for not only the communications hub in the patient's home, but anything that attaches to that. So I hope to share real world experience in today's session.

DR. SMITH: Hi, I'm Joe Smith. I'm the Chief Medical and Science Officer for West Wireless Health Institute out in San Diego. So in contrast to the real world experience that John's going to provide, I'm obviously from Southern California. So I may have a different view.

It is tough as the last speaker to be introduced on the last Panel of the day in a rather contentious and, I think described by some as unwieldy, conversation to add dramatic value. I'll not shrink from the attempt but, you know, there's got to be a lower bar at some point.

You know, I think mHealth, wireless health, mobile health, however you want to call it, I think it offers the opportunity for disruption in healthcare, and I would say different from what we've seen recently. I think, you know, we recognize that we can't continue on the path we have as we spend approaching 18 percent of GDP on healthcare, and this notion of decentralizing and democratizing healthcare information and that mobile health, mHealth opportunity is to do so, I think it's then -- it's really no surprise that the regulatory framework lags behind this technological swell of adoption. I think Brian Dolan this morning did a good job of saying, you know, it's growing geometrically in terms of the acceptance by patients and by doctors. And so all of that has happened really in the absence of regulatory clarity, and I think that bespeaks the notion that this is, in fact, a disruption.

And I think it also speaks to how we should I think seek to regulate it. The technology and the adoption is moving at a time constant which is a good deal shorter than our typical regulatory time constants, and while the last Panel we talked about predicting what it's going to be like, I think, you know, we think of it as a Dan Quayle-ism, but it's really a Niels Bohr quote that prediction is difficult particularly when it involves the future, and I think what this field's going to look like in 10 years is sufficiently different from what we might imagine and say today that I would not want to be authoring regulatory guidance that was not going to go away in that timeframe.

And so I think we need to be rather circumspect about the things we write down and chisel in stone today or in the weeks ahead, as the field's moving so quick, and I think there's an opportunity to have a process change here, where instead of branding a particular form of regulatory environment and framework and then having to fashion all of our efforts into it, I think the notion of providing some minimal guidance and then learning as we go, as long as we all learn while we go.

You know, you guys may have seen a really cool app that just got released out of some smart guys at MIT. They said, you know what? When everyone's driving around our city, and we're all stopping at the same red lights, but none of us know the cadence of the red lights. Let's mount your little smartphone on your dashboard, and we'll figure out where you are and what color your light is, and that way I'll know if I'm driving, you know, 800 yards behind you, that that light's about to turn green and I don't have to slow down. Or I'll know that that light just turned yellow and I do have to slow down. And the net impact is a 20 percent improvement in gas mileage in those users in Cambridge.

Why couldn't we do that in a regulatory environment? Why couldn't we learn from those that are ahead of us, and not that the FDA is a stoplight. I don't want to give you that particular analogy, but why couldn't we learn from the experiments ahead of us what the regulatory environment's going to be so that we can all learn together from all of the trials and tribulations, and that way there'd be some additional value provided by the FDA, and it's particularly around interoperability. I think this is the value proposition for a lot of this technology.

And we saw earlier today people talk about wanting to get out of the box, you know, not wanting to be in the regulated box because they didn't so much see the value proposition of interacting with the FDA. It looks like risk and cost and delay, but where's the upside of it? And there is upside. They do provide guidance and help in terms of refining product definition and what testing's necessary. We need to provide more of that up-front value so that people will, as someone talked about at the break, willingly having their products reviewed by the FDA, even if it's not a Class I or Class II or Class III designation. That would be a wonderful customer-centric view of regulation that perhaps is a bridge too far to go just today.

But nonetheless, interoperability is the value proposition, and we have to make sure that the regulation we write down in the days and weeks ahead don't inadvertently make it more difficult to have that interoperable space, and that's what I think we're going to try to do in the Panel today.

MR. PATEL: Thank you, everybody. I think all of you at least agreed on one thing is these systems are getting more and more interoperable, and that's the key here. As the systems get more and more interoperable, I think I could boldly say here that this area needs to be solved. We have at FDA recognized that and want to make sure that the solutions that we come up with are considered as we start developing new guidances or new policies going forward.

So the goal here is maybe not to have regulations, not to have many regulations which have the perception of being chiseled in stone. Can we do that? I think that's a question open for the Panel. Can we do it if we have policies? Can we do it without some other mechanism? I think that's the process part of the solution, and then there's the parsing out of the problem itself and trying to figure out how can we look at this, or how can a manufacturer like John looks at it and goes, that splitter along with or was it Brad? Or was it John?


MR. PATEL: And so John goes, that splitter --

DR. SMITH: You're anonymously describing John. (Laughter.)

MR. PATEL: So that splitter, along with the cardiac monitoring system that he sells, doesn't have to have the same level or needs to have the same level based on the application and based on the intended use. So can we get there?

DR. SMITH: One key thing that I heard was interoperability --

COURT REPORTER: Can you press the button please?

DR. SMITH: I'm sorry.

MR. PATEL: Again.

DR. SMITH: Can I get a tape? (Laughter.)

UNIDENTIFIED SPEAKER: I don' t know. Is that an accessory? (Laughter.)

MR. PATEL: So rather than addressing process -- Joe, that's really critical. I want put that off for a little bit before we get into that because I think that's critical as well in terms of how do we get there. But I think what do we take there is in front of my mind right now to say, what is it that we need to take through the process that we're going to go?

So speaking about intended use, Brad, you proposed a couple of other additional options on top of the intended use going forward. I'd like to see, you know, Joe and John, your reaction to that proposal.

MR. LaLONDE: I really like that lower classification that Brad added because the phone splitter example just is so apropos for that. This is a convenience for patients in their home. It is not a part of the intended use to monitor a defibrillator nor to give information to a physician that would change a clinical diagnosis for that patient. But the way that the accessory rule is applied today, it could be construed as a part of the communication link in transferring information from the home to the secure website, and further clarity around that category of technology that furthers or simply enhances the transport of information I do think needs attention right now.

MR. PATEL: Joe, do you want to react to that?

DR. SMITH: Yeah, I think there's a whole host of ubiquitous and general purpose bits and pieces that find their way into everyone's view of how they can fashion a communication chain a little bit better, a little bit smarter, and I'd hate to see all of those general purpose pieces fall into, you know, an already overburdened regulatory environment.

MR. PATEL: So speaking of that transferring mechanism or the communication mechanism, we published a rule in February, the MDDS rule, which sort of addresses that to a major extent. It seems that there's still some confusion. So I'd like to see if Donna-Bea had any reactions to that, especially coming from a purely software world and starting to use data only generated by all of these devices.

DR. TILLMAN: Well, I mean at the risk of stating the obvious, I think the question always is, is what's the appropriate degree of regulatory oversight to address the risk, and what is the risk here that we're talking about, and I think that when you talk about data, you're talking about miss of incorrect data or lack of availability of data, and I think that at the end of the day, when you're talking about software, you're eventually getting down to quality systems, and so, you know, from my perspective, I think even though I have to be careful not to pat myself on the back since I was part of the development of it, but I think the MDDS rule was actually a very smart rule, and I think that, you know, at the end of the day, as manufacturers of medical device software, which Microsoft is now, you know, we need to make sure that we have a quality system in place and that we're able to ensure that the product that we're putting out does what we say it does and meets user needs and intended uses.

So, you know, my sort of long, long answer around that is I think that the way in which FDA envisioned MDDS and to focus on the quality system is sort of the fundamental regulatory tool for ensuring the safety and effectiveness of those products, I think gives us a lot of flexibility in moving forward, and I think an approach like that, while it may not solve all of the questions about this, mobile medical apps might be a really good place to start.

MR. PATEL: Okay.

MR. PARKER: I think that we're talking about a couple of things here that are somewhat still complex, and that is one of my points here is that what we're trying to do is get these comments down to the point where a company who has never been involved in this field, most likely the app manufacturer who decides, hey, I think this is kind of a cool idea, I have this idea about making this thing where I can actually monitor somebody's application or monitor their heart rate and combine it with some of their other data that, you know, we can kind of give them an overall general idea of their health.

So what we have here is the -- what we need to do is try to clarify the legislation to make it more easier for these individual companies, these individual organizations, to understand what the regulations are. So I think there's a certain level of regulation complexity that gets involved here that we need to find better ways of simplifying that. Some of that is relatively straightforward, you know, maybe providing more examples of what you mean. So what's in, what's out kind of activity.

Secondarily, perhaps using language that is more common to the industry in particular as far as the overall comments of what, you know, what technology may be used.

And I think that, you know, the third area is things like this. So I think that, you know, have comment periods like this where you have some open statement afterwards, even after you issue the legislation on saying and providing guidance to individual companies to say this is what we mean, this is kind of how we want to address the market space. Those are certain areas I think that are important for us to understand in this level of complexity from this language perspective.

Now, on the other side of this, I think that one of the things that we're definitely working towards and want to understand is that whole level of when is a device, you know, when you take a look at that interoperability aspect of it, and I connect the device from unit A to unit B, what do I inherit? What do I not inherit? And how do I get to the point of clarifying how each device in that chain has its specific level either (a) affected or (b) remains so that I don't have to go back and recertify everything.

So I used an example of that weight scale in the past, and on the previous Panel, you know, a weight scale is a relatively straightforward device, Class I device, but if I put it in a CHF diagnostic capability, in an ACO model, accountable cure organization, who now wants to push that patient home much sooner because it's going to save them money, and they're monitoring that individual using that weight scale, there's a certain level of interoperability that I need to have from that device, and I may change now that level of criticality of that device because I'm now using it to measure specifically perhaps something about the heart function of that individual because I'm seeing their weight gain go up.

So that's an issue that we have that we still need to address is when, you know, the intended use is going to change device manufacturers original, you know, applications, and I think that's something that we have to take a look at from a mobile medical app. The overall perspective is that, you know, when I start to develop those applications, do I start to change the original intent of the devices that I'm connecting to, and when I do that, what is the back end interoperability that's going to be required.

So, you know, here again we look at standards as an aspect of that and perhaps, you know, we think very strongly about that aspect of can standards by the FDA incorporating a new list of standards and says, look, you must meet this certain level of base playing field. So the standards are the base playing field, that at least from there, then you can start to look at assessing the level of risk. So I think that there's a certain level of you've got to bring the industry up to a certain functioning level with standards, and then from there you have to start assessing the interoperability aspects of it.

MR. PATEL: Brad, you mentioned risk as part of your solution. How would you see that sort of incorporated into the intended use either before or after one determines their intended use for that product? What do you think about that?

MR. THOMPSON: Well, I do start with risk. Risk is the whole basis on which the medical device legislation is written. We're supposed to tailor the regulatory approach to the level of risk.

The problem with risk or an assessment of risk is that it's not self-executing. As a matter of policy, you can't say if you're above 80 units of risk, you're regulated. If you're below 80 units of risk, you're not regulated. You can't just tell the public that and then they figure it out and they know exactly what's regulated and what's not regulated.

So risk instead has to be a basis for figuring out the underlying policy that FDA expresses, and you have opportunities to do that in a couple of different fashions, and you asked initially, just about five minutes ago, also a question about process. What process does the Agency need to go through?

Well, you have a couple of processes that are available to you. One is the successful one that Donna-Bea just referenced, classification, right. And that whole process is based on risk. You have to make a finding that all the products in this category are of this general risk level and then regulated to this point, right. That takes resources. That's more written in stone than guidance is because it takes so much time and effort to develop a classification regulation that you just can't do it as often and you can't change as often. I get that, but a certain amount of that is necessary because that's FDA's process, statutory process for taking into account risk.

But you also have guidance, and where you could use guidance here is in particular saying what's not regulated because you don't have to go through the classification process to say that. And I can't speak for the folks out here, but I know from a lot of the people that I work with, that's a huge issue is figuring out what's not regulated, getting that crap off the table so that we don't have to worry about that.

And in the area of accessories, that's where the guidance document is kind of thin right now, and you've got to go, and I think Anand said this in the very first Panel, you've got to dig deeper into kind of the exact mechanics of how it's to be used and the target populations, and you went through a nice leveling of like six different categories. You've got to get to that level for the guidance document to be truly meaningful or executable by the public, and those levels have to include commercial issues, not just technology issues. You've got to deal with this issue of bundling. If you sell everything together, you put the stupid splitter in with the kit, is it really a Class III just because you bundled it?

There have got to be some level of permitted claims that don't create the risk that it's worth regulating. So a splitter manufacturer might say, this is useful for medical technologies. Well, it's useful for everything, but he just wants to market it in particular for medical technologies. Does it really make it risky enough that it needs to be even a Class I medical device? I would say no.

So you have the ability through guidance to say we're going to take a risk-based approach, and we're going to say these things are carved out, not regulated, and they're carved out not just on the basis of the thing and its label, but how you market them, what you say about them. Maybe the fact that you mention conformance to a standard that has medical implications, that's okay. You can do that because ultimately you want communication. You don't want the users to be befuddled and not know really what works well together because no one's doing any labeling. If they listen to lawyers, you know, the risk is they'll say nothing but just put it out there and say you figure it out, and that's the worst of all policy.

MR. PATEL: Yeah, great. John, do you want to react to that?

MR. LaLONDE: You know, I would say a couple of things here. Risk is a hard thing to deal with. Clinical studies and large-scale statistical looks at data will have confidence intervals and the like, but risk-based approaches to software and applications don't have that same specificity.

For a device manufacturer, risk typically gets translated into safety, and so for a medical device, whether it's Class II or Class III, if you're doing a submission to the FDA, you know, it really starts with what can go wrong with the functionality that you have included in your intended use, and then how do you mitigate things that can go wrong. And I think that's where looking at risk and not having to deal with the unintended consequence of things that are chained together would be a great simplification for a lot of device manufacturers. When I say device, I don't mean necessarily hardware. I mean hardware, software, or integrated systems.

But I think that's what people getting into this space will have to address is safety and efficacy, safety starts with what can go wrong, not what just goes right, in the intended use, but what goes wrong, and how are you dealing with things that go wrong that are relevant to the functionality that you provide, and as long as that what can go wrong can be bounded to the intended use, and not dealing with permutations that we just did not envision when we did the original filing, I think that will help in many ways around this not just accessory rule, but interoperability more importantly.

MR. PATEL: Right. Joe, putting your clinician's hat on, I want you to sort of respond to this example that has been floating around about this splitter. Can you conceptualize this to be a component if it's like embedded inside the box versus sold, get it from Radio Shack kind of situation? How does a practitioner sort of look at that, and what expectations do they have when they have an accessory either sold separately or packaged separately inside a box?

DR. SMITH: I think this is one of the unintended consequences of regulation that needs some thought. I mean so I can well understand a device manufacturer thinking, gee, I don't want to have to go out and do supplier qualifications of everybody who makes a splitter to put a splitter into the box when actually the device functions perfectly fine without it. And at the same time, they might perceive it to be a benefit to their patients and all the customers to actually pick a good one, but yet they're going to demur from doing that because, you know, they can't actually figure out which one of these is best or strike up a relationship with a company that makes, you know, a couple of hundred million of these things and five percent of them or one-tenth of one percent are going to get used for medical devices, and that's going to be all of their liability, and then as a result, you drive up the cost of that splitter by having them know that their device is now packaged with a medical device.

But I'd sooner respond to the weight issue, right, the weight scale. So, you know, we can imagine a risk associated with a weight scale. We can say, well, the number could be wrong, and the doc could interpret that as a need for a drug that they didn't otherwise need and then they give them the drug and they have an adverse event. Oh, my God, they die.

You can always concatenate from where you are to some god-awful outcome through an unrealistically unlikely sequence of concatenated misadventures. You know, frankly, the risk for a weight scale in a 75-year-old person's home with heart failure is more likely tripping over it than an adverse consequence from getting the wrong weight and that's because there is context for interpreting that weight, you know.

So that's going to go to a heart failure nurse or it's going to go to a doc, and they're going to go, you know what? Your weight didn't go up 10 pounds since yesterday because I'm talking to you and you sound the same to me. Why don't you get on the scale again, you know, and so there is an integrated contextual system which understands the technology has its own limitations and that, particularly when used by individual patients at home, has its own additional limitations, and the system evolves to mitigate those risks, and so it's kind of an unfortunate and inappropriately sterile environment to imagine that device and its risks apart from the context of clinical care in which it functions. And I think we do the industry and the patients a disservice when we always migrate to the most risky scenario in the absence of that context.

MR. PATEL: Good.

DR. TILLMAN: I just have to chime in on that because, you know, we had a concept back in the 1989 draft software policy called competent human intervention that, you know, we sort of -- it was a double-edge sword, but I think the point that Joe's making is a really great one, and that is that when you're looking at these devices, when you're looking at intended use, and you're looking at risk, you can't not take the competent human out of the equation. And, you know, when we think about these things, we can always come up with an edge case where somebody dies, but you have to be able to presume that there is a competent human in the loop, and I think that, you know, it's fair for FDA to differentiate between those two. If you've got a closed loop system with an infusion pump and, you know, you're measuring glucose, and you're doing an artificial pancreas, I mean it sounds like a Class III device to me, but on the other hand, you know, if you've got a doctor in the loop who's evaluating that information, then the same set of equipment suddenly becomes Class II.

So I think that there are things to think about that you can't ignore that competent human, and I think even though we sort of push that concept aside, you know, even maybe we were thinking ahead of our time back in 1989, and maybe we need to bring it back.

DR. SMITH: Well, and if anything, this current revolution where we're decentralizing, democratizing healthcare information, it doesn't necessarily have to assume a competent human because actually those are the people who are reaching for this information in the moment. I mean we're having a real pull for it from not just the individual patients but from their families and their other caregivers, and so I think if it was a good assumption in 1989, it's a better one now.

MR. PARKER: And one thing I want to follow up on, I think that, Joe, you were making a point on that. I think there's sort of an underlying context here, because Brad started bringing it up as well, and that is it's about these devices that have their original intent not in the medical world. So, you know, for example, the splitter itself, it's primary function is not in the medical world. It's primary function is a technical component and, you know, as you mentioned, probably less than five percent or whatever will be sold in the medical context unless the manufacturer was specifically making it that way.

That applies to a wide range of these devices that we're talking about today. Cell phones, for example, you know, the original context is not for them to be in the medical world. So maybe there's a potential way that we can take a look at, as a basis for measurement, here again is another sort of barrier of entry or sort of the first entry point is, is its original intent in the medical world only? If it's not, you know, if it's sold in other parts of the ecosystem for other purposes -- the automobile. Here again, you know, so the automobile is sold not for a medical device, but perhaps this becomes part of the background activity. So networking devices can be that way as well.

DR. SMITH: Well, I would offer that if the automobile were sold as a medical device, it would never be approved. We lose 40,000 people a year in automobile accidents.

MR. PATEL: Did you have something else?

MR. LaLONDE: Yeah, just one other comment. You know, Chuck mentioned the cell phone. One other thing around interoperability is peaceful coexistence, and while we think of the singular application, another thing that's going to have to be addressed is unintended consequence because two applications, or three or four or seven, all happen to co-reside on a general purpose computing platform, and having to deal with or ensuring safety in terms of peaceful coexistence is a really thorny problem right now. And what has led device manufacturers in the past, whether they were handheld general purpose or desktop or whatever, is to become the system's integrator and own essentially the software/hardware integration to ensure peaceful coexistence of whatever applications are delivered.

So in this era, we're going to have to deal with you are not the sole purveyor of applications on a device, and how do application developers deal with other application developers when you have no knowledge of what their applications are doing?

MR. PATEL: So that's actually an excellent segue into my next question is, when mobile apps get connected to your, you know, cardiac monitor, that you have full control over, and we talked about a variety of manufacturers ranging from the person in the garage to very sophisticated, somebody like Microsoft doing this or Google doing it or Apple doing it, how do you  -- I mean there are two questions asked in the agenda here is, how do we ensure device functionality is not affected, one, and just compatibly, which is what you're talking about, living peacefully together, how can you ensure that or what are different ways of assessing that? Even forget FDA for one second, how do you as a device manufacturer ensure or sort of get to know that it's not going to affect my device which I sell? Any thoughts on that?

DR. TILLMAN: So I mean I think one way you do that is you can develop standards around how applications for use in this kind of environment need to be written, you know, basic things like when you're done with memory, you get rid of it, you clean it up. You know, simple things that are just sort of good software engineering practice, and if you can take those and develop standards around that and you can say that if you're going to write an app that's going to operate in this interoperable environment, here's the rules you've got to play by and that makes sure that everything sort of plays nicely together. So I mean that seems sort of obvious but I think it's a necessary first place to start.

MR. LaLONDE: Yeah, I would certainly agree with that. Virtualization and other things to create, define sandboxes for applications help a lot. You will still have to do a lot of testing. We do an enormous amount of regression testing just to be complete about it, but I think there are good practices for the construction of software in this kind of environment that really lend itself to helping on this front.

MR. PARKER: I was going to say that I think you're moving to the point where you're talking about here of virtualization of the entire activity. So it's actually not running directly on the platform perhaps. So it's really taking a look at moving the whole application performance to the cloud. So, you know, any smartphone today, plus even some phones that aren't considered on the smartphone category, have that capability of even running web browsers or at least the ability of running a service on the back end that's not necessarily using the memory of the device itself. So that may be another way of looking at classification of applications and a way to actually secure them into a sandbox area.

MR. PATEL: Any thoughts, Brad?

MR. THOMPSON: No idea.

MR. PATEL: That's a first. Anyhow, so I think we talked about, accidentally talked about a couple of things here which I had not planned on, is one about the process itself, of how to get these thoughts known to the stakeholders and I can see -- and we talked about a couple of stakeholders here already. One is the original device manufacturer who are getting connected to. Two is a third party who is just coming up and making things usable from a totally different perspective, not quite sure whether they realize the full extent of what they're doing or not doing. From their point of world, I think they're doing great things but the implications on other things. And simple example like living peacefully together on a PC is a really simple example, and at least from my background, I know it's a pain to just have somebody install a couple of applications together along with the McAfee or some other wireless program which resides on your computer.

So having said that, one other task we had as a Panel here is to sort of determine if the intended use was the right sort of path to get on, and obviously we need to fine-tune it as we go, and we sort of accidentally tripped upon one other concept is what do we have to let folks who are getting in this world, making third-party applications, or third-party accessories, what do we expect them to do? What part of the picture we want them to own up to or have them cross that, not cross but at least be at that expectation of standards or whatever? Are we talking about the same thing because I can see the medical device industry making the cardiac monitor, I'm just going to pick on you, John, and making certain things and they're in full control making the device safe and effective. Somebody else comes along and may totally disrupt that cardiac monitor. What expectations should we have on those folks, or should we not have an expectation?

MR. LaLONDE: We'll hunt them down. (Laughter.)

MR. PATEL: That's the way to do it.

MR. LaLONDE: Well, it's like everything else we've said, one size isn't going to fit all. So first you have to stratify based on risk and figure out, you know, if it's a Class III device, probably a different standard applies to that than with Class I or Class II.

If you're in one of the lesser regulated classes, I think what we're suggesting as a coalition is that there be a clear expectation that the one who makes the claim substantiate that claim, and so if we have levels of substantiation that are clearly articulated, it's up to them to do that testing, that compatibility testing before they make the claim. So if they're going to claim compatibility with one or two specific branded devices, then they test with regard to those. If they're going to try and make a more open ended claim, then they have a higher burden, and they have to be able to show that standards are in place necessary to show that the compatibility will be the same throughout that class of devices.

But you put the burden squarely on the person making the claim, and you let them know what that burden is, then let them do it. That would be for the lower classes. If you're claiming specific compatibility to a Class III device, you're in a different risk profile.

MR. PARKER: And I think we still have a question, too, outstanding about, you know, devices versus the app itself and where the risk lies because in some cases you can have, here again the weight scale, a Level I, versus an app that could actually potentially be a Level II or Level III depending upon the intelligence that is applied based upon the guidance that you've issued at this point.

So, you know, is it, you know, where's the higher level actually reside in this case? And it could be in the back end system itself from the networking perspective.

MR. PATEL: And that was the point, and the proposal is, you know, somebody could integrate Class I, Class II, Class III information. It could be just pure information and having nothing to do with actually connecting, just gathering information and making a brand new sort of use of it, and that could by itself have its own risk levels associated with it. So that's really where I was going with that last suggestion.

MR. LaLONDE: You know, I thought Brad did a very nice job in the prior Panel around intended use because it does start with the commercial aspect. Who is selling the offering and what are they saying about it, i.e., promotion? That's a big part of the classification is back up what you claim your product can do.

MR. PATEL: Right.

MR. LaLONDE: And I think that that's really important for the new companies starting up in this space, whether it's in the context of the triangle that was described earlier, that if you're in a certain level, know what you're getting into because if you're in the middle or upper tiers of that triangle, you're going to be expected to have a quality system, and you're going to be expected to have design controls for the offering that or offerings that your company provides, and what you say about them is really, really important. So if you don't want to be in the business of making claims about disease management, don't make those claims, and really steer clear of that, and maybe you just have a logging application, but that's what I think is important for the companies getting in. It's not so much intended use by itself. It's understanding the nature of claims, promotion, and activities around marketing and sale of your product, and then what does that really mean in terms of responsibility to consumers as well as to the caregivers or providers?

DR. SMITH: And I'm sorry that Julian Goldman had to leave. He's the fellow who spoke briefly at lunch from Partners about their efforts to try to integrate up all sorts of medical device information in a hospital, and then I'll probably get this wrong as a description, but something that needs to be contemplated, it's his view that you can integrate up information from all of them and create a bit of a wisdom layer and then give that wisdom layer the opportunity to modulate individual device behavior even to the point of turning things on and off. And I think, you know, with a history in the medical device world, that ought to give some pause because you may have a device which you think is autonomous and automatic and functioning just as you describe, and then that there can be some automatic wisdom layer above that device that can modulate its function, has its own sort of regulatory hurdles and functional requirements that may be yet higher than any of the devices in the loop because it integrates up over lots and then actually does something with that information.

DR. TILLMAN: Yeah, and I totally agree with Brad's perspective that it all has to come back to intended use, and I think that the person making the claims or the statements about what it's doing ultimately is the individual that's responsible for sort of demonstrating that it, in fact, does that, but I think that systems where the data is flowing one way are totally different from systems where the data is flowing a different way.

So if you're talking about therapeutic or anything that's actually controlling or influencing devices, I think we're talking about a totally different kettle of fish. I think mostly what we've been talking about today is systems where information is flowing out of the medical devices into the systems, and I think in that case, this approach, this intended use- based approach is very rational.

MR. PATEL: Great. I'm starting to get questions from the web. Before I forget to announce the Twitter hashtag, it's #FDAmHRegAcess, which is R E G A C C E S S, reg access, FDA mHealth RegAccess. So tweet on that, and Morgan over here is going to pass me notes.

One question, I think we addressed this already, is to John's point. How can we make sure everything plays nicely? Will the sandbox prevent unexpected adverse events?

MR. LaLONDE: It can help. There's no guarantee, and I think one thing that we've done in the past when you're the integrator of hardware and software, security is just as important as peaceful coexistence, and so just a real practical example, you'll shut down all of the ports that your app or your service does not use, and it's really important to have those things a part of the way that you construct your sandbox so that you're isolating the things that are trying to get into the sandbox as much as how data securely leaves your sandbox.

MR. PATEL: So it's more about preventing unintended folks coming into your sandbox rather than --

MR. LaLONDE: Exactly, and I said before, safety overlaps with security here, and so as you start, in our world, there's an approach called failure modes effects analysis, and it's essentially what can go wrong with your set of functions or your functionality? And it's a useful process to look at how do you mitigate hazards and how do you go about providing evidence, again if it's a regulated system or application, how do you provide evidence that you've thought through some of these elements here of unattended consequence or security?

MR. PATEL: All right. Do we have a question?

UNIDENTIFIED SPEAKER: This is part question, part comment, but I think it's a topic that I don't think has been brought up today, and so I'm going to throw it out to the Panel.

We all know that whether you're talking about a conventional medical device or software application, that we use our fundamental theoretical principles to kind of estimate what the risk is before it's actually been used in real world settings. So we do our best, and it's actually the underlying design combined with our best guess of what the use cases are.

But a huge component of how we manage risk in regulation of conventional devices is what we learn about the real risk when it's out during the postmarket period.

So it's sort of two questions I have. One is that, you know, when it comes to things like, when I think about use of mobile apps, that becomes, while it's theoretically possible to track every use, it becomes really challenging to do your conventional surveillance because you have to be able to somehow understand what your denominator is and what your numerator is and be able to do reliable trending to really know whether, in fact, you've either underestimated or overestimated the risk and whether you need to pull that back and do a redesign.

So I'm going to ask the Panel, you know, when it comes to these mobile apps, how actually would we handle what I think is a huge component of really understanding the dynamic quality of risk in these applications or these products and how would we handle the postmarket surveillance?

MR. PATEL: Anybody want to react to that?

DR. TILLMAN: Well, in mean in some ways if you have software-based devices, it's almost easier to get that kind of information. I'm just thinking about how many of you have seen applications, either mobile apps or on your computer, where it says do you want to share your information with fill-in-the-blank manufacturer? And so I think that there is, you know, these applications can be designed in such a way actually I think to facilitate information about performance once they get out there.

Then you run into privacy and security issues which obviously are very real, but I do think that, I know at least from our experience, you know, the nature of the kinds of communications we have with our customers and our software capabilities actually makes it easier for us to collect that kind of information than it would be if we made a different kind of Class I device like a tongue depressor.

MR. LaLONDE: If you're in a regulated environment, just say a Class II or Class III medical devices, your quality system is required to have tools or processes to deal with customer feedback, and FDA or other notified bodies that look at your quality system will evaluate and see if you've got proper controls in place, and how do you handle just the very nature of a customer complaint or a request for enhancement and that doesn't necessarily have to be based on automaticity within the application itself. It may be your customer support group logs all calls and they triage what people are saying or difficulties that they're having with an application.

There's more structured ways of doing postmarket surveillance for Class III devices that the FDA will look at structure and population size and the like, but it can be as simple as how does a customer support group handle feedback and then what are you doing about that feedback in terms of go forward design change.

UNIDENTIFIED SPEAKER: My question revolves around the concept of a systems integrator, and as an analogy, let's take the PACS world where you have a variety of PACS components that are each regulated individually. They're all 510 cleared. They all have DICOM conformance statements, and you can assemble those components and have a great working PACS or you can assemble those components and have a PACS that doesn't work at all.

So who owns that burden of making sure that all these components come together and work in a safe and effective manner, and what if it's the buyer of the system? Are they engaging in a manufacturing kind of role? What if it's a third party or one of the PACS components manufacturers?

MR. LaLONDE: Who is selling the system?

UNIDENTIFIED SPEAKER: Each individual PACS component manufacturer is selling their component.

MR. LaLONDE: Then I think at least, you know, my opinion is each individual component has intended use or claims about their component, but if a systems integrator warrants that the total, the combination of these things provide certain capabilities, then the systems integrator is responsible then for ensuring the integrity and functionality of the overall system.

UNIDENTIFIED SPEAKER: So is that one of the things that's missing in mobile apps and mHealth in general where you have this heterogeneous environment with solutions coming from many different places that all want to be used together?

MR. PATEL: That's true. That's true. That's a part of the interoperability question that exists today. When we looked at the mobile apps and we tried to provide the guidance, I'll let you go in a second here, Brad, but I just want to provide a context of how the mobile apps guidance came about. We talked about interoperability. We talked about software application. We talked about who uses components as part of their solutions so to speak, and in the end, it boiled down to the app manufacturer is actually using all the existing infrastructure, to just put it broadly, to make a claim or an intended use so to speak, that's where it boiled down to is that's where the law calls out to say if you're leading the user of that particular solution to a point, that's where it stops, and that's really where assurances of safety and effectiveness sort of exists. So having said that, Brad, you had something to say.

MR. THOMPSON: I think we're probably saying the same thing. Maybe I'll say it just a little bit differently.

There is a regulatory requirement that every medical device have adequate directions for use. There's an exemption from that if the use is commonly understood. So someone in that scenario should have provided enough directions for use that you would know how to build the system using their directions for use, or it should have been commonly understood how to piece them all together.

So in either event, either somebody didn't provide the directions, they were overestimating what people understood, or they provided directions and the systems integrator said, you know, I'm smarter than they are, I'm going to build my own and make it even better than what they said in the directions.

So the manufacturer's responsible up to the point of their directions, and if someone chooses to go beyond that, then they're in the realm of off-label use, and that's permissible so long as they're doing it only for their own use and not for providing to somebody else.

MR. LaLONDE: You know, one other comment there. You're asking about systems integrator and the like. Just the term app can be a constraint for us as we think about functionality for intended use, and many times I think that application may conform to people's notion of what computers were and how a dedicated piece of software resides on a thing that you carry with you. It may not be that way in 10 years, and what we call applications today may be services or utilities or other things that are constructed completely different than what we think of today, and the app in some ways has this notion of self-contained functionality on a computing device, and it just may not be that way going forward.

So the more we can kind of steer clear of our definition of computing today and think more generically and how regulation can deal with change in design and architecture without having to reinvent itself and try and catch up again and again, I think would help everyone.

MR. PATEL: Great. I do have three comments here, and one question -- two comments and one question.

The first comment is going back to the phone splitter example. The question was raised about practitioner's view of the splitter when it was bundled versus not. An argument could be made to be taken to the extreme and even argue that the phone line transmitting data is a device as well, yet applying a practical approach, most everyone would say the phone line is not. The same answer could be applied to the splitter. It was just a comment.

Another comment here, all devices are composed of components. Only finished devices are regulated. Medical device manufacturers are responsible for knowing the hazardous scenarios that arise from each of the components and control that risk design, if any, and warn and label, if any.

So I think good comments. I think they are very generic and not probably specific to accessories as to such.

Having said that, I don't see any more folks standing up. Anything on the web, Morgan?


MR. PATEL: So I'll take this opportunity to thank you for participating in the Panel. It was a great discussion. I would really encourage everybody to submit their comments, again thought-provoking discussions that happen in the Panel discussions would help you sort of gear your comments to the docket in a way that would be helpful for us to finalize the document. Thank you again.


MR. PATEL: We have five folks signed up to do then. I'm just going to say their name. Please line up after the previous speaker has spoken so we can actually move forward. Shahid Shah from Netspective is the first one signed up. Jason Brook, Aaron Kaufman, Sutha Kamal, and Yishai Knobel from Agamatrix.

So the next person would be Shahid Shah if he's in the audience.

Okay. That will make it four then. Jason, do you want to go?

MR. BROOK: My name is Jason Brook. I'm an attorney with Epstein, Becker and Green in Washington, D.C. I am here on behalf of the mHealth Regulatory Coalition or the MRC, and I'd like to thank you for the opportunity, Bakul, to speak today.

A number of the Panelists today have thrown out the MRC name, and so I want to take a moment to describe for those of you who aren't familiar with the Coalition who we are and what we do. We are a diverse group of mHealth stakeholders who include for profit and not for profit organizations as well as patient advocacy groups, and our mission is to help FDA or promote clarity around how we think mHealth products, which is broader than mobile apps. We would include the hardware aspects of mHealth products. We want to provide clarity in how those types of hardware and software should be regulated and particularly addressing two questions. One is what types of products should be regulated which we talked about throughout the day? And if a product is regulated, at what classification?

Someone noted earlier in the afternoon, or earlier in the morning actually, that the draft guidance doesn't really address how these products that will be regulated as mobile apps or mobile medical apps, how they'll be treated in the classification scheme that exists within the FDA.

So what we have done is drafted a proposal to FDA which we will be submitting in response to the request for comments for the mobile medical draft guidance, and what we want to focus on is the three areas that we've really been touching on throughout the day, intended use, and I think I tried to keep count, and I think we mentioned intended use 1,001 times today, so I won't belabor that point too much.

But we also propose ways to address the accessory rule both in the hardware as well as software context.

So the most important aspect really is the intended use and its relationship to risk and risk assessment. So we also in our proposal to the draft guidance is to develop a risk model that would allow FDA as well as industry folks, stakeholders, to really be able to identify based on risk whether a particular intended use for a product will cause that product to become a regulated medical device.

We applaud FDA's approach. We agree with the approach to regulating products that are moderate to high risk, and using enforcement discretion or exempting products that are on the low risk end of the scale. In particular, we agree that EHRs and PHRs and general IT products should not be regulated.

Someone mentioned this morning the importance of identifying or defining what an EHR is. I think that's a valid comment.

I would add that with respect to intended use claims, it's really important for the draft guidance to provide clarity in a definition of what general health and wellness products are. So I think if you ask everyone in the room, the definition would be slightly different. So I think it's really important that we provide clarity there.

And one of the things we've touched on is the importance of solutions. We have provided a particular set of criteria that we think can be used to identify what types of intended use claims a manufacturer can make about a product that will allow that manufacturer to determine whether the product is actually going to be regulated or not by FDA.

So from an intended use perspective, I would encourage the FDA to strongly consider the approach that we have proposed or will be proposing in our comments for the MMA guidance.

I'd like to say I used my little smartphone alarm clock's stopwatch timer to make sure that I didn't go over five minutes. So I appreciate the opportunity to speak here and thank you.


MR. PATEL: Aaron Kaufman.

MR. KAUFMAN: For something new, here's someone from Silicon Valley, the place where stuff like this gets built often. So I'm going to spend four minutes probably talking about four quick points that are interesting to us.

I work for a company called Massive Health. We build software to help people get healthy, stay healthy.

The first thought I would offer is that apps that claim clinical things ought to be regulated the way that clinical systems are regulated. There's probably an opportunity to say that there shouldn't be a dichotomy between building a useless logbook and building something that has clinical validity, and indeed I think there's an opportunity to allow a huge amount of innovation to be created by sort of creating a tier in between the two.

The second thing is that for apps that are regulated, waterfall worked for a good 30 or 50 years. It was great. Waterfall doesn't work any more. So MRDs and PRDs and all that sort of other stuff that is sort of the isocolera (ph.) of software -- process isn't used by anyone, from startups to Google to Microsoft to Apple, to anyone. Just isn't done.

And so there's got to be a change, I think, of how you create patient safeguards, how you build applications that are safe and that are reliable and that behave in sort of an expected way, but that don't go back to engineering principles that we stopped using 20 years ago.

And so Massive Health is starting to do a survey of a bunch of developers to figure out what we think should be the state of the art sorts of developer process controls, and we'd love to have FDA engage us in doing that as well.

We would love the FDA to help us with guidance on the presentation of novel data. We're big on interfaces at Massive Health. We think that the way you present information to people is hugely powerful, and we think that there's going to be a ton of innovation around user interface, around data presentation, around not just a column of numbers and not just a bar chart and all of a sudden you get into this place where what's creativity, right. All of a sudden if I use the same things that create an infographic in the New York Times, have I created something that requires FDA approval in an application? So I think there's going to be a lot of innovation there, and we look to the FDA to help provide us guidance on that topic.

We'd also like a little bit of guidance around the distinction between prescribing something and giving someone encouragement to do the thing that they want to do. So we focus a lot on behavior change, meaning we tell people to do things which are important to their health, things like taking their medication perhaps. At the same time, these are things that people want to do. So where do you switch between being encouraging and using game techniques and things like that to practicing medicine.

Finally, I would ask that we all be thoughtful about turning apps into regulated medical devices simply because they pull data off of regulated devices. So if I pull data off a blood pressure monitor or a glucose monitor, unless that app is really prescribing something very, very specific, it doesn't seem reasonable that it should be a Class II device.

In fact, it seems further unreasonable that if a user enters their blood glucose data for me, that I can trust that more than I can trust the data that came straight off the device.

So I think that there is a lot of innovation that's going to happen between using the computer that's in your pocket to interact with a whole constellation of devices that are going to be on your person, from pedometers to a blood pressure cuff to a glucose meter, but that the amount of innovation is probably going to move most quickly on the software side and be really cognizant about sort of how you regulate those devices, regulate the software rather relative to devices, is going to make a huge difference for developers.

So that's it for me. Thanks for the time.


MR. KAMAL: I think I'm the last speaker today. So congratulations for getting to almost 4:00, and I think it was a fascinating day. I want to thank Bakul again. I think we all learned a lot here, and thanks for giving us this place to express where we're coming from and what we are struggling with every day as an industry. So, again, thank you for giving us the stage.

I want to push a little further on what John LaLonde and Brad discussed in the most recent Panel, about peaceful coexistence. It sounds like something from the Middle East. I'm from Israel. So I can definitely relate. But I want to push it a little more on the apps side, on the software side. What does it mean this peaceful coexistence? And I'm speaking today, I'm from Agamatrix but I speak on behalf of the MRC on the concept of software modularity and reusable software. And we're going to propose to apply principles from these two concepts to the issue, for example, two medical devices talking to the same app.

Now, software as we heard, we talked about interoperability, and interoperability just implies how complex software systems have become, and John made a comment, maybe "app" is not the right word. We have the system that's comprised of many different modules, and these modules communicate with each other, and these modules are potentially created by different manufacturers, and there's an interface between these modules, and when we sell a product, we bring the product to market, and we say this product is intended to be used as a module that graphs your blood pressure readings, and that module can live and coexist peacefully alongside other modules. And these modules can be regulated independently from the rest of the system if they can fit squarely within an existing classification.

And this is similar to the FAA's regulation of usable software that states explicitly that GPS systems can be used as reusable software. If it was cleared once, it can be reused again.

So let's take an example just for flavor, and this is just an example. The MRC is supporting the broad concept of software modularization, not just this one example, but think of the blood pressure cuff would be classified, working with an app, that gets the readings from it, and it would be classified as a Class II, Class II medical device.

Now, let's say that there was a binary module. This is the app, and this is my blood pressure cuff, and there was a module that lives here that acts as a proxy to this medical device and is created, that this module that lives here is created by the manufacturer of the medical device and is responsible for all the interaction with the medical device, with the blood pressure cuff. Then suddenly you have a module here that isolates the other modules from the medical functionality.

So the concern is that in the case of a medical device that is connected, apps will become unnecessarily regulated, even if the rest of the app, other than that proxy module, even if the rest of the app doesn't add any medical value.

So in the case of multiple devices, let's say blood pressure cuff and a glucose monitor talking to one app, each device can come with a module that lives in the app and acts as a proxy. So you have one proxy to the blood pressure cuff and one proxy to the glucose monitor, and the rest of the app can be isolated and protected from that, protected so to say to that medical functionality.

And how does the communication work between the rest of the app and the modules? That's why we have APIs today, APIs that are restrictive and API stands for application programmer interface. These are the protocols of communication where these modules define how to communicate to other modules.

These standards have been used in other industries for years, and we can leverage this to regulate what's required for regulation in mHealth. And now the regulatory burden regarding this connected device falls on the manufacturer of the device/the module, not on the manufacturers of the other modules.

So the manufacturer of the app, the rest of the modules takes on the regulatory oversight only on the portions of the app that are not covered by that proxy module according to the intended use, according to how the rest of the modules are marketed.

And here again we are borrowing heavily from the FAA's regulation of reusable software, and this approach has been used in all types of aviation systems including Level A. That's the highest classification, and you can look at FAA Order 8110.49 Chapter 12, approving reused software life cycle data.

So how do we ensure safety? Because one could argue that a binary module that is operated by another module instead of by a user might be a higher risk of malfunction, and I think we just had the discussion about how to ensure that, and again, the burden is on the device manufacturer to demonstrate all the defensive mechanisms, the defense mechanisms that we just discussed. So the module was designed and developed in a way that it doesn't affect other modules. The module is reusable across all intended systems. It was validated and verified in the key scenarios, just like I test myself on Windows 7 versus Windows Vista. If you make a module, test that it works in the key scenarios, and the manufacturers should implement defensive program technique, input and output validation, error handling, memory management, data management. These are all standards in software that can be used here to encapsulate what needs to be regulated.

So to recap, software in-house system can be modularized and can be reused, both at the app level but more on the sub-app level. Think of modules. App might not exist in five years. Modules probably will.

So functionality that doesn't require regulation should not get regulated if the FDA approves modules with restrictive APIs. So, of course, such modules should be developed with all the good software principles and defensive program techniques that we discussed so that safety and effectiveness can be reasonably ensured. Thank you.


MR. PATEL: I want to thank everyone for staying here and sticking to the end of the day. I really appreciate your participation.

With this, we're going to end today's session, and we'll start tomorrow at same time, 8:15. We'll start tomorrow at the same time. Interesting discussion tomorrow, more to come. So please hang tight with us. I think it's going to be much more challenging tomorrow, and we're looking for more feedback. Thank you again, everybody. Have a good night.

(Whereupon, at 3:56 p.m., the meeting was adjourned.)


This is to certify that the attached proceedings in the matter of:


September 12, 2011

Silver Spring, Maryland

were held as herein appears, and that this is the original transcription thereof for the files of the Food and Drug Administration, Center for Devices and Radiological Health, Medical Devices Advisory Committee.



Official Reporter