workshop on medical device interoperability:...

1

Free State Reporting, Inc. 1378 Cape Saint Claire Road

Annapolis, MD 21409

WORKSHOP ON MEDICAL DEVICE INTEROPERABILITY:

ACHIEVING SAFETY AND EFFECTIVENESS

+ + +

CO-SPONSORED BY FDA/CDRH, CONTINUA HEALTH ALLIANCE, AND CIMIT

+ + +

January 25, 2010

9:00 a.m.

FDA White Oak Campus 10903 New Hampshire Avenue Silver Spring, MD 20993

WORKSHOP ORGANIZING COMMITTEE: FDA: JOHN F. MURRAY, JR. FDA/CDRH Office of Compliance SANDY WEININGER, Ph.D. FDA/CDRH/OSEL/DESE CIMIT/MEDICAL DEVICE INTEROPERABILITY PROGRAM: JULIAN M. GOLDMAN, M.D. Director, Medical Device Interoperability Program, CIMIT Medical Director, Partners HealthCare Biomedical Engineering SUSAN WHITEHEAD Medical Device Interoperability Program, CIMIT CONTINUA HEALTH ALLIANCE: MICHAEL ROBKIN Anakena Solutions SCOTT THIEL, M.B.A., M.T.(ASCP), R.A.C. Roche Diagnostics Corp.

(410) 974-0947

2


Annapolis, MD 21409

PRESENTERS/MODERATORS: DONNA-BEA TILLMAN, Ph.D. Director, Office of Device Evaluation, FDA/CDRH CHARLES P. FRIEDMAN, Ph.D. Chief Scientific Officer, Office of the National Coordinator for Health IT JEFFREY E. SHUREN, M.D., J.D. Director, FDA/CDRH DOUG ROSENDALE, D.O., F.A.C.O.S. Veterans Health Administration, Office of Health Information, Joint Interoperability Ventures; Doctor of Osteopathic Medicine and Fellow of the American College of Osteopathic Surgeons JULIAN M. GOLDMAN, M.D. Director, MD PnP Program and CIMIT Program on Interoperability; Medical Director, Partners HealthCare Biomedical Engineering; Attending Anesthesiologist, Massachusetts General Hospital/Harvard Medical School DAVE deBRONKART "e-Patient Dave," e-patients.net; Co-Chair, Society for Participatory Medicine BRAD THOMPSON, J.D. Partner, Epstein Becker Green MAUREEN BAKER, C.B.E., D.M., FRCGP Clinical Director of Patient Safety, NHS Connecting for Health, England YI ZHANG Visiting Scientist, CDRH/OSEL/DESE MARY BRADY Associate Office Director, FDA/CDRH/OSB, Home Care Initiatives MICHAEL ROBKIN President, Anakena Solutions DOUG GREY, M.D. Chair, KP Biomedical Device Integration Council, Vice-Chair, KP National Product Council, The Permanente Medical Group

(410) 974-0947

3


Annapolis, MD 21409

PRESENTERS/MODERATORS (cont.): TOM JUDD National Project Director, Clinical Technology, Kaiser Foundation Hospitals TOM McGRANE Principal Solution Consultant, Kaiser Foundation Hospitals TIM GEE Principal, Medical Connectivity Consulting JULIAN M. GOLDMAN, M.D. Physician, MGH/PHS/CIMIT FRANK E. BLOCK, JR., M.D. Professor of Anesthesiology, VCU DICK MOBERG President, Moberg Research, Inc. G.M. SAMARAS, Ph.D., D.Sc., P.E., C.P.E., C.Q.E. CEO, Samaras & Associates, Inc. PRADUMAN JAIN CEO, Vignet, Inc. BRIGITTE PINIEWSKI, M.D. CMO, PeaceHealth Labs MIKE PARADIS Wireless Sales Manager, Dynastream Innovations, Inc. BRIAN FITZGERALD Deputy Director, Center for Division and Electronic Software Engineering; Office of Science and Engineering Labs; CDRH/FDA JOHN ZALESKI, Ph.D., CPHIMS Department Head, Biomedical Informatics, Philips Research North America DALE WIGGINS Vice President and CTO, Healthcare Informatics and Patient Monitoring, Philips Healthcare TRACY RAUSCH Founder and CEO, DocBox, Inc.

(410) 974-0947

4


Annapolis, MD 21409 (410) 974-0947

PRESENTERS/MODERATORS (cont.): PETER KELLEY Director of QA/RA, Capsule Technology, Inc.

5


Annapolis, MD 21409

INDEX PAGE

INTRODUCTION - John F. Murray, Jr. 8 OPENING/LOGISTICS/WELCOME - Donna-Bea Tillman, Ph.D. 9 PRESENTATIONS Device Interoperability and the National Health IT Agenda - Charles P. Friedman, Ph.D. 18 Q&A 45 Safety and Effectiveness Challenges in Interoperability - Jeffrey E. Shuren, M.D., J.D. 51 Setting the Stage: Device, Local, Regional, and National Perspectives on Medical Device Interoperability - Doug Rosendale, D.O., F.A.C.O.S. 60 Q&A 72 Clinical Perspective on Interoperable Medical Device Systems - Julian M. Goldman, M.D. 86 Q&A 114 Consumer and Patient Perspective on Innovation and Interoperability in Healthcare - Dave deBronkart 122 SESSIONS Session 1: Lessons Learned from Existing Regulatory Practices Moderator - Brad Thompson, J.D. 141 NHS - Maureen Baker, C.B.E., D.M., FRCGP 142 Diabetes and Home Management - Yi Zhang 148 FDA - Mary Brady 153

(410) 974-0947

6


Annapolis, MD 21409

INDEX (Cont.)

PAGE

Q&A 158 Session 2: Enterprise Issues Moderator - Michael Robkin 173 Digital Operating Room - Doug Grey, M.D. 174 Tom Judd 178 Tom McGrane 181 Converged Medical Device and Enterprise Network - Tim Gee 184 Q&A 192 Session 3: Systems-of-Systems Issues Moderator - Julian M. Goldman, M.D. 204 Systems-of-Systems Issues - Frank E. Block, Jr., M.D. 205 Using Standard Communications Protocols to Implement Medical Device Plug-and-Play - Dick Moberg 209 Wrangling the Human Element of Interoperability: Defending Against Reason's Latent Flaws and Dekker's Drift - G.M. Samaras, Ph.D., D.Sc., P.E., C.P.E., C.Q.E. 216 Q&A 226 Session 4: Mass Interoperability Moderator - Brad Thompson 239 Mobile Health - Praduman Jain 239 "Tooling" Communities to Advance Community Resilience - Brigitte Piniewski, M.D. 243

(410) 974-0947

7


Annapolis, MD 21409 (410) 974-0947

INDEX (Cont.)

PAGE

The Do's and Don'ts of Creating a ULP Wireless Network - Mike Paradis 253 Q&A 262 Session 5: System Level Risk Analysis Moderator - Brian Fitzgerald 264 Multi-Parameter Data Integration to Support Clinical Decision Making - John Zaleski, Ph.D., CPHIMS 266 FiO2 Control in Preterm Infants - A Case for Device Interoperability - Dale Wiggins 273 The Building Blocks of Clinical Systems - Tracy Rausch 279 Managing Risk in Systems of Systems - Peter Kelley 285 Q&A 290 ADJOURNMENT 303

8


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

M E E T I N G

(9:00 a.m.)

MR. MURRAY: Good morning, everyone. I'm

John Murray. I work in the Center for Devices, in

the Office of Compliance, and I'm in the software

compliance business. I'm a stickler for starting on

time and finishing on time, so I don't know where my

co-host is, but I'm starting without him.

I do things in software compliance like

helping decide whether your software's a device,

helping decide how your software should be

classified, helping decide how your software should

be validated, all kinds of things related to software

compliance issues.

And our first speaking today -- well, the

first thing I have to mention is that everyone in

this room has a cell phone, I'm sure of that, at

least one, or some other teleporting device.

UNIDENTIFIED SPEAKER: Teleporting device?

MR. MURRAY: Teleporting, so we can zap you

out of here. So I ask you to please either turn off

your cell phone or put it on no sound or put it on

vibrate, some form like that.

And our first speaker today is actually the

person that I hold personally responsible for

(410) 974-0947

9


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

starting this workshop. We had a meeting about six

months ago. The people from Continua came and talked

to the Director of the Office of Device Evaluation,

and she listened very patiently, and then she offered

to help them by saying why don't we have a workshop?

And I was in the same room there, and I volunteered

to help her and to help to do this workshop.

So the first speaker this morning is

Dr. Donna-Bea Tillman. She's the Director of the

Office of Device Evaluation here at CDRH, and the

Office of Device Evaluation does pre-market reviews

in the form of IDEs, 510(k)s, PMAs, and all the

things pre-market belong to Donna-Bea. And just to

give you an idea about how big ODE is compared to

CDRH, CDRH has about 1000 people, 1200 people. ODE

has 500 to 600 people. I'm not sure of the exact

number, but I'll say it's on the half. So I'd like

everybody to welcome Donna-Bea. Thank you.

(Applause.)

DR. TILLMAN: Thank you and good morning.

You guys actually had the hard task. I had the easy

task. I'm just the pretty face behind the mike to

welcome you here today and sort of lay out the

charge. But that's one of the things about when you

get into senior management, you get to bring good

(410) 974-0947

10


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

people together and you get to give them a charge,

and then you get to go off and do other things. So

this morning I'm going to give you your charge, and

I'll talk a little bit about what I hope's going to

come out of this, and then I'm going to leave the

incredibly bright people that I see in this room

alone to do the work. All right, let's see. So do I

just click the mouse? Oh no.

UNIDENTIFIED SPEAKER: Try the space bar.

DR. TILLMAN: The space bar, okay.

UNIDENTIFIED SPEAKER: Hold on. The outer

space bar.

UNIDENTIFIED SPEAKER: I don't think this

software's been validated.

DR. TILLMAN: The arrow?

UNIDENTIFIED SPEAKER: Glen is coming.

DR. TILLMAN: No. Is there a clicker?

UNIDENTIFIED SPEAKER: No.

DR. TILLMAN: Do I just say, Next slide?

(Laughter.)

UNIDENTIFIED SPEAKER: That works. Yeah,

let's do that.

DR. TILLMAN: I can do that, too.

UNIDENTIFIED SPEAKER: Yes, we can do that.

DR. TILLMAN: I'm happy to do that. Next

(410) 974-0947

11


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

slide. Oh, I love seeing myself on the video camera

while I talk. This is just really -- all right,

still waiting on the next slide.

UNIDENTIFIED SPEAKER: He's downloading

something.

DR. TILLMAN: Okay. Welcome to White Oak,

and for many of you, I suspect this is your first

visit to your lovely campus. The Center for Devices

and Radiological Health has been here since the

spring, and I hope that you all didn't have too much

trouble finding parking and finding your way around.

This is really exciting. To move to White Oak was a

really big deal for CDRH because it enabled us to be

in closer proximity to the other people in the

center. A lot of the work we're doing crosses Center

boundaries, and we hope you enjoy our lovely

facilities. Next slide.

So why are we here today? Well, we're here

today to develop a more in-depth discussion about

some of the many challenging issues around the safety

and effectiveness of interoperable medical devices.

Next slide.

So just to tell you what I think is

probably painfully obvious to many people in this

room, and that is that interoperability and the

(410) 974-0947

12


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

opportunity to interconnect medical devices clearly

can have a significant positive health -- positive

impact on the health of the American public. There

is a tremendous amount of opportunity that faces us

today with IT technology, with the advent of more

complicated and sophisticated medical devices. With

all we know, we really are standing at the cusp of an

era where we're going to be able to revolutionize how

healthcare is delivered in this country.

But the tricky thing is it has to be done

right, and I think there are a lot of challenges, as

you all know, with doing this right. I also think

that there's a lot of demand, and I think you know

that there's a lot of demand for interoperable

systems. We've got the President's healthcare

agenda. We've got the increasing complexity of

medical devices. We've got the rising cost of

healthcare. How can we continue to deliver world-

class healthcare in this country and yet be able to

afford to pay for it?

And I think all of these factors are things

that influence the need for interoperable medical

systems and for systems that talk to each other and

for ways in which we can bring all of the disparate

pieces that are out there today together. Next

(410) 974-0947

13


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

slide.

So this is a really complicated and hard

issue, and in order to make it happen, there are a

number of very disparate groups that we really need

to get together in one place to have a conversation.

And it's very exciting today because we have

representatives from the IT industry, we have

representatives from the medical device industry, we

have representatives from different alliances. We've

got CIMIT, and we've got FDA here today. We've got

my colleagues that are involved in the Office of the

National Coordinator here today. We have all of the

right people here in this room, and this really is a

unique opportunity to bring all of these people

together and have a discussion about these issues and

try to develop a path forward.

So the number one agenda for this meeting

is really simply to get everybody to get together in

a room and to have the kind of dialogue that we had

in the planning and putting this meeting together,

and that's already happened. And somebody said to

me -- Julian said to me just a few moments ago, and I

agree with him, that even if nothing else happens,

this meeting has already been a tremendous success.

So let's give ourselves a hand for the success we've

(410) 974-0947

14


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

already had so far.

(Applause.)

DR. TILLMAN: Okay. So we've already had

that first success, but I think frankly there's the

potential to have even more of a success to go

through the discussions that you all are going to

have, to break off into the small working groups, and

to address the questions that are on the next two or

three slides. Next slide.

So in the FR notice that we put out, there

are, I think, a number of questions that we said that

we need the answers to, and these really form the

framework of what we hope that you will be discussing

today, presentations and the work that you're going

to be doing in the breakout sessions. Next slide.

And the next slide. I don't need to read

these two. You already know them. But we need to do

more than that. Yeah, it would be great to bring all

you people together to have this robust discussion,

but at the end of the day, we really need to be able

to have something that identifies a framework and a

path for moving forward.

In order to be able to actually make this

vision that I talked about a few moments ago a

reality, we need a regulatory framework that provides

(410) 974-0947

15


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

regulatory consistency, predictability to the

industry so that the industry can feel that this is

healthcare and a space that they can get into. We

need something that fosters innovation because

clearly the technology that we have today is going to

be -- the technology that we have in 10 years is not

going to be the same technology we have today.

Things are growing by leaps and bounds. And we also

need an approach and a framework that fosters and

supports safety and effectiveness because obviously

at the end of the day, what this is all about is

promoting and protecting public health.

So what we're hoping is that you all are

going to have a robust scientific conversation,

you're going to have these presentations, and at the

end of the day we're going to be able to develop a

conference report and some concrete recommendations

for how we're going to move forward from some steps

that we need to take.

This isn't going to happen overnight, and I

don't suspect that you all are going to come out with

all of the answers, but at least if we can come up

with a few initial steps and maybe some ideas about

the broader framework in which we need to move

forward, I think that that would just add another

(410) 974-0947

16


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

success on top of the success we already have had.

So next slide.

So that being said, I want to encourage you

all to take this opportunity to meet people you

haven't met, to have a great meeting, and I'm really

looking forward to the results from this conference.

Thank you very much for coming today.

(Applause.)

DR. GOLDMAN: Good morning, and thank you

to Donna-Bea. She's already gone. My name is

Julian Goldman, and I'm here standing here in front

of you to introduce our next speaker. Our next

speaker is Dr. Charles Friedman, and he will be

speaking about device interoperability and the

national health IT agenda.

Dr. Friedman is Chief Science Officer in

the Office of the National Coordinator for Health

Information Technology. And this is a new role for

Dr. Friedman, and in this role he is responsible for

matters related to research, innovation, evaluation,

and education in international programs, a pretty

broad portfolio. Previously, he was the Deputy

National Coordinator for Health IT, and in that role

he worked to build collaborations in the public and

private sector.

(410) 974-0947

17


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

He has a long and interesting and varied

academic background, and I'll just give you a little

snapshot of some of things that he's done. Prior to

joining the Office of the National Coordinator,

Dr. Friedman was Institute Associate Director for

Research Informatics and Information Technology at

the National Heart, Lung and Blood Institute, so the

NIH, and functioned as the Institute's Chief

Information Officer. From 1963 to 2003 he was

Professor and Associate Vice Chancellor for

Biomedical Informatics at the University of

Pittsburgh.

He's also been busy publishing over 150

articles in scientific journals, a textbook that's

quite well known, and is past President of the

American College of Medical Informatics, and he

currently serves as Associate Editor of the Journal

of the American Medical Informatics Association.

I'm really pleased that Dr. Friedman was

able to get away from his busy schedule. There's a

lot going on in the Office of the National

Coordinator today, and we're fortunate to have him

make a commitment before he got pulled away to some

other pressing matters. So thank you for taking the

time to be here, and we look forward to hearing what

(410) 974-0947

18


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

you have to say.

(Applause.)

DR. FRIEDMAN: So good morning, everybody.

I'm delighted to be here. The topic of this meeting

is a topic of great interest to me and to the office.

I do need, in addition to thanking Julian for that

wonderful introduction, to correct one thing. I may

be old, but I could not have been a professor at the

University of Pittsburgh starting in 1963. I don't

know what that date's supposed to be, but I'm old

enough. I don't need to be any older.

DR. GOLDMAN: Now I'm disappointed.

(Laughter.)

DR. FRIEDMAN: Will I be able to advance

the slides myself?

UNIDENTIFIED SPEAKER: You can if you want.

DR. FRIEDMAN: Okay, using what mechanism?

UNIDENTIFIED SPEAKER: Well, we're going to

have change the setup in just a little bit.

UNIDENTIFIED SPEAKER: I can do it. Just

say next slide and --

DR. FRIEDMAN: Because I've got some

builds, and it's going to be kind of weird. Will it

take too much time?

UNIDENTIFIED SPEAKER: One second.

(410) 974-0947

19


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

DR. WEININGER: While they're setting up,

why don't I just make a few quick logistical

announcements.

MR. MURRAY: Speak into the microphone.

DR. WEININGER: While they're setting up,

why don't I make a quick few logistical

announcements. There are coat racks right outside

the door here, so if you want to hang up your coat,

hopefully the temperature will change. I ordered

good weather. Some of it came, and something else

came along with it, so you'll just have to bear with

me. The restrooms are down the hall here and on the

right, and if those are busy and full, there's

restrooms on the symmetric side of the building, on

the other side, so you can use either one. Please

try to stay in the conference center. This is a

relatively secure facility.

There are sign-up sheets for the breakout

sessions on the benches outside, so please sign up in

the category that you think is most interesting. We

have more categories than we have space, and so we'll

do some consolidation, and you might not get your

first pick but, you know, we'll appreciate your

input.

And I want to say that this is a workshop

(410) 974-0947

20


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

and not a conference. The intention here is for us

to bring up the ideas and have lots of good

discussion and try to get a handle on what the issues

are. So please don't feel like it's the folks up

here preaching at you. This is our workshop, and we

should all participate as much as possible.

So thank you very much. I'm Sandy

Weininger. Sorry. John Murray and I are local FDA

hosts, and you can see that we're not professional

workshop organizers, but we'll get through it.

Thanks.

DR. FRIEDMAN: Okay, thank you, thank you.

Thank you. Perfect timing. Absolutely terrific. So

let me launch into my presentation now and begin by

saying what I very much need to say for policy

reasons but also because it's true, that what we are

doing in the Office of the National Coordinator, in

collaboration with a very, very large number of

wonderful people who are supporting us in various

ways in this endeavor, is a work in progress.

The film is still very much in the cutting

room, and there are pieces of film in the final,

going into the final, and the floor is also covered

with outtakes, some of which will be seen eventually

and some of which probably won't. Because of this, a

(410) 974-0947

21


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

lot of what I'm going to tell you today is a

description of work in progress.

What I'm also going to find myself in a

position today is one where, because we have

regulations out on the street and that are in an

open-public comment period, I cannot say anything

that could be construed as a commentary or an

interpretation of that regulation. So if it seems

like I'm doing a little bit of a dance here in terms

of what I say, it's because I am, but it's also the

way it needs to be at this point. I cannot share my

own ideas about these regulations. I can't say

anything that's interpretative in any way with regard

to these things. Just the facts.

With this talk, I think it might be the

best use of a very limited amount of time to frame

your work in a bit of a policy and technology context

that derives from the activities that are ongoing

under this rubric of the national health IT agenda.

And, in fact, I will begin by talking about what I

mean when I use this term national health IT agenda.

So I'll talk about what is going on, the

recent changes that have occurred -- I guess they're

not so recent anymore -- that have set changes in

motion. I'll talk about where we are right now. I

(410) 974-0947

22


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

will introduce this concept that I'm sure you have

all heard about, called meaningful use. Is there

anyone who has not run into this term somewhere along

the line?

And I will describe the plan that has been

put forward, to the extent that it exists right now,

for achieving meaningful use of health information

technology in the country, and I'll say something

about our progress. I think all of this will create

a useful context.

Then, in my closing few slides, I will

bring the theme of this meeting together with the

general national health IT agenda and try to call out

some significant points of intersection which I hope

will provide useful guidance to you all going

forward.

So what do I mean by a national health IT

agenda? Well, if you have to go back in time, and

this seems like a long time ago, you can go back to

April 2004 when former President Bush signed an

executive order that created the position of a

National Coordinator for Health Information

Technology, and along with that executive order and

the creation of the position, a goal was put forward

that a majority of Americans should have their care

(410) 974-0947

23


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

supported by interoperable health records, electronic

health records, by 2014.

An office, as these things tend to happen,

grew up around the position of the National

Coordinator, that office called the Office of the

National Coordinator, charged to provide leadership

for the nation toward this implementation of

interoperable health information technology and an

infrastructure supporting it and, from a historical

perspective, one might call April 2004 and these

events the beginning of a national health IT agenda.

This agenda was, of course, completely

supported by the new administration. It was

referenced by the new President Obama then on January

24th of the previous year, just about a year ago, and

the goal there was to computerize the nation's health

records in five years. That's a quote from his first

radio address. Take note that it isn't a literal

doubling of the goal, but it certainly can be

construed as one. The previous president had said a

majority, and clearly by implication, his successor

said everyone. So the goal on the same timeframe was

considerably accelerated.

Another event happened early in 2009, in

February, on February 17th. The Congress passed and

(410) 974-0947

24


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

the President signed the Recovery Act, which

contained within it an act, a sub-act, if you will,

known as HITECH, and among other things, HITECH

authorized the sum of $2 billion to the Office of the

National Coordinator to support the advancement of

this national health IT agenda. It also called for,

in a separate section of HITECH, a program of

incentives to be paid to eligible providers and

hospitals who attain the state of meaningful use of

health information technology.

A point to emphasize, of course -- and

probably this is not necessary, but I think it's

important to say it anyway -- is that the end goal of

this effort is not technology. We anticipate that

through adoption and meaningful use of health IT

there will result -- other things have to happen as

well, tremendously improved healthcare and population

health for the nation. Donna-Bea referred earlier to

the unsustainability of the cost and growth in the

cost of healthcare in this country and clearly

greater efficiency as well as safety of healthcare

are goals that are envisioned through health IT and

meaningful use.

So just to show you what lies ahead of us,

let's take a look at where we are right now. One of

(410) 974-0947

25


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

the things we do at ONC is survey the nation on the

state of health IT adoption or EHR adoption. And we

have not quite reached the point of being ready to

release the 2009 figures, but here are figures for

late 2008, and you will see that adoption of at least

a basic system in physician offices in the country

stands at 21 percent right now. Seventeen percent

have what's called a basic system. An additional

four percent have what's called a fully functional

system.

The situation in hospitals, again, based on

2008 data that were published in 2009, suggest that

adoption of at least a basic EHR across all units of

hospitals in the United States stands at something

like 11 percent. Now that's a little bit misleading.

I'm not telling you that if you walk into nine out of

10 hospitals, you won't see a single computer in use

in support of patient care. What this statistic

reports is the number that have at least a basic

system installed on all clinical units. If you break

out some of the date in this article -- and I would

suggest you take a look at this article to see the

details -- you will see, for example, some figures

more in line with what the casual observer in a

hospital would observe, laboratory and radiology

(410) 974-0947

26


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

reports being supported by electronic technology in

about three-quarters of the hospitals, across all

units, drug allergy and interaction alerts in about

half, and an electronic medication list in about

half.

So those figures that look low with regard

to hospital adoption does not mean that many

hospitals are not along the pathway to adoption. It

reflects the number of hospitals that meet all of a

set of criteria for adoption with the technology

reported installed across all units.

We have also made progress, and many of you

either know about or maybe have even been directly

involved in the effort in building a so-called

Nationwide Health Information Network. I'll return

to this in a little bit of detail later. It is a

pillar of an interoperability agenda for the nation.

I just want to say for the moment that the NHIN, as

it is known, is not a separate physical pipe for the

movement of electronic health information. It sits

on top of the internet, uses most, if not all, of the

internet protocols. What it is is a system of

standards, services, and agreement for secure and

trusted connections that lies on top of the internet,

and it is a project that we have been working on for

(410) 974-0947

27


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

several years. So that's kind of where we are now.

Let's move a little bit into the realm of

policy, exploring what meaningful use is and what

progress we have made along this pathway.

One way to look at what we have been asked

to do by Congress in the HITECH law is to take the

law itself, the statute, and take it apart into

components. And this is a useful way to start. And

one can see that HITECH, if you take the law apart,

really consigns ONC to do four things.

One could be listed under the topic of

national coordination through an office that is now

in statute as opposed to being the product of an

executive order. ONC is now established through an

act of Congress, not through an act of the

presidential pen. It would take an act of Congress

to uncreate ONC now that an act of Congress has put

it in statute.

A second component of HITECH, based on the

law, is this program of payment incentives to

eligible providers and hospitals who achieve this

status of meaningful use of certified EHRs. That's

another key point, that meaningful use can't be

meaningful use of any EHR. It has to be meaningful

use of a certified EHR.

(410) 974-0947

28


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

There have been various estimates of what

this program will cost. These are all estimates of

net costs after taking into account the savings that

will be realized for meaningful use, in addition to

the amount of the incentives that will actually be

paid. The incentive payments begin in 2011, and they

can be paid through either Medicare or Medicaid.

There are several supportive grant programs

authorized in HITECH, and then there are enhanced

privacy and security provisions also called out. So

if you want a kind of very high-level way to think

about HITECH, you can divide it into these four

categories. I'm going to run you very quickly

through each one now.

Under national coordination, I mentioned

ONC becoming a permanent organization. The law

created two new federal advisory committees, one for

policy and one for standards. We are required to and

are in the process of beginning to revise the health

IT strategic plan. We are to adopt an initial set of

standards and certification criteria, we are to

establish a certification process, and we are to

establish a governance of the Nationwide Health

Information Network that I mentioned before, in

addition to many other things, but this is sort of

(410) 974-0947

29


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

the highlights under national coordination.

I mentioned payment incentives and

meaningful use as the second component. An important

point to highlight here is that meaningful use really

is a game-changer in the way information technology

is conceptualized. Meaningful use changes the focus

from a technologically oriented focus, rooted in

adoption, is the technology there, is it turned on,

to a focus on behavior. Meaningful use is all about

what clinicians are doing with the technology, not

whether it's there and whether it's turned on.

The law also specifies some significant

aspects of meaningful use. I mentioned that a

meaningful user must use a certified EHR. A

meaningful user must also exchange health

information. This brings in, explicitly, the

interoperability agenda that is a focus of this

meeting, and meaningful users must also be able to

report -- must actually report if they are a

meaningful user of quality measures.

We have implemented -- and I think many of

you know about these programs -- a whole set of grant

programs that were authorized under HITECH, a program

of implementation assistance that is being realized

through the creation of a program of regional

(410) 974-0947

30


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

extension centers. There is a grants program with

awards to states and territories to promote health

IT. These grants are focusing on emphasizing health

information exchange, another major connection to

interoperability.

There are actually four separate grant

programs that are directed at building the health IT

workforce. We have on the street a funding

opportunity announcement to create a set of beacon

communities which are to be examples of exemplary

application and meaningful use of health IT. And we

have on the street -- applications are actually due

tonight. So if you're planning to write one and

haven't started, I'm not sure why you're sitting

here.

(Laughter.)

DR. FRIEDMAN: There is a program of health

IT research activities with four focus areas, many of

which touch on the topic of this meeting, that is

underway and will be implemented. We have just

privacy provisions. There are many called out in

HITECH, one that's very, very important. We are

required to and will and are in the process of

recruiting a national chief privacy officer. All of

this, of course, goes to the essential element of

(410) 974-0947

31


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

trust, that the public must trust that their data in

electronic form are protected. And I will, in the

interest of time, probably not elaborate on that. I

think that point is clear and important.

So let me now say a few comments about the

progress we have made toward implementing the

programs that are mentioned in the HITECH Act and

that I reviewed before.

In order to describe our progress, I'm

going to take a slightly different tack in describing

what we are doing. Instead of parsing the law point

by point, I'm going to talk about how some of these

activities come together. And one way to think about

this is that the movement toward meaningful use can

be seen as having two key strategic elements.

The first element is adoption of health IT

systems. The second element is the establishment of

a trusted pathway for health information exchange.

If you superimpose these two elements, you then have

the infrastructure in place that is necessary to

enable meaningful use, adoption of technology, and

the ability to move information, the essential

information mobility, in a trusted fashion that is a

requirement for meeting, then, all of the statutory

components of meaningful use, adoption of certified

(410) 974-0947

32


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

EHRs, health information exchange, and quality of

reporting.

So, what are we doing to build Element 1,

adopted health IT systems? I'll remind you where we

stand with regard to progress. If this were the

United Way, our campaign at the moment would not be

in very good shape. There are many things we were

doing, but we can call out four primary initiatives

that relate to adoption and can be seen as movers of

the nation to adoption, and we have made significant

progress along each of these areas.

With regard to the payment incentives for

meaningful use, it is necessary first to establish a

legal definition for what meaningful use would be, in

other words, to establish a clear criterion that must

be attained before an eligible provider or a hospital

would be able to receive these payment incentives.

As I mentioned at the very beginning of

this talk, there is a NPRM, a Notice of Proposed Rule

Making, on the street in a public comment period.

That is a proposed regulation that would define the

first stage of meaningful use. That was released on

December 30th and is in a two-month public comment

period. It is great reading, and I encourage you to

look at it and please do comment on it because we are

(410) 974-0947

33


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

very dependent on having your comments.

I should add that HITECH gave CMS, not ONC,

primary responsibility for developing the regulation.

We, of course, were very closely involved in a

collaborative role with CMS in developing this.

The regional extension centers grants are a

major catalyst for addressing Element 1, that is,

moving the nation toward higher levels of adoption of

health IT systems as a foundation for meaningful use.

The funding opportunity for the first round of

regional extension centers was issued on August 20th,

and that process of identifying the first set of

regional extension centers is well along.

A number of health IT workforce grant

opportunities were issued in November and December.

There are many, many estimates on the street of the

number of additional trained health IT workers that

will be needed to support a national movement to

meaningful use. One estimate that we have been using

is approximately 50,000 over and above what the

system at its projected rate of growth would produce

if unamplified. So these funding opportunities will

amplify the system and build workforce capacity.

With regard to a certification program to

establish what are the criteria for these systems to

(410) 974-0947

34


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

achieve that status of certification which is

required as a basis of meaningful use, there is an

interim final rule expressing an initial set of

certification criteria that has been issued and that

was issued on December 30th.

Element 2 goes to this trusted pathway to

exchange information. The primary initiatives to

support this can be seen as standards, the grants to

the states that I mentioned before, the Nationwide

Health Information Network, and privacy and security.

I will mention, just to call out some of the progress

we have made, the same interim final rule that

propounds an initial set of certification criteria

that was issued on December 30th also advances an

initial set of standards that are primarily designed

to support that first stage of meaningful use.

Grants to states funding opportunity was

also issued on August 20th, and the selection and

award to recipients of these grants is at a very

advanced stage.

The Nationwide Health Information Network

is, at the moment, being redesigned and reformulated

but also is entering, at the same time, into very

limited early production. So progress is being made

with the NHIN, and there are a number of activities

(410) 974-0947

35


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

underway relating to privacy and security. I saw you

have time sheets there. How much time do I have?

UNIDENTIFIED SPEAKER: You have plenty of

time.

DR. FRIEDMAN: I have plenty of time?

UNIDENTIFIED SPEAKER: Yeah. Fifteen

minutes.

DR. FRIEDMAN: Okay. Pardon me?

UNIDENTIFIED SPEAKER: Fifteen.

DR. FRIEDMAN: Okay.

MR. MURRAY: We're just preparing for the

end.

DR. FRIEDMAN: You're just preparing for

the end.

MR. MURRAY: But you have plenty of time.

Twenty minutes.

DR. FRIEDMAN: So I'm at the end of the

beginning now.

MR. MURRAY: We're just learning how to do

this.

DR. FRIEDMAN: Okay.

MR. MURRAY: Bear with us.

DR. FRIEDMAN: So just a little bit of

sidebar. And I think it's important just to mention

this, and I you have more questions about it, we can

(410) 974-0947

36


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

address this perhaps in the question and answer

period. You may have come to your own conclusion as

you've listened to me talk about this Element 1 and

Element 2 adoption and a mechanism of trusted

information exchange, that Element 1 and Element 2 by

themselves will not get the nation where it needs to

go.

Elements 1 and 2 by themselves will not

support the development of a learning healthcare

system or a system of population health, which -- all

of which are dependent on the ability to aggregate

information, again, in a trusted and secure way, and

perform analyses on data that are aggregated in some

way so decisions about the state of populations,

looking across individual patients, can be made.

So there is, although our plans to develop

it are not nearly so well formulated, also an Element

3. Element 3 are the additional components of a

national infrastructure that are going to be

necessary to move the nation to a learning healthcare

system, a system that can collect data about care and

data from other sources, put it together, figure out

what's working, figure out what's not working, and in

that way generate knowledge that can be used to drive

improvements. Element 3 is also required for

(410) 974-0947

37


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

population health activities to support basic and

clinical research, taking advantage of the

capabilities that will be put in place through the

other two elements, to do post-market drug

surveillance, to do biosurveillance, epidemic

detection and tracking.

And you can think of Element 3 as requiring

three underlying components, what can be called

gridware, that which puts the data that are needed

together and moves it from where it is to where it's

needed, learningware, which are the analytics

necessary to discover new knowledge to make sense out

of the data once aggregated, and what Craig Mundie

from Microsoft persuaded me to call cool apps, which

are the component of the system that end-users

actually interact with and do have a value for them.

So three elements, two of which I described

in some detail and a third which is conceptually

important but not yet the focus of an ONC-oriented

coherent program yet, can be seen as the elements

which together comprise the national health IT

agenda.

So let me know, as I draw this presentation

to a close, bring that policy and technology and

statutory framework that I described into some

(410) 974-0947

38


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

juxtaposition with the device interoperability

concepts that are the themes of this meeting. So to

begin, let me direct you to places where there are

resources where you can track the process of

meaningful use being defined. The first document I

would call your attention to is a set of

recommendations that came forward from the Health IT

Policy Committee in August of 2009. All of these can

be found on our website, healthit.hhs.gov/

meaningfuluse. Excuse me. And the second document

is the proposed rule which came forward formally from

CMS and was published on December 30th of 2009.

These documents are a very important

foundation to give you a sense of how the definition

of meaningful use is evolving. Meaningful use, as it

evolves, as it is defined and as it evolves, is going

to be an important policy framework and foundation, I

believe, for the device community to be aware of and

to engage with in order to pursue the agenda, I

believe, you are about at this meeting.

When you look at the policy priorities for

meaningful use, which are expressed both in the

recommendations of the policy committee and also in

the Stage 1 proposed rule, which builds heavily on

those recommendations, you will see that there are

(410) 974-0947

39


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

four policy priorities. These policy priorities, you

will notice, are not IT priorities. They are not IT

goals. They are health goals. The first is to

improve the quality, safety, efficiency of healthcare

and reduce disparities. The second is to engage

patients and families. The third is to improve care

coordination. The fourth is to improve population

and public health. And the fifth is to ensure

adequate privacy and security. So meaningful use is

use of health IT in pursuit of these goals.

Another key point to recognize about

meaningful use as it is unfolding is that meaningful

use will not be defined once and remain defined as

such forevermore. The definition of meaningful use

will follow an escalation path, and right now three

stages of meaningful use definitions are envisioned.

Stage 1 -- and the emphasis of the proposed

rule on the street right now is Stage 1 -- will

articulate the criteria for meaningful use that will

take effect in the first year for which hospitals and

eligible providers are eligible to receive incentive

payments. That was a mouthful. Did that make sense?

So align Stage 1, even though the rule

making process is starting earlier, so the rule would

be in place by the time it is needed, align Stage 1

(410) 974-0947

40


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

with 2011 because that is the first year any eligible

provider or hospital can be deemed a meaningful user.

The Stage 1 proposed meaningful use criteria are

multifaceted, but if you have to put a word or a

label on them to summarize them, it would be an

emphasis on the capture and storage and sharing of

data. Stage 1 is Stage 1.

Stage 2, as envisioned by the policy

committee -- and the slide I'm showing you here is

directly from the recommendations of the policy

committee -- as you would expect, envisions and

anticipates more sophisticated use of health IT in

support of those five policy priorities. And a label

you can put on the Stage 2 criteria is advanced care

and processes with decision support.

And Stage 3, which you can align with the

year 2015, are criteria that envision improved

outcomes. So it is a graduated process beginning in

2011 and culminating in 2015. That is the vision for

meaningful use and the evolution of this definition.

So when Julian and I were talking about

this talk and how it might be helpful to you all, one

of the things we talked about was the relationship

between these meaningful use policy priorities and

the device interoperability themes that are the foci

(410) 974-0947

41


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

of this meeting. So Julian and I worked together to

develop this crosswalk, and I think it's pretty clear

that the various policy priorities underlying

meaningful use relate quite clearly and closely to

the requirements that might be realized through

increased and improved device interoperability.

Under improved quality, safety and

efficiency, and disparity reduction of healthcare, it

can be seen that accurate, complete, and automated

data capture, through devices and of course

everything else that feeds data to electronic health

record systems, is necessary to achieve these goals.

With regard to engaging patients and

families, relating this back to the theme of this

meeting, home-based medical device data acquisition

is important to engage patients and family

participation in care. So there's a relationship

there. Improved care coordination also requires

accurate, complete, and automated data capture, back

to bullet one.

Improvement of population and public health

connects because a national infrastructure that

supports interoperable devices will clearly also

support comprehensive population and medical

surveillance. And, finally, with regard to privacy

(410) 974-0947

42


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

and security, a device data security model must be

part of a modern medical device development

regulation and certification environment. So at a

conceptual level, what you are to be addressing at

this meeting clearly relates to the policy priorities

of meaningful use.

So in the previous slide I described a

conceptual relationship between meaningful use and

the development of device interoperability. What

would we see if we actually looked at the documents

that are on the street? Well, if you search the

Health IT Policy Committee recommendations for

meaningful use -- and particularly a wonderful

document. It's a 10-page document that I couldn't

show you on a slide, and it's a whole matrix laying

out the policy committee's vision of meaningful use

for 2011, 13, and 15, and I highly recommend that you

take a look at it.

But if you search that document for

interoperability or any kind of reasonable substring

of interoperability, you'll find that that word

appears once and you will find that the word device

appears four times. But that's really not what's

important. What's important is that medical device

interoperability in the policy vision put forward by

(410) 974-0947

43


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

the policy committee is specifically envisioned for

2015. You will see it right there in the matrix.

You will also see, in the vision of

meaningful use for 2013, that data feeds from home-

monitoring devices under -- relating to the engaging

patients and families policy priority is a specific

objective envisioned for 2013.

So the string matches might be a little bit

misleading there, in terms of their frequency, and

point of fact, there are two clear connections

between these policy recommendations and medical

device interoperability.

In the CMS proposed rule, the NPRM that is

on the street for comment, interoperability appears

18 times and device appears two times, and the

context in which device appears is in relation to the

definition of computerized provider order entry and

really isn't device in the context that I think this

meeting is focused on. But remember that the

meaningful use regulation, proposed rule that is on

the street now, is focused on Stage 1 or the 2011

criterion.

So to bring this to a close -- and again, I

have to be careful about being seen as commenting on

the proposed rule. But I think it is a descriptive

(410) 974-0947

44


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

statement to say that the conceptual connection

between meaningful use and interoperability is

illustrated by the proposed rule, seen particularly

in the proposed rule's emphasis on interoperability

as a key important component of meaningful use. If

you look at ONC's agenda, as I outlined it with these

elements, interoperability goes directly to Element 2

and Element 2 to many activities that we are

currently engaged in.

A second comment I would leave you with is

that interoperable devices, as what might be seen as

a domain, have significant potential to advance the

policy priorities of meaningful use, and the signal

for this is the specific reference in the policy

committee's recommendations, which are only

recommendations but important nonetheless, that

specifically call out topics of direct interest to

this meeting for -- as recommendations for the 2013

and 2015 definitions of meaningful use, which will be

determined in the future.

So what I've tried to outline for you

today, bringing this to a close, is what we are doing

in the Office of the National Coordinator, what the

policy framework is that guides what we are doing,

where we are, the enormous amount of work that we

(410) 974-0947

45


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

have left that we will need your help to bring to

completion, and also the existence as what might be

seen as a convergence path between what you all are

about here today and where meaningful use, if one can

read the signs that are out there, is quite possibly

going to be headed.

So I think we are singing in the same key.

We have not yet joined the choirs, but I think there

is enormous potential for that to happen. So we are

enormously interested in the work you all will be

doing here over the next few days, and I hope my

participation in this meeting can be one foundation

for future interaction between us. Thank you very

much.

(Applause.)

DR. FRIEDMAN: Did I leave time for some

questions?

DR. GOLDMAN: Yeah, please.

DR. FRIEDMAN: Do you want people to use

the microphone?

UNIDENTIFIED SPEAKER: Yes, please.

DR. GOLDMAN: Yeah, please use the

microphone and introduce yourself.

UNIDENTIFIED SPEAKER: You've used the word

quality a number of times, Dr. Friedman, throughout

(410) 974-0947

46


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

your talk. Have you gotten to the point where you

have operationalized it or begun to operationalize

it? How are we going to measure whether you've

achieved quality in this context?

DR. FRIEDMAN: Okay, that's a great

question. I think if you access the proposed rule,

you will see many of the Stage 1 criteria for

meaningful use, proposed Stage 1 criteria for

meaningful use laid out and specific quality measures

to be reported are included in that proposed rule.

So it's there, and it couldn't be more explicit.

Again, this is open for public comment. If you have

comments on what's there, we'd love to hear from you.

DR. GOLDMAN: A very shy audience.

DR. FRIEDMAN: Well, you must have a

question.

DR. GOLDMAN: Well, I actually would like

to just clarify. I want to say, from here, I want to

correct what I said because I misspoke and you

pointed that out. So for the record, because of, you

know, where we are, that your position as Associate

Vice Chancellor was 1996 to 2003, apparently. So the

error was mine.

DR. FRIEDMAN: And while you're making that

statement, change my hair color?

(410) 974-0947

47


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

DR. GOLDMAN: Yes. You're looking younger

right now.

So are there any other questions for

Dr. Friedman? Yes, please come up to the microphone.

MS. BORRELLI: Good morning, Dr. Friedman.

I'm Alice Borrelli from Intel.

DR. FRIEDMAN: Hi, Alice.

MS. BORRELLI: I feel enlightened now that

I happened to read the fine print pages. But I do

have a specific question about how many -- I think

you got at this to a very good degree, but if you

could go a little deeper on how do the 2011 -- and as

outlined in the order, really lay the groundwork to

ensure that there's interoperability and that home

devices will be able to be formed in as 2013 and 2015

rollout? Is there -- work being done to ensure that

that happens?

DR. FRIEDMAN: That's a very good question.

I think that the important thing to say in responding

is that Stage 1 is Stage 1 and you build the edifice

from the ground up. And I think, again, if you look

at the meaningful use requirements and particularly

the certification criteria which are contained in

what can be seen as a kind of companion document in

the interim final rule, you will see how we have

(410) 974-0947

48


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

built Stage 1, the conception of Stage 1, CMS and us,

to be that from both a policy and technology

perspective, that foundational element.

While you won't see devices mentioned, what

you will see are the concepts of interoperability

that apply not just to devices but to any information

exchange process which must have a set of features in

order for the goal -- that ultimately that data in

computable form can move from where it is accurately

to where it's needed, with the data at the receiving

end having the same meaning as it did at the

transmission point. You will see how those general

concepts are being baked into this foundation.

So I think if this plays out as we all

envision it, and I very much believe it will, this

community, as it thinks specifically about devices

and how they play into this, will be able to build on

this solid foundation which not only enables the

specific functionality required for Stage 1

meaningful use but also creates the potential for the

next and more sophisticated stages to follow.

DR. ZALESKI: Good morning, Dr. Friedman.

John Zaleski from Philips Research. In attributes in

your Element 3, it looked like, in some regard

related to clinical decision support, was that the

(410) 974-0947

49


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

intent? I mean, obviously it extends beyond that

but --

DR. FRIEDMAN: Um-hum.

DR. ZALESKI: -- there is a clinical

decision support flavor to some of those

applications, the coolware, as an example, which you

were referring to.

DR. FRIEDMAN: Um-hum.

DR. ZALESKI: Is that a correct assumption

or is that -- am I off the mark?

DR. FRIEDMAN: Clinical decision support,

in its most sophisticated and fully elaborated form,

requires Element 3 because you can envision, in a

learning healthcare system, the studies that are done

which generate new knowledge, can then find their way

into the knowledge bases that are the drivers of

clinical decision support, and you have a kind of

continuous quality improvement cycle enabled by

Element 3. So, yes, the nirvana of clinical decision

support requires Element 3.

But I think it's also the case that

decision support, to be -- that is effective to a

significant degree, does not require that automated

creation of knowledge. So there are also elements --

there are also significant components of decision

(410) 974-0947

50


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

support. Call it as part of Element 1, as well. And

if you read the Stage 1 NPRM or look at the

meaningful use matrix from the policy committee,

you'll see decision support called out there, but not

of that most sophisticated nature.

DR. ZALESKI: I've been reading it. I've

been going through it. My reason for asking that is,

frequently, when clinical decision support is thrown

out there, specifically in the context of CPOE or in

EMR systems as opposed to real-life device, and

that's what I was referring to.

DR. FRIEDMAN: Right. And I understand the

distinction, and it's the same scenario. You start

basic in a way that lays the potential for greater

sophistication, and you add the sophistication over

time.

DR. GOLDMAN: Thank you very much,

Dr. Friedman.

DR. FRIEDMAN: Thank you.

(Applause.)

MR. MURRAY: Last Wednesday here at CDRH,

we had a very exciting day. We were all gathered to

hear the Center Director tell us our strategic plan

for 2010, and we were all sitting there quietly and

patiently waiting for him, and who showed up but the

(410) 974-0947

51


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

Commissioner of the FDA, and she had some really

great news for us at CDRH.

We now have a permanent Center Director,

Dr. Jeffrey Shuren, who received his juris doctorate

degree from the University of Michigan, has a medical

doctor degree from Northwest University. He's board-

certified in neurology, he's been an assistant

professor of neurology, and he's worked for the FDA,

I think, for about 11 or 12 years. He's worked in

Medicare/Medicaid, he was in the Office of Policy, he

was an Associate Commissioner, and I think it's great

that we have him today to speak to us, and I'd like

to welcome Dr. Shuren to the podium. Thank you.

(Applause.)

DR. SHUREN: Good morning. Well, thank you

for coming to discuss this important topic, and I can

see clearly by the number of people in attendance

here that it's an important issue for FDA, the

medical device industry, and the healthcare

community. I understand that this topic has been

under discussion for many years, and it's my hope

that this workshop can provide the necessary impetus

to make medical device interoperability a reality.

The commercial marketplace has already

created many capable interoperable systems. All

(410) 974-0947

52


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

around us, technology provides products that work

together, ranging from your computer, to your TV, to

your car. Interoperability is everywhere, and it's

created huge benefits for millions of people. It's

improved productivity, efficiency, and jobs. We have

new things like automated and web-bill payments.

We've got safer things like traffic reports. And we

even have some new problems like texting while

driving.

We at FDA believe that the technology and

the knowledge are currently available to design,

develop, and implement a safe and effective medical

device interoperability system. What we need to do

is to pull it all together first by answering several

critical questions. That's why we're here today.

Today, for the most part, the majority of

medical devices are not interconnected and hence not

interoperable. In this environment, each device is

represented by a single standalone product or entity.

Data from each individual device is presented

separately to the practitioner. It has been the

responsibility of the practitioner to integrate the

data from these independent sources.

These individual medical devices provided

by many medical device manufacturers are generally

(410) 974-0947

53


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

designed to operate independently. They do not

address interfacing with other devices and therefore

generally are reviewed and regulated by FDA on an

individual basis. As a result, the integration of

device data and interoperability of devices has

become the responsibility of the operator of the

device, often the clinical practitioner.

For example, a pulse oximeter won't work

downstream from a blood pressure cuff because no

pulses get through. It's the responsibility of the

practitioner to understand how to use the devices

properly.

In another case, a patient's ventilator was

shut off to allow an X-ray to be taken without motion

artifact. However, the X-ray film got jammed and the

medical team worked diligently to get it out, but no

one remembered to turn the ventilator back on, and so

the patient died.

In some advanced systems, several

manufacturers have created integrated and somewhat

interoperable devices that only include their own

proprietary product line. This partial integration

is achieved through proprietary interfaces that are

manufacturer specific. These proprietary interfaces

modify the original FDA-approved products. In these

(410) 974-0947

54


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

instances, the modifications are typically reviewed

by FDA.

The partially integrated clinical

environment performs some of the synthesis and

integration that was typically performed by the

practitioner. In some situations the practitioner

gives up to the integrated device some responsibility

for safety.

MR. MURRAY: Can you go one slide ahead?

DR. SHUREN: What's that?

MR. MURRAY: One more slide ahead.

DR. SHUREN: Oops, didn't click it. There

we go. So as interoperability increases, we see a

possible transfer of safety responsibility from the

practitioner to the machine or the system. And

several examples come to mind, like alarm integration

and prioritization, automated blood pressure tracking

correlated with ECG and trending leading to an alarm

condition, and automated remote practitioner

notifications.

As a clinical device environment becomes

completely interoperable, the ability for truly

integrated plug-and-play will emerge. This

interoperable clinical environment can be described

as follows: it contains open and nonproprietary,

(410) 974-0947

55


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

manufacturer-independent interfaces; it provides for

autonomous integration, operability, and

communication between multiple vendor devices; it

provides the ability to deliver enhanced patient care

and safety systems through customized synthesis and

integration and automated safety interlocks; it

provides for the implementation of safety interlocks

in a multi-vendor environment; and it allows for the

flexible clinical application of devices in a multi-

vendor environment.

Just as interoperability in the commercial

world has achieved great success and impact, the

focus of device interoperability should be to achieve

beneficial clinical impact. This slide identifies

several examples or types of potential clinical

impact. And here's how an interoperable clinical

environment can improve patient care.

First, the ability to interchange sensors

and actuators, based on clinical need, allows us to

transition from an equipment-centric environment to

one that is more patient centric. The practitioner

will have the ability to unplug an existing module

and select a new module that may provide more

appropriate functionality for the patient without the

traditional restrictions of proprietary or legacy

(410) 974-0947

56


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

standalone device systems.

Secondly, greater availability and cost

competitiveness of devices may be achieved by the

reuse and reduction of costly infrastructure that

would traditionally have been designed and developed

by each individual manufacturer. Ideally, this leads

to increased patient accessibility to device-based

care.

Third, these systems will allow for the

implementation of patient-centric safety interlocks

across a broad spectrum of devices and device

manufacturers. For example, interoperability could

allow for automatic synchronization between a

ventilator and imaging equipment designed to take a

picture during the ventilatory pause.

Fourth, these systems can allow for the

implementation of functionality that may result in

improved quality assurance, such as assurance that

patient-specific data is recorded and transmitted in

appropriate and consistent units. So, for example,

it could prevent patient weight recorded in pounds

from being sent to a pump that computes the dosage in

kilograms.

Fifth, the practitioner has the ability to

combine device functionality and data in a way that

(410) 974-0947

57


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

best suits the specific patient clinical need.

And sixth, the practitioner can automate

protocols to perform device readiness checks and

automate setup of clinical applications and safety

interlocks.

It should be no surprise here that the

number one challenge to assure the safety and

effectiveness in an environment of interoperable

devices is what's prominent in FDA's mind. But

before we can even begin to take on that challenge,

we need to assure that we ask all the right questions

and address those questions with valid science.

Answering these questions will help us identify what

tools we need to develop to facilitate and assure the

safety and effectiveness of interoperable devices.

These tools may include standards, guidance, test

methods, protocols, and certifications.

At a minimum, FDA traditionally examines

these issues to assure the safety and effectiveness

of devices, namely clinical, engineering, risk, and

management. We will need to examine the specific

clinical scenarios to understand the intended uses,

clinical applications, and their effect on public

health. In addition, clinical scenarios and

applications can be used as a basis for determining

(410) 974-0947

58


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

intended use and for identifying potential

contraindications.

The quality and safety of these systems is

highly dependent on proper design. Assuring proper

design includes a well-defined system. The list

above identifies a set of design elements that should

be defined. This applies not only to the individual

devices but also to the system in which the devices

interface, namely a system of systems.

Identification of the involved risks is

critical. It can drive engineering design as well as

the regulatory review process. Such risk includes

those inherent in individual devices, those inherent

in the multiple-device environment, and those present

in the clinical environment.

And, lastly, there are many unanswered and

yet unposed questions related to the management and

control of these types of systems. Establishing the

appropriate management control system will be

necessary to assure the initial and continuing safety

and effectiveness of these interoperable systems.

Important questions to be addressed include who is

going to develop and maintain the tools, who's going

to implement the tools, and who is going to decide if

the tools are efficient to assure safety and

(410) 974-0947

59


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

effectiveness.

So with that, let me end by thanking all of

you for attending today's workshop and for what we

hope is going to be a lively dialogue. Thank you.

(Applause.)

DR. GOLDMAN: Thank you very much,

Dr. Shuren. I know you have to run off to another

meeting. We appreciate you taking the time today.

DR. SHUREN: I actually can stay for a

little bit.

DR. GOLDMAN: Okay. Well, I'd like to

introduce our next speaker. There he is,

Dr. Doug Rosendale. I'll tell you a little bit about

Dr. Rosendale. He's the Director of Joint

Interoperability Ventures within the Veterans Health

Administration, Office of Health Information, OHI,

and he's also a board-certified general surgeon. And

I won't even make any jokes about that. He's the

Chair of the Surgery Discipline for the American

College of Osteopathic Surgeons and was previously

Chief of Staff in the private sector and Chief of

Surgery at Grand Junction VA Medical Center in

Colorado, and he trained in medical informatics and

is an affiliate faculty at the Harvard Medical School

Decision Support Group.

(410) 974-0947

60


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

Dr. Rosendale's health IT background spans

many aspects. He's been active, I think one way to

characterize it is in health IT that relates to

patient safety initiatives, especially around

surgical care. And he's received awards for that

from the American College of Osteopathic Surgeons.

He's widely published and has been working this past

couple of years with the White House on a number of

initiatives also that relate to interoperability for

public health. And for that, I'm very pleased to be

able to welcome Dr. Rosendale.

(Applause.)

DR. ROSENDALE: Okay. Well, audiovisual

never stops me.

DR. GOLDMAN: What happened?

DR. ROSENDALE: Oh, they're trying to load

my deck.

DR. GOLDMAN: It'll just take a minute.

DR. ROSENDALE: Yeah. But I'm good. I can

do it without.

DR. GOLDMAN: So how's the weather in

Colorado?

DR. ROSENDALE: You know, I haven't been

there in a week. I decided to spend two weeks here

in the Beltway, so now I'm learning about rain.

(410) 974-0947

61


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

Thank you for having me, by the way. I'm Doug

Rosendale. I'm a surgeon from Western Colorado. If

you haven't noticed the boots, I wear them a lot, and

I'm considered the Colorado cowboy for that reason.

Just for interest, I'm curious what the

target audience is. My military guys tell me that

there's always a target for something, and so --

(Laughter.)

DR. ROSENDALE: So I need to understand who

I'm talking to. So by raising your hand, can you

tell me -- and by the way, I don't do well behind

podiums. I want to move, and if that camera would

follow me, that'd be great. How many people here are

policy makers? Any policy people? How many people

here are clinicians, like doctors, nurses, allied

health professionals? And how many people here are

technology-oriented individuals? Oh my, now I'm in

deep trouble. That's why I wear these boots.

(Laughter.)

UNIDENTIFIED SPEAKER: High boots.

DR. ROSENDALE: High boots, that's right.

All right. Well, I've got a pretty good idea of who

we're talking to, and I think this is a very exciting

discussion, something that Julian and Sandy and I

have been talking about for a long time.

(410) 974-0947

62


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

My primary goal is to talk about levels of

interoperability. It's not just interoperability.

And by the way, nobody I know in Western Colorado

knows what that word means, and I refuse to give up

on it because it's a very important word.

Interoperability means that things talk to each

other, and we don't do that too well, and when my

daughters were 13 and 14, they didn't talk well at

all to me, so I know what's that about.

By way of introduction, first of all, I was

trained in general surgery, and I come from the

Veterans Affairs. And I know I'm going to get

through this without that slide back. I'm going to

try my best. The idea is that we come from Veterans

Affairs. There's about 150-plus hospitals and 13

clinics. How many folks are familiar with the

electronic medical record that Veterans Affairs uses?

You're pretty familiar with that. So you know it's

really integrated. It's an integrated solution where

the ancillary services like lab and rad and pharm and

the EMR itself are all integrated. And so now we're

on this beacon horizon of opportunity with things

like OR systems and ICU systems. And I heard the

gentleman here from Philips.

So all of those physiologic tracking

(410) 974-0947

63


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

solutions have to be managed within the point of

care, so in the ICU, ER, OR, those areas. We're

good. Okay, let's see how many slides I got through

without using them. See, I'm not a slide guy, so I

like to use a lot of pictures. So I just hit the

button?

UNIDENTIFIED SPEAKER: Go ahead.

DR. ROSENDALE: Can you hit buttons for me?

UNIDENTIFIED SPEAKER: You go forward and

back with the arrows.

DR. ROSENDALE: Okay, got it. I have to

read that? Okay. All right. So basically Julian

introduced some of these things. I'll catch up on

the slide deck. You know, VA has been working --

we've done this for about 20 years, working on

integrating our electronic medical record. What I do

now is I run the Joint Interoperability Venture

portfolio for Veterans Health Affairs' Office of

Information. What does that mean? It means that we

are trying to reach out and integrate with our

military colleagues, and so there are about 50 -- I

was talking about the numbers of hospitals. There's

about 50 Army, Navy, and Air Force hospitals that we

work with. We have what we call sharing environments

or joint ventures.

(410) 974-0947

64


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

And so in North Chicago there's a specific

pilot where the Navy hospital is integrating with the

VA hospital into a single building, and if you know

anything about moving in with your in-laws, it's not

easy. And so there are challenges with trusted

partnerships and infrastructure and firewalls and

fiber between the systems, and what we discovered is,

from a business architect perspective -- and I'm a

wannabe business architect -- the business

architecture is really what drives all of the

infrastructure architects -- architectures.

And so what we discovered is, as you need

to have identity management, first, you need to make

sure you're reconciling the patient. How many folks

here are working on specifically identifying

management solutions with device interoperability

with probabilistic matching solutions? Anybody doing

that? One guy. So that's very telling, and so I got

to tee this up. So I need to tell a story about the

pathologist and the private care doctor and the

surgeon. And they all in part of the world -- and

it's like every doggone morning somebody's goose

hunting.

And so these three docs decide to go goose

hunting, and they're in their duck blind, which is

(410) 974-0947

65


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

really a goose blind, and a flock of geese fly over,

and the pathologist goes, well, you know, the surgeon

and the primary care doc, the family doc, brought me

out here, so they must be geese, so I guess I'll

shoot one and then I'll dissect it and find out for

sure. And boom, boom, boom, he shoots the goose and

he gets one and he's happy.

And then another flock of geese fly over

and the internist -- or the primary care doctor says,

well, I'm not sure what they are, but I've been

looking at the droppings and I did a few tests, and

it looks like it's probably a goose and not a duck

and not an eagle. So blam, blam, blam, and he shoots

these geese out of the sky. And they're all happy.

And then the surgeon sees the next flock of

geese fly over, and he goes, blam, blam, blam. What

the hell were those, anyway?

(Laughter.)

DR. ROSENDALE: And the reason this is an

important point -- and I've told this joke a thousand

times, but not quite like that, in the context of

identity management. You want to make sure that was

a goose because if you don't have a license for a

goose and you shot a duck, or what I do at my back

deck is I shoot woodpeckers and that's really

(410) 974-0947

66


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

illegal --

(Laughter.)

DR. ROSENDALE: -- is you have to make sure

you've got the right bird, the right patient. And

why is that important for device interoperability?

It's important because when you're looking at the

North Chicago environment, a patient comes into the

hospital, the first thing they're going to do is go

up to that clerk and they're going to get registered

into the system.

Well, guess what? They're not registered

in the DoD system. They're only registered in the VA

system. Or they come up and they talk to the DoD

clerk and they're not registered in the VA system.

All of a sudden you have a mismatch. You don't have

the right patient. So you got to the duck, you don't

have a goose, and that's a problem.

And so the first thing we had to manage is

the identity management circumstance and registering

patients jointly in the two electronic records.

Well, that's no different for a device. The device

has to know that you've got the right patient. Why

this is pervasive and critical is if you start at the

point of care in the ICU, once you get registered and

you're in an EMR, and then you want to think about

(410) 974-0947

67


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

how that information is ultimately going to be shared

through the NHIN -- I guess we can't call it the

N-HIN anymore. It's now the NHIN, which sounds like

ninny, and I can't even deal with that.

But the point being is you have to make

sure that that identity of that patient transcends

from the point of care, the device, and -- oh, by the

way, the devices need to be talking to each other.

That's what the smart guys have already talked about

here today. And then if that information, that

physiologic information is an analytic data store, it

needs to be stored in the EMR in such a way -- I got

to catch up with my slides now.

By the way, this is our landscape. This is

what we have to deal with with federal healthcare.

This is VA, DoD, and HHS. And so that's a lot of

docs. And then if you add on probably 10 times that

amount for private care, it's very huge.

Let me jump ahead. I have a lot of

pictures here, but this really speaks about, you

know, the complexity of where we are today. And this

speaks to the levels of interoperability. So if

you're dealing with a device, that information, that

identity has to transcend all the way through the

EMR, and then if you're a doctor at Kaiser or at DoD

(410) 974-0947

68


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

and you want to have a C-32 travel over, if that

identity is not matched up, then you got the wrong

patient. And if you don't have -- how many people

here know what deterministic identity management is

versus probabilistic? And so that's the key point.

All I really want you to learn today is

that I'm not a goose hunter and that identity

management is the most important thing that I can

have everybody take away. If we don't get identity

management right and we don't use probabilistic

matching as the mechanism to do so, we are not going

to get any kind of interoperability between the

devices and NHIN. It just won't happen. So that's

how critical this is.

And so how many folks here are actually

working on devices? I've been to the University of

Pennsylvania groups and the high confidence groups,

and I know that Helen Gill is here. And we talked

about this a long time ago, and everybody wanted to

have test environments to actually test the

interoperability of the sharing between devices and

those test environments have been very slim to none.

If we could concentrate on probabilistic matching of

identities, we could make a huge difference. And

what we found in VA and we found with our NHIN

(410) 974-0947

69


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

project in San Diego is that there's really about

five identities that you need. You need your first

name, middle name, last name, Social Security number,

date of birth, and there's all of this twitterbating

about whether or not to use Social Security numbers.

In my mind it's relatively irrelevant. It's not a

matter of one identity. It's a matter of five or six

attributes about the individual.

And so we found that if you have five

attributes on the VA side and you have five

attributes on the DoD side but three of them are

wrong, they got the last name wrong, she got married

or changed her name or somebody mistyped or fat-

fingered a Social Security number, as long as you can

match up three of the five or three to three in a

probabilistic matching solution, then you've got the

right patient 99.99 percent of the time.

And so that's the missing piece in my mind,

is nobody has been effectively taking that on. And

so single sign-on, identity management, initiate with

a company. I think that was just picked up by

Microsoft, and there are other companies that do this

sort of work. I can't really mention those names,

but there's a lot of people that are working on this.

And one last point, and it's about the

(410) 974-0947

70


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

architecture. I said I wanted to be an architect.

There's really the business architecture, and then

there's the platform upon which all of this works.

And I know Dr. Friedman mentioned that we didn't

really want to talk about technology, we wanted to

talk about the business of medicine. And not so much

the business of medicine, but the active taking care

of patients.

All the electronic environment is, is a

reflection of the actual dialogue between patients

and providers. That's all it is. It's a mere image

of that. And as a surgeon I became disgruntled with

the fact that I had to operate and then I had to go

do all of this paperwork and dictate the op report

and do all of these orders and all of these things in

the electronic environment. What we need is a

mechanism so the devices that are part or agents like

these are part of what we do every day, and so part

of our workflow capturing the data along that path.

If we do that, then we will have a much more

efficient methodology for taking care of patients.

So with that, I'll open it up for any

questions. I didn't really mention much about our

project in North Chicago. We have multiple joint

facilities in Pensacola, Honolulu, in Anchorage and

(410) 974-0947

71


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

all over the country, like the map shows. It's

really foundational work because it's boots-on-the-

ground work. It's where you really don't ethereally

talk about these concepts of trying to create

interoperability and creating incentives. It's

really the real work. And so that's what we do, is

we're more a pragmatic entity. We actually develop

the true business requirements for the users, and we

translate that into technology solutions.

We have a hundred million dollars going

toward just a few things, single sign-on and identity

management, joint registration, order portability.

That's the other piece. And EMR is basically read,

write, and order. That's all an EMR really is. And

then you need to do the business intelligence of

knowing what your workload is and what your financial

reconciliation is. For the military it's operational

readiness. And then you have to be able to schedule

patients within the medical center.

And so those are the five key areas we're

concentrating on because nobody's ever done it

before. Everybody talked ethereally about how it

should be done, but nobody ever did it. And so the

NHIN project and the work that we're doing with joint

ventures is foundational for that work. So thank you

(410) 974-0947

72


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

very much. I appreciate it.

(Applause.)

DR. ROSENDALE: Oh, one more thing. Before

we go to break, I need everybody to stand up just

real quick. Just stretch a little bit and help me

out. Wave your hands and stretch like this, and let

me take a picture.

(Laughter.)

DR. ROSENDALE: Because what's really

important to me is to get a standing ovation at every

meeting.

(Laughter.)

UNIDENTIFIED SPEAKER: I've got a question

for you.

DR. ROSENDALE: Yes, sir.

UNIDENTIFIED SPEAKER: I'm real glad to

hear the folks --

DR. GOLDMAN: Please use the microphone.

UNIDENTIFIED SPEAKER: I'm sorry.

DR. GOLDMAN: We have a lot of folks on the

web, on our webcast, so we want to stay on the mikes.

UNIDENTIFIED SPEAKER: I'm real glad to

hear the folks on the western slope are doing good

work. I've got a question about trust for you, not

in the context of the upper strategic levels but at

(410) 974-0947

73


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

the point where we're talking about individual

devices that you would like to plug and play

together. For the most part, no device trusts the

other at this point. It's a classic business problem

in the commercial interoperability world. How is the

VA dealing with that issue, if you've made the

progress that you talked about in the slides? And I

think it's a fundamental problem.

DR. ROSENDALE: Right-O. I mean, the trust

issue is actually the number one issue. Like I said,

when you move in with your in-laws, you have to trust

them that they're going to let you, you know, use the

kitchen. And the reality is, is that that trusted

partnership is one of the greatest challenges.

We've had, at the medical center level,

take that down now to the device level. In VA what

we've done is we have a team in Hines in Chicago who

have actually worked with a number of companies in

trying to make sure that the messaging and the

security standards are adhered to so that when that

device plugs into our network, that those standards

are met. And particularly the security and the

messaging. And those are, you know, the technical

services that are necessary for this

interoperability. And so what we've done is we

(410) 974-0947

74


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

worked with those vendors and created an environment,

a testing environment to show that sort of plug-and-

play capability. But it was not easy. I can tell

you, it took many years for that to occur. There

were a lot of technical discussions, a lot of policy

discussions that had to occur, and then there were

the testing, the true technical testing to make sure

that the device didn't tank our system. And that has

happened too.

And so those are really tough things to

manage, and like I said, it's not ethereal; it's real

boots on the ground. Does it work? Does it connect?

Does it transfer the data properly? So we've had to,

through trial and error and a lot of hard elbow

grease, work through that. And we've had great

success.

MS. RANDALL: Good morning, Doctor. I'm

Debra Randall. Thank you for your comments. And

speaking of boots on the ground, the VA has one of

the most advanced home medical device systems for the

veterans. Is there any particular experiences you've

seen on the topic area you've been discussing,

interoperability and identification of the

individual, that came out of that work that you could

point out to us?

(410) 974-0947

75


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

DR. ROSENDALE: Right. A good friend and

colleague of mine and an Englishman who likes the

same kind of beer I do, Adams dark, is head of that

program. And so he has done a magnificent job in

working with vendors and developing the care

coordination and telehealth program within VA. And

I've watched his challenges and his successes along

that path, and it's the same situation, it's the

trusted partnership.

Now, the issue is you can create

environments that are relatively siloed, that sort of

pseudo-interoperate with your enterprise. And so by

doing so you can send faxes, you can send PDFs, you

can send that sort of information. The VA is so far

advanced in its integration and interoperability

level, I think Kim says that we're probably Level 7

out of Level 7.

And so we have done great work in showing

that the HL7 or the messaging that comes from those

devices integrates into our telehealth applications

in the medical center and then that information can

be ported to our electronic medical record. That

last part has been a bit of a challenge. Any time we

try to write back to our EMR, everybody gets twitter-

witty. Anytime you want to read from our EMR, it's

(410) 974-0947

76


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

relatively easy.

And so the right back component or the

transactional interoperability with messaging and

security with orders is the challenge. Nobody's done

that that well, but it's necessary. And I don't

understand it when most private sector communities

can take from their EMR and write a prescription at

CVS or Wal-Mart or any other pharmacy. They already

have order portability. Somehow they've broken that

trusted partnership challenge. Does that answer your

question? Yes, sir.

MR. ZAKIAN: Vaughan Zakian from Nuvon. I

have a question about identity and the portability of

the identity through departments because as it stands

today in most areas and EMRs, it's all location-

based. So how are you addressing the fact of

location-based systems and identification of

parameters that you're talking about?

DR. ROSENDALE: Yeah. So as I mentioned,

the attributes of an individual. One of the

attributes of an individual is where they're located.

I'm in FDA, which was a real pain to get into today,

let me tell you. But the attribute is location and

who you are, based on the issues I mentioned, and a

number of other factors.

(410) 974-0947

77


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

When you break up the architecture, you

decouple the architecture, and you've got not just a

tightly coupled architecture but an application on a

database, and you break this apart where you've got

the middle tier that's actually allowing the

flexibility of communication between the applications

and the database. Everybody has an iPhone, I bet.

Well, iPhones are simply a platform upon which

anybody can build an application for purpose. My

favorite is Shazam, so I can tell what music I'm

listening to. The idea is, is those applications

then talk through that middleware, the enterprise

system bus, and they reconcile the identity using

services like the one I mentioned.

It's a service-oriented architecture where

those services are provided, not tightly integrated

with the current technology in architecture, but

they're outside of it as an engine that actually you

subscribe to. And so a device is no different than

an EMR. And the guy over here at Philips is my

favorite guy because he's shaking head like this and

he hasn't shaken his head like this, so I must be on

to something. Right? Right? Right?

(Laughter.)

DR. ROSENDALE: Yes, sir.

(410) 974-0947

78


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

MR. ZAKIAN: However, you know, when you're

putting these parameters together to identify the

patient, right, in a system where you're talking a

middleware that's managing that --

DR. ROSENDALE: Yeah.

MR. ZAKIAN: -- then you must be issuing

another token that's an identifier of --

DR. ROSENDALE: Yeah.

MR. ZAKIAN: -- data for that.

DR. ROSENDALE: Yeah, sure. Yeah. I mean,

there's no reason why you can't share tokens of

sharing specific to your device. In fact, if you're

looking at device -- if you're looking at devices

that go south and you need to contact all of the

patients that had that device, that were managed by

that device, you need to be able to track that.

So that metadata is absolutely necessary

and there's no reason why -- I mean, it's the Google

opportunity. And I don't mean Google Google, I mean

Googleplex. You can add as much metadata to our

current data platforms as you need to to make sure

identities are square. I don't think anybody's doing

it that well, particularly at the device level.

MR. ZAKIAN: We're getting closer.

DR. ROSENDALE: Okay, that's the challenge,

(410) 974-0947

79


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

by the way.

DR. BAKER: I'm Maureen Baker. I'm

Clinical Director for Patient Safety at NHS

Connecting for Health in England. I do -- of correct

patient identification and particularly if you were

talking about -- between -- networks. Now, we have

something called the NHS number and across the NHS,

which is a unique identifier, and usually in our

system we struggled to implement that,

particularly -- however, what you were explaining

about probabilistic matching, if I were to think of a

scenario of twin boys born to a Muslim family, they

have the same gender, the same date of birth, the

same address, the same middle name, the same surname,

then I just don't see that that level would give us

the reliability that we would look for and -- is it

reliable enough in the first place? Is there a

possibility that a generation of unique identifier

either in the --

DR. ROSENDALE: A very good question. And

you actually just revealed that .0001 percent error

that I didn't talk to. I didn't say 100 percent.

Now, we are 95 percent with our master patient index

in VA. If we have probabilistic matching, we will be

99.99 percent. Your question is, Is there an

(410) 974-0947

80


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

opportunity for creating a unique identifier that's

all trusted? I argue that even the unique identifier

is not ideal because you can still fat-finger and

make a mistake with that single number. And so you

have to have solutions --

UNIDENTIFIED SPEAKER: -- then the

probability of entering an invalid number would be --

DR. ROSENDALE: So as Chuck Friedman said,

this is not all a technology discussion. This is a

business process discussion. The business process is

such that you can actually build the technology so

that when you get an error, when it does -- when none

of them match and you think you've got the right

patient, the way we manage that is we manage that so

that there's a list of those that are fallouts.

There's a fallout. Then you have to do manual

investigation to make sure that you're finding that

person, which could include the very identifier

you're talking about.

I mean, all that identifier is in my mind

is a metadata component of what you've accumulated as

a list of attributes about the individual. And so I

think we're smart enough in science and probabilistic

and statistical matching that we can create the

models that fit the business process, not just hope

(410) 974-0947

81


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

and pray that the technology does all the work for

us. I don't know if I answered that. But I'm a

surgeon and I'm very practical. If it doesn't work,

I just find a bigger knife.

(Laughter.)

DR. ROSENDALE: Yes, sir, in the back.

DR. BLOCK: Frank Block. I'm an

anesthesiologist at VCU.

DR. ROSENDALE: There we go.

DR. BLOCK: I'm losing my voice here.

DR. ROSENDALE: I've got your Wall Street

Journal here if you need it.

DR. BLOCK: Oh, thank you. At our Society

of Technology in Anesthesia meeting a couple of weeks

ago, Don Dettler (ph.) spoke to this ID, whereas as a

physician, I have a national practitioner ID.

There's actually no way that a patient can obtain a

national medical record ID even if the patient wants

one.

If our dream is to have a chart that can be

used anywhere in the country, you go to the ER, you

join the service, you go to your private clinic or

whatever, the dream would be that there would be some

sort of national medical record. If it doesn't have

a number, how will we ever get there?

(410) 974-0947

82


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

DR. ROSENDALE: So that's a tough question.

The discussion we've had so far is about the

probabilistic matching. Probabilistic matching means

you add science and statistical probable capabilities

to your electronic environment. And so it's very

similar to the lady from England, is everybody wants

to hang their hat on a single ID because they think

that's the panacea, and I don't know that that's the

case. I know that Don Lindberg, when I went into the

National Library of Medicine, he had me hold my hand

up to a plate, and that was the handprint. That was

yet another attribute about me. And then there was a

fingerprint, and then there's a retinal scan.

There's all of these bio -- what do you call that

again -- biometrics that allow you to have the

attributes. So I'm not convinced that a single

identifier is going to be the panacea. I think we

need to be more -- we need to be smarter than that

and use science and probabilistic matching in order

to do so. Would you help me here? Because that's

the second question on this.

DR. ZALESKI: I stopped nodding. One of

the things --

(Laughter.)

DR. ZALESKI: One of the things from the

(410) 974-0947

83


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

perspective of science -- I won't belabor this -- but

that we look at it as an example is bringing in

a priori data. So this is one reason why medical

information for medical devices is so important,

having a full and complete record. With oncology

patients, many of the oncology patients that we

study, we bring in a priori images in a probabilistic

fashion on calibration and save the patient of those

images to ensure -- not just because we're looking at

the images to look for lesion changes, but we're

looking -- we're assessing the likelihood that this

really is the right patient. This is especially

important when we're talking about follow-up CTs and

MRIs and for radiological treatment of patients. So

that's just one example.

DR. ROSENDALE: Yeah. And that's perfect.

In other words, the attribute of an individual -- I

mentioned that the digital environment is purely a

manifestation of who we are and what care we

received. That's all it is, whether it's an X-ray,

lab studies, or a genetic study. And so first name,

middle name and last name is pretty basic. That's

just your name.

But what you're talking about is

reconciling the information that already exists in

(410) 974-0947

84


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

the electronic environment and say this is actually

the same patient. This is the same chest X-ray he

had in, you know, hospital A versus hospital B. And

so taking it to that level is even more sophisticated

than what I've described. But instead of a single

ID -- and I think we need to be following that, that

path. And so thank you for that support on that

conversation. I've got one minute. Last question.

UNIDENTIFIED SPEAKER: I mentioned earlier

that I thought the best thing to do was ask the

anesthetist to ask the patient their name. While I

agree with what Frank said is the dream, it is only

the dream when you're trying to talk about

identification, and it ceases to be the dream when

you have to add the layer of security on top of it.

You have one ID, one single attribute that's a

deterministic attribute, that's very easy to spoof,

to steal, to do all kinds of things with. When you

go to probabilistic matching, then you make that

security --

DR. ROSENDALE: Yes.

UNIDENTIFIED SPEAKER: -- breach much more

difficult.

DR. ROSENDALE: Absolutely. And I like

your boots, by the way.

(410) 974-0947

85


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

(Laughter.)

UNIDENTIFIED SPEAKER: Yeah, well, I'm not

from the western slope. I'm from Pueblo.

DR. ROSENDALE: Thank you very much.

DR. GOLDMAN: Thank you very much.

(Applause.)

MR. MURRAY: It's break time, right?

DR. GOLDMAN: Right, it's break time, and

the break is right outside, and please return

promptly. Our next session starts at 11:20.

(Off the record.)

(On the record.)

DR. GOLDMAN: Welcome back. So we're going

to need some help from a number of people in the

audience. If you notice that your neighbor is dozing

off, it's because we ran out of coffee, and a lot of

people were really pained by the absence of coffee.

Thank you. So I can't help that, but what I could do

is encourage everyone who's still awake to either use

your right or left elbow, as needed, to stop the

person next to you from snoring.

UNIDENTIFIED SPEAKER: We could start a

caffeine drip.

DR. GOLDMAN: We could start a caffeine

drip. Yeah, that'll be fine. No problem there. Two

(410) 974-0947

86


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

hundred milligrams will get rid of any headache. So

that's it.

And the other announcement that I have is

that you've been signing up outside on the papers for

the first breakout session, but there are two. So

you'll have to go back when those things are ready

for sign-up to sign up. I think it'll start at

lunchtime, where you can sign up for the second

session. So keep in mind that there's another thing

to sign up for. And that's it.

DR. WEININGER: Do you want me to introduce

you?

DR. GOLDMAN: Sandy's going to introduce

me. This is kind of strange. I already know who I

am. So why don't I just get started. And my name is

Julian Goldman. I'm an anesthesiologist at

Massachusetts General Hospital, and I've been working

on interoperability in a program based at CIMIT, the

Center for Integration of Medicine and Innovative

Technology, since 2004. And many of you in the room

have somehow been involved or participated in some of

those activities. My other hat is that I'm the

Medical Director of Biomedical Engineering for

Partners HealthCare.

Now, what I'm going to focus on in my

(410) 974-0947

87


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

presentation are some of the clinical perspectives,

and I think that the prior speakers did a very good

job of hitting some key clinical points. And so

there may be a little bit of overlap and an echo. If

I can get that timing just right, maybe I can get it

to continue and I can stop speaking and it'll just

continue. So maybe I should turn the volume down on

the speaker. All right. So let's get started.

This is going to be my talk. If the coffee

arrives and you have to run out, then you won't miss

anything. So the first point is that innovation

outside of healthcare has changed our expectations

for healthcare, and that's what's different this year

versus 5 years ago or 10 years ago or 15 years ago or

20 years ago. And there are people in this room who

have been looking at addressing interoperability

barriers for two decades or longer.

The second point is that medical devices

are key data sources for electronic medical record

systems. And I'll make that point as I go through

that.

Number three is that safe standalone

devices are not adequate to maintain patient safety.

So in the medical device world and the FDA regulatory

world, the focus has been on the single standalone

(410) 974-0947

88


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

medical device and the user interaction with that

device and the device interaction with the patient.

But that is not adequate to ensure the

safety of patients, and I hope to make that case for

you. And the essence there is that system solutions

are what are required to create error resistance. We

can't make things idiot-proof, but we certainly could

make them error resistant.

And then finally, there's actually

tremendous demand for success and focus on what we're

doing here over the next two and a half days because

we are seeing now that clinicians, clinical

organizations, societies, the public really wants us

to have it, and so the time to do something is now.

Well, it's getting close to lunchtime, and

so it seems that I'll get your stomachs grumbling.

How many of you have ordered Domino's pizza online?

All right, about 15 people will admit it.

(Laughter.)

DR. GOLDMAN: And the rest of you just

won't admit it. So you get online and you build your

pizza, and then you have this pizza tracker and the

pizza tracker starts off with you've got it made,

you've got it heat-waved, you've got it on the way,

you've got it. And there are some intermediate

(410) 974-0947

89


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

steps. And it even tells you the name of the

delivery person who will bring it to your door, and

you know, it tells them, if you like the job they

did, to let them know it with a hug or perhaps a tip.

So that is what we have come to expect in

other places. We have real-time status. We have all

sorts of information that is conveyed through a

website, and we have the data seamlessly available

when we order a pizza.

And when you send a patient down to

radiology for a procedure or a person comes through

the clinic and has to make three other stops for a

blood draw, an X-ray, and something else, you don't

even know if they're still in the hospital, let alone

if anything was done correctly, and therefore the

impact that that might have further on. So maybe

Domino's could start doing it for us in the hospital.

I don't know the answer, and I'm not proposing a

solution.

The iPhone was mentioned before, and I

think the iPhone is a very good example of a

commercially successful platform. It isn't an open

platform, but enough of it is open until you get the

job done. And this is a pretty interesting news

story that came out in September of '09, so a new

(410) 974-0947

90


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

news story. iPhone gets Zipcar drivers on their way.

Now for those of you who, you know, use

Zipcars or those of you who don't, it's like a

library. It's like a rental car that's available, a

shared rental car, in your neighborhood. Usually you

get online and you make a reservation, and then you

have access to the car.

But when they did this, they developed an

application, and you can see towards the bottom of

the screen, it says, "Zipcars app is the first to

control the operation of a car, which is why David

Cole, Chairman of the Ann Arbor, Michigan based

Center for Auto Research, calls it a breakthrough."

And he says, "Once you have this kind of electronic

ability in a cell phone, there's no end to the type

of technology you could bring to cars." Well, it

sort of controls a car. It really just unlocks a

car. But, you know, I guess if you're an insurer,

that's what you care about the most. I don't know.

But it is really significant, and it shows

the power of a platform because when they built the

iPhone, they didn't know -- I'm sure they didn't know

that it would be used to unlock Zipcars. And that is

the power of the ability to standardize a platform

that you then open for innovation. So

(410) 974-0947

91


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

standardization doesn't preclude innovation. It

actually facilitates it in ways that are really quite

powerful, as we're seeing today.

Another example of things in our

environment that work quite well is the warning

system that a pilot has, a smart alarm. If the pilot

tries to land a plane and the landing gear is not

deployed, there's an alarm in the cockpit that is so

loud it could probably wake the dead.

Now, the alarm is a smart alarm. It's a

smart alarm in the cockpit. Why is it smart? Well,

you want to know that the landing gear is not down,

but you don't want to know that when the plane is at

altitude at 30,000 feet. You only want to know that

when it's coming in for a landing. So the plane has

to know it's coming in for a landing for the alarm to

be activated. So the plane does that because it

knows its airspeed, its altitude and attitude, wing

flap position. It depends on the plane. There are

different ways of doing it. But this is an FAA

requirement for all planes. And so that type of

contextual awareness is available to the system

because of the sensors and the integration of the

data, and it does require data from a number of

sensors to provide that augmented vigilance.

(410) 974-0947

92


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

Now, what if a pilot wants to land with the

landing gear up? What if they want to do that? Why

would they want to do that? Well, I call it the

Hudson River override. You don't want your landing

gear down if you're landing in the Hudson River.

So not only can you not deploy the gear,

but you can suppress the alarm because,

appropriately, it was determined that that alarm

would be a distraction and therefore it would be

problematic. So the point is not to take away

control from the pilot. The point is to augment the

pilot's vigilance and still have appropriate control.

And that's really what we need in many areas of

healthcare.

So the first conclusion, going back to the

first slide, other industries have elegant and

effective system solutions. Wouldn't these

capabilities be useful for patient care? Well, let's

look at some challenges and examples.

How about capturing complete data from the

electronic medical record? Now, this is a photo --

these are photos from the operating room, and on the

left there's a patient who was hit by a car and we

were saving the person's life one afternoon. You

have a lot of people in the room taking care of the

(410) 974-0947

93


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

patient. You can see a pile of blood bags that are

being used to be transfuse blood on the bottom left,

a pile of drugs that were open on the right for

resuscitation drugs, and in the upper right there is

an anesthesiologist who's manually entering data into

the electronic medical record system.

So the physiological data goes in

automatically because the devices are connected to

that EMR, but none of the other data goes in, drug

administration, activities in the room. So there's a

lot of manual data entry required. And, in fact,

that is one of the shortcomings, the limitations of

this EMR.

And I would propose that the anesthesia EMR

is the most comprehensive and sophisticated one that

exists in clinical care because it's been around for

a long time, and it has certain features that allow

real-time entry of data under most conditions. But

even that can't keep up with the amount of data

required to have accurate tracking of this. So this

record will not be -- necessarily be complete or

accurate. It'll be a lot better than we had in the

days of paper, but we still can't connect.

Now how about this? On the right are two

photos of a physiological monitor in the operating

(410) 974-0947

94


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

room. And for those of you who are not clinicians,

it just looks like a dizzy oscilloscope, but for

those of you who are used to seeing waveforms, you

can see these are physiological waveforms from the

vascular system. But even very experienced

clinicians -- and probably, I would guess, Frank

Block is probably at the top of that game in this

room -- would have difficulty interpreting exactly

what happened on the screen.

So, Frank, do you have an idea of what's

been going on this room? You don't have to say

anything. No clue. And Frank I know well. He's

brilliant, and he's a very experienced

anesthesiologist. And if all this data is in the

record, it's still hard to tell that in the room you

have a team of people performing CPR on this patient.

The arrow is pointing to the head of the one that's

performing chest compressions. This patient was

having some trouble during a complicated procedure,

and this is a resuscitation.

So think about the challenge ahead of us.

Even if we populate electronic medical records, even

if we send all this data in, if we don't have new and

better ways of gleaning better contextual information

from the environment, we'll just have records full of

(410) 974-0947

95


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

this data that even experts really won't be able to

interpret or use to then improve the quality of care.

And this is a problem that still does not

have a solution, and these are technical solutions

that are required, research that's required, the kind

of things that should be supported and funded by some

of our federal agencies supporting this kind of

research, such as NSF and NIH.

Here's another example. The bottom panel

is a snapshot of our electronic medical record in the

operating room, and the upper left and right screens

are pictures of the physiological monitor at two

times -- just a few minutes apart. If you look at

the top screen, you can see that the heart rate, as

measured by the electrocardiogram, is roughly the

same in both, about 60 to 69. In the bottom of the

monitor, you can see that the pulse rate on the left

is 79 and the pulse rate on the right is 170. So

there's a big discrepancy on the one on the right,

and the reason for this discrepancy is that the heart

rate or pulse rate can be measured different ways.

The electrocardiogram, the top one is measuring it

through electrical activity of the heart. The bottom

waveform is measuring it through the pulsations in

the fingertip that are being measured by the pulse

(410) 974-0947

96


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

oximeter. And because that waveform that you see on

the third waveform from the top is kind of a funny

looking waveform, it doesn't have nice smooth

contours, the instrument is incorrectly calculating

the pulse rate, but it's doing it intermittently.

Now, if you look at the medical record on

the bottom, the permanent record, and you follow the

green dots, you could see that the heart rate jumps.

From down here it's correct, it's 79, then it jumps

up here to 170, and it drops down again.

So the permanent record has documented

incorrectly these alterations in pulse rate, which

could have been correct and could be the result of a

number of different problems, typically cardiac

problems. But in this case they're incorrect.

And we would never know the reason, the

etiology for this, if we didn't have a snapshot of

the waveform, and we wouldn't have had that if I just

hadn't happened to be the operating room with a

camera because our systems don't record that data.

So our systems are incapable of letting us go back

today and actually see the source of the problem and

diagnose or figure out improvements in treatment or

provide information back to the medical device

manufacturer so that they can improve their

(410) 974-0947

97


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

algorithms. And we can't do that today, either.

Now, here's another interesting way to use

the system. So this is an interesting new algorithm

called protocol watch, which has tremendous

capability to add real-time decision support in

physiological monitors. And here's this poor patient

who was kept up all night long. This was in

November. I got his permission to use the photo.

(Laughter.)

DR. GOLDMAN: Who was kept up all night

long by an alarm on the screen because this alarm is

for a protocol watch for severe sepsis screening.

Now, I happen to know that this patient was not

admitted with anything related to severe sepsis, but

with an arrhythmia, and therefore this was an

irrelevant protocol for him.

Furthermore, it alarmed regularly all night

long, and you can see over here it says action

required. Action required. Boy, you know, that's

the monitor that cried wolf, right? There's no

action required. And why was action required?

Because if you look at the boxes, it was missing

data. It did not have data from the lab on white

blood cell count, and it did not have glucose

information, and it didn't have temperature, all

(410) 974-0947

98


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

things that could've been populated automatically if

it was easier to get this data into the system, and

then this poor patient wouldn't have left the

hospital in worse shape than he went in.

So new problems are emerging, and with

broad use of electronic medical record systems, we're

starting to see latent problems with different data

on different systems. So it's not only connectivity

and getting the data, it's with getting some of the

wrong data.

Here's another photo. Let me take you

through this. In the bottom center there's a picture

of a machine that measures coagulation, an ACT

machine. It's a point-of-care device -- excuse me --

and it has an RS-232 output, as you can see on the

bottom left, and then it has -- uses an adapter to

send that data through the clinical information

system. Then it goes downstairs and hops across a

few network cables and goes to places I don't really

know, and then it comes back upstairs and shows up at

the point-of-care electronic medical record, and

there it says ACT and the time is 11:06.

So here's the procedure. You give the

patient a dose of heparin, and then in 30 minutes,

depending upon your protocol, you measure the ACT and

(410) 974-0947

99


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

you see what the number is, and based on that you

decide how to re-dose the drug. I was really puzzled

as to why it seemed that I was waiting 30 minutes by

my wristwatch and by another clock, but the data was

about 25 minutes.

And it took me awhile to figure out how to

get into the right screen on the instrument to find

out that its time was set -- in this example it was

10:54 and my wristwatch was 11:02. So there was an

offset because these devices don't use network time.

They're more like the VCR that just blinks, you know,

and flashes 12:00. And that's the case with medical

devices. They don't consume the common time protocol

that's used for all our other systems.

So this is a very significant source of

error, and one that really had me puzzled for a while

and one I can't do anything about. I can't go and

change the time on these instruments. I'm not

allowed to touch them. I'm not certified.

(Laughter.)

DR. GOLDMAN: It's probably a good thing.

So conclusion number two is that medical devices are

critical data sources as data consumers because we

should've been pushing the time to that device, for

example, and probably pushing the patient identity to

(410) 974-0947

100


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

that device as well. And, therefore, to address the

things I just showed you in terms of the richness of

the data and the context, effective connectivity is

essential to do that, and we're not there yet,

either.

What I'd like to do now is run through some

clinical examples of where interoperability or system

integration could've made a difference to patient

outcome. This horrendous photo shows patients who

were burned during surgery, and because it's fairly

easy to ignite things in a patient environment where

there's enriched oxygen, the patient on the left

upper part died, the one on the right survived.

And, you know, the laser worked just like

it was intended. All the devices in the environment

worked like they were supposed to. These are, of

course, FDA-regulated devices. There were no

problems with the device. But the patient's still

dead. That's the problem.

Now, the most severe injuries are injuries

that are -- typically are blast injuries of the lung

that occur when a breathing tube, an intratracheal

tube is ignited. That's what it looks like if you

hit an endotracheal tube with a laser when you have

oxygen flowing through it. It turns into a

(410) 974-0947

101


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

blowtorch. So what we do is we try to reduce the

oxygen concentration in the breathing system before

the surgeon activates the laser. And so the team, as

a team, has to remember to check with each other and

say -- you know, the surgeon has to say, I want to

start the laser. The anesthesiologist has to say,

Okay, I reduced the oxygen. You have to wait several

minutes for the concentration to fall, and that's a

variable amount of time based upon the system and so

forth.

And remember the airplane. If the pilot

tries to land, they get a klaxon that tells them

there's a problem. But here we're depending on

teamwork for something that can cause as devastating

injury as this.

So why we can't measure the concentration

of oxygen and have a safety interlock that either

prevents the activation of the laser or just warns

the surgeon not to activate the laser until the

concentration drops? Well, the fact is this was

proposed and published in 1999, and it's still not

commercially available because of the difficulty of

the interfaces, because we have no way to

interconnect these systems at the point of care. So

a lot of ideas like this have been proposed over the

(410) 974-0947

102


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

last few decades, and in fact, there's no shortage of

good ideas; there's just no implementation of those

ideas.

Here's a scenario of failure to continue to

ventilate a patient or breathe for the patient.

Normally when a patient goes on cardiopulmonary

bypass, we start off with them on the anesthesia

breathing machine, the ventilator on the right, and

then when we go on bypass, the bypass machine

circulates blood and oxygenates it so you no longer

need the ventilator. And normally we switch back and

forth. When you finish the bypass run, you go back

on the ventilator, except if you forget to turn the

ventilator back on after bypass. And you may think

that's a hard thing to forget, but there's a lot of

stuff going on in the operating room at a time like

that.

And you can look back 13 years in the

literature, and there's older literature that shows

that people forget to turn the ventilator back on

after bypass and patients are either injured or they

have to go -- or they are temporarily injured,

resulting in a longer -- they have to go back on

bypass for the longer bypass run. There's all sorts

of bad things that happen. And it continues to

(410) 974-0947

103


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

happen.

And I've asked thousands of

anesthesiologists around the world, and I'm still

looking for the one who could tell me they never

forgot to turn the ventilator back on. I haven't met

that person yet. They've caught it within a few

minutes, typically, but others haven't and they've

told me about the patients that have died.

So again, the devices worked as intended.

The bypass machine worked correctly, the ventilator

worked correctly, everything worked correctly, except

we still we have dead patients. So why can't we have

a smart alarm that says there's a patient attached to

the system and both the ventilator is off and the

bypass machine is not circulating? It doesn't seem

like rocket science. It's just a basic connectivity

barrier that's prevented people from building these

very reasonable solutions.

Here's another example. This is a patient

who had gallbladder surgery, and during gallbladder

surgery, at times it's necessary to perform an X-ray

during surgery to image the system that drains bile

to see if there's a stone in place, and that

procedure is called the intraoperative cholangiogram.

And what happens is that the surgeon injects that

(410) 974-0947

104


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

contrast agent directly into the structure and then

they roll in an X-ray machine and take an image, and

during that time we turn off the ventilator for about

30 or 40 seconds, which is fine. You can hold your

breath for 30 or 40 seconds. There's no problem.

But, again, if you forget to turn the

ventilator back on, it's quite a serious problem.

These are very rarely reported, but these occur. And

here's a report from the Anesthesia Patient Safety

Foundation newsletter in 2005, and a 32-year-old

woman died because of this very problem. And I've

heard about this problem many times, but it just

hasn't been popularized. So again, all the devices

worked correctly, the X-ray worked correctly, the

procedure worked correctly, but the patient died.

That's a problem.

Now, it's not just those procedures. More

and more so, with increasing frequency, there are now

interventional radiology procedures, other procedures

in remote locations in the hospital, all of which

require cessation or temporarily a ventilation --

stopping a ventilator because of the image quality.

So here's a picture I took in

interventional radiology, and there's an anesthetist

on the right and she's thinking, I better get out of

(410) 974-0947

105


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

here because they're about to start the high-energy

X-ray and they tell us, Get out of here. Turn off

the ventilator and leave the room.

So the next pictures shows there is no

person in there, and we have to remember to go in and

turn the ventilator on, or we go in and we have to

remember to turn it on. This could happen a half a

dozen times in the course of two hours or so. So

this is not an infrequent esoteric problem. This is

becoming more commonplace and even more so as we

start to do robotic surgery and automatic

manipulation of organs with imaging.

Now, what's the alternative? Well, you can

synchronize the X-ray with the ventilator. You can,

say, just like you do with a flash in a camera, you

know, just take the image automatically at the right

phase of respiration. Or you could, say,

automatically stop the ventilator for 10 seconds and

while it's paused take the X-ray and have that

automatic. It doesn't matter if there are subtleties

of how that might be done.

There's research to show different ways of

doing this. The point is that there could and should

be a way to do it. Perhaps different ways, if you

want to take a breath at the peak of inspiration or

(410) 974-0947

106


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

after exhalation. This was published, this was

performed, this was studied in the intensive care

unit with five radiologists comparing X-rays with

different ventilating normally or synchronizing with

an X-ray. It was performed 11 years ago. The data

is really quite good, and it shows the better quality

X-rays. You don't have to retake the X-ray. Again,

we can't do it today. And this is some work we did

in our lab, at our CIMIT lab in Cambridge, where we

implemented some of these examples.

So I want to kind of take you down to

thinking for a moment of what is required for safe

synchronization of the ventilator and X-ray. Well,

it's not safe to just control a ventilator through

another device, if you want to call it control.

Every manufacturer of a ventilator will say quite

clearly, There's no way in the world I'm going to let

some other manufacturer turn my ventilator off, and I

think that's quite reasonable. So that's not going

to happen.

But what could happen is, if the ventilator

could provide a real-time signal to trigger the X-ray

so the X-ray is triggered at the right phase of

ventilation, that's one possible way to do it. And

that's not done today either because we don't have

(410) 974-0947

107


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

the reliable timing on the signals because they're

not intended for this purpose yet.

Or, alternatively, number three, the

ventilator could have a pause feature and an

autonomous restart, and then the X-ray could activate

that feature. So the X-ray machine sends a command

to the ventilator, and it says I want you to pause,

and the ventilator says okay, I'll accept that

command, or it may say no, because the physician told

me I can't, or it may say okay, I'll accept that

command. It pauses for 10 seconds, and then no

matter what, it restarts on its own accord. And that

is a way to do that, and that's some work that we've

done with collaborators both at the University of

Pennsylvania and also at the University of Illinois,

who've looked at safety critical systems and how to

network them in that way.

So the new ventilator standards that are in

draft form are incorporating some of these notions

and requirements in an early form, and if anyone has

questions about that, I'll direct you to Dave Osborn,

who's sitting over there.

So here's another interesting thing. It's

called image-registered gastroscopic ultrasound,

IRGUS. I didn't come up with that acronym. So this

(410) 974-0947

108


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

is a new technique by an investigator at CIMIT, Kirby

Vosburgh, who just sent me these slides, and it shows

that on the left you have ultrasound, on the right

you have CT scan data, on the bottom you have a 3-D

model and then you have -- up on the right you can

see a gastroscope that has special sensors so that

the system knows exactly where that scope is placed

in the esophagus and further down. And therefore you

could have a 3-D model with the probe in place to

show the operator, especially if they're about to do

something that could damage tissue or to get a

precise biopsy.

This is the future. This is a melding of

all the information and the device information to do

things we never could do before. So the burden on

connectivity and what could be achieved, you know,

this is the future. The other examples are

relatively simple, but they're still killing people.

So conclusion number three is that many

longstanding problems cannot be fixed and patients

are being injured. And improvements in patient

safety, clinical care, and healthcare efficiency

require heterogeneous system solutions. And

scalable, versatile integration requires medical

device interoperability. Interfaces must be updated

(410) 974-0947

109


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

to support the required functionality.

So in the X-ray example, if the interface

doesn't allow you to send a command to the ventilator

to pause it, well, then we haven't succeeded. And

the current standards typically don't support that

either. So the standards have to start to include

that capability as well.

I want to mention briefly that clinical

requirements are really the essential driver for most

of these things. They're really necessary to assure

that the solutions are going to be useful. And we

need carefully documented scenarios. In our program,

in our medical device interoperability program, we've

been eliciting requirements for a few years. They're

not enough, but they're a starting point. And so

we've been doing that at various meetings with

surgeons, anesthesiologists, clinical engineers, and

so forth, to help to drive this work.

This is an example of how the data, some of

it's organized, and we've done this with the help of

Sandy Weininger here, who's here at the FDA, and a

number of other collaborators, and Tracy Rausch, who

might in the room, and Rick Schrenker, who's here.

So it's really taken -- I don't want to use the term,

but it's taken the village to do this kind of work

(410) 974-0947

110


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

because it takes the -- really this broad range of

expertise and perspectives from the clinical

engineering, biomedical engineering, systems

engineering, clinical, and so forth.

It's kind of hard to read that overlap on

top. But there's a standard that just published,

called the standard for the integrated clinical

environment. It's ASTM Standard 2761. And in the

standard in Annex B, there are seven clinical

scenarios right in the standard, and I think this

might be -- you know, it's one of the few standards

that include scenarios as a justification for the

requirements.

And some of the things I just presented to

you are some of the requirements that are in that

standard. And, of course, you know, we as a

community have been collecting this to put it into

the standard to accomplish something that everyone

could then share and read.

This is a diagram from the standard, and

the other thing that I'm really pleased about is the

standard shows -- in the diagram it shows a

clinician, it shows a patient, and a whole bunch of

other stuff that help you get the job done. And how

that's all connected and how it's going to work is

(410) 974-0947

111


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

the subject of a fair amount of work, including the

work that's here in front of you today, so that you

can have safe interoperability of the components

required. And some of the notions that are included

here is the idea of a data logger to collect all the

information that's transferred within a system so

that one could go back and analyze -- if there are

problems with the system, one can determine what that

was, and the idea that there's an external interface

to the hospital information system because this data

might be a relatively high bandwidth, fine

granularity and so forth, and you need some kind of,

you know, low bandwidth connection. And so to do

that, that's really essential. And there are several

other notions that are contained in here that there

really isn't time to dig into it in any detail.

The other thing I wanted to point out is,

as I said in the beginning, there's quite a bit of

interest and support now, and that's why now is

different than five years ago. This is a statement

by the American Medical Association that was

formalized at their assembly in the springtime. This

resolution states, as you can see, that the American

Medical Association supports interoperability of

medical devices to improve patient safety and patient

(410) 974-0947

112


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

care. And they're the seventh society to do that.

The Massachusetts Medical Society is one of them as

well. And it just shows that this is no longer

something that's kind of out there and esoteric, but

really needed.

And the other thing that I'd like to bring

to your attention is an agreement between Partners

HealthCare and Johns Hopkins Medicine and Kaiser

Permanente from October of 2008, and this is called

MD FIRE, for medical device free interoperability

requirements for the enterprise. If you don't like

that acronym, talk to Mike Robkin, who came up with

it. This is work that was performed with

stakeholders from the organizations. I'd like to

emphasize that the stakeholders include the legal

departments from these three institutions, clinical

representation, IS, biomedical engineering, and

materials management, and this document describes --

it's a position statement and sample of

interoperability and RFP contract language. It's

freely on the web at mdpnp.org.

This is an example from the first page of

the document. That's a nationwide call to action for

interoperability of medical devices and systems. So

it comes up every now and then that, gee, is there a

(410) 974-0947

113


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

business case? Will people buy it? Do people care?

And the answer is, I would think so at this point.

So conclusion number four is that

clinicians, biomedical engineers, health delivery

organizations, medical societies -- and you could add

a few other things in there if you wish -- want

market access to interoperable devices to enable

innovation and reduce the cost and complexity of

device-to-EMR integration.

And I think this is pretty cool. If you

look at this, it says it all began with a new of way

of thinking. They're standing on their bicycles

while looking over the fence at the plane, and it

does -- it is a new way of thinking. It's a new way

of thinking about healthcare. It's a way of thinking

that we could have a pervasively integrated

environment that then begins to serve as a platform

for decision support and safer systems.

Interoperability is a means to an end. It isn't an

end in and of itself, unless your business is to sell

interoperable things, which is fine. But in

healthcare it's a means to an end.

So with that I'll wrap up, and I may have

time for a question or two. I'm not good at keeping

my own time, so I actually don't know. So let me

(410) 974-0947

114


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

take a couple of questions, and then we'll move on.

But one at a time, please.

(Laughter.)

DR. GOLDMAN: You really miss that coffee,

don't you?

MR. MURRAY: No, I think it was a very

nicely given presentation.

DR. GOLDMAN: All right. You got a

question?

MR. HOYME: Yes. Well, I'm Ken Hoyme with

Boston Scientific. Before that I spent 18 years in

the aviation business building safety critical

systems for commercial aircraft, so I always find

fascination with analogies with the aviation world.

One of the things that's going to be

different about the medical device world and

interoperability is there isn't the equivalent of a

system integrator. There isn't the Boeing that is

putting it all together. So the example of the

auto-landing system and the integration, a regulatory

body imposes on an organization like Boeing the rule

that says you're going to have demonstrate that the

system works together to do this particular function

or you don't get to start selling the airplane and

make your $10 billion investment back.

(410) 974-0947

115


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

Defining interoperability amongst sets of

different device vendors allows the pieces to be

there, but today I think we're more equivalent of

you've been to the Oshkosh flying air show where the

individual builder goes to the vendors and they pick

their navigation system and their radio and they

build their experimental airplane and bolt it

together. And I think of all the different IT

systems we have in the different hospitals, different

physicians putting their EMRs together, we're a

little more in that world than the integrator.

I'd be interested in your thoughts about

how do we fill in that intermediate layer because if

we do it with all the standards, it tends to be

really slow. It takes years to develop the standards

amongst them.

DR. GOLDMAN: Okay. Well, I think that's a

great point, and I think I would look at it as two

ends of the spectrum. So one of the end of the

spectrum are avionics with all the certification, and

one cannot just go shopping and replace what they

want. And if you look at the other end of the

spectrum, you have something like USB memory sticks

that you can buy in Target and plug into any

computer. And five years ago they would frequently

(410) 974-0947

116


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

give you the blue screen of death, and today they

work really well. But they could crash and there

could be a problem.

And so perhaps we don't just say that

medical device interoperability and system

integration is one point on that continuum. Maybe we

say that it's a range on that continuum. And for

some things it's okay to accept the possibility of a

system crash or a failure when one is collecting

intermittent low-acuity information, perhaps from in

a home or a telehealth setting, and one might say

that somewhere else along that continuum, you know

how the system -- where you need greater assurance of

performance because you have robotic control, robotic

integration of X-ray and laser and other things like

that.

And so in the ICE standard, the ICE

standard looks at the higher acuity environment and

then talks about some of the assurances that are

needed before a device will be allowed to

interoperate with the others. So one has to be sure

that the devices are appropriately certified and so

forth and so on. And those are much tighter

requirements than one might have at a lower end. So

I don't think we're just talking about one thing in

(410) 974-0947

117


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

one application, but I think it's a continuum that

could map onto that other continuum.

And then, therefore, it gets to the point

discussed and will be discussed, I think, further,

that if we require that comprehensive pair-wise

testing for all of our interfaces, it does put us at

a point where we're so far away from the USB memory

stick that we just can't build anything.

So we need to somehow come to a balance

where there are appropriate tools and methods that

are available for those system integrators to

integrate in clinical environments. And certainly

our, you know, biomedical engineering department is

prepared to do that and others are as well, and there

are many companies who would love to stand up and do

that, but we probably need to share tools and

resources that the community can build to make that

possible. So those aren't one -- I think, like the

open source movement, you know, we want everyone to

beat those things up and see if they're really safe

and viable. But that's just my answer.

MR. McGRANE: Tom McGrane with Kaiser

Permanente. So you build a very compelling case, and

there's a lot of obviousness to the need for this and

there's a lot of industries that do this. So the

(410) 974-0947

118


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

problem isn't necessarily technology. So what really

is keeping us from getting this reality that I know

you're very passionate about? And what would you

expect timeframe-wise? When do you expect that we

actually start seeing the breakthrough and the

realization mainstream for all of this new stuff?

DR. GOLDMAN: Well, there isn't really much

of a rush. We have until Wednesday. So, you know,

take your time.

(Laughter.)

DR. GOLDMAN: So I think that on the one

hand it seems like this isn't the hard technology or

science question, and that's because for some of

these applications it isn't. I mean, it isn't a

challenge at all. It has to do more with who is

willing to take the risk because you have to build

the community of capabilities and products, and it's

very hard to do that in an organized, synchronized

way.

And I think that's what Continua has done

well, as an example, by getting buy-in and then

having now over 230 companies and healthcare delivery

organizations who all said we'll buy into this at the

same time and made a change. But there are some hard

science and technology questions that haven't been

(410) 974-0947

119


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

answered. We don't know how to certify these systems

at the point of care. We don't know how to integrate

these and swap devices if something fails in a

clinical environment. We don't know how to do that

yet.

And so I think that there's a range of

these harder questions that have to be addressed in a

focused way, and then there's a range of things we

can do now, and there's really no reason to delay and

then -- you know, so there are a number of issues

here. And I think we identified these as streams of

issues within our program in 2004, as issues around

regulatory questions, technology questions, absence

of complete standards, there has to be a business

case, it has to be clinically driven.

So we have to look at all of those streams.

And I think there's been progress in every one of

them, but there are some big gaps, and I think we're

all here together to try to address some of the more

challenging gaps. I think this will be the last

question.

MS. HAILPERIN: Hi, I'm Marilyn Hailperin

from Santa Rosa Consulting, and I think one of the

pieces that's missing here is where healthcare IT

consultancy would work with hospitals. But most of

(410) 974-0947

120


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

our clients are not considered partners, but they are

community based, and they are making these decisions

on the basis of a constituency that's not here, which

is their CHR vendor or their premier device

manufacturer. So they're going with a Philips

solution because I feel safe doing that. Or I'm

going with a solution that ethics says had worked in

some of their places before.

And the innovation may be happening in the

more academic and broader institutions of which

you've spoken. But I think, down at the grassroots

level, there's a lot of people who recognize the

benefits in patient care and are making decisions

that will prevent them from making better decisions

later because they have invested their financial

resources in an infrastructure that they're stuck

with.

DR. GOLDMAN: Yeah, indeed a challenge. I

liken that to that fact that today you can walk into

the checkout aisle at Target and you can buy a USB

memory stick for $15 and you can't even find a floppy

drive anymore, a floppy disk. And what we lack today

is we lack the ability on a purchase order to tick

the box that says I want my device to be

interoperable and to support a whole host of clinical

(410) 974-0947

121


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

use cases. MD FIRE tries to see that thinking, but

there's a long way that we have to go before we get

there. Until we can tick off the box and place the

order, we're going to continue to have this problem.

So I think there's a lot of work to be

done, but once it's available in the marketplace,

then things will move. And so part of being here

together is to figure out how to make it happen in

the marketplace. And we need the community, the

academic community, the regulatory community, and

others, to really make that happen, to partner with

those who can build it. Thank you very much for your

attention.

(Applause.)

MR. ROBKIN: Thank you, Julian, and thanks

for the plug on MD FIRE. If anybody needs some

acronym consulting, I'm available.

(Laughter.)

MR. ROBKIN: I'm Mike Robkin. I'm one of

your steering committee members for this workshop.

I'm up here to introduce e-Patient Dave, Dave

deBronkart. Dave is a high-tech analyst and a high-

tech marketer. He's also a Stage 4 cancer survivor,

and he has been blogging that experience and others

on a blog called, appropriately, e-Patient Dave.

(410) 974-0947

122


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

It's a very insightful and provocative blog.

If you're not aware of it, I would strongly

recommend that you follow it. He brings up many

issues, some of which you're going to hear about now.

And Dave is also founding co-chair of the Society for

Participatory Medicine. And the fact that it took so

long to have a society for participatory medicine is

an indictment of where we have been and a sign of

hope for where we can be. So please welcome Dave.

(Applause.)

MR. deBRONKART: Do I get a keyboard? So I

know this is a great challenge. Speaking right after

lunch, people's bellies are diverting all the blood

away from the brain, and people tend to fall asleep

during a speech that's not vigorous. It's even worse

when we're late for lunch, with no coffee at the

coffee break. So it's my job to make it worth your

time. I'll be as quick as I can. So a punchy little

title here, a little different from what we've seen

so far.

Should this be advancing when I click the

mouse?

UNIDENTIFIED SPEAKER: The space bar.

MR. deBRONKART: What space bar? There's

no computer here.

(410) 974-0947

123


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

DR. GOLDMAN: It's FDA-cleared. It'll

work.

MR. deBRONKART: Science, science, science.

UNIDENTIFIED SPEAKER: The arrows work.

MR. deBRONKART: The arrows work. Great.

Thanks. A quick review of how I came to be here. As

he said, I'm a high-tech marketing data geek. I do

database stuff in the marketing department. I worked

for a software company on Route 128 in Boston. Three

years ago I got sick, then I got better. I became a

blogger. I almost died, and we'll talk about that

very briefly.

The thing I want to convey here, when I

first started talking after I got better, I started

talking at medical conferences, is people talked

about patients as if they were somebody who's not in

the room. Each of the speakers before here today, as

excellent as they were, when they asked how many are

doing this, how many are doing this, nobody even

asked are there any patients here? And this is like

designing consumer products without talking to the

people who are going to use them. We're going to

miss the mark.

And I say this as somebody who's made that

mistake in my career. So your time will come. I'm

(410) 974-0947

124


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

sure some of you have already been through the

experience of being at somebody's hospital bed as

they're approaching death. This is going to be

relevant to somebody you care about sometime in the

predictable future.

I want to point to this. This is

HealthLeaders Magazine, which goes to 40,000 C-level

executives. Their cover story in September was on

the patient of the future, and this is about

participatory medicine. There is a paradigm that

says knowledge exists in the head of industry

professionals, physicians, and so on.

Anything I say about physicians, don't take

it as me saying doctors are crap. Doctors saved my

life, okay? I almost died and they saved my life.

I'm not talking about that. I'm talking about this

new relationship where patients are actively engaged

in being responsible for themselves. That means you

being responsible for your well-being as well.

People ask how I got into this. People

asked JFK how he became a war hero. He said it was

easy; they sank my boat. In my case, I went in for a

shoulder X-ray and they called back the next day and

said your shoulder's going to be fine, you've got a

rotator cuff problem, but there's something in your

(410) 974-0947

125


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

lung. And what that turned out to be, that was a

golf ball sized tumor that we eventually figured out

there were many of them.

This is a CAT scan slice through both of my

lungs. Still didn't know where they were. Had an

ultrasound and found out it was a big hunking tumor

in my kidney. In fact, there were two of them

sticking out two different sides, sticking to

different parts of my innards. That was a grim,

sobering night. That was three years ago this week

when we got that diagnosis confirmed.

I've been online since 1989. I Googled my

butt off to learn everything I could. What I read on

WebMD is the prognosis is poor. Almost all patients

are incurable. And, in fact, then when I talked to

the oncologist and found out the treatment I was

going to get was high-dosage interleukin, I went to

their website, and this just happens to be their

standard diagram of what Stage 4 kidney cancer looks

like, and son of a gun, by coincidence, up there in

that lung, there's that tumor that was there.

There's one in the left femur. I found out

later that I had one growing in my leg because the

leg broke. That's how advanced the cancer was. And

in addition to these, I also had one in my skull. A

(410) 974-0947

126


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

great picture, right? I also had these other ones.

And what I found when I scored my condition was that

my median survival time was 24 weeks after diagnosis,

and at this point two of those weeks had already gone

by. This will get you to focus --

(Laughter.)

MR. deBRONKART: -- and to care about what

works and what doesn't. Now understand also, I went

into this experience as a guy who spent his life in

high tech, watching industries evolve. Okay. So

this was all filtered through my experience. Now, a

chef who goes to eat a restaurant brings a different

experience to that from a chef -- from other patrons.

Second, e-Patient activity I get -- I'll

explain the word e-Patient later. My doctor

prescribed aCoRE. On the day of the diagnosis, he

handed me this prescription slip and told me to go

join this patient community. I later found out that

this was the best source of reliable, up-to-the-

minute information about kidney cancer anywhere on

the internet.

Because information changes so rapidly and

all our systems and our physicians are overloaded and

everything, they have a thousand -- the ordinary

primary physician has a thousand conditions to deal

(410) 974-0947

127


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

with, and I had nothing better to do than to study

kidney cancer.

Now, in my case they told me immediately

that I was already at the best hospital in the

northeast. I didn't need to go anywhere, but I knew

that with certainty. They also told me to try to get

high-dosage interleukin if you can. Many patients

who show up in that patient community don't hear that

from their doctors because their doctors' information

is out of date.

The third thing I did was I shared my PHR,

my hospital's medical record password, with family

and friends so I could be engaged with them. They

could help me understand what was in there. Some

people think that patient empowerment is about

patients now know everything. Well, no, sorry, far

from it, right?

One of the things I wrote about on my

journal that I started was reading one radiology

report that said visualized portions of the bowel are

grossly unremarkable. We all thought that was

amusing. I also misconstrued some CAT scan data.

This is not about a patient rebellion. This is about

patients participating and being engaged. Long story

short, the treatment worked. Fifty weeks after the

(410) 974-0947

128


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

original scan, this was what was left of that tumor.

Miraculous treatment. I love good healthcare, no

question about it.

Now then, I discovered the e-Patient

working group, this blog, e-Patients.net. This

avuncular-looking figure top center there is actually

Tom Ferguson, the doctor who founded this group. He

died in 2006. He said e-Patients are equipped,

engaged, empowered, enabled.

John Sharp of the Cleveland Clinic, when he

discovered our group this past fall, said if you

haven't read the white paper that's on this site, you

don't understand the future of medicine. It contains

many, many anecdotes of how patients, given the

access to information that the internet gives them

and the ability to connect with each other through

the internet, are contributing value.

Again, it doesn't mean patients are right,

doctors are wrong. It means -- and this is

profound -- that it is a real error to think that all

useful knowledge comes from people in the industry.

There are enormous amounts of good that can be done

to improve care this way.

This is a slide put together by my primary

physician, Denny Sands, who is a part-time physician

(410) 974-0947

129


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

and part-time works for Cisco Systems. He talks

about knowledge symmetry, going from knowledge

asymmetry to knowledge symmetry, from paternalism to

participation to a consumer-provider partnership.

This is a blog post that I wrote about a

year ago. This is the essence of this new kind of

relationship. Physicians are coaches. Patients are

players. We talked in the discussion on this blog

post. A common complaint from physicians is, you

know, they'll recommend, like my doctor will say,

Dave, you know, you ought to eat different, you ought

to exercise more, and that's the end of it. The

patient goes out and doesn't do on the playing field

of life what the doctor recommended. And I

commented, in that white paper, one of the

conclusions is the best way to improve healthcare is

to make it more collaborative.

So the question becomes how can we do that?

And this is Denny Sands. One of his points is how

can patients participate if they can't see their

information? Right? Imagine if you were responsible

for driving a car but you didn't have the same

information about where you're at that your mechanic

has. So we formed the Society for Participatory

Medicine, as Mike said. Now, here's where we get

(410) 974-0947

130


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

into the device thing. All right.

So we published weight guidelines, and we

encourage people to use a scale. What if we

published speed guidelines but didn't give people

speedometers? Now as it happens, when I came up with

this metaphor, I was talking with Joe Fedar (ph.) of

Continua last Friday, preparing for this talk, and I

came up with this idea of these monitoring devices

being like speedometers, and I said, you know, I wish

I had a photo to illustrate this point. Well, this

was on the front page of a local paper yesterday.

Very convenient. Think about this. You're warning

people what the speed is. What if that guy had no

speedometer? How would they be able to achieve their

best?

Now, I'm going to switch over and put my

high-tech hat on. Given that, you know, I say I want

a lot of really useful devices. Like I find myself

thinking, how come every time I step on my bathroom

scale, it doesn't get recorded somewhere? I'll tell

you, I try to be responsible about this because I

went online looking for a Bluetooth bathroom scale so

I could have the scale talk to my cell phone, which

would upload to the internet. The first page I found

said so you're too lazy to use a paper and pencil.

(410) 974-0947

131


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

(Laughter.)

MR. deBRONKART: And you think your problem

is that you need more gadgets. Right? But I do want

more gadgets, all right, because, you know, I've seen

-- the first half of my career was in an industry

called typesetting machines. This is an industry

that has been disrupted out of existence by desktop

publishing.

By the way, talking about interoperability,

the fonts that we saw in the first half of this day

were not correct because the Adobe Premier webcast

system does not properly render fonts from monotype.

And so here we are actually displaying in PowerPoint.

This interoperability thing, that's the world I came

from because I want to see the kind of high-speed

innovation that put my career out of business.

So some lessons from the high-tech

industry. Excuse me. Object-oriented programming.

There are principles called encapsulation and unit

testing. Some of you will be aware of this. I just

want to point out briefly that in this kind of

approach, you test the interface to each device, not

the internals of it, and you don't try to test the

whole workflow. Now, you certainly need to be sure

the whole workflow works right. We don't want the

(410) 974-0947

132


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

kinds of disasters -- I said on Twitter during your

talk, Sickening stories I know exactly. You know,

these are like train wrecks, right? The switch is

set wrong and everything happens automatically and

people die. So thank you for sharing that.

But object-oriented programming. Now

here's the thing. This is a relatively new -- well,

compared to the early part of my career --

discipline. I found this graphic last night, a

T-shirt that says object-oriented programming is an

exceptionally bad idea, which could only have

originated in California. And it's from a legendary

software guru, Dijkstra. He was the father of

structured programming. He got rid of -- he

campaigned against the Goto statement. If you're a

programmer, you'll know what that means. He was a

Turing Award winner, one of the leading minds in

software, but that was in 1972. The world has

changed since then. Moore's law, right?

The impact of Moore's law, I knew

programmers who wrote machine code that were like

super-optimized in the old days, and they hated the

fact that faster computers made sloppy programmers

successful. There you have it. The penalty for

changing your mind dropped dramatically when

(410) 974-0947

133


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

computers got that much faster. So flexibility

became affordable and actually became more valuable

than efficiency, super-optimized efficiency. I saw

companies go out of business because they didn't

recognize that this had changed.

The next lesson from high tech. And I

could talk for hours about this, but I'm trying to

get us to lunch. The old approach to developing a

product was called waterfall. Waterfall was things

would flow downhill. You would decide what you want

the thing to do and plan it, and you would make up

your damn mind and have things go downhill, and when

it got to the end, it would do what you wanted it to

in the first place.

When I was involved in product planning for

typesetting machines, it was so long ago that we

could look at an industry and say, you know, the

newspaper people need a machine that does X, Y, Z, so

let's study it for six months and then we'll hire

some spec writers and blah, blah, blah, blah, blah.

And then we'll get some developers and then we'll

invent a machine, and by the time we have the machine

ready to come out of the factory, the world was the

same as it was when we had those meetings two years

earlier.

(410) 974-0947

134


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

No longer true. Today, what you have to be

able to do is agile, agile development. I know some

of you are aware of this. Recognize that you can't

figure out in advance anymore exactly what you're

going to need once you're done. Deal with it. This

may drive you crazy, that you can't spec the whole

thing out in advance, but that's the way it is.

Besides, things change out there so fast that the

target moves once you start developing.

So what you do is you get started with half

a plan and you adapt as you go along. And in order

to that, you've got to keep your options open.

You've got to design the thing so that it's easy, so

that you've got its functionality all bundled up

inside itself, and the only thing you really specify

that the outside world cares about is the interfaces

between the things.

The third thing from high tech -- and this

is why it's so important that we accelerate the rate

of release of new devices: a rich ecosystem. Like

this is the Drupal content management system. It's

used to be build many websites these days, this

incredible ecosystem. This is software products and

companies that can connect to Drupal.

What this is means is, is if you start a

(410) 974-0947

135


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

company or you write a program in your spare time

that plugs into Drupal, you can play with all these

people. You have this vast market. If instead the

population of your ecosystem is constrained for one

reason or another, your market potential is

constrained, and that limits innovation.

The way I put it in a blog post in

September is I want innovation at a rate that

resembles the rate of improvement in cell phones. In

2011 I want to think that this healthcare tool I'm

using today is like that, is so 2009. Right? And,

finally, the last thing. I've worked in software

tests -- what did I do? Show full screen. There we

go.

This issue of a combinatorial explosion.

It's a geeky term. Here's a scenario for you. It

has to do with testing individual devices versus

every combination. Imagine there are 2,000 models of

Dell PC and a thousand models of HP printer. If we

test every one in isolation, we'll have 3,000 tests

to do. If we want to be certain that every

combination works, that's two million tests to do.

And I'm not downplaying the importance of

testing and total workflow things. I think there's

an application for, like, limit checks so that even

(410) 974-0947

136


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

if some combination of circumstances of devices

causes something to go out of whack, you have

something like your landing gear aren't down, that

kind of a detector. Or, you know, there's oxygen in

the lungs, don't turn on the laser. That sort of

thing.

My point here, though, is given that so

much -- there's so much opportunity to do good with

participatory medicine. Consider this: two million

combinations versus 3,000 individual items, 667 times

more work. Consider the budgetary impact, the

probability that'll ever get done, the time delay,

and that has a drastic impact on innovator's payback.

It impedes innovation, and the consumer's benefit.

We will not get there in time doing it that way. By

the time you are desperate for better healthcare, it

won't be done. The good news is, from other

industries, as other speakers have talked about,

there are methods that have been developed that we

can just pick up and use in this industry.

I want modern mash-ups. For those of you

who aren't familiar with what a mash-up is, it's

where we -- well, similar to the iPhone and Zipcar

story. You have something that was developed without

knowledge of what other things are going to plug into

(410) 974-0947

137


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

it. There's a pizza shop in my town that has a map

that says get driving directions. The people who run

that pizza shop don't know how to do that. They just

plug into Google Maps. That's call a mash-up. And

mash-ups increase the value of every piece of the

ecosystem.

Old school. My doctor actually has a

plastic model of a heart on his desk. Okay? And

then there's the visible man, plastic statue, right?

Well, a few months ago I was roaming around on the

internet and what did I find, visiblebody.com.

Three-D. A free website. Just click on things on

the menu on the left, remove the skin, remove this,

that, and the other thing. One of my tumors was

attached to my soleus muscle. I had no idea really

where the soleus muscle was. So I went in and I

found it. It's that blue thing there. And I could

rotate that in 3-D.

And then I had this epiphany. I had this

epiphany. I thought, you know, that digital CAT scan

that I have, why I shouldn't I have Google Earth for

my body so that my physician, instead of picking up

the plastic heart and saying, well, this is what a

heart looks like and your this-that is wrong, right,

he could show me, over time, look what's happening

(410) 974-0947

138


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

because you're not doing this, that, or the other

thing.

Now, here's the thing. If this data were

out there where innovators could get at it -- no.

You know what it is? My coat is hitting the

keyboard. Some people are just over-exuberant. If

innovators could get at the data, we could have stuff

like this coming on. Visiblebody.com is free. You

know what that adds to the healthcare industry

budget? Zero, right? You know what it costs when

Google hooks up something else like this?

So I'm not saying it's trivial. I'm saying

there are methods we could use that will produce

results. Don't leave me this way, in a ditch. Give

us speedometers and tachometers and pressure gauges.

Help us heed the guidelines. I can do a lot better

if I know how I'm doing. Here's a runner -- I

grabbed this off the web last night -- with monitors

on his arm. That's it. Thank you very much for your

time and attention.

(Applause.)

MR. deBRONKART: Shall we go to lunch?

DR. WEININGER: You can take some

questions.

MR. deBRONKART: Okay, questions? I can't

(410) 974-0947

139


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

believe you people have been so good and attentive.

Thank you. Any questions or is it just lunchtime?

It looks like lunch.

DR. GOLDMAN: Thank you very much.

MR. deBRONKART: Sure.

DR. WEININGER: I have two quick

announcements or one quick announcement that has two

pieces. Folks participating in Session 1 and

Session 2, if you would please come up with your USB

sticks and reload your presentations. We think we

have a better way than they were loaded originally.

So thank you very much. And lunch is outside.

Do I have any other announcements I was

supposed to make?

DR. GOLDMAN: Yeah. We should tell people

when to come back for the webcast.

DR. WEININGER: Lunch will be done at one

o'clock, so come back then, please.

MR. MURRAY: One o'clock, one o'clock.

(Whereupon, a luncheon recess was taken.)

(410) 974-0947

140


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

A F T E R N O O N S E S S I O N

(1:00 p.m.)

MR. ROBKIN: Well, I hope you enjoyed your

lunch. Ladies and gentlemen, we're ready to start

back up again with our first moderated session. We

were fortunate to receive many, many, many fine

presentations for this workshop, and so the

presenters have graciously offered to shorten their

presentations down to 5 or 10 minutes, as the case

may be, so we can get as much content as possible in

the workshop.

So we've organized these presentations into

sessions where there'll be a moderator and two,

three, four, or five presenters. And, hopefully,

with everyone's cooperation, we'll be able to stay on

time and on track and we'll have time for questions

at the end of each presentation. So I'll thank you

in advance for your cooperation and for your help in

keeping our questions and our answers relevant and to

the point.

I'd like to introduce Session 1, which is

"Lessons Learned from Existing Regulatory Practices."

The moderator for Session 1 is Brad Thompson here on

my right. Brad is an attorney, and he's the leader

of the connected health practice at Epstein, Becker

(410) 974-0947

141


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

and Green, and he's just recently agreed to be

counsel to the Continua Health Alliance on FDA

matters. Continua is, of course, one of the sponsors

of this event. And what Brad probably won't tell you

is he's also -- he wrote the book. He's author of

the book that is used in law schools on the

regulation of medical devices. So, Brad, all yours.

(Applause.)

MR. THOMPSON: Thanks very much, Mike.

This is a different style, this afternoon is a

different style than this morning. This morning you

could pretty much sit back and listen and maybe ask a

couple questions at the end and that was okay. Our

expectations, though, have gone up for you now. You

have to work for your lunch. We do expect you to be

very involved in this discussion, and we're going to

deliberately keep the three presentations to five

minutes each to make sure that you have enough time

to get your questions asked.

And your questions may be of a policy

nature. They probably shouldn't be, you know, well,

I've got this product, when can I get it approved,

kind of thing. So if you keep them to a policy

level, I'd appreciate it. But the goal is to have a

robust discussion. We have folks from a regulatory

(410) 974-0947

142


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

agency here. What they say is not binding. They can

just speak freely.

ELECTRONIC VOICE: At this time, please try

again. Please enter your --

(Laughter.)

MR. THOMPSON: That was not me. I didn't

do it. All right. So we're going to get right into

it. I don't want to cheat anybody from their time.

ELECTRONIC VOICE: Welcome to ready

conference. For security verification, please enter

your pass code followed by the pound key.

MR. THOMPSON: Can I just turn it off? No,

I can't turn it off, huh? All right. Why don't we

start off. Our first panelist is going to be

Dr. Maureen Baker. She is the Clinical Director of

Patient Safety of the NHS Connecting for Health in

England.

DR. BAKER: Thank you very much. I'll do

my best to keep to time. What this suggests is

that -- I'll talk over this guy for a start.

ELECTRONIC VOICE: If you need further

assistance, please call customer service at

(719) 457-6904 --

DR. BAKER: Maybe not.

ELECTRONIC VOICE: -- or (888) 254-3533.

(410) 974-0947

143


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

DR. BAKER: Anyway, as there is so little

time for the presentation, if there's anything I flag

out or say that anybody would like more chance to

discuss, I'm around all the rest of the conference,

so please come and talk to me about it later.

A bit of context as well probably is

necessary. The NHS, the National Health Service, is

the gateway for all -- pretty much all healthcare in

the United Kingdom. It has 1.3 million employees.

There are about a million contacts with the NHS every

day, and it covers primary, acute, ambulances, mental

health, the lot. So if any of you were wondering

about the NHS, then it's a fairly huge organization.

Now health IT. NHS Connecting for Health

is the agency that is taking forward the national

program for IT in the NHS. And I'm a physician with

a patient safety background. I was formerly with the

National Patient Safety Agency in England, and when I

became interested in the patient safety agenda, it

struck me that as a physician using IT in my

practice, 100 percent of British GPs, general

practitioners, are computerized, electronic health

background, e-prescribing, internet access, on the

desktop, et cetera, et cetera.

And my interest was how do we use this for

(410) 974-0947

144


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

safer care? What is the safety benefit from the IT

agenda? And so we've been working in this area for

the last five years, and when we started -- and I am

fortunate to work with some safety engineers who have

a background in aviation, missile systems, and they

have taken a very useful approach, I think, to the

question of the safe systems, how can we rule out

systems that don't introduce new risks to patients

that weren't there before?

And the combination of five years work has

been that we now have two sets of safety standards

for health IT in the NHS. And these have been taken

through our information standards board, so they're

now PACA standards. And we've actually been using a

formal clinical safety management system in NHS

Connecting for Health for some time. The standards

are based on that. And as with all standards, I

mean, this must be -- I think engineers are

wonderful, but why don't they give standards names,

you know? Why is it all letters and numbers?

So two sets of letters and numbers. And

this first one, DSCN 14/2009, is a standard for

manufacturers, and basically the principle is making

a safety case. So it's up the supplier to see if

this piece of equipment is safe in the context in

(410) 974-0947

145


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

which it will be used, and here is my safety case.

I've done a hazard assessment. I've thought through

what can go wrong. I've put together the mitigations

for that. Here is the evidence in my safety report,

and that's my safety case.

DSCN 18/2009 is the onus on the healthcare

organization, which is largely around safe

implementation and maintenance of health IT. Now, we

have these standards now. They apply, as I was

saying, to electronic health record, the EPIS (ph.)

guiding that we do, and electronic transfer of

prescriptions, the PAC service, GP to GP, and the

electronic record is transferred not just between one

practice to another, but possibly between one system

supplier and another. So we have all of these

programs, and they're now covered by the standards,

but that's with health IT. What happens when we now

move on to and want to incorporate devices?

So, much of NHS care in the UK is provided

from family physician practices, general

practitioners. Around 90 percent of all contacts

with the NHS are provided through GPs. And as I was

saying, the GPs in the UK have their computerized

systems, and they've had them for years basically, so

they're very familiar with them. We're now moving

(410) 974-0947

146


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

on, and we've had a number of scenarios this morning

about the potential there is for many more devices to

interact with these systems in British general

practices. But indeed any EHR, whether it's in

office practices in the U.S. and hospital services,

there are a whole -- the scope is enormous.

So let's talk about, in this instance, the

blood glucose scenario, where the patient has a blood

glucose monitor in the home and the results are

transferred electronically to the physician practice.

These are some of the components that might be

involved in enabling this. And then we come into the

regulatory issues. In this context, what is a

medical device and what is health IT?

Certainly in the UK there's a completely

different regulatory framework applying here, and so

you have to think about this: Which software is

medical software? Which supplier classifies which

component? And basically, is this -- would this be

considered an end-to-end medical network? There's an

American standard, IEC80002. Well, I think it

probably would be, actually.

However, the cost components are dealt

with, if there are any, in the system, and pretty

importantly, what are the responsibilities of the

(410) 974-0947

147


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

healthcare organization, again, under the existing

NHS standard? So I've gone through that quite

quickly. I just wanted to flag up to you a cross-

section of some of the issues involved.

Now, we've also got to consider that any

regulation needs to be proportionate and effective.

It needs to be effective in keeping patients safe.

Basically, else what's the point in having it? If

it's not proportionate, it won't work. I'll tell you

what'll happen with glucose meters and British GPs.

They have to go through a whole set of hoops, such as

they can satisfy it's safe to link up these glucose

monitors, they just won't do it. If they just won't

do it, that means that patients don't get the benefit

of that particular technology.

And by the way, manufacturers won't be able

to sell them in that market. So that's something to

be borne in mind. Okay, I'll say again meet the

plain ownership of safety responsibilities, and one

standard we're thinking about is IEC80002. Thank you

very much.

(Applause.)

MR. THOMPSON: All right, our next speaker,

Linda -- we have a switch on the agenda. Linda will

not be joining us. Instead, we will have -- I hope

(410) 974-0947

148


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

I'm pronouncing his name right -- Yi Zhang.

MR. ZHANG: Yes, that's right.

MR. THOMPSON: Oh, I got it. Good. He's

with FDA/CDRH.

MR. ZHANG: Thank you, everyone. I'm

Yi Zhang. I'm a software engineer from the Office of

Science and Engineering Laboratories of the CDRH

center, FDA. The scenario I'm presenting today is

about diabetes management in home environment. I'm

hoping this scenario can inspire the discussion here

about what considerations need to be made on the

interoperability of home-use medical devices.

As you know, diabetes is one of the leading

causes to deaths for American people. Diabetes can

be categorized into Type 1 and Type 2, depending on

how the patient's pancreas is defective in insulin

creation. A patient with Type 1 diabetes cannot

produce insulin at all, so they need to use infusion,

the injection, to survive.

Currently, the -- of patients with Type 1

diabetes in the United States, about 10 percent of

them use insulin pumps for insulin DB rates.

Basically, the insulin pumps can provide two basic

patterns of the insulin DB rate, first, a specialty

rate, DB rate, which uses a low-rate, continuous

(410) 974-0947

149


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

insulin infusion to replace background insulin

secretion. The other type is corrective bolus

insulin DB rate, which administered a bolus of

insulin immediately and to bring a high blood glucose

level back to normal or to cover the carbohydrates in

a meal. So although it's very hopeful in managing

diabetes, the insulin pump can put patients into

risks. According to the FDA database, in 2008 there

were more than 5,000 adverse events reported, related

to insulin pumps.

So one of the primary reasons about the

insulin pumps is that patients operated their pumps

mostly in home environment, where they have no access

to the operation instruction, technical support from

their doctors and the physicians. So they are more

likely to make mistakes in configuring correct,

appropriate insulin profiles. Plus, current insulin

pumps require the patient to do a finger-stick test

to detect Vg levels.

As the technology advances, more and more

diabetes patients use glucose sensors for continuous

blood glucose monitoring and to save the trouble of

doing finger-stick tests. A glucose sensor can be

either subcutaneous or implantable.

No matter which format it is, a glucose

(410) 974-0947

150


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

sensor needs to produce digital readings every few

seconds. More of the glucose sensors can now talk

directly to the insulin pumps to save trouble -- save

the patient the trouble for manually inputting

readings to the pump. Then insulin pumps can

calculate the bolus dosage based on the digital

readings received from the sensor. However, the

current glucose sensors are pretty mature because

-- many because they are not accurate enough. For

example, a implantable glucose sensor can only

guarantee 85 percent accuracy.

So the diabetes society is locating --

bring multiple glucose sensors in to assist and to

detect Vg levels simultaneously, which clinical

studies -- many clinical studies have been done on

this direction, and it shows using medical glucose

sensors can significantly improve the accuracy of a

sensor.

Having this scenario defined, then, what

consideration we need to make on the safety of the

system? Or, especially, what interoperability issues

we need to consider behind this scenario? To my

opinion, we need to address at least the four or

three issues.

First, communication failures. We need to

(410) 974-0947

151


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

ensure the safe, secure, and the robust communication

between the insulin pumps and the sensors. Among

many communication issues, the most important one is

how the pump can decide appropriate Vg readings if it

fails to communicate to at least one or more glucose

sensors.

The second issue is the electrical

compatibility issues. Since being deployed mostly in

home-use environment, these pumps are open -- exposed

to various sources of radiation. So the performance

of a system as well as the interaction between the

pump and the sensor can be affected by the radiation.

Also the system can upset other medical devices that

a patient wears, wear the EMI issues.

So what standard should be -- the system

should comply with in order to ensure correct

performance and the correct interaction for the pump

and the sensor? And then the system is also open to

extreme environmental conditions like excessive

humidity, extreme temperature, vibration, dust, et

cetera. Those extreme environmental conditions can

also affect the performance and the interoperability

of the components.

So interoperable diabetes management

systems should not only include a pump, many sensors,

(410) 974-0947

152


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

but also introduce the physiological sensors and

remote connection with the doctor's remote

telemedicine. The reason to introduce physiological

sensors are twofold. It's twofold. First, it's more

dangerous and life-threatening that the insulin pump

continue to infuse insulin even if the patient is

closing the pump due to severe hypoglycemia. So the

system would be much safer if it incorporates

physiological sensors that can detect if a patient

falls into coma and instruct the pump to stop

infusion. And the second reason is the patient's

sensitivity to insulin, he worries when his physical

condition changes. So bringing more physiological

sensoring to the system can keep the pump better

input about what the patient's physical condition is

and how to adjust the DB rate accordingly.

One factor about the insulin pump is -- the

insulin pumps is that they manage your diabetes

passively, but the remote assistance from the doctors

can only instruct the insulin pump to approach

optimal DB rate profiles very quickly. So

telemedicine is also a key issue to develop safe

interoperable diabetes management. What safety

issues and the interoperability issues we need to

consider for this ideal situation, when the

(410) 974-0947

153


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

situation -- if the situation is compatible. So I

would like to leave this question to the workshop.

Thank you.

(Applause.)

MR. THOMPSON: Next we're going to have

Mary Brady, who's the Associate Office Director,

FDA/CDRH/OSB, responsible for home care initiatives.

MS. BRADY: Okay, I'll try to take my five

minutes here. So basically what we're going to go

through is a home-case scenario. I tried to keep it

as simple as possible, yet you'll find out it could

be very complicated as well.

So I looked at a heart rate monitor,

something that's going to usually look at transient

symptoms of people, such as palpitations or syncope.

Usually the person is also hooked up to a scale of

some sort, and they're also hooked up to some type of

blood pressure measuring system.

These all then go into a data aggregation

device, and it's a physiological signal transmitter,

and it receives information as well. It can record

any type of activity. In this particular scenario,

it's going to record the weight, the blood pressure,

and the heart rate monitor. All of this data is

recorded online, and it is transmitted to the

(410) 974-0947

154


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

physician, who receives this and can take action on

it. And if there's a problem with the wireless

transfer, some of these also can be hooked up

telephonically.

So what you have basically is a single-

component system that delivers continuous and

sometimes periodic computerized monitoring. This

happens typically 24 hours a day, seven days a week.

It automatically transfers that data, and it can be

in another state. It can be a far location. It's

not just right down the road. It's not just, you

know, down the street. It promotes patient

compliance through its ease of use, and this is

something that's very important in a home

environment, that it's very easy to use for the

patient. And remember, again, it's wireless data

transmission. So they're supposed to be allowed to

manually record this data and transmit it

telephonically.

And here's just a picture of the case

overview, where you're having the three different

systems going into the aggregate system and then that

transfers up to the physician's electronic health

record.

Okay. So here's the situation. This just

(410) 974-0947

155


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

happened last month, and this is a real-case

scenario. This patient was having transient episodes

of syncope. And so she went to her physician and her

physician said let's monitor you for a short period

of time. So she did. She received an expired device

from her physician. Walks out, turns around and

looks at it and says this is expired. And he said

that's okay, you can go ahead and still use it, it

works. So as soon as she gets home and it's all

hooked up, it starts alarming, and this is due to it

being expired. So she has to switch this out now.

Okay, now she receives different information. She

has called the 800 number that's really nicely

located on this device. She calls them and she gets

different information each time she calls down there.

And as she's waiting for her new device, she's

sitting there quite anxious and her physician can't

help her at this time because he doesn't have any

more devices with him.

So she started receiving phone calls, and

after the device started working, she got her new

device. It started working, okay, and it started

alarming and she would call them -- that's not on

this particular thing, but she would call them and

say something's wrong here. And they said, well,

(410) 974-0947

156


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

we're not receiving any data that says you have a

problem. And she said, well, it's alarming.

Well, then she turned around and received

phone calls from the data receiving site, wondering

if she had disconnected the device because they

weren't getting any readings. And she turned around

and said, well, no, it's all connected. I don't

understand what's going on. First I call you and I

have an alarm and you don't catch that, and then you

call me and say you're not getting any signal. So

there was a mix-up two different ways there.

She lives in the first floor apartment at

the base of a hill. Some days she can't use her cell

phone, and she was thinking, hmm, is there something

that's kind of associated here? So she would move

over to the window with her heart rate monitor, and

sure enough, it would start working again. So she

was concerned that what was going on with that

aggregator that was taking all of that data had the

same issue as the cell phone and was hoping that she

could get that data transmitted manually just in

case, but she did not receive a manual monitor with

this.

So she's really unsure how much data was

really transmitted through that device, and when she

(410) 974-0947

157


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

called her physician, he said, oh, I think I have

enough data. Let's go ahead and work with it. And

she didn't want to wear anymore anyway. So you're

looking usability, usefulness, things like that.

So the potential problem here is that this

is a signal-detection risk and it's possibly poor

quality of service with a medical device. It brings

you to ask, you know, who is responsible for the

different areas? If it's being used in the home, who

is responsible for the good transmission of the data?

And is there national reliance upon data? If we take

this out and broaden it to the entire United States,

who's responsible to make sure that that data is

being received here and being sent properly? And are

there going to be integrity problems that increase as

home use increases with this type of device? And how

does this design influence the ease of use?

In the error messaging area, you just have

to think about what kind of alarm should be there

when the device is disconnected or transmitting data.

Should it warn about interference and to what extent

do we provide warnings for this and how many warnings

should you be providing?

And in the area of troubleshooting, how

should troubleshooting occur when you're not sure

(410) 974-0947

158


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

what really is happening? So how do you go through

that? As a patient yourself sitting in your home,

how do you try to figure out what's going on with

your device?

And for data identification areas, when you

move devices from one person to another -- remember,

this was bring transferred from one patient to

another to another -- how does it know it has changed

to the next person? And we kind of talked about that

earlier this morning. And how long can you keep the

data from each person inside that device? So these

are just issues that are up for discussion today, and

hopefully we can get some good talk on them. Thank

you.

(Applause.)

MR. THOMPSON: All right, what I'd like to

do -- and by the way, for the panelists, we've got

these microphones. You can stay where you are for

this part, but you're going to have push the button

that sits right in front it, down at the base there,

in order to be able to talk, I believe. All right.

I'm going to open it up for questions in

just a second, but I have a question that I want to

go down the row and ask the panelists to comment on,

and then we're going to turn it over to the audience

(410) 974-0947

159


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

to get your questions as well.

All of you come from regulators of various

sort. That may not be a good description of the

English counterpart, but you're all involved in

health policy. I want to ask you a question, not so

much from a legal point of view, because that's too

much minutiae, but I want to ask you one from a

policy and a clinical standpoint.

Each of you presented an array of

technologies that began with a device that touched

the patient in some way, measured something, in some

cases even an insulin pump that delivered therapy.

And then it connects through a series of steps,

components, to either a computer or a cell phone, and

it's ultimately, maybe, transmitted to a physician's

office, and there's software involved at each step of

the way. From a risk standpoint, just a risk

standpoint, which components do you think ought to be

regulated? Okay?

So do you want to go through your scenario

in your mind and figure out which components you feel

engender enough risk to merit regulation by the

appropriate body, from your own cultural perspective?

I realize we have different jurisdictions involved

here. Do you want to begin? It's essentially the

(410) 974-0947

160


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

questions you posed rhetorically, Maureen, at the end

of your -- the second to your last slide, you had

which are the devices and which software gets

regulated? I'm asking you to sort of answer your own

rhetorical question.

DR. BAKER: Yeah, yeah. I think there does

need to be a regulation framework that encompasses

the whole system. Now, that's not to say that

manufacturers of cell phones need to comply, you

know, so that -- I mean, they don't care whether

their cell phone can be used for this application or

not. But the body that introduces this as a system

would need to provide -- in my opinion, there needs

to be some assurance that if you're going to put a

cell phone in this, you can do it safely. And so I

feel that there does need to be a regulatory

oversight of that, but where it should be, I think

we're just really in the process of teasing out

because at the moment, and certainly in the UK and in

your context, it isn't clear and the questions are

really just starting to be asked, as far as I can

see.

MR. THOMPSON: Can I press that just a

little bit further to get a little bit more specific?

If I have a cell phone, call it a pear cell phone,

(410) 974-0947

161


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

but just a hypothetical cell phone, and the medical

device manufacturer says you can connect my device to

a pear cell phone -- pear as in the fruit and not the

pairing -- is the medical device manufacturer then

responsible for showing that they can work together?

Is that the point you're trying to make?

DR. BAKER: Yeah, I think it's like a -- so

you know, if you buy a computer game -- I think we

still do -- so you can use this on machines that have

got this capability, and it'll be a list of what the

capability is that's required for that game to

function properly. So I would foresee that as part

of the case the supplier needs. And yes, it can link

up to the cell phone, but the cell phones need to

have the requirements, and then presumably it's then

up to our -- or possibly the health organization of

group to see, yeah, this cell phone, the one I got

here, is appropriate for this device to connect to.

MR. THOMPSON: I want to ask the same

question. You described an interconnected blood

glucose sensor and pump, but you also described then

a remote connection that might be ultimately tethered

to a physician's office. So could you describe which

of those components, just from a risk standpoint, not

a legal standpoint, but from a risk standpoint, which

(410) 974-0947

162


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

of those components ought to be regulated?

MR. ZHANG: Well, first I'll make it clear,

the role of our Office of Science and Engineering

Laboratories is to provide engineering support for

the regulators in FDA. So this might not -- I might

not be the best one to answer this question. But

from the engineering point of view, of course, for

insulin pumps and glucose sensors, right now they're

independent. They are considered as separate medical

devices and they're regulated by FDA.

About the connection between the pump and

the glucose sensors, I don't see any -- I did not see

any submissions in this scenario. But the data

transmission from the insulin pump to the remote --

to the doctor's PC or the physician's, I would like

to let Mary answer this question. And it has to be

regulated by someone, but I don't think the FDA.

MS. BRADY: Yeah, I think I can speak more

from a clinical perspective, and I welcome our folks

in the labs to come up if they want to offer up

something. But I believe there needs to be

regulatory oversight for an entire system when it's

being used outside of a controlled clinical

environment. Once you're going into the home and

outside of a clinical environment, it's virtually

(410) 974-0947

163


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

uncontrolled.

So there needs to be some sense of that

what you are doing, there's reassurance that if

you're trying to diagnose and provide treatment to a

patient, that there's assurance that something is

actually happening and it's accurate, accurate to an

extent that we want it to be in that kind of

scenario.

I believe, when you have a system that

starts off with a patient and they are feeling that

they are safely being monitored from a remote site

and they have no way of understanding how to

troubleshoot something or know that their information

is being transferred, that there needs to be some

sort of mechanism that way.

To the area of cell phone technology and

all of that, where you have an intermediary piece,

all the different pieces that go in between the

patient and the physician, I think there needs to be

some sort of oversight there as well. I'm not saying

that FDA needs to call them all a device. We don't

know that. We're still in the process of working

through that. But what you need to have is an

understanding that when I have this device, I'm

probably going to have this for a period of time, and

(410) 974-0947

164


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

the way that technology upgrades itself so

frequently, I'm not sure that if you kept everything

separate, that every piece of that technology would

be keeping up with each other.

So if you're upgrading your cell phone, is

that also going to handle that application or not?

Just, you know, questions we need to be asking

ourselves right now.

So I think there needs to be some type of

oversight overall to make sure that when these things

say they're operating as a system, they continually

and consistently operate as a system.

MR. THOMPSON: At this juncture, I

forewarned you that I wanted a lot of audience

involvement. Are there questions and comments from

the audience? If so, you'll need to go to

microphone, please. Yes.

MR. deBRONKART: First of all, the story of

the idiot company with the data collection device, I

went through exactly that with Wells Fargo, trying to

get an erroneous payment returned to me a week ago.

Every person I talked to, seven phone calls over

eight days, said the previous person had it wrong.

And the amazing thing is that they are really

competent at their processes for receiving money.

(410) 974-0947

165


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

(Laughter.)

MR. deBRONKART: And not for dispensing it.

And it wasn't that they were crookedly trying to hold

on to it. They just obviously had the idiots working

in that department. Or, actually, it's more likely

that they just hadn't defined their reliable process.

So it's easy to be a smart aleck and rant about this

stuff, but there really is a question: How do we go

about engineering the processes that will make the

right things happen?

The best thing I know from my business

experience is to get -- is to put into the process

the people who suffer if it's done wrong. Okay?

Now, diabetics happen to be a great community for

this. They're like the prototypical e-Patient, very

engaged. They're happy to stand there and say no,

wait a minute, you didn't do this, you didn't do

this, we need this, and things like that.

So I'll just float out the suggestion that

involving what we call the invisible stakeholder,

right, the patient, in the certification process is a

good approach. The other thing -- and this is a

question. I don't know how we go about it, but I'm

kind of surprised, given how things go in the high-

tech industry, that there are these issues of how

(410) 974-0947

166


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

devices communicate reliably, right? Like a device

is sending out a signal, but there's no closed loop

verification that the data has got there, right?

The basic way that the internet is designed

is something gets sent out, and you get word back

that it arrived. And if it didn't happen, then it

tries again and it tries again, and eventually you'll

get an error message saying you couldn't connect.

So I don't know what to do. What I'm

really curious about is how could it be -- and I mean

this not as a wisecrack. How it could be that so

many smart people would not be aware of existing

solutions for things like getting data from one

device to another?

MR. THOMPSON: Any of the panel have a

reaction?

MS. BRADY: I think they're afraid of

regulation.

(Laughter.)

MS. BRADY: No, I'm just kidding, I'm just

kidding. I'm not sure. I think that's why people in

this room are together now to say this is something

really that could potentially get out of hand and

that we need to start putting some sort of wrapping

around it at this point. That's my understanding of

(410) 974-0947

167


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

this. I can't agree with you more. Yeah, thank you.

MR. THOMPSON: Why don't we go over here?

DR. MUN: I'm Dr. Mun from HCA. We have

been doing exactly the patient monitoring at home in

the last six months, and we have done wireless and we

have done 802.11. We have done -- the experience we

have had up to this point is that insulation issues

are very difficult because when you walk in a home,

initially we thought the easiest thing to do is use

wireless G.

So then you can just put the device in and

just walk out. You don't have to touch anything.

Because we are afraid if you go in there and touch,

let's say, phone lines or even their video lines, if

something does go wrong, then how can you manage

that? So that's what we decided to do initially.

And then a problem became that some houses

have good reception and some of them don't. And the

next thing we realized is that the cell phone company

changed the protocol it's sending information between

cell towers. So all the things we have done first

three months went down the toilet because we're

convinced that they changed it, because initially

they denied that they changed anything. And so this

was -- to put it very nicely, it was a circus on our

(410) 974-0947

168


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

side and we looked very stupid. Meanwhile the nurse

who's getting this information -- in our case the

nurse gets the information and then gives it to the

physicians because they filter it, and a physician

comes out, looks at all this information, and there's

the basis.

So when the communication does not happen,

the nurses now feel that they have a liability

because they have this information but they cannot

give it to the physician, or they cannot collect

information on time. So I know on the physician side

they are saying why do I have to look at this thing

every day? Am I getting paid for this? And they're

not.

So in terms of regulatory issues and all of

that, I think before we go there, we need to have a

reliable system, and we need to have a clear

definition of what the service is expected to be

provided as well as expected to receive because

without that, I don't think any regulatory issue

would make any sense. Thank you.

MR. THOMPSON: Anyone on the panel have a

thought or reaction?

DR. BAKER: Yeah, cleaning up. This is why

we need to really start working to think how you do

(410) 974-0947

169


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

it properly. And it is something about thinking of

the device, the piece of cake, in the system in which

it works. You cannot think of a piece of cake in

isolation.

MR. THOMPSON: I think you stood up next.

MR. GRYZWA: Okay.

MR. THOMPSON: So we'll do you and then you

over there.

MR. GRYZWA: There's something I'd like you

to consider as you develop these systems that we

talked about, like the aggregator, clearly a piece of

medical equipment. What we struggle with -- I'm Mark

Gryzwa. I'm from Boston Scientific today for the

management. We have a Class III implant in a

patient. How do we classify the device that will

then talk to it? And if it is a commercially

available cell phone, what do we with that software

on that, and how do we partition that from the other

software that may be on that phone?

Then you get to the internet quality or the

3G network, AT&T, the very service providers out

there in the world. Do we put some kind of

restriction on them as well? We talked about like if

you were on AT&T, is that enough to make it work?

And then, now we get to the back end system, as I

(410) 974-0947

170


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

like to call it. How do we classify that, which is

really just store and present data? And then if we

manipulate that data in any way, have we increased

our risk?

So these are all questions that we wrestle

with daily on these systems, and the more clarity you

can provide us as to how that classification can work

throughout the system -- we acknowledge that it is a

system front to back and that system can include your

IT professionals. It can include people that answer

the phone. But we really need some clarity as to how

that works all the way through. It can't be Class

III medical all the way down to the server, but what

is it is what we've been wrestling with.

MS. BRADY: My question for you, I guess,

is have you worked through this at Boston Scientific?

Have you come up with some ideas as to how you think

this would be best taken care of, each piece of the

system, as you're talking about?

MR. GRYZWA: Sure, we have tons of ideas.

(Laughter.)

MR. GRYZWA: We never lack those. It's how

do we get that dialogue like this, with folks like

you, on a regular basis, to say, here's what we're

thinking? Where do you want to take this? Because I

(410) 974-0947

171


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

think you're struggling with it as much as we are, if

not more, in rating more and more of these systems

heaped on you. They're clearly not unregulated.

What, you know, we look at is a lot of EHRs. A lot

of EMRs today kind of got into existence without a

whole lot of oversight, and now they're becoming

slipped in. We're trying to figure out where we fit

in that, kind of that broad spectrum of things.

MR. THOMPSON: By the way, I've been given

the two-minute warning, and I apologize to those of

you standing up, but maybe we can have discussion

over the break or something with our panelists, but I

think we only have time for one more question. In

the blue stripe.

MR. WITTERS: My name is Don Witters. I'm

with the Center for Devices and Radiological Health.

I lead the electromagnetic compatibility and wireless

group. Many of the issues that were discussed here

have wireless components in it. But I wanted to get

back to your question, which is really working in a

shared-risk environment with not only wired but

wireless components. How do we manage that? How do

we get a handle around it? How do we get that

framework, as one of the speakers talked about it.

Mary's example is a good example, I think,

(410) 974-0947

172


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

of quality-of-service issues because there wasn't a

good quality of service. One of the other speakers

spoke to that, too. But there are also other aspects

that deal with this. To get a handle around it, we

need to develop a better process by which we can

recognize, by which we can develop the tools, the

information, that are independent of any particular

point of view but are right to the focus of this.

We developed a guidance, a draft guidance

for wireless medical devices. We are also involved

in a series of workshops since last year, where we

were discussing these issues and how we can come

together. Some of that started to deal with some of

the aspects of the questions that you had.

So I think not only do we need standards,

we need standards that not only involve safety but

effectiveness, and there are really no standards that

deal with effectiveness. We need processes that

really deal with these fundamental issues of the

shared risk. Whose risk is it? Whose responsibility

is it?

There is one aspect that's being developed

now, the ISO 8000-1, which does speak to network IT

and risk management, that is coming to fruition.

That's only one piece, but more tools need to be

(410) 974-0947

173


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

developed. So I'd just encourage a more vibrant

discussion with as many of the stakeholders as

possible in this area.

MR. THOMPSON: Thank you very much. I've

been told that we're out of time, unfortunately.

I've also been reminded that we're going to have

sessions later on in the program where we're going to

break out into working groups, and a lot of these

topics will be great for discussion fodder among

those groups. So I want to thank our panelists very

much for their contributions.

(Applause.)

MR. ROBKIN: Thank you, Brad, for

moderating that session. The last question, I think,

is a good segue. This is the session on Enterprise

Issues. I'm Mike Robkin, and I'll be your moderator

for the next few minutes. First up will be a

presentation by a team from Kaiser Permanente. Doug

Grey, who's a physician and chair of the Kaiser

Permanente National Product Council -- sorry, the co-

chair. Vice chair?

UNIDENTIFIED SPEAKER: Vice chair.

UNIDENTIFIED SPEAKER: He's the vice.

MR. ROBKIN: Vice. So if you're not

familiar, Kaiser is, of course, a very large

(410) 974-0947

174


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

provider, and the National Product Council oversees

the acquisition of Kaiser's medical devices. So here

is the voice of the customer. He'll be followed by

Tom Judd, who's National Project Director, and then

Tom McGrane, a principal solution consultant. After

that we'll have a presentation by Tim Gee, who is a

medical device connectologist. He runs a blog.

What's the blog?

UNIDENTIFIED SPEAKER: Medical

Connectivity.

MR. ROBKIN: Medicalconnectivity.com. And

he's the founder of the first conference on medical

device connectivity. So Doug.

DR. GREY: Thanks. The first time I met

Michael was when you made the decision about our

digital operating room, and for those that are

unfamiliar with that term, that's really how surgeons

manage images in surgery. In other words, if you're

doing laparoscopic surgery and you want to see the

gallbladder, that's what it is.

And so about two days ago Michael said

we've got some urgent news. We've got to truncate

your presentation down to five minutes. And so I

said I could do you one better; I could do it to five

words: can't see, call biomed.

(410) 974-0947

175


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

(Laughter.)

DR. GREY: And you've all probably heard

that before. We're going to divide our presentation

into three components. My first is from a

physician's perspective, a provider perspective, and

also a procurement perspective. There are some

clarifications that have to be done around the loaded

word of integration, where integration has become

ubiquitous in our system, and I'll clarify that. Tom

Judd is going to talk about the unique challenges of

a digital operating room, and lastly Tom McGrane will

talk about some IT challenges and potentially

opportunities.

Integration. The elephant in the room for

us is when we opened our first hospital for -- with a

digital operating room, and I got a page when I was

in Washington about 10 minutes later with a guy

saying I can't see the gallbladder.

This used to be an environment where you

plug a monitor in, you plug a camera in, you'd

connect the two, and everyone was happy. And I think

what has happened now is there are a raft of devices

that have to integrate.

And so the image, instead of going directly

to a monitor, goes through all sorts of circuitry so

(410) 974-0947

176


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

that you can recall images from the medical record,

you can store them, you can capture them, you can

compare them. All of those things have to be done.

And so the elephant in the room for us is now we've

gone from a world of a nurse turning on/off switch to

something where you need an IT consultant to fine-

tune your operating room.

But integration for Kaiser means even more

than that because I can guarantee you that there's

not a surgeon that I work with that really cares

about the back end, front end, or anything else. All

they want to do is see a picture. And so there's all

sorts of IT integration that has to take place if you

are going to meaningfully capture those images.

We have been trying to be creative because

when you craft a new contract and you've got a

billion dollars of installed base of equipment and

you make a procurement of $10 million of equipment,

you have to integrate that into your system. How do

you go about, as a chess game, managing all those

unique devices so that you can move them between

hospitals, around in rooms, et cetera, to make them

more effective?

The integration, to the nurses, they raise

their hand and say pardon me. I don't have a

(410) 974-0947

177


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

bachelor's in integration. This is going to affect

my workflow. I'm here for the patient. How I am

going to manage this with all the efficiency and

quality measures that you're likewise inflicting on

me? So integrating into the workforce is one of our

great initiatives. We've got a whole center

around -- just near the Oakland Airport to really

focus on how this equipment gets integrated into the

workflow. That's something that is another issue.

We build two to three hospitals every year

and open them, and yet the hospital's a hybrid of

equipment. They aren't just new equipment. We

cannibalize all sorts of different things to make --

in the name of efficiency.

But then Tom Judd gets called, and he has

to integrate different cameras, monitors, routers,

the cabling is new, the interface with a different

supplier because the interface last year was with one

supplier and now we have supplier B that needs a new

interface. So all of those challenges are something

that aren't in the name of integration of seeing a

picture in an operating room, but those are equally

important.

And then, lastly, we have a whole

contracting arm, but how do you go about quantifying,

(410) 974-0947

178


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

when you acquire new devices, what the actual cost

is? Because we're in a mode now, in this new

environment of the obligation of plugging something

in and having it connect, that you may save 10

percent on a contract but then spend 30 percent

trying to solve the problems of integration into the

system that you couldn't solve because you couldn't

anticipate it.

So these are all integration issues. Yes,

we can talk about the interface and the direct

connection, but those are equally important and

likewise will have tremendous impact on the quality,

the safety, and the value and efficiency of what

we're trying to accomplish. So I will hand the baton

to Tom.

MR. JUDD: Thanks, Doug. We've done some

simulation along the lines of this particular case

study, and a lot of this capability is, of course, in

use. And I'm going to make it simple and fast here

because I was asked to. But from an image management

-- I mean, obviously there's Julian's, wherever you

are, anesthesia and vital signs measurement and

monitoring going on. This is the image management.

What's new about image management? Of

course, the radiographic image is being pulled in,

(410) 974-0947

179


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

whether they're real-time or, you know, archived

images. But the whole visible light -- I heard the

Director this morning talking about using those jpeg

images in many creative ways.

So management of visible light in the

context of visual operating image management, where

we're talking about a cockpit computer in the corner

that does a lot of functions. We're talking about

the tower with the camera control unit and the

endoscopes in the operative field and so on.

So here's some of the things we've seen,

particularly for those surgical specialties that use

a lot of images. What we're really talking about is

changing workflows, optimizing workflows, higher

quality care with better efficiency. So there's a

preop component to it. This, by the way, is able to

be automated for different surgical specialties,

different procedures.

But what do you look at before you go in

the room? What combination of digital visible light,

digital pictures, radiographic, and so on? How do

you set up the room so that, you know, between cases

all you got to do is say what the procedure is and go

in and do it? Intraoperatively, what do you display

where?

(410) 974-0947

180


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

You know, we got urologists, for example,

that need to look at high-res fluoroscopy on one

screen right next to high-definition endoscopy to put

the catheter at the right place at the right time.

And there's the whole -- how do you manage the

process of capture, annotation, storage, and so on,

the image management postoperatively? Other things

that come into play in this, what is that aggregator,

that first link that was talked about in the HPSP

documents, to manage this process? What about

bringing in wireless devices like ultrasound? How do

you wrestle with that? Doug talked about image

management role definitions. How does this change

what the nurse does when in the procedure and what

the doctor does before and during and after the

procedure? And then bring in the component, not just

of surgery, but setting up the surgery with the

virtual visits and pushing images around before.

So this is just a quick flowchart. We kick

off this digital operating room process with the

patient demographics that allow the middleware, the

DICOM wrapping of the images appropriately, and then

the HL7 messaging that tease this back up to the

doctors and the electronic health record and then a

visual of that. Tom.

(410) 974-0947

181


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

MR. McGRANE: So it's doctor, biomed, IT,

and that's the pecking order within Kaiser

Permanente.

(Laughter.)

MR. McGRANE: Lined up just right. Okay.

So speaking a little more generally beyond just the

DOR effort, initially, one of the things we're

focusing on is we have a very large enterprise

network. We have eight different regions, 32

hospitals, and Kaiser's pretty big, as I'm sure you

all know, and within that there's a lot of networks

and a lot of systems that have grown up.

So we're right now trying to integrate all

of our systems onto a common enterprise because as we

move to an EHR, which we have primarily done, and we

have all of the information, we have the ability to

put all the information onto a common platform, a

common EHR, but we don't have all of the systems that

collect data yet onto the network so we can get to

the EHR. So that's the process we're in.

And, you know, as we do that, we have a lot

of challenges, and this goes to, I think, a lot of

the questions we heard from the previous panel about

the standards and where you impose standards and

regulations and perhaps where can you go -- if it's

(410) 974-0947

182


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

too regulated, it's very difficult. You can't get

the -- I like the term mash-up, if we're over-

regulated.

So from an IT perspective, we have this

huge responsibility to make sure that all of this

traffic going across this enterprise network isn't

infected with viruses, isn't corrupted, you know,

people aren't, you know, stealing data. And that's a

tough thing because it's always morphing and people

are getting more creative, so we have to stay on top

of it. So as we have our, you know, switch and

router vendors, like Cisco, constantly developing new

technologies, you know, WEP protocols for better

crunching, we want to be able to, just as quickly as

they develop it, overlay it into our network. The

challenges we often come across as we start bringing

in different systems on the biomedical systems is,

okay, we want -- you can come on to the network.

There are these rules or these guidelines,

and oftentimes it's like, well, we can't do that, we

can't have that version of malware run on this

device. Why not? And often we hear, you know, FDA

regulations. I think sometimes that's overused by

our biomed buddies. You know, I'm not so sure, but

we do hear that a lot.

(410) 974-0947

183


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

And to the extent that the devices that we

do incorporate from an IT perspective are over-

regulated, there's a balance here, you know, we all

understand, but it really inhibits the ability to

bring them on board and to get the patient data to

the record, electronic record, so that it then can be

shared across with other medical centers.

Like Kaiser -- had started interoperating

and sharing their data. But if we can't mash-up, if

we can't work nimbly, it's going to be very

challenging. Under the specific recommendations,

this is kind of back to the DOR example I wanted to

add in this. So I remember when we were going

through our initial forays with visual ORs and we had

the vendors set up and we were working with it, the

vendor, as good vendors do, they kept increasing and

enhancing the technology, and as we -- sometimes at

our request, because we're so big we can do that.

And as we get this technology advancement

we say okay, you know, you've betaed it, it's

working, we want to turn it on, and often we were

told, well, you know, it's not FDA approved yet.

Well, when is that going to happen? And, you know,

it takes awhile, and while we're waiting FDA

approval, we're not getting the benefit of already

(410) 974-0947

184


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

developed technology.

In fact, I can remember the example with

digital alarm, that the vendor told us we have it but

we're not submitting it yet to the FDA because the

process takes awhile and, you know, there's a certain

amount of effort. So we have to get -- we wait until

we have a certain amount of enhancements all stacked

up before we even submit them. And this, you know,

of course keeps us and the physicians from having the

technology that was developed for them to benefit

them and we're kind of in line. So I guess that

would be my one message while I'm here in the lion's

den talking about the speed of which things that are

submitted get through the process. And a very short

summary. We need minimum requirements defined

between the suppliers and FDA. And after that, we'll

take care of the rest.

(Laughter.)

MR. GEE: Well, I'm going to sort of

leverage off the presentation that was just given,

although I have a somewhat different point of view.

As opposed to being over-regulated, I think maybe

we're a little under-regulated.

So this is how medical device systems are

created. It's how the requirements are gathered.

(410) 974-0947

185


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

It's how they're specified and designed. It's how

they're approved or cleared by the FDA. And this is

how they're used in the real world. A big

difference. A huge difference.

Now, I would imagine that the majority of

those systems that when they do get installed are

installed to specification of the system that was

cleared by the FDA and you know, everything's kosher

in that respect. But certainly over time, I would

bet every one of those systems gets way off the

reservation.

So there's four issues, problems, that

could be addressed. One is particularly -- and I'm

speaking mainly on the networking side of things as

opposed to up at the application layer. Networking

standards, we've got a lot of great networking

standards. We don't need more networking standards.

We just need to better use the ones we have. And

right now there's so much flexibility, you could have

a range of variation in standards, configurations,

and profiles that are adopted and insisted on by

hospitals around the world that is huge.

There's really no reason why we can't take

that variability and narrow it down substantially so

that medical device manufacturers, who are not

(410) 974-0947

186


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

networking rocket scientists -- I mean, let's sort of

admit that -- can have a much reduced scope of things

that they need to do so that they can make a medical

device that's a reasonable network appliance, because

that's what they are becoming, in a way that is

consistent and presents fewer variables for

everybody.

The other thing that networks need is some

kind of framework within which to do coexistence on

the network. If you go out and you buy medical

device systems from CareFusion and Hospira and GE,

Philips, Welch Allyn, and you try to put them all on

the same network, it won't work. How are they

supposed to solve that problem, though? I mean,

they're all -- many of them are direct competitors.

They can't sort of meet in the back room without

raising FDA -- not FDA, but antitrust issues. There

used to be a framework so that that can occur in a

way that they don't have to worry about disclosing

proprietary information and don't have to worry about

antitrust issues. They also need a framework for

test and certification to be able to support

networking infrastructure beyond the vendor that they

had installed in the lab when they developed their

product.

(410) 974-0947

187


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

Let me know. How many people are aware of

a vendor that does more than -- supports more than

one wireless infrastructure vendor with their system?

Anybody? Okay, there is one company. It's

represented here today. Draeger supports four --

five?

MR. FUCHS: Four.

MR. GEE: Four wireless infrastructure

vendors. They're the only ones in the industry. And

so, you know, you go into a hospital, and they base a

decision on clinical requirements for a system that

requires one network infrastructure vendor. Hospital

IT says no, no, we use another vendor's

infrastructure, and all of a sudden you've got a

problem.

So what we need is some kind of test and

certification mechanism so that when I release a new

wireless patient monitor, it not only supports the

manufacturer that I had in my lab, but it supports,

you know, three, four, five others as well. And one

of the wrinkles here is that that test and

certification needs to be more than just a weekend

plug-fest in a hotel ballroom. It needs to be

something that conforms to the FDA's quality system

regulation because they're medical devices. And if

(410) 974-0947

188


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

you don't do that, then you just force the

manufacturer to redo all that testing themselves

anyways, and the plug-fest ends up being a waste of

time.

And everybody in the industry needs a

framework to ensure the safe and effective creation,

maintenance, and evolution of these systems in the

real world. There's a huge sustaining engineering

burden here, not just as network infrastructure

manufacturers upgrade their firmware or replace a

router with a new router or change to the next

generation of wi-fi infrastructure. It's also the

servers and the operating systems as well as the

medical device systems, although they tend to change

a lot more slowly.

So to propose some solutions here, just to

spark a little conversation, from a provider

perspective, the IEC80001 is a great start. But, you

know, hospitals need to do a lot more than risk

management. They need to have a whole framework of

policies and procedures to manage change, to be able

to first capture all the requirements and

specifications for all the different medical device

systems that they're supporting, and then be able to

keep all of that straight and make sure that

(410) 974-0947

189


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

everything they do is in conformance. And then, when

the product that they need for conformance is no

longer available from a manufacturer, they can go

through an appropriate process of risk analysis and

testing to find a replacement component that still

results in a safe and effective medical device

system.

Common network designs and configuration

profiles, I mentioned that earlier. If the industry

could sort of get together and say instead of we're

going to support this much variability, let's support

this much variability, it'll be easier for everybody.

Wouldn't it be great if we could test and certify

provider networks so that the hospital would always

know that, you know, we're in conformance with this

profile? A manufacturer that wants to come in and

sell a system knows they're in conformance with that

profile, and it makes the whole process of getting

the technology, implementing it quickly, and being

able to benefit from it that much easier.

On the manufacturer side, we need a

framework for doing test and certification for the

network medical devices, both coexistence as well as

supporting, you know, multiple infrastructure

manufacturers' products. And then we need this

(410) 974-0947

190


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

framework to be extendable so that we can provide

ongoing support for, you know, the constant changes

that occur in all of these off-the-shelf technologies

that we use.

You know, there's a certain amount of

sustaining engineering that has to be done depending

on what a risk analysis shows has changed, and it can

be substantial or it can be lightweight, but you have

to go through that process to figure out what it is

and then do it. And to expect every hospital to do

that on their own, and every manufacturer to do that

on their own, it's crazy, it's inefficient. We've

got better things to spend our money on, like cool

clinical features that will save lives.

So how do you come up with these

frameworks? How do you make all of these decisions?

Well, here's a graph showing the usual suspects.

Okay, we've got the FDA, we've got the IHE, ISOs or

SDOs, like HL7, DICOM, 11073, Continua trade groups

and then some other thing. And these are the

criteria for our market, which, I should say I'm

speaking sort of hypothetically from the acute care

market. The ambulatory market already has a group

called Continua Health Alliance that pretty much does

much of this, although in a different way. But

(410) 974-0947

191


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

you've got to have acute care expertise, be able to

develop and support network profiles, do the vendor

test and certification, provider test and

certification.

IEC80001 is more of an implementation

thing. You get a great standard, but you know, it's

a great process. But some hospitals, without

guidance, will create really great risk analysis and

others will create really poor risk analysis. So

there needs to be some guidance. And then QSR

compliance, familiarity and ability to deliver on

that.

And as you can see, there's really not any

group that we can sort of take this to and dump it on

their lap and say, here, fix this. Probably the

trade groups can do a lot of it. Certainly the nice

thing about a trade group or a consortium or an

industry -- I'm sorry -- a trade group like HIMSS or

AMI (ph.) or the ACCE is that they can work directly

with their members to create network profiles and

things like that, help educate them on IEC80001,

participate in the development and expansion of 80001

beyond risk management. So some food for thought.

MR. ROBKIN: Thank you, Tim.

(Applause.)

(410) 974-0947

192


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

MR. ROBKIN: So I'd like to start off with

some questions from the audience.

UNIDENTIFIED SPEAKER: Yeah, I'd like to

address the comments of our last speaker. It occurs

to me that you described Boeing, the systems

integrator. I don't know whether you're putting

forward that as a business model, but it occurs to me

that, now using the aviation example, we've just

plopped down and said, okay, airlines and components

manufacturers, avionics manufacturers, you've all got

to do it this way. And I don't think the FDA is in a

position to be a Boeing.

UNIDENTIFIED SPEAKER: Why is it us? Why

don't we let Boeing do it?

MR. GEE: Yeah, actually, I've had a

similar discussion with -- was it you, Sandy? I

think it was -- about, you know, it's the FAA that,

you know, certifies airframes, and it's the FDA that

is more about process. And what I think we need as

an industry is not so much somebody to tell us how to

do things but an organizational structure for us to

figure out what to do.

UNIDENTIFIED SPEAKER: And, Tim, this gets

back to the discussion of the last panel actually,

and I'll refer back to the analogy that was used

(410) 974-0947

193


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

relative to the defense industry, that gentleman over

here, relative to the quality of service, and

requirements are often quality of service. In

defense systems, like these large-scale defense

systems, one solution with a quality-of-service

problem is simple: supply it. In other words, as

opposed to living off of AT&T or Verizon, pick your

poison, essentially you have your own certified

network that you certify.

In the situation that was described in the

last panel -- and I think that is really reflected in

where things are moving with 80001 -- the challenge

is related to, well, where do you certify? You know,

you can't -- unless you control the network, unless

you control the entire environment, how do you

certify the entire environment?

You might specify quality-of-service

minimum requirements in order to achieve -- you can't

participate unless you achieve certain minimum

requirements. Then I'll wait for the torches and the

tar and feathering out in the hall after I make that

statement. But the point is, is that unless you

control the end-to-end, how do you assure that you

achieve the high quality you need?

And the fact is we don't control it. We

(410) 974-0947

194


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

control one aspect of it. We control either the

devices or we control communication to the devices

immediately. But in terms of some of the scenarios

that were described previously which -- well, you

didn't have connection unless you walk near the

window, as an example, or didn't have a connection

unless you turned around and patted your head three

times.

These types of challenges are going to

proliferate throughout the entire interoperability

environment, unless something is done relative to the

end-to-end problem. And it's more than -- obviously,

when you exit the enterprise, that's where one area

you run into a problem.

Several years ago intra-enterprise

communication was a problem, and I think that -- you

can think of it even that it's sort of kind of going

the way of the dodo. But even so, in order to

achieve effective home health now, one might take the

model from the AT&Ts of the world or the Brinks, so I

guess the quality-of-use securities are the 911

security dispatchers.

But even there you're not guaranteeing the

service. The services, if given that direction to

supply the connection to get through, you will get a

(410) 974-0947

195


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

response. The challenge seems to be and continues to

be guaranteeing the service required to ensure that

you can rely on these systems for intervention, which

I think is really key from the safety perspective.

MR. ROBKIN: Let me redirect that question

or comment back to Kaiser. Do you guys want to talk

about what it would take to certify the enterprise

network and maybe how you would feel about giving up

network functionality for medical device

interoperability?

MR. McGRANE: You know, I would say -- you

know, I guess the word standardize or certify. But

when I hear certify, what comes to mind to me is, you

know, recertify and recertify, and it really does

take away from the ability to be nimble and the mash-

up factor goes away. If the guy using the iZipcar

had to, you know, wait for AT&T or somebody to

recertify something for that occasion, he wouldn't

have been able to do it.

So I think there needs to be, in areas

where the -- and there is areas, of course, where

certification is key is, you know, patient safety

here. But in areas of network protocol and things

like that, like I focus on, I think standards-based

common interfaces, that's all good. But to the

(410) 974-0947

196


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

degree that we need certification, you know, there's

just too many moving parts. We'd be stuck. We'd be

frozen.

MR. GEE: In looking at this issue outside

of the hospital, where you don't control the network

and you don't control a lot of these things, I think

a lot of it comes down to how you do your risk

management and how you design your solution and how

you mitigate those risks that you've identified.

Obviously if you can't mitigate those risks that

you've identified in a way that created a product

that's safe and effective, then it should never have

been cleared by the FDA until the technology's

available to do that.

MR. ROBKIN: Question?

MR. MADDALI: Mahesh Maddali, Boston

Scientific. Just an off-the-cuff comment here.

We've talked about the ownership of assuring safety

of medical devices on the hospital institution

infrastructure. Again, you know, the diagram, Tim,

that you showed up there, where it's completely

broken apart, what's the regulation on that?

I mean, sometimes I think if you sort of

start asking yourself how does that end certified --

I'll use the word tested or whatever. Maybe that'll

(410) 974-0947

197


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

start forcing a discussion like the Boeing, the

aggregate, where the FAA is talking to Boeing as to

this is how we want this done. And that's forcing

common standardized processes on all the sub-

suppliers and sub-vendors. Maybe if it comes through

the hospital side, on the back-end infrastructure or

anything like that, maybe that'll also foster some

kind of commonized standards.

UNIDENTIFIED SPEAKER: Well, the FDA

doesn't regulate that. It's the practice of

medicine.

MR. MADDALI: I realize. I know the FDA --

that's just a quick off-the-cuff.

MR. ROBKIN: There wasn't anything as close

to what you're talking about. The proposed MDDS rule

came out from the FDA, which touches on some of those

topics.

Rick, you had a question?

MR. SCHRENKER: Yeah. Tim, the first

thing, I thought that you hit a lot of nails right on

the head from a provider standpoint and from an

engineering perspective. I found the statement going

beyond 80001 sort of interesting, and do you -- are

you willing to -- do you have any ideas on expansion

beyond risk management that you'd be willing to

(410) 974-0947

198


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

mention?

MR. GEE: Yeah. I just finished a project

for a hospital, creating a framework of standard

operating procedures and control documents that -- to

provide the framework for dealing with multiple

medical device systems on their shared network

infrastructure and EMR integration and all of that.

And when I was done and looked back it, it's almost a

mini QSR for hospitals.

You know, you come up with your goals or

your intended use, and you do a risk analysis like in

80001, as it's currently drafted, and you go ahead

and implement and test that, which isn't an 80001 but

could be in, you know, 80001-2012. And then you have

the sustaining engineering piece, where you track

those things as they change over time and manage

that.

UNIDENTIFIED SPEAKER: It's called

corrective and preventive action.

MR. ROBKIN: Okay.

UNIDENTIFIED SPEAKER: I have a question

from the telephone.

MR. ROBKIN: Go ahead.

UNIDENTIFIED SPEAKER: This is directed

toward Tim Gee. Brian Shoemaker wants to know what

(410) 974-0947

199


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

the possibility, at least for hospital network type

of situations, of establishing one or more physical

centers with actual network setups and various

devices for honest-to-gosh testing, certification of

devices in a hospital-type environment.

MR. GEE: One of the SOPs that I developed

dealt with creating a lab because you have to have a

test lab just like manufacturers do. If you're a

hospital and you have these systems on your network,

you have to have the facility to be able to test

those changes before you roll them out into

production. And actually that's one of the big

challenges because if you're an organization like

Kaiser, how do you take a little office somewhere and

create a lab that actually is a reasonable

representation of their huge enterprise network? But

it's clearly a requirement. You probably could speak

to that.

MR. McGRANE: Yeah. So we've done that.

Dr. Grey mentioned our Garfield Center, which is a

large building that we mocked up to look like a

regular clinic or a hospital floor, and there's

patient beds, there's telephones that they would

have, the whole room environment, the nurse call

stations. So we emulate that because we have -- you

(410) 974-0947

200


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

know, we definitely do not want to be taking these

new systems in the hospitals and, you know, road

testing them live and with real patients in real

settings.

So we've emulated it, and it actually comes

down to you can only go so far. At the end of the

day, you know, you can simulate as best you want, but

until you actually take it out and go into the real

hospital and do it, I mean, you're still going to

learn some lessons.

But we found that with this mockup

hospital, we're able to catch a lot of the stuff we

otherwise would've missed. You know, from a wireless

network, we can emulate not only a clinical setting

but the network they would be participating in. And

as the EKG things roll around, we can kind of learn

stuff about some of the challenges we come across.

MR. ROBKIN: Okay, I think we have time for

one or hopefully two more questions.

MR. ARMANDEL: Hello, I'm Dave Armandel

(ph.). One of the options that we have here, I

think, in the standards is, certainly on a network

like that, you can actually have some automated

tests. It's always looking at the network and always

looking at protocols, and so you can always make sure

(410) 974-0947

201


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

the device is working properly.

And so we can have it whether it be self-

tests, whether it be where it's running all the time,

the automated, in an automatic fashion. And clearly

that's not going to catch all escapes, but certainly

you can catch quite a few of the escapes in doing

that, as opposed to a system that once you deploy it,

you don't test it but every now and then. Okay, once

a year or once every six months. Just like we're

looking at. The tape is monitoring for individuals.

With healthcare, certainly in the hospital, you could

implement something similar.

MR. ROBKIN: Yeah, the challenge there

would be to have some sort of test or certification

that covers a significant portion of the risks

because what most enterprises do is they have some

little offices, a few tests for solving the last

problem, but nothing comprehensive.

MR. ARMANDEL: Well, I think that's what's

interesting here to me because I think we have an

opportunity to be starting to look at what needs to

be placed in devices, et cetera, to be on the

network -- easily, but certainly I don't know if the

scheme of that would actually help ensure that you

could do the testing. In other words, if you don't

(410) 974-0947

202


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

design the test then, okay, then -- test it. Then

you're clearly not going to have folks to make sure

it's --

MR. ROBKIN: One last question.

DR. BAKER: Yeah, listening to this

discussion, I thought I'd reflect that as part of the

empire of NHS Connecting for Health, we have a

network called the National Integration Center, which

definitely tests systems that wish to connect up to

the spine, the NHS spine, and that's what it's been

doing so far.

It's branched out into -- we now have

something that's called -- and that's more like for

the design and feeding back things, and it's looking

at them and is kicking it back. Then, like you

said -- however, it strikes me that there may well be

a development function there for that structure and

to do at least some of the communication processes

that have been discussed. And it would, however, be

leading into a whole new area, and I'm thinking we

can probably do this in a national way, but is it

possible to do it in the many scales below that?

MR. ROBKIN: Thank you. A good point.

We're going to take a break now. Come back in 10

minutes to the hour. If you're missing -- if you'd

(410) 974-0947

203


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

like a summary sheet with some issues to write down

or a summary of the upcoming presentations, they're

on the table here. So 20 minutes. Thank you.

(Off the record.)

(On the record.)

DR. GOLDMAN: Ladies and gentlemen, first

we have a warm hello to all of you out in web land.

I don't know what to say to web land. I don't know.

I don't know if there is a web land, but kind of

there's a TV land.

There is a sign-up sheet that was outside

and will be circulated for the ride share to return.

So you'll see it. It's pretty clear. You indicate

whether you have extra seats in your vehicle and/or

you indicate if you'd like to ride with someone, if

they have it, so -- and we'll see how that works out.

Again, there is a shuttle bus at five o'clock, but

we're not sure how long it will take for the

roundtrips for the shuttle bus, given the traffic,

and we thought we'd, you know, maximize the ride

sharing.

This next session is our Session Number 3,

Systems-of-Systems. As Brian says, you can say that

again.

UNIDENTIFIED SPEAKER: Say it again.

(410) 974-0947

204


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

DR. GOLDMAN: Systems-of-Systems.

UNIDENTIFIED SPEAKER: Loudly, so the

people outside can hear.

DR. GOLDMAN: No, I can't be that loud.

And in this session, we have three people on the

panel. We have Dr. Frank Block, who's going to talk

about systems-of-systems issues and will present a

scenario that will be the starting-off point for the

rest of the work. Then Dick Moberg will talk about

using standard communications protocols to implement

medical device plug-and-play. And George Samaras

will talk about wrangling the human element of

interoperability, defending against Reason's latent

flaws and Dekker's drift.

DR. SAMARAS: Thank you, Julian.

DR. GOLDMAN: And with that title we're

expecting a lot. I'm going to just take a moment,

and then I'm going to sit down and the panel's going

to run on its own for a while.

Dr. Block is from VCU. Dr. Block is an

anesthesiologist and also a world-renown technology

expert in monitoring and clinical technologies and

things of that sort. And Dick Moberg has been

working on medical devices for a long, long, long

time. We know each other a long time. Dick has been

(410) 974-0947

205


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

working on an implementation, a standards-based

implementation of IEEE 11073 classic, in his company

and on some research work under STTR, and it's been

really very helpful to have his perspective of

implementation.

And then George Samaras, I guess, this is

his old home. He used to work at the FDA and now

works to facilitate other companies' research and

activities in regulatory and other engineering areas.

I don't really understand a whole lot more about what

he does. It's all very mysterious to me. But with

that, let me hand it over to Frank to start with the

scenario.

DR. BLOCK: Thank you, Julian. My voice is

still trying to give out, so bear with me.

Everything's on the slides. So if you can't hear me,

it's actually okay. I think Julian actually covered

everything pretty well. I'm going to give you a

clinical vignette that has several issues tucked away

in it.

We have a burn patient in ICU Room 1. The

patient is connected to a multi-parameter monitor, or

MPM, that monitors blood pressure, EKG, pulse

oximetry, and so on. The patient is admitted to the

multi-parameter monitor with a name and medical

(410) 974-0947

206


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

record number, and the MPM is both connected to a

central monitoring station and also to several

bedside devices. Pretty typical ICU setup. The

bedside devices for this patient are a standalone

cardiac output monitor, an electronic bed scale, an

electronic urine output monitor, and an infusion pump

with a closed loop controller.

Everything is fine. The data from the MPM

and the beside devices are recorded and trended on

the MPM and also at the central station. In fact,

this system has been working very well for several

months. They've had a recent software upgrade, and

today the system worked fine for several hours and

then the caregiver noticed that the MPM has stopped

communicating with the bedside devices.

The infusion pump is continuing to infuse

at the most recent rate. The other bedside devices

are working, but they're just not talking to the MPM.

The old trend data are still available both at the

MPM and the central station.

So the caregiver tries to do a little

troubleshooting, and they turn the bedside devices

off and back on and they unplug and re-plug each

bedside device, and then they unplug all of the

bedside devices at the same time and plug them back

(410) 974-0947

207


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

in one at a time and it's still not working.

There's only one other MPM available in

this particular ICU that isn't connected to a

patient, and that's next door in ICU Room 2, and it

happens to be made by a different company. So the

caregiver moves the MPM from Room 2 to Room 1 and

connects it to the patient while the first MPM is

still connected. That's the way you do it so you

don't lose any monitoring.

And so they unplug all of the bedside

devices from the old MPM and connect it to the new

MPM, and now they're all working again. And now the

old MPM, just in time, has stopped working entirely;

it is completely dead. So the trends that were

available on the MPM are no longer there. They're

not on the new MPM. The old trend data from the

bedside devices is not reloaded onto the MPM.

So the caregiver tries to admit the patient

on the new MPM and gets an error message that says

that the patient is already admitted because, of

course, the patient was already admitted on the old

MPM and the normal procedure would be that you would

discharge the patient from the old MPM first, which

is a great idea except the old MPM is now completely

dead and there's no way to do that.

(410) 974-0947

208


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

Meanwhile, at the central station, the

central station still thinks that the new MPM is

located in ICU Room 2 and the patient data are being

displayed in the wrong location at the central. The

central station also thinks that all of the bedside

devices have been moved from ICU Room 1 to ICU Room 2

because they're now connected to the monitor that it

thinks is in Room 2. And of course that means that

they're no longer connected to the patient in Room 1.

So the nurse manager goes to the MPM to try

to configure its new location, and of course the

clever designers have determined that it won't take a

new location while a patient is connected to it. So

that doesn't work either. So the caregiver has an

idea. They use the admit function to enter a patient

with the same name and a different medical record

number, and now the system is happy, and now the data

are being trended, but the central station, of

course, thinks that there are two patients. And the

old trend data on the central station cannot be

downloaded to the new MPM, and the hospital medical

records office will soon be screaming as soon as they

figure out what they have done.

So here is a rather chaotic scenario that

has dozens of issues that are contained in it. I

(410) 974-0947

209


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

wish I could tell you that this wasn't a pretty true

scenario, but unfortunately it is all too true. And

the next presentations will focus on just a couple of

these issues, and I hope we'll have some time in some

of the later discussion periods to talk about some

more of the issues. Thank you very much.

(Applause.)

MR. MOBERG: So my job was to look through

Frank's scenario, and when we first talked, I was

supposed to go over the engineering issues and tell

everybody in eight minutes how we're going to solve

them, and obviously I didn't get very far. So let's

go back through a couple of these things. So here we

are, if you remember the scenario. So we've gotten

one. There's another one in a different room, made

by another company, right? And then we unplug all of

the devices. We connect them all to the new MPM made

by another manufacturer, and they're now all working

again. Well, that's as far as I got because, wow,

how did that happen? You know, it's like we've been

working for 10 years to make this happen.

(Laughter.)

MR. MOBERG: And it wasn't even a problem

for Frank.

(Laughter.)

(410) 974-0947

210


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

MR. MOBERG: So actually what we're doing

is really trying to make this work, and so I wanted

to focus a little on that and, you know, tell you of

the laundry list of problems that we found just

making this happen. I didn't get anywhere else in

your scenario.

So what we're trying to do then is, you

know, let's say on the right is this multi-parameter

monitor and we have -- and I work in the neuro area,

so these devices are going to be more neuro oriented.

So on the left we have two devices that we want to

plug in here, and the idea is that we want to take

those same devices and plug them into another multi-

parameter monitor made by another manufacturer.

Well, right now we have to do that with proprietary

drivers, and there a lot of companies in here

working, including ourselves, making drivers for all

of these different devices so they'll all plug into

our specific sort of data collection and multi-

parameter monitors, as Frank said. So obviously, you

know, that's sort of tedious, and this is just the

procedure we go through at our company for a new

device to be added.

And we're an FDA-regulated company, so we

started doing a device definition document. We

(410) 974-0947

211


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

negotiate with the manufacturer to get their

protocol. You know, you can see all the steps down

there. We write a driver. We then try to beg,

borrow, or steal a device to test it and all this

stuff.

These are the particular areas in red here

that are very specific to our device. So every

device we interface, we're doing some stuff that's

sort of standards oriented, some stuff that by

definition has to be specific to our data collection

system, the way we display it and all that.

Well, what we would like to do is get away

from all of this, and this is sort of what's going to

open up this -- and I'm preaching to the choir here

to some extent, but what we need then is a standard

protocol of the device and sort of standard receiver

on the receiving end, and then the plug-and-play

works, right? But as we all know, these are legacy

devices, so we need adapters in there that translate

the legacy protocol into the standard protocol and

then this will work.

So what I want to do is show you -- here's

what we've been doing. So we make a product, the one

thing on the right, and basically you could think of

it as, you know, most vital signs monitors now do

(410) 974-0947

212


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

hemodynamics, and they work from the neck down.

Well, we're just basically using the same concept but

from the neck up, and that feels about 30 years

behind hemodynamic monitoring because everything is

in little discrete boxes all over the ICU. None of

them talk to each other. They all need to be sucked

into a central sort of display, and that's sort of

what we do. So this device just came out.

But what we're trying to do now is, you

know, we hooked up with Julian after many years of

knowing him, but then got involved with ICE about

three or four years ago and got some funding from

TATRC and a little bit from the NIH. So we're taking

our propriety device, and we're migrating it into --

we're taking the components out and migrating it into

an ICE-based system, and we're learning a lot in the

process, and that's what I wanted to share a little

bit with you.

So we're building adapters to hook the

devices in. We're building sort of a data aggregator

for the network controller and adding functions like

decision support and stuff on the supervisors. So

here are the adapters. We're looking at -- I took

the 11073, and we're coming up with some designs for

these. We prototyped them, and you can see what's

(410) 974-0947

213


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

sort of attached up at the top there.

This is a demonstration we did at TATRC

last summer, where on the left you can see our -- we

actually took three devices, and we hooked them

together and made little adapters and they were

all -- so that's a little adapter right there, and

then they all go over here, and all the data from

these devices are all, you know, talking 11073 and

display over here on one device, right? And I don't

know who that guy on the right would be.

I just want to go through a few issues. I

just have three issues. One is that we found out is

that -- is we concluded that compliance to the

standard does not guarantee consistency of

implementation. So in 11073, there's a lot of room

for wiggle in there. There's scanner objects.

There's these object IDs and private object IDs and

all this stuff. And unless company one and company

two deal with those the same way, you know, they're

doing this, you have some -- you could have some

potential problems there with sending the data over.

So compliance to sort of the standard of how we all

implement that is one of the issues.

The other one that's come up in our field

is time synchronization. So we have to get all of

(410) 974-0947

214


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

this data together time-synchronized. Now 11073

handles that actually quite nicely. But in neuro,

there are a couple of examples where you really need

to synchronize things very tightly, and one of the

issues is looking at bringing out a regulation, and

there's a lot of research work going on by just

looking at things like mean or total pressure and ICP

and closely synchronizing those, but they have to be

synchronized tightly, and what we need is a way to

send that, the accuracy of this synchronization,

over. So how granular is your data is another thing.

And then another thing is if we are -- one

of the things that actually, I think, Julian turned

me on with part of the ICE thing is instead -- we

also, in addition to getting data over, we would also

like to be able to manage devices, right? So if

we're going to get all of this data in one place, why

not, you know, give something to the biomeds to be

able to go back and find out what version of software

was used to collect that data from that patient for

quality issues and things like that, and where is

that device?

So we would like to be able to put sort of

metadata from the devices on these -- you know, on

these adapters, tie that adapter to a specific

(410) 974-0947

215


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

device, and then send that over along -- you know,

along with our sort of, you know, data collection

thing. That assumes that this adapter is always

going to be associated with this device, right?

And so the whole device association thing

comes up with our adapter. So how do we build

something into the adapter that allows us to

associate it with a particular device and a

particular software version? That's a tough problem.

We haven't really figured it out yet. We're waiting

for the FDA's unique device identifier to come out,

and I might be dead before that, but I'm not sure.

I'm trying to hold on.

(Laughter.)

MR. MOBERG: So that's another thing that

we've -- and it actually goes back to some of Frank's

scenario of being able to associate devices with

rooms and all of that. So it's a very similar

problem.

So just to keep this short, I just have

some suggestions. One is, in the exercises we've

done, it seems to me that we probably are going to --

we're going to need a lot more than a standard and

probably we've come to have something like an ICE

best practices. So if you're going to implement

(410) 974-0947

216


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

this, it might be good to have some guidance from

that and also guidance from maybe professional

organizations, FDA and so forth.

And then the second part of that is we

probably want to have some way to do third-party

testing of either adapters or the communications and

all of that. And it's been nice at this meeting.

I've met some of the people from NIST, and I think

they're doing a great job of developing some testing

tools and everything and then probably have those

third-party agencies that manufacturers go to to test

their devices. So I think something like that might

work. And that's all I have to say. Thank you.

(Applause.)

DR. SAMARAS: I'm going to try to follow on

with Frank's vignette. I'm going to take a small

piece of it. The scenario is fictitious, but what

actually happened is not a fiction; it's just been

masked. If any of you in the room actually recognize

what I'm talking about, please don't blurt it out.

But basically the cascade of events actually

occurred, and this is just to illustrate the problem.

The clinical scenario is that we have a patient being

infused for volume management. He's a burn patient.

We have some programmable intelligence. We have some

(410) 974-0947

217


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

sensors, some Ringer saline going in. And this

system of systems actually worked fine, and then it

didn't, and it was not readily obvious why it didn't.

Here's kind of a diagram of the case

scenario. We have both the regulator, the healthcare

facility, and the two manufacturers. Manufacturer

Number 1, or N, actually built the infusing device

and one of the inputs -- this is not actually what

happened, but I'm trying to translate into what --

into a similar set of circumstances. One of the

inputs was not guarded. However, the manufacturer of

the programmed intelligence had guarded both their

inputs and outputs and therefore there was no obvious

problem. The latent flaw that was caused -- that

existed in this system didn't show up.

UNIDENTIFIED SPEAKER: George, use the

mouse to move around because the folks on this side

can't see your pointer.

DR. SAMARAS: Oh, I'm sorry, I'm sorry.

Okay. So the folks at the FDA reviewed both of these

systems, and they cleared them, as you would expect

they would, and the initial user at the healthcare

facility tried out the system. You had to put all

the pieces together and it worked fine.

And what we don't show in here, though --

(410) 974-0947

218


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

Frank tipped our hand here -- is that between this

point in here, a remote software upgrade was sent to

one of the two units, actually to the programmed

intelligence unit. And in that instance this new

employee at Manufacturer N missed guarding one of his

outputs because it wasn't in the requirements. It

wasn't spelled out as part of a requirement.

And so a new clinician comes along -- I've

lost my mouse -- and this last user sets it up and

sets up a set of parameters in such a way that it

hadn't been used that way before and the system

failed. And as Frank kind of implied, they turned it

off, they turned it back on again, they played games

with it, and it wasn't obvious what had happened.

And by the way, during the same time,

the -- I'm sorry. Let me back up here. The

inspectors at the district office had also inspected

both of these manufacturers, and they both found --

they were found that they were compliant and no real

problems.

So before I tell you more details about

what actually occurred and why it occurred, who do we

blame? If we blame the reviewers, you can watch

administrative clearances grind to a halt. The

inspectors are not trained or resourced to detect

(410) 974-0947

219


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

what it is that we're going to ultimately understand.

The initial user, they put it together and it worked

just fine. The last user, as far as we understand,

they used it per the various manufacturers'

instructions. Manufacturer N, maybe, maybe not.

Manufacturer M, the first engineer did everything

right. The second engineer did what he thought was

correct, did his job the way he understood it.

The point that I want to make is that this

is and will always be a systemic failure. The

component failures, the particular incidents that

happened or what device actually failed, they're

merely symptoms, and until you deal with the

underlying disease, you will not be able to get the

rid of the symptoms.

Okay, let's talk about a couple of human

factors issues that will lead us to why I believe it

happened. First of all, there are two types of

errors that humans make. There are user errors,

where the locus of control is the actually healthcare

provider, the user, the engineer, whatever, and those

have to do with expertise, memory, workload, and

behavior.

But then there's another category of errors

that are called use errors, and there the locus of

(410) 974-0947

220


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

control is not the individual using the device on a

system but in fact is the way the system was

configured and developed. And this kind of looks

like the quality system regulation because it is.

Management controls, risk management, design

controls, document record and change controls impact

how the device is actually physically realized and

how it then interacts with the user. The user not

only interacts with the device but the device

interacts with the user.

There are two classes of errors that

developers or manufacturers can make. There are

propagated errors, and those are, you know, you make

a mistake in a needs analysis. You then have a hole

in your design requirements. You then have a hole in

your specification, your design specifications. You

realize the device. Physically you make it, in other

words. And you've got a problem, but you can detect

that problem with engineering validation. Compounded

errors are a different problem, and they actually

show the limitations of engineering validation, which

doesn't get talked about much.

The first kind are after James Reason --

he's a professor at Manchester University, I guess is

where it is. He wrote a book in 1990 called Human

(410) 974-0947

221


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

Error. And basically what happens is he pointed out

that you can make a mistake in your needs analysis,

miss a design input, a requirement, and not notice it

because you always do your specifications a certain

way and so it masks it.

As a result, this green arrow down here is

what we call a latent flaw and will not appear until

there is a change in the specifications for some

unknown reason. You know, you buy a part from

another supplier, you have an engineer that makes a

change because he knows this is a better way to do

it, and all of a sudden this latent flaw unexpectedly

and suddenly becomes an unanticipated failure.

The second type is after Sidney Dekker and

he wrote an interesting book -- and I have the

references on my last slide -- called Ten Questions

About Human Error. And in this case it's like the

latent flaw but it propagates through to the

specifications, and then because of the way we build

stuff, we routinely manufacture stuff, it gets masked

and then it doesn't show up for quite a long time.

And he is in the aerospace and aeronautics

business of human error, so he was talking about how

variations in maintenance of an aircraft led to

basically it crashing and killing a whole bunch of

(410) 974-0947

222


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

people. But the concept is generalizable to any kind

of engineering system.

Now, I would argue that the reason that the

two manufacturers ran into this problem, which was

then recognized or landed on the healthcare provider,

is that they had two disjoint development lifecycles,

which are iterative. This is basically an example of

classic systems engineering done in the '20s, '30s,

one of the first agile methods. Actually, it's not

generally recognized that way. But what happens is,

rather than following a waterfall procedure, the most

effective way is to keep cycling through these.

And you saw at the beginning of that little

use case study that in fact both manufacturers kept

doing stuff, but they weren't interconnected. As a

result, because there were missed design inputs,

because there were defective or missing design

inputs, they propagated through to create a problem

when the device was released.

Now, I'd like to offer an opinion as to why

I think design controls, which are central to the

quality system regulation, not only didn't work but

cannot work. What happens is verifications occur.

You know, we get our marketing folks and human

factors folks to go out and identify who the

(410) 974-0947

223


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

stakeholders are and what their needs, wants, and

desires are, and from those we select a subset that

are economically and technically feasible, and that's

what we put into our box. And so those are the

requirements for the box.

And then the engineers take the

requirements, and their work product are the

specifications, the design outputs. And then the

manufacturing folks build those or prototype them,

and then they get -- at each step of the way we're

verifying that the specs match up to the

requirements, the requirements seem to match up to

the stakeholder needs, and then we finally do a

validation.

But we are validating against the design

inputs, against the requirements. If your

requirements are defective, if you did not properly

translate -- identify your stakeholders and properly

translate their needs, wants, and desires, there's no

way that you can get the correct set of requirements

and there's no method -- this is actually a diagram

of the quality system regulation and design control

regulation, 21 C.F.R. 820.30. There is no way that

you can figure out that you are missing a stakeholder

through validation or through verification.

(410) 974-0947

224


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

So the argument that I would make to you is

that the armamentarium that we have now works in

certain cases, but as we start to put together

multiple systems into larger integrated systems, we

are going to run into a new set of problems that are

going to need a new approach to dealing with it, both

within the company that's doing the development as

well as within the regulatory bodies.

So from my perspective, here is the

challenge. The failure loci -- was that one or two?

Or am I dumb? Two. Good. The failure loci were

people doing their jobs as they understood them. The

failure cause, as I read it, or defective design

inputs resulting in latent failures and drift, the

root causes were that lifecycle management, in other

words, from lust to dust, all the way until the user

facility throws the device into the can, that's the

full lifecycle. And if we back up here -- no, I

don't have it on that, actually. Forgive me. And

the regulatory emphasis was on marketing and

manufacturing, which from a precedent perspective,

that's fine. That's what the FDA has always done.

So the conundrum is everybody did their

job, but risk management, risk assessment, and

verification and validation weren't up to the job for

(410) 974-0947

225


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

catching it because both manufacturers did their jobs

correctly, did those procedures. The regulatory

challenge is that when you increase system

complexity, which will happen when you start having

interoperable devices because what is complexity but

merely more components, more pieces to interact with

each other and therefore to give you unanticipated or

unexpected behaviors, you're going to get an

increasing number of failures and a lot of bad PR.

My suggestion is that the regulator

consider shifting their emphasis from marketing and

manufacturing to lifecycle management. The reason I

say that is, for the most part, I mean, we do have

outliers in the industry, and we do have newbies

coming in, new firms, startups, but for the most

part, industry is mature. They know how to do all

the basic stuff, and they do it well.

For the regulators, it's a little more

difficult because regulating marketing and

manufacturing is easy. They've been doing it for the

past what, 20 years or whatever it's been since the

Bureau of Medical Devices was created. But lifecycle

management is a much more difficult problem.

The second possible solution -- and I think

these kind of need to be considered in concert -- is

(410) 974-0947

226


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

greater vigilance by medical device manufacturers

that are building interoperable devices, to worry

about what are latent flaws, what are drift, who are

our stakeholders? Now, our stakeholders are not only

the people that we're selling to, the people that

maintain the equipment, but also all those people

that we're going to have interface to.

And finally we need to improve the

understanding of the users, both physicians,

managers, engineers, and regulators, of complex

system failures, that is, not just one-point

failures, and also that there is a human factors

component that is of critical concern for each and

every one of the stakeholders. And here are those

recommending readings, James Reason, Sidney Dekker,

and Dismukes et al., which is an issue on limits of

expertise. Thank you.

(Applause.)

DR. GOLDMAN: Well, that was wonderful.

Let's open up the mike to questions. I've saved a

few for emergency reasons only. We'll see what comes

in from the audience. And who will tell us if

there's any web questions coming in? I'll guess

we'll find out.

MR. MURRAY: I spent about four years

(410) 974-0947

227


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

riding around in a submarine, and everything we did

and every system we owned had at least four levels of

backup. You started out with remote operation. If

that didn't work, you ran to the local switch. If

that didn't work, you ran right to the valve itself.

You needed to do it with hydraulic oil or compressed

air. And if all else failed, you took out your

wrench and operated the valve that way.

So my question is, I mean, is there

anything in this discussion about what kind of backup

systems do we put in place when we convert everything

to a computer-based society and it fails? Is that

involved with the risk management in this process?

In other words, do we put a backup system in place?

How do we address that? Because it seems to me, when

these systems go down, there's going to be no patient

treatment hand-delivered.

DR. SAMARAS: For the scenario that I gave

you, I think the problem was that your spanner didn't

open wide enough to turn the valve manually. And

that's where you got stuck.

MR. MURRAY: I mean, why don't they just go

in there and write the readings down manually instead

of relying on the remote?

DR. SAMARAS: At 60 beats per minute, do

(410) 974-0947

228


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

you mean?

DR. GOLDMAN: Frank, do you have --

DR. BLOCK: Well, I think we missed already

with the electronic medical records. We've beaten

our medical staff and many of them use these -- and

now when they go down, and they do go down, nobody

knows what to do. And so to think that people are

having trouble doing the normal procedures and

miraculously they're going to be able to perform some

sort of emergency backup procedures, I actually don't

have much hope for that, I'm sorry.

DR. SAMARAS: If they were under water and

were about to drown, they'd figure something out, but

they're not.

DR. GOLDMAN: So Tim? Tim Gee?

MR. GEE: Yeah, I'd like to ask the panel

of the kinds of issues that we run into every day,

what percentage of those are a result of just poor or

inadequate design and which -- and how much of it is

a result of just an insufficient regulatory

framework, as you suggested.

DR. GOLDMAN: Are those mutually exclusive?

MR. GEE: No.

DR. GOLDMAN: Okay.

DR. SAMARAS: In my experience, I've not

(410) 974-0947

229


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

run into poor or inadequate design or inadequate

regulation. If anything, I think we regulate too

much in areas that we don't need to regulate, and not

enough. My perspective is, is that you have

engineers who have a specific duty and a specific set

of training solving the wrong problems. And if you

can't give them -- pose for them the correct problem,

then why would you expect them to come up with the

correct solution?

DR. GOLDMAN: Frank?

DR. BLOCK: Well, I think there are some

significant design problems, the main one of which is

failure to understand the environment it will be used

in and the way the people will use it. And it may or

may not be what you had in mind. There's no

substitute for spending an unbelievable amount of

time in the clinical environment and seeing how

people are really using your equipment.

DR. GOLDMAN: So let me go through my

experience two weekends ago on call in the hospital.

I was working in some ORs and I heard -- I was too

busy, but I heard that on the same day in another OR,

they were unable to get the electronic medical record

to work. So they were using paper, a paper record,

which was amusing because it's been about six years

(410) 974-0947

230


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

since we've used paper in our institution and people

don't know how to use paper. We need a manual to use

paper. So there's a record missing all sorts of

data.

But I went into that room at 5:00 or

6:00 p.m. and, you know, I had a chance to hear more

about it and they told me that the touch screen input

wouldn't work, so they couldn't manually enter the

data that isn't acquired automatically, the non-

physiologic data couldn't be entered.

So I just took a quick look behind the

anesthesia machine, and I saw a coil of wire, a cable

that was underneath a wheel, and I saw that it was --

you know, because it was pulling on something, I

noticed that there was a connector that was partially

out, a USB connector halfway out on the back of the

anesthesia -- on the PC that's on the side of the

anesthesia machine, the PC that's used to host the

EMR.

And, of course, as you would expect, that

was the equivalent of the mouse input, which is what

the front of a touch screen uses. A touch screen has

a video input, and it has a mouse equivalent for the

touch screen, and that was partially out. And, you

know, people were too busy, busy with that patient's

(410) 974-0947

231


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

care and also weren't comfortable with the system to

look and see. So they had an entire day of a record

that's really missing a lot of data.

If this happened 10 years ago, it would've

been a more complete record, but now we've become

dependent upon -- on the electronic system, so people

are no longer adept at maintaining a paper record in

real time because it's actually -- it's a unique

skill. And so I looked at that and, anyway, it

was -- you know, once someone had the time to look at

it, it was a fairly trivial fix.

And I wonder, based upon the discussion we

just had, is the problem regulation? Is the problem

incorrect use of technology, connectors that, you

know, don't stay? There's no way to fasten that USB

connector in place. Is it the use of the incorrect

technology in the wrong environment? Or is it just

something that we have to live with? In any event,

it's a real problem.

At another time in another operating room,

I noticed the surgeon lost the video image in the

middle a laparoscopic procedure, and that was quite a

problem because everything goes dark. They have

sharp instruments in the patient's abdomen, and if

the patient starts to bleed, they can't see that the

(410) 974-0947

232


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

bleeding has started, and they can't stop it rapidly.

So when they get an image again, it may be too late

to stop the bleeding because they can't see -- they

can no longer see. So they would have to convert

from laparoscopic to an open procedure.

And what happened, in fact, was the same

thing, an analogous thing, a USB connector slipped

off the back of a PC that was inside a mobile case,

and it took someone who knew the system very well to

quickly run into the OR, and he knew exactly where to

look and he addressed it.

So I'd like to toss that out, those

scenarios, out to the panel and say, well, what's the

category? What should we do about it?

MR. ZAKIAN: I have an answer for that.

DR. GOLDMAN: An answer comes from -- yes.

MR. ZAKIAN: It's very interesting that, in

the healthcare environment, we're always monitoring

patients but we never monitor our systems to that

degree. And that's where the failures are. The

failures are in not having systems that are being

monitored and self-healing systems and the quality of

that system.

For instance, you know, a USB cable, a USB

connector coming off a PC, if you had a proper

(410) 974-0947

233


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

monitor looking at that PC and what that PC was

doing, it would tell you on the screen that your USB

port -- your USB connector is disconnected.

Or, in the same token, it should be able to

tell you whether the data that's going out to the EMR

is going out or not. And that's what really lacks

here. It's a monitoring of the systems that are

monitoring the patient.

DR. GOLDMAN: So part of it is system

health or system diagnostics.

MR. ZAKIAN: Absolutely.

DR. GOLDMAN: But part of it is should we

be using connectors like that for systems like this?

Are they appropriate?

DR. SAMARAS: If that was on John's

submarine, it would have a lock on it so that it

couldn't fall off. The problem is nobody asked for

the lock the way the military does. On the other

hand, the cost of everything -- if you've done

anything for the military, as I have, the cost

skyrockets.

DR. GOLDMAN: It doesn't have to be

titanium for a USB connector.

MR. MOBERG: So part of this -- so I think

Vaughan's point is correct, and I think John's point

(410) 974-0947

234


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

is a correct one as well. Twenty years ago, before I

had my life change and went into the medicine, I was

in the defense arena and we were doing design

relative to anything, you name it, military. We

involved captains, corpsmen, et cetera, in the

process of design. So they were involved in

essentially designing the use cases and actually in

designing the designs. So they actually were

involved in the actually detailed drawings and

designs of the systems.

It seems to me, what you're all speaking to

a degree is involvement in the clinical trials,

involvement of clinicians of all sorts, respiratory

therapy, nursing, et cetera, both in the use cases

and in the actually design of the technology and how

it's actually used as well. I don't think it

would've picked up Julian's specific case, but I

think Vaughan's point would have.

And I see sort of a dichotomy, a difference

here between the way we treat the design of --

although we do engage in clinical trials, in the

process of actually doing the designs themselves and

involving the clinicians at the point of care and the

process of actually looking under the hood at the

architectural drawings in doing a systems-of-systems

(410) 974-0947

235


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

architecture.

DR. SAMARAS: I have run into so many of my

clients who have -- my clients' engineers who have

said I'm constrained from changing what I built. I

have to build to the requirements that I'm given.

And if I don't build to those requirements, I'm going

to get in trouble. And if it's not in there, I don't

do it. Even if I think it's a smart idea, I may

suggest it, but by the time it goes all the way up

the chain and all the way back down, it's too late.

So I think the problem we have is we're so

used to dealing at the manufacturing and marketing

end of the stick that -- which is the blunt part.

Unfortunately there's another sharp end of the stick.

It's not when it goes to the doc, it's also when it's

poking the engineers who are trying to figure out

what they're supposed to do.

DR. GOLDMAN: Frank. And we have one more

question, then we have to stop.

DR. BLOCK: Yeah, I just wanted to mention

Charles Perrow's book Normal Accidents. I expect a

lot of you are familiar with that. He looks at

shipping disasters, Three Mile Island, the space

shuttle, and so on, and his basic thesis is that if

you have a system that is, number one, complex and,

(410) 974-0947

236


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

number two, tightly coupled, that accidents should

not really be considered accidents; they're basically

normal.

Just for a perspective, the human body and

the physiology of the human body and everyone sitting

in this room, just resting in your chair, not

connected to any medical devices, is incredibly

complex and incredibly tightly coupled. And even in

a very simple world of medicine, as soon as we start

doing things to that, it gets even more complex and

more tightly coupled, and as we get more and more

advanced technology and systems and interfaces and so

on, it's not getting simpler, it's not getting less

tightly coupled, it's going the other way.

UNIDENTIFIED SPEAKER: I just have a quick

question. The one thing that we've started to

concerns ourselves with, I guess, is addressing the

black box and making sure that the device you're

talking to or the system you're talking to is the one

you expect to be getting data from. We've been

focusing a lot on the data itself, but as things from

outside the hospital, outside the firewall, you can

start considering yourself really with the widget

itself that's actually taking the data. So in other

words, either the data comes over -- well, is the box

(410) 974-0947

237


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

you're actually talking to the one you expect? Do

you expect that to be an issue going forward?

DR. BLOCK: Well, I mean, there's no

substitute for an adequate front end, but I will

emphasize, for instance, when I talked about

automatic recordkeeping, the ability to hook these

devices up to your EMR, I always emphasize that all

of these devices that are recording the data, they do

not record patient data. That is a myth. They do

not record patient data. They record monitor data

and device data. Those data may be right, those data

may be wrong.

In that sense, it's just like a video

camera pointing at the box, and it records the

numbers that you saw. And so you need to have that

healthy skepticism as to whether the numbers coming

out of the box are right or wrong, and if they are

wrong, how do you get into mischief when they are

wrong?

DR. GOLDMAN: Thank you. I think that was

the last question, but we have one from the ether.

UNIDENTIFIED SPEAKER: Yes, from

Brian Shoemaker. How often do system/equipment

designers actually have their engineers, not just the

marketing mavens, spend time directly at a hospital

(410) 974-0947

238


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

or clinic watching doctors and nurses use their

systems?

DR. BLOCK: Well, about 25 years ago, an

anesthesia machine company, which is no longer in

business, told us that none of their engineers had

ever been in an operating room when a case was going

on. And these were people who were designing our

anesthesia machines. So it gets better today, and

the FDA says it has to be better today, but I think

there's always an opportunity to do more.

DR. GOLDMAN: Yeah, I think the short

answer is not often enough. They're welcome. We're

eager to have them experience the joys of patient

care so that we can remind them of how -- well, how

what's easy to diagnose in terms of a USB connector

being part way out of the back of the computer is

trivial in your office, in fact, goes undiagnosed all

day long when people are under pressure to care for a

critically ill patient, which was indeed that case.

And they're not necessarily comfortable with the

electronics that they might face.

And that's the reality. Simple things like

that are actually too complex to be dealt with by

people under that kind of pressure, who then are

afraid they'll get in trouble for breaking something

(410) 974-0947

239


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

if they touch it. The same getting in trouble

concept they talk about in engineering.

So thank you very much to the panel and to

the audience.

(Applause.)

MR. THOMPSON: While we're loading the

presentation -- it should be done in just a second

here -- this session deals with mass

interoperability. I'm not really sure what the hell

that means, but we're going to be talking about

things like mobile health and wireless health. And

we've got some interesting use cases lined up. Our

first presentation will be by Praduman Jain,

sometimes also referred to as P.J., who's the CEO of

Vignet, Inc. He's going to talk about mobile health.

MR. JAIN: Good afternoon. My name is

P.J., and I'm the founder and CEO of a company called

Vignet, Inc., and we are in the business of providing

a mobile platform for connected health. We've been

looking at this space for a while and have some

thoughts to share.

So industry has been focused a lot on

looking at connected health, and in various studies

there's a lot of discussion of connected health

reducing costs and improving the quality of care and

(410) 974-0947

240


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

that the traditional methods of healthcare have been

augmented by a lot of newer technologies, remote

patient monitoring, telehealth. A lot of wireless

and mobile solutions are also coming into this. So

clearly these are all new grounds, new areas, and you

know, from the perspective of patient care, obviously

ensuring safety is paramount in the delivery of care.

I want to go back a little bit and look at

the history. So we are talking about mobile phone.

As you look on the left here, this -- he was pretty

happy with his mobile phone. He was able to make a

phone call. The first wave of that was voice only,

right? We would just be able to talk remotely. The

next wave in these types of phones, we all know about

the stub antenna and the black-and-white phones, but

we were very pleased because now we could do voice

and data, voice and SMS. We could send messages,

right? The third wave came around and probably in

the audience all of us carry a third-wave device

today, where we do voice, messaging, and data

applications.

So if you look at the continuum of time

here, we've been embracing mobile and more and more

functionality today. You know, go around the list of

new applications. We do mobile banking, mobile

(410) 974-0947

241


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

wallet. We do a lot of location-based services. So

mobile has been doing a lot, and we've embraced it.

The question is what's next, right?

People are going to do what they're going

to do, and people are going to use them for a variety

of healthcare applications, call them medical, call

them fitness, call them any of these applications.

So we came up with a couple of use cases just working

within the industry, and these are the things that

industry's talking about.

This is a use case where the mobile device

is used as a conduit. So you have a medical device,

a pulse oximeter, a weight scale, what have you, and

mobile is just a conduit. It receives the data,

sends it into an electronic medical record, personal

health record. That's the role of the mobile. The

question is what should happen from a regulatory

perspective for a situation like this pure conduit?

The next use case is the mobile is a

conduit, still just like the use case before. The

internet, the web, the server in the cloud, whatever

terminology we want to use, that internet is now

processing the data. So looking at all of the data,

and are there any alarms, alerts? And it's sending

the data back to the mobile for primarily display

(410) 974-0947

242


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

purposes. So mobile's role is only again a conduit

and a display mechanism.

In a third use case, where there is no role

of the web or the internet, mobile is doing all the

work here. It reads data from the medical device.

It stores it on the mobile. It checks for out of

range, and it provides alarms, alerts. All of the

processing is done by the mobile. So what's the role

of mobile, then?

And in this use case, the fourth use case,

mobile is doing all the work. In addition, it's also

receiving a lot of software updates from the

internet, from the web, and those updates are now

being downloaded to the medical device. So mobile is

again acting as a conduit for the software that's

being transmitted from the web to the medical device,

and mobile is a conduit. So these were all the

different use cases and scenarios that seemed

plausible.

We believe that the mobile phone can be an

attractive platform for the delivery of care. There

are four primary functions involved in delivery of

care. There's some sort of collection of data, there

is display of data, there is the processing of data,

and there are some software updates. There are

(410) 974-0947

243


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

things that a manufacturer would do to update a lot

of the systems.

So the mobile phones can be used for a

variety of applications, from education, just purely

health education purposes, to monitoring, to

diagnostic, to treatment, and it would be very

beneficial to have very collaborative, nimble, and

flexible pathways to ensure safe and effective

guidelines around mobile and the role of mobile and

how that should fit in in the delivery of care.

Thank you.

(Applause.)

MR. THOMPSON: Next up, we're going to have

Dr. Brigitte Piniewski, CMO of PeaceHealth Labs.

DR. PINIEWSKI: A slow start here. Hello,

Brigitte Piniewski with PeaceHealth Laboratories, and

I'm here to answer Brad's question, what is mass

interoperability about and how does that change our

responsibility as an FDA organization, as vendors, as

manufacturers, and as healthcare delivery systems?

And I just want to encourage the head-

nodders in the crowd, because I do better when

there's agreement with things I have to say, so

please feel free to head nod.

So the main point of this presentation is

(410) 974-0947

244


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

to really remind us -- one of the speakers this

morning said that we used to have the luxury of

having an idea, spending some time organizing it, and

by the time we were ready to deploy, everything was

still in place so that the relevance was still there

and what we had worked on was received effectively.

And with today's talk, I'd really like to focus on

how much the world has changed and how the

opportunity for looking at things differently is

really upon us now.

And just to set the context for this, the

value proposition for the FDA here is to support the

2010 national -- the nation's first health security

strategy. This strategy, put out by the HHS,

suggests that we would really like to share

responsibility between government, individuals,

communities, the responsibility for future health

expression. And so we'd like to learn how we can use

connectivity, mass connectivity, to provide

communities with a proactive community voice and

really use the power of the end of many to build

proactive resilience for communities. And we're

going to do that through maximizing this resolution

of pre-endpoint experience, and I'll give you an

example using a flu pandemic, such as H1N1. So from

(410) 974-0947

245


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

those of us on the ground, here's the view. We'd

like to frame this up so that we can discuss this as

we move forward.

Here is an ideal scenario where we have

wellness on the Y axis with peak wellness at the top,

deteriorating down to illness and death at the

bottom. And then the X axis shows us the ideal

scenario throughout the decades of our lives.

If, in fact, we could just have all of our

communities exist with something close to our peak

health potential throughout and then drop off rapidly

to death, then this would be optimized. However,

what we see as clinicians on the ground, our mission

at PeaceHealth is to be responsible stewards of

community and individual health, but we can't do it.

Every day we're reminded by our patients that this is

the sort of thing we're seeing: an earlier and

earlier encroachment of chronic disease expression in

the population.

In this room we probably have many of the

very last of the accidentally well. The traditional

medical system was the green line. We should all be

well until we are ill, and then medicine should be

introduced when we become unwell and return us back

to perfect health. But we're now in this age of

(410) 974-0947

246


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

chronic care management, which, when we get down to

the bottom -- oh, here, I should be using the arrow,

right -- when we get down to the bottom here, we're

no longer able to really return individuals back to

peak health. Eighty percent of what we do is chronic

care management.

And so what I'm suggesting is that in this

episode up here, in wellness, pre-illness, and

illness, we have this deteriorating ability to return

people back to health. And so the reversibility or

the fluid phase is decreasing as we move down. And

what we're really seeing with our children is this

rapid progression, in early age, into decreased

health expression.

So 60 to 80 percent across multiple

studies, across multiple locations on the globe, is

being suggested as preventable health. So our

population is not well until they are ill, and if we

invest all of our energy in understanding how to turn

the care paradigm, this bottom part of the page, into

a perfect experience, if we could make doctors,

patients, and devices perfect at all times, we would

still be sort of down here in this space and likely

just return the individual to perfect care but not be

able to return them to optimal health.

(410) 974-0947

247


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

And so one of the real challenges with

where we are today and the opportunity, as we'll

describe later, is that this system down here in

illness is all predicated on the requirement of

sufficient levels of pathology. We need sufficient

levels of pathology to be able to measure and

quantify whether we've effectively altered something.

And that has put us into the place of defined

clinical trials. But when we wait for sufficient

pathology, we lose the ability to return people to

health.

And so the whole point of mass

interconnectivity is, in this space above here where

there's insufficient pathology but where we can

connect in very, very, very many, we can start to

deliver practical truths, practical scientific truths

that will be of sufficient correctness to adjust the

choice architecture for our community and make them

safer at the end of the day. Then if we make this

area safe, flawless, and perfect, we will not have

protected our communities to experience the peak

health potential that they could have.

And I just remind all of us that a few

short decades ago, each of us were in a community

that had no ability to have Type 2 diabetes until you

(410) 974-0947

248


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

were in your fifth or sixth decade of life. That's a

health advantage that we neither deserved nor earned.

It was just there. And that environment does not

exist today for our children. In many communities

Type 2 diabetes is 50 percent of the pediatric

diabetes burden.

And so understanding how to use this mass

connectivity to let the community teach us what

really works effectively is an opportunity that

interconnectivity, such as Vignet, brings to us

today. And because it's available, we have a

responsibility to understand how to use it

effectively.

So not that everything is truncated with

mass boundaries, but I just wanted to highlight.

This is current regulatory environment. This is

where we've built the Cadillac of understanding very

high-risk environments, very important to get to the

right drug for the right person at the right time.

But above there, there's a learning

opportunity -- sorry. Above there, there's a

learning opportunity to build a model that the

community can teach us in a relatively low-risk

environment many of the things we're struggling with,

because the bottom part of the page here, this

(410) 974-0947

249


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

current regulatory environment, as we've heard over

and over again today, is infinitely complex. There's

so many moving pieces. There's IP involved. There's

this, there's that, there's the next thing. And so

understanding how to get it all right down here may

be a relatively insurmountable task. But up here,

where we have a relatively low-risk environment, we

can have the user environment start to teach us some

of the simple things in terms of how should they work

together and how do they bring us value.

So let's go to the example where we take a

pulse ox, because many of us are familiar with pulse

ox and the narrow intended use of pulse ox, you get

to use it in the ICU, in the OR suite, not so much in

the ambulatory setting, and it has a high competence

in this very narrow intended use. But let's build an

environment that we talked about for the upper use.

What is the use of pulse ox outside of this intended

use, and what would be the regulatory environment

that would allow the pulse ox to learn how to be used

in a community that is not part of this narrow

intended use?

So the plan is to identify not just the

wild west, where we just instrument everybody at all

times and hope something valuable comes out of it,

(410) 974-0947

250


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

but really a much more structured approach where we

identify the health outcome that we wish to target.

We check the medical literature and clinical

experience for avoidable contributors. Then we build

this mass interconnectivity and we accumulate data.

In the beginning we don't have any

predictive capacity. But as the data builds, we lift

to a place of sufficient correctness, and in just the

choice architecture, to respond to what we've learned

from the sufficient correctness. And then we repeat

the cycle.

So in an H1N1 world, where -- forget this

picture but remember the earlier picture -- we had

people coming along at peak health, dropping all the

way down to not just illness but also to death. We

had 14-year-olds last season that were perfectly well

but succumbed. The parents were unable to detect

when it was time to get this child into healthcare,

and stopping that deterioration of pulmonary function

wasn't possible in some cases.

And so the question becomes can we use

technology to sufficiently divide those who are going

to have complicated pulmonary course with the flu and

those who are not going to have a complicated course

with the flu? This is not a fixed intended use.

(410) 974-0947

251


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

It's a flexible intended use. We want to know, can

we find this out? So technology gets together in a

nimble and agile and quick environment, and in the

space of a weekend, almost -- I have high aspirations

for our technologists here -- they can build a patch

that will put together temperature, O2, and heart

rate. And let's deploy that across our flu season to

an end of many and start to watch the patterns to see

whether in fact we can pull from that very large

dataset an ability, a proactive ability to understand

who in our population may or may not be more likely

to experience a complicated flu versus a non-

complicated flu.

And so this gives us a way in which

communities can start to understand how to use

technology to proactively have some idea of what is

the anticipated ICU burden of this next flu epidemic.

And so rather than have a flu experience be

disseminated across a community and no information

taken, that experience gets delivered to a vacuum.

But in this environment, we understand that

this may be very clinically relevant information.

Let's make it low cost. Let's patch it. And then,

in the space of a flu season or two, we start to have

very important, sufficiently correct information

(410) 974-0947

252


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

about how do you separate those individuals, and we

can start to proactively understand what is the

suggested ICU burden of this next flu that we're

going to have by monitoring these sorts of markers in

the next season. And then we get better. Perhaps

the heart rate's not so good. Maybe we need heart

rate variability, and we should put that in instead.

So of course many benefits, many

challenges, but I think one of the deep and powerful

implications of mass interoperability is we have

access now to information that we didn't have before,

access to making sure that tomorrow's resilience,

community resilience, is not the same as yesterday's

resilience.

Use the community health experience to

teach us all that it can teach us about moving

towards greater and greater and greater resilience.

Don't allow community health experience to be

delivered to a vacuum. Provide it with a structure

in which that experience -- and I always say no

experience is too small -- can be organized and

analyzed to provide resilience the next go-around.

And this is Edna St. Vincent Millay. She

says it much better than I do because she's a poet.

So I'll just read it for you. In a nutshell, "Upon

(410) 974-0947

253


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

this gifted age, in its dark hour, rains from the sky

a meteoric shower of facts; they lie unquestioned,

uncombined. Wisdom enough to leech us of our ill is

daily spun; but there exists no loom to weave it into

fabric." And so I'm hopeful that the FDA and this

organization together can build that loom. Thank

you.

(Applause.)

MR. THOMPSON: Okay, next up, we have

Mike -- is it pronounced Paradis?

MR. PARADIS: Paradis.

MR. THOMPSON: Paradis. Wireless Sales

Manager, Dynastream Innovations.

MR. PARADIS: Yes. I think I'm the only

sales guy in the whole room, so I apologize in

advance.

UNIDENTIFIED SPEAKER: Sell us something.

UNIDENTIFIED SPEAKER: Make no mistake,

everybody's selling something.

MR. PARADIS: No, I understand. I don't

want to make this a sales pitch by any means. I

think, in the 30 years or so that I've been out

flogging semiconductor products, I've had to set a

lot people straight when they went down the wrong

path. So I'm going to try to do what I can to maybe

(410) 974-0947

254


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

start that path a little earlier for you.

Dynastream Innovations was the inventor and

creator of a protocol called ANT. It's the de facto

standard in the fitness world, so from accelerometer-

based technology, heart rate straps, things like

that. The ANT Plus Alliance, as you can see all on

my bling, I'm a proud Continua member. Thank you

very much for the opportunity. And I'm also a very

proud ANT Alliance member. We have an alliance of

200 and -- approximately 210 members.

So, anyways, what we're going to do this

time is talk about the simple do's and don'ts when

you're specifying a network. This is not the

technical specifications, but when you're making an

idea of what kind of data, how often you'll want to

have it, and what it should it look like, if you want

to live in an ultra low power environment, consumer

products, very low battery usage.

Okay. So the system do's, the thumbs up.

Those are the important things. The most important

part in this room, I think, and I've heard from

numerous people today and other times, is a shared

communication link. You don't want to have a problem

with giving your information to somebody that doesn't

want it or that you don't want to have it go to.

(410) 974-0947

255


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

So that's always from a wire. If you take

a wire away, you have the ability for other people to

get that data. So my suggestion and our suggestion

is to make that association scalable, not something

that's mandatory at the top level, but something

that's very, very simple. I know we heard about --

that preventing -- the 60 percent in there that's

preventable. That's the business that we're in.

We're in the business of keeping people fit and

exercising and taking away the potential of perhaps

having Type 2 diabetes, or at least helping that.

But that's a simple process. That's a

consumer product. It uses simple broadcast

methodology. Nothing really tight, no strong pairing

mechanisms. But you do need some very secure

communication authentication for treatments. Even

weight scale information has been deemed to be very

secure requirements. So make sure when you plan for

your products, or when you're making a specification

as part of the SIG group, that you allow for both.

Make a simple user interface. I picked

that picture because to me it epitomizes the angst

that people without technological interfaces in their

life all the time feel when they try to use something

that's been thrust upon them. So let's try to make

(410) 974-0947

256


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

it automatic. So try to think of those things when

you make this system integration decision.

Always look for extended battery life

wherever you possibly can because that's going to

make it easier. There's no charging mechanism that

you have to worry about and a complex user interface.

And then try to find multiple use cases that you can

put into one simple transport mechanism or some

methodology.

Consumer price points. Believe me, in the

30 years that I've been doing this, that's the target

every one of my customers has had. So it's not

really possible out there, but the closest to zero

wins typically. And we're going to try to deploy

these pieces of technology in a mode that the

consumer will want to use them. They're going to

want to get it awful close to that zero, rather than

trying, you know, to make it a very expensive

opportunity for them. So we need to keep the bill of

materials that these devices have as simple as

possible.

And our test and certification targets have

to be really kept at minimum. Every time you have to

test something or certify it and go through rounds

and rounds of that, it adds bottom-line dollars. A

(410) 974-0947

257


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

$10,000 addition to a process adds a dollar to each

10,000 piece device. So that dollar multiples into

10, perhaps, when it gets through a bunch of hands

before it gets to the consumer. So think about those

decisions when you're making that thing at the start.

And then it's hard to pick one technology

out of that. I have one, and I'm not throwing my

technology out as the winner by any means, but allow

for multiple technologies. There's technologies

today that are very, very strong and good, and

there's technologies that'll be coming tomorrow

that'll be 10 times better. So don't shoehorn us

into having only one specific technology required.

So PAN, again, this personal area network.

So that's that body-worn network that you see where,

you know, the fitness world has. Basically the

bottom cost goes down as you start to integrate the

devices. The innovators start at the bottom left-

hand corner, and as you get farther down the price

curve, you start to get adoption curves starting to

go up.

And if you think of Bluetooth as a great

example, when it hit the cell phone, it became a

dollar. Before that it was $8. So the fact that it

had lots of adoption, companies like CSR and Broadcom

(410) 974-0947

258


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

could take the features of a chipset or over a whole

board and put it into one device and then change that

device every cell phone year and, you know, making

hundreds and hundreds of millions of devices.

So there are some current technologies out

there in the PAN space, and you can see ours is on

there. This is not a sales pitch. It's as close to

reality as I can think because a lot of them are the

reality in other markets, but they're not the reality

in the personal space, where we've got about seven

million units now out in deployment, so we're kind of

up that adoption curve a little farther. So there's

lots of good technologies out there. Consider them.

They're all great.

Low battery consumption. I've heard from

the blood glucose market that a glucometer can't

operate on anything but a coin cell battery. It's

important to have that target in mind. That's what

the use case is. It's not that it can't operate on a

double AA battery or a chargeable lithium pack, but

the use case is it should operate on an inexpensive

consumer-replaceable device. It should.

So always try to keep that in your mind

every time you make a decision step, adding extra

amounts of data, adding extra authentication

(410) 974-0947

259


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

communication back and forth. That consumes power

and that doesn't allow you to live on a small battery

such as a coin cell.

And interoperability. Everybody's talked

about it today. That's a little indication of what

our ecosystem looks like. It's extremely

interoperable. We have 11 device profiles, Bluetooth

and Bluetooth Low Energy, ZigBee. A bunch of the

other standards have a got group of profiles also.

They demand interoperability. And we always say 100

percent interoperability is the minimum you should

count on. Never give into, yeah, it's almost

interoperable; if you do this it's interoperable.

So try to keep your interfaces as simple as

possible, and then target hardware implementation as

often as you can. The closer you get to the hardware

with an implementation of a protocol or a network,

the more reliable that interoperability is going to

be. So I hope I'm not losing anybody on the non-

technical side. I'm trying to keep it as slim as

possible.

So here are the don'ts. Again, the angry

smiley face. So wired systems historically have a

lot of data traveling across them. They can.

They're a wire. There's no limitation. There's no

(410) 974-0947

260


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

power consumption issues. So taking that historical

usage and trying to duplicate it in an ultra low

power wireless system is going to be virtually

impossible. If you want to live up to the do's that

we heard about, a coin cell battery, low bill

materials cost, the user interfaces, they've got to

be very simple.

And a sensor communication. Now, this may

not read extremely well, but if you think of a sensor

measuring some data to send a time of each time that

measurement was taken, and software revs and battery

life and all of that information across every

message, it's going to consume a hundred times more

power than you could in a very simple consumer-driven

kind of a product. So try to take that information

and put it in somewhere else in the system.

So this is a wireless watch. It takes the

day, date, and time that it's got, and it puts it

together with the heart rate information and it

stores it, and then when it gets close to a PC, it

uploads it to the PC. It's not sending that

information across from the heart strap every time.

And allowing manufacturer-specific file

structures, that's a challenge. You're not going to

get interoperability. Hardware-wise, you can, but if

(410) 974-0947

261


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

you have two files that don't look alike, they're not

going to interoperate. The health records are going

to be a problem. So don't allow that.

Over-complexity. You can see there,

there's a little bit too many locks on that bike.

That's over-security. I had one picture that I tried

to get that had a thousand locks on one bike because

you can over-secure a bunch of things. And it really

doesn't do much more than the two locks that would be

sufficient. But really try to take the assurances of

the connection. Take the security costs and the

money that it costs to do that and the battery power

into consideration. Don't overdo the security

requirements as best you can.

Encryption is very expensive, by the way.

You can get free encryption engines, but the time

back and forth is a very large amount of battery

consumption, and it also is a level of complexity at

the host processor that's going to cause you a larger

bill of materials cost. So sometimes people say, oh,

it has to be encrypted, and it doesn't really have

to.

And broadcast for fitness is the way to go,

in our minds. So authentication for blood glucose

and blood pressure and periodic communication for

(410) 974-0947

262


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

activity and heart rate and SpO2 and some of those.

Stay out of the tunnel vision. Remember

that you're not just making one device. You're

trying to make an ecosystem. So try not to define it

as the device that you're friendly with. And having

data correlation, having multiple points of data

makes sense of that data. It makes it look better.

And hear no evil, see no evil. Blind

interoperability assurances. You'll hear that all

day long from people that say, yes, it's going to

work. Listen to somebody who says, here, it does

work. That's the end of my presentation. Thank you.

(Applause.)

MR. THOMPSON: We're running just a tad

behind, so we're not going to be able to take many

questions, but we could take a couple of them. Maybe

while you guys -- if anybody wants to ask a question,

if you could come to a microphone, and I'll ask one

in the meantime. And P.J., I'd like to ask it of

you.

In your presentation, I thought you did a

nice job of laying out some of those use cases. I

wonder what you think about the regulatory solutions,

what you want to see happen in order to enable some

of those use cases. Remember to press the button

(410) 974-0947

263


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

there before you respond.

MR. JAIN: As I was pointing out early on

before the use cases, that from a consumer

perspective, from a patient perspective, people are

so used to using their mobile phone, they're going to

want to use it regardless. So obviously, you know,

we've got the FDA here, and they're going to be

looking at it from -- perspective.

But from a user perspective, I just want to

be able to use my device, and I expect it to be safe

and effective to be able to provide me with the value

that I've gotten so used to. So I think it's really

working collaboratively with the FDA to come up with

that answer of what that should be.

MR. THOMPSON: Okay. Do we have any

questions from the audience? If not, I guess we'll

move on to the next presentation, but I'd like to

thank these panelists first. Thank you very much.

(Applause.)

MR. ROBKIN: So before we begin the last

session for today, there are only a few people who

had room in their vehicles, so if you could be nice

enough to wait at the door at the end of the

sessions. There will be two shuttle buses that can

carry 15 people.

(410) 974-0947

264


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

UNIDENTIFIED SPEAKER: Each, each.

MR. ROBKIN: They will be ready. Each. A

total of 30 people. Fifteen times two is 30. And

they will be downstairs at five o'clock if you want

to take a shuttle bus back to the hotel. If we run a

little long and you don't want to take the shuttle

bus, there are lots of cabs, of course, and they will

have a phone number for the taxi service downstairs

by the security. No, once. Two buses going once.

If you know you want the cab, please tell Lindsay or

Molly out front, and they'll call a cab for you ahead

of time. All yours, Brian.

MR. FITZGERALD: Well, welcome to the last

session for the day. We're going to be talking about

system risk management here, and it's a nice lead-on

from the systems-of-systems talk we had earlier.

MR. MURRAY: Who are you?

MR. FITZGERALD: My name is Brian

Fitzgerald -- thank you, John -- in case you didn't

know me. I'm here with the Food and Drug

Administration, the Center for Devices, and I got

conned into moderating this session here. I've got

four excellent presenters. Let me introduce them

before we call them up.

We're going to be starting with John

(410) 974-0947

265


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

Zaleski, and I want you to just understand that John

literally wrote the book, and possibly the first

book, on integrating device data into the electronic

medical record. John's with Philips Research in

biomedical informatics aspects.

Then we're going to be asking Dale Wiggins

to come up and talk to us. He is the CTO of patient

management and health informatics at Philips

Healthcare. Then we're going to have Tracy, Tracy

Rausch, who is the founder and the CTO of DocBox,

point-of-care healthcare informatics. And lastly

we're going to have Peter Kelley, who's the Director

of QA and RA, with 20 years history of development at

Capsule.

And with that, what I want to do is, just

before we have these presentations, there are two

questions that I would like to put on the table,

questions that if our presenters don't get the

opportunity to answer, that you will have the

opportunity to answer us at question time. So I'll

put these questions out now so that you have time to

think about it.

The first one, when we're talking about

systems of systems, what risk management paradigm is

being used when these systems are created and

(410) 974-0947

266


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

aggregated and maintained? What risk management

paradigm is being used? The second is who is doing

the risk management of these systems? Perhaps the

corollary to that is who can do it? So let's just

keep those two questions in our mind, and I'll bring

them back up again, and let's see if we can discover

something new about these risk management paradigms.

The question is from one of our online

viewers, is do I know about OHME? OMHE. And the

answer is no. What I'm going to do is I'm going to

ask our questionnaire to enlighten us during the

course of this presentation so that we can share the

answer. John.

DR. ZALESKI: So I'm going to touch on

actually a vignette that Dr. Goldman brought up early

in his presentation, and after Dr. Friedman gave his

talk, we were talking offline, and I'm actually going

to touch on, I think, an aspect of Element 3 that he

was talking about. So what I opted to talk about

here was time and frequency alignment of multi-

parameter data and primarily from the perspective of

clinical decision making.

So this is kind of an eye chart, but really

what I'm focusing on here is real-time clinical

decision support systems require accurate high

(410) 974-0947

267


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

frequency data, that is, data that arrive in real

time, that are used in real time for clinical

decision making within what I call one meter of the

bed or one meter of the patient. Many devices employ

gateways. Some are direct connects, and those on

gateways typically possess common timing and

synchronization services.

And Dr. Goldman referred to NTP earlier,

the specific concerns over integrating data for

multiple devices that are not calibrated to common

timeframes and do not provide common time windows and

therefore asynchronously need to have data pulled in

order to make clinical decisions. And I'm going to

identify this -- I'm sorry. I'm going to demonstrate

this from the perspective of one scenario, one I have

lived, and just to illustrate the types of challenges

involved.

So we've all seen pictures today or various

pictures of high acuity environments. This is

another one. I'm showing essentially different types

of devices that are in use at the bedside in a high

acuity environment, typically an intensive care unit,

but potentially OR as well. And in these

environments, clinical decisions need to be made, and

what I'm showing here is somewhat of a rubric for

(410) 974-0947

268


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

clinical decision making.

I'm identifying the fact that there are lab

information systems, radiological information

systems, X-ray, CT, et cetera, that are used -- long

X-rays as an example -- departmental information

systems, devices, enterprise health records, all

information that are associated with a patient, that

are essentially pulled together in the process of

creating or establishing an action to assist the

clinician in the bedside point-of-care assessment of

a patient. So clinical decision support systems that

involve real-time decision making have to pull

information from all systems together to be able to

make effective decisions.

And one specific example that I like to

show is one of spontaneous breathing trials or

managing patients postoperatively. An example of

such patients are coronary bypass patients. The so-

called CABG patients are those who typically are

managed postoperatively. That is what? They're

essentially on the mechanical ventilation. I'm

showing a subset of parameters here, a very small

subset of parameters, just to illustrate the process

against a temporal axis, the time axis. So as an

example, spontaneous breathing versus mandatory

(410) 974-0947

269


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

breathing, what the ventilator is doing and how the

ventilator is reduced over time as a direct response

to physician orders and what the patient is doing in

terms of spontaneous breathing, title volume, cardiac

output.

And then what I'm showing typically are

synchronous data that is collected. The X's indicate

data that are normally collected synchronously, that

is, they're offered up, they're sent by the devices

typically without being requested, and then data that

are essentially queried at asynchronous intervals,

including infusions. And I'm showing nitroprusside

here as a simple example of that, a vasopressor and a

vasodilator.

And the point being that the time intervals

associated with the collection of these data are not

necessarily aligned at any one center of time. And

I'm showing that here by the vertical bar, which

illustrates that data availability and staleness,

potentially, in relationship to a request for

clinical decision support. So you can see here these

ovals that identify the request for information,

which actually exists between two specific active

known times or known pieces of data when they're

actually available versus when they are available

(410) 974-0947

270


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

synchronously. And one potentially motivating

requirement or need for this is the writing of an

order for reduction in respiratory support, reducing

a patient from intermittent mandatory ventilation

level 12 to level 8 or to CPAP, continuous positive

airway pressure.

These decisions are made on the basis of

the patient's overall data, including laboratory

information system, O2 saturation, et cetera. And

sometimes the data are available and sometimes they

are not. The point being that if data are stale, are

old, then a clinician will be making a decision on

relatively stale data. But compounding this problem

is the fact that some of the data may be arriving

from devices that are not necessarily aligned in

time, in terms of the overall network time.

So I think Dr. Goldman showed a simple

example of one clock showing one time, another clock

showing another time. Frequently, as an example,

mechanical ventilators are an example of these --

typically are not on gateways, whereas multi-

parameter monitors can be, through their gateway

architectures, and infusion pumps can be as well.

The point is that the data that arrive from the

multi-parameter monitors versus single or standalone

(410) 974-0947

271


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

devices can be offset, and it may not be known how

far they were offset. So what is complicating or

potentially compounding the problem is the situation

in which absolute time is unknown, and especially

with regard to clinical decision making.

So, what are the potential hazards

associated with this? Well, misaligning vitals data

when integrated or fused together could impact the

clinical decision making from the perspective of

misaligning orders, misunderstanding when the actual

data were valid, and when an order actually was

accomplished, when it was actually carried out by a

staff member, and accurately recording the

information, the clinical documentation.

Orders based on time differences can result

in misalignment of when, as an example, a change is

performed on a mechanical ventilator or an infusion

pump, data not collected on one system because the

time threshold is not met on the system, as an

example. The list goes on and on. Some of these are

more acute than others, but the point is, is that

they can occur and in large part because there is no

common timeframe for them.

Now one possibility or one -- in terms of

clinical impacts, I decided I'm not going to go into

(410) 974-0947

272


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

detail in this chart. But the potential impacts are,

as an example, cardiac output changes can occur as a

result of infusion results or infusion changes, and

they can occur very, very quickly. So we're not

talking about changes here that have a long center in

terms of time interval. They can occur very, very

rapidly when changes in infusion drips actually

occur, et cetera. So we're talking about situations

in which high accuracy is necessary.

In addition to that, if we could provide

the capability to do gap filling, that is, be able to

pull data in when it's required for clinical decision

making, so that when there is a time gap between

available data asynchronously, we could go back to

the device either automatically or flag or identify

in a fashion similar, I think, to what Dr. Goldman

was talking about, simply identify the fact that data

are missing and go and request it or query it from

the device, when necessary, or notify that there are

data missing or a decision is being made on the basis

of data that are stale, as opposed to simply just

saying, well, this is the latest information that

happens to be in the record, in the documentation

system.

One possible approach to doing this is --

(410) 974-0947

273


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

and we've all seen various -- or some of us have seen

various representations of devices talking through

gateways to interfaces engines, to departmental or

EHRs. Being able to automatically go and re-query

for information that is stale would be very useful to

do. And that's basically it.

MR. FITZGERALD: Thank you, John.

(Applause.)

MR. FITZGERALD: Now we'll have Dale

Wiggins.

MR. WIGGINS: I'm amazed. I never saw a

research organization finish on time before. Sorry.

I get punchy at the end of the day. It's great to be

given the presentation at the end because I know that

we're the last group before drinks and so the

questions will be short. There we go.

Okay. So I'm going to talk about a

clinical problem that when I first heard about it, I

thought it was pretty straightforward. There's

publications out on the internet available, talking

about this clinical problem and when you read it, it

seems like it would be a great case for device

interfacing. The benefits are quite clear. The

problem with realizing those benefits is that if you

do it with today's clinical practice, it requires

(410) 974-0947

274


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

clinician time that quite frankly they don't have.

They basically have to sit in front of the devices

all day long and manually adjust all these settings

continuously. So I'm going to try to talk a little

bit about this problem, some of the issues that I

uncovered looking at them.

So the basic problem is relatively simple,

at least I'll simplify it to something that I can

understand, and I'm sure some of the clinicians can

add a lot of complexity here. But the basic problem

is either too much or too little oxygen for

ventilated neonatal, preterm infants, in other words,

in the neonatal ICU. So what they're trying to do is

adjust a setting on the ventilator, which is the

inspired oxygen fraction, to maintain a pulse

oxygenation rate with the patient.

So what I tried to represent here is,

graphically, whether some of the workflow -- what's

the major workflow, what's the control points that

are realized in terms of solving this clinical

problem? So it all starts up top and obviously it

starts with an order. And what that is passed down

to is someone that ultimately needs to execute that

order, and that relates to making specific settings

on a ventilator, which ultimately impact the patient,

(410) 974-0947

275


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

and hopefully we get the required results out of

those settings to ultimately achieve the therapy

goal.

I think the complexity -- the first

complexity that you uncover is that we often ignore

patients, especially neonates, are not a predictable

machine. You know, we like to think about, you know,

in my technical world that, you know, everything's

logical, everything's predictable. And I think Frank

said it earlier best. You know, patients are not

entirely logical and predictable.

So we do have feedback mechanisms built in

along the way. Unfortunately, I think in current

practice, a lot of these feedback mechanisms relate

in a lot of clinician overload. And I think, as

Julian pointed out, a lot of times it's patient

overload as well. He showed a nice example of one of

our applications that ultimately kept him up all

night.

And ultimately, I think, it does make the

case for how we can improve a lot of that workflow, a

lot of that patient outcome, and as we've studied,

you know, the ability to impact the way that that

patient receives that care can ultimately have big

impacts on their improvement and their ultimate

(410) 974-0947

276


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

outcome as well.

So what we've also represented here is some

of the clinical decision support opportunities that

we see in this clinical scenario, if we did have some

of the automated feedback loops built in, you know.

And I think there's -- we often look for the perfect

solution, but what we've tried to identify here are

there are actually multiple different ways with

varying levels of complexity that you can look for

partial solutions.

So in this next slide what we've tried to

do was just, you know, at a high level, identify some

of the major settings that, you know, I talked about.

You know, if you look at it from a top level, it's

relatively a simple use case. You've got one setting

you got to adjust and one measurement you need to

observe.

Well, in reality, when you think about it

from the order, the therapy order that is given and

how you translate that into all these settings, all

the various interactions with the system that the

user has, whether it be setting the various modes and

settings based on the order, device connectivity and

device failures, actually adjusting some of the

settings along the way, and then also how we

(410) 974-0947

277


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

ultimately feed back, it does become a rather complex

endeavor.

What I next tried to do is identify some

specific issues in each of those categories. And I

think you've heard probably most of them in different

scenarios today. In order not to throw too many

stones in a glass house, if you will, I'm going to

talk about the one that's most relevant to the

patient monitoring business, since we're involved

with it. And again, I'll use Frank's example.

He said that it's careful to note that

those observed measurement values, they aren't

patient measurements; they're device measurements.

They're what we interpret the signals to mean, and as

such, you know, we like to think that they're

100 percent accurate. I'm sure that everybody would

like to think they're 100 percent accurate, but they

aren't. They're subject to the transducers that are

applied to the patient. They're subject to motion

artifact. They're subject to environmental

conditions.

And all those factors come into play in

terms of the accuracy of that measurement. And

unfortunately we look at study after study that says

that, well, if you're just looking at that HL7 vital

(410) 974-0947

278


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

sign, for instance, well, you're probably going to

get about a third of those in error, and that might

even be in a really good case.

So I think it's really important -- and I'm

going to move in interest of time -- to make sure

that we're keeping track of what is the specific use

case, and as we're drilling down on those interfaces,

to think about how are we expecting to use that

interface and making sure that we really do have the

right specifications and the right requirements

associated with those interfaces, such that we really

can get the results that we achieve. And I think a

multiple of speakers today have talked about that in

great detail, but I think to me that's one of the

overriding things that I have heard that's really

consistent throughout this carrier.

I did want to be -- this is my last slide,

and I thought I'd be remiss if I didn't mention that

there is a lot of great work that's going on in the

standardization area. And ultimately, I think, from

a vendor standpoint, standards need to be part of the

solution because ultimately when we talk about

getting vendors to participate and ante up to this,

we need the standards so that the business case is

broad enough that ultimately you can make profit at

(410) 974-0947

279


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

the end.

I think that, you know, the -- I'll use the

old joke. You know, the good thing about standards

is that there's so many to choose from. I think some

of the real things that I like about what I see

happening today is that we're starting to move more

from just the base standards, more into true

interoperable profiles, and I think, as those become

demanded by customers, that then we really will be

able to achieve some of the breakthroughs.

But this list up here, as well as the other

ones, isn't sufficient. There's a lot of holes in

terms of as we put these systems together, they still

need to be addressed. There's a lot of fundamental

research and technology investment that needs to be

made to, for instance, get those pulse ox values to

be much more accurate, make the requirements and

specifications much more clear so that we really can

put these systems together in a reliable fashion.

Okay.

(Applause.)

MR. FITZGERALD: Let's welcome Tracy Rausch

to the podium.

MS. RAUSCH: So about five years ago we

were sitting in a conference room with a few people

(410) 974-0947

280


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

in this room with Dr. Goldman, and he says we have

all of these clinical scenarios and stories, and what

do we with them? And myself and a couple other

clinical engineers kind of looked at him and said

that's probably a pretty good question. And that's

where this work actually started was, you know, in

that conference room. What do you do when a doctor

tells you a story? How does that actually translate

into something or requirements that an engineer, as

we've heard before, who's never been on the OR, who's

never been in ICU, can actually understand what that

doctor's actually saying? This work went on for

about four years. Fits and starts.

And what's starting to come out of this

work is that there are basically some building blocks

that are common amongst almost all clinical workflow.

So we're talking this from a perspective of -- you

know, we've heard the technical approach to this.

How do you integrate? But really the system is a

clinical system, and right now this is the picture of

the clinical system. And basically the text is what

you're going to hear, if you hear two nurses talking

to each in a room across from two patients. Some of

it's a little frightening, but we'll get past that.

So basically the reality is, is healthcare

(410) 974-0947

281


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

is a combination of many systems. These systems

include the people, the information systems, the

medical devices, and the patient. We've heard a

bunch of talks today. Most of them are leaving out

the people part of this aspect. So how does actually

clinical workflow impact what you need to do for

interoperability and device integration? You can't

design a system without understanding how the parts

work with each other. You get unintended

consequences, and there's a safety issue. So I did a

little math last night, so my numbers might not be

great. We can negotiate those back and forth. I

figured I don't even need to read it. It's big

enough.

(Laughter.)

MS. RAUSCH: This is in a critical care

unit. This is the number of combinations. I don't

even know how to say this number, so we're just going

to leave it of what it is. One of the things we can

do, in a system-to-system, medical device types can't

be the primary component of the system. We need to

go down one more level lower. What is that

functionality of that device? This allows us to

advance innovation. If there's a new management

parameter, we shouldn't have to go back and redo

(410) 974-0947

282


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

everything. We should be able to classify that

parameter as a certain component.

Using functionality of the devices, it's

going to allow for that advancement. But early work

has shown there's basically a common set of building

blocks. Through the work of the ICE-PAC and the

plug-and-play program and my company, DocBox, and

some others, we've actually done a pretty intensive

analysis of ventilator processes and workflow of

critical care. What are the different situations?

What are the different scenarios? And also with

infusion therapies. When we put these two down

beside each other, it's a really big conference

table, I can tell you that right now.

I believe right now we have probably about

70 letter-sized pages of workflow that's printed out

of basically what happens if you take one infusion

pump and one ventilator and put them together at the

site of care, of what a clinician is responsible for

doing. But all of a sudden you start looking at it

and things start popping out. There's commonality

among all of these clinical workflows, commonality of

decisions.

So if we could actually capture what those

common device components are, we could actually start

(410) 974-0947

283


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

to look at systems in a safe way, because if we can

make each of those individual components safe and the

interactions to them safe, our combination number is

still pretty big, but it goes down a little bit.

Some of the examples of these blocks -- and

you know, we're naming them generically, this is

ongoing work -- will be, how do you collect data?

How do you send data? How do you compare data? And

this is coming from the clinician's perspective.

This isn't coming from one device talking to another.

What is the functionality and what does that

clinician need at the time of, you know, these

interactions that occurring?

So I've still got this big number, and I'm

not really sure what to do with it. So my first

thought, I'm not -- you know, I don't know

everything. Let's go borrow some of the technology.

So now I'm not saying that we need to go adopt

certification processes from other industries. I'm

not saying we need to go do other things. But let's

learn how they get through that process, and can that

technology be designed for the healthcare system?

Aviation's been using simulation since

1934. We're a little behind on the ball here. Right

now there's not a single airplane that's designed

(410) 974-0947

284


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

that the entire system is simulated, a system-to-

system, before a single piece of device is made.

The Defense Department can simulate an

entire battlefield environment and understand what

the logistics are, where things happen, where things

are supposed to go, and what are the risks if

something doesn't occur. Computing power in these

simulations, it used to take them about 300 hours to

do this analysis. They're now telling us it takes

about 30 hours. And the technology can be done on

basically a workstation, and that's pretty amazing.

So I have pictures, thanks to some

colleagues. They're simulating nuclear power plants.

They're simulating new facilities. They're

simulating the battlefield environment. And it's not

just the pretty pictures and, you know, the avatars.

You can move the environment and see where things

are, but it's actually the analysis that's behind it

that's the important part of this. You can look at

relationships, you can look at risk points, you look

at where things fail, and you can do this in a way

that you can use technology to actually help us

understand how these requirements work and interact

with one another.

So some of the conclusions. If you use

(410) 974-0947

285


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

functional building blocks instead of the device

types to understand how systems interact with one

another, you probably have a little better

understanding of what's going on and actually how to

make and design heterogeneous safe systems. And the

other thing is let's utilize some existing analysis

methodologies to move towards, you know, either

certification methods or another method that works

for healthcare, to understand these systems to

systems.

So I wanted to thank the plug-and-play

team, the ICE-PAC team has contributed to this work,

and Lockheed Martin Simulation and Training Systems

Virtual Labs Division.

(Applause.)

MR. FITZGERALD: Thank, Tracy. Please

welcome Peter Kelley to the podium.

MR. KELLEY: If you can all bear with me

for a few moments.

(Pause.)

MR. KELLEY: All right. Sorry for the

interruption. First, I'd like to thank the FDA and

CIMIT and the Continua Health Alliance for making

this opportunity possible. I believe this is a

really important subject that we all are talking

(410) 974-0947

286


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

about today, and this is really an outstanding

opportunity to be able to just get together and to

discuss it.

What I want to talk about today is to just

explore applying some of the concepts that are

embodied in the IHE framework and applying those

concepts to risk management for the purposes of

controlling risks in systems of systems. We've had

many scenarios painted today about really potentially

disastrous occurrences that could happen, and I've

got my own that I'll show you very briefly just for

illustrative purposes. Before I do, I need to point

out that I'm not proposing that IHE take on this

charter. What I'm trying to do is to reuse some of

the mechanisms that they have implemented quite

successfully and applying those to management of risk

so that -- for the purposes of stimulating a

discussion around this topic. We've heard a lot of,

as I said, scenarios and possible mitigations. What

I'd like to present is a way of bringing those

together in a standardized way that could really help

to facilitate the implementation of risk management

via both ISO 14971, which is risk management for

medical devices, and the new IEC80001.

Before I do, I just thought I would go

(410) 974-0947

287


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

through a real brief walk-through on risk management.

Risk management is a structured way of assessing the

potential harm that could occur during normal use and

non-normal use of medical devices, or in this case

systems of systems.

We start with a risk analysis. We identify

hazards that could occur. We identify hazardous

situations that could trigger those hazards and then

we assess that. Part of the assessment is the

identification of the harm that could occur and the

likelihood that that harm would happen. The harm is

then evaluated to determine the severity of that harm

and the probability that the harm would in fact also

occur in the presence of the hazardous situation. In

the event that the risk assessment reveals an

unacceptable level of risk in either the system or

the device, you move on to risk control, where you

identify mitigations that you put in place and to --

and after you have done that, you do a residual risk

analysis to make sure that you have not added more

risk to the system than you have removed from it.

The risk case scenario that I want to talk

about today is a closed loop system -- we've heard,

again, several of those today -- with a bedside

computer-assisted medication administration

(410) 974-0947

288


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

application which is controlling the infusion of a

patient on cardiac medications. The BCMA receives

the patient's vital signs through an MDDS, a medical

device data system, and all of these systems are

residing on a hospital network, along with EMR and

ADT applications.

This is an example of a risk profile that

is called patient association. Each profile can

contain any number of risk case scenarios. For

brevity, I'm presenting only one here. A hazard is

associated with each scenario. In this one there's

an incorrect association between a monitor and a

patient. In this situation the two patients are in

the cardiac care unit, one is on a vasopressor, the

other's on a vasodilator. Both are controlled by a

BCMA. Through some happenstance in between the EMR

and the ADT system, or perhaps any other number of

scenarios we could describe, the association of the

monitors, the vital monitors for patient A gets

associated with patient B or vice versa. The BCMA

then instructs the infusion pump to titrate the

vasodilator too rapidly. The harm that results is

that the patient goes into deadly dysrhythmia and

ultimately dies.

Using the risk management process, the

(410) 974-0947

289


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

obvious severity of that is catastrophic. And for

this example, rather than going through the

evaluation and determining whether or not this

mitigation would be required, I'm assuming, for the

purposes of illustration, that we would want a

mitigation for this issue.

And this brings us to a risk case control

example. The idea here is that we would have -- each

hazardous situation would be accompanied by a

standardized risk case mitigation. In this very

simple scenario that I presented, it could be that a

requirement be put in place that all transactions

must include a patient identifier. Perhaps there's a

subset of transactions that we could identify that

would need that. But if a patient identifier had

been included with that transaction between the BCMA

and the infusion pump, the infusion pump would've

recognized that it was the wrong patient that it was

being told to change the titration form. The

verification of this could be a standard test

protocol similar to what IHE does now.

Finally, vendors would be able to publish

statements, declarations of conformity, if you will,

to identify the risk case control statements. So

they are effectively declaring that they have

(410) 974-0947

290


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

implemented the specific mitigations. These would

then be used as a deliverable for complying with

IEC80001.

One of the benefits that I could see for

doing this is it takes a lot of the ideas that I've

heard about today, a lot of the difficulties we

encounter, a lot of the potentials that could be put

into place to correct those, puts them into a

framework where we can all talk about these things at

the same level, where we can identify standard -- not

standards but standardized mitigations which can be

used to correct them. And then it gives the vendors

a convenient means of being able to declare that yes,

they have implemented that.

The hospitals who are then trying to apply

80001 to their healthcare network can then say, well,

we've got vendors A, B, and C, who have done these --

who have met these risk profiles, who have

implemented these risk mitigations. That fits with

the mitigations that we are requiring. And that is

my presentation. Thank you.

(Applause.)

MR. FITZGERALD: Thank you very much,

Peter. We have a few minutes left. We can throw the

floor open to some questions and maybe some answers.

(410) 974-0947

291


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

We have two questions on the table. What risk

management paradigm is being used, and who is doing

the risk management of these systems? Peter managed

to touch briefly on those two issues. Does anybody

else have any comment or any question about these two

things?

MR. MURRAY: I have a question for

Dr. Zaleski, but not your question.

MR. FITZGERALD: Go ahead. Let's field

some questions.

MR. MURRAY: I was interested in the time

synchronization -- the product, and in listening to

both you and the other folks, we all view medical

devices as pushing devices, data push, not data pull

primarily because historically that's the way it

works. The box sits on the wall or on the table and

you look at it or you wait for it to spew out its

data. If you were to turn it around and make it a

pull approach, would you then eliminate your -- or at

least eliminate part of. I can see where you

wouldn't eliminate all of the time delay and the

synchronization of it.

DR. ZALESKI: You wouldn't eliminate the --

that's one of the part of the process. You have to

provide the capability. But what you need to do is

(410) 974-0947

292


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

provide the intelligence to be able to request the

information.

So if you go back to Julian's scenario,

whereby the ventilator assumes a pause during the X-

ray and then resumes after that, that could be a --

that is an example or one example potentially of a

situation where the device could push data

asynchronously or the data could be requested

asynchronously, on the event, transmit this

information verification, as an example. I'd say

it's one aspect of it. It's not the complete.

MR. WIGGINS: Can I add something to that?

Just to add one more thing, from the standpoint of

the way we implement our system today, we actually do

pull in the time from the enterprise systems in our

central station environment and then we -- so we

synchronize to that level, and then we have a much

finer grade synchronization between the central

station and the bedside monitors themselves. So I

think, you know, that's part of the challenge, that

we need to make sure that we understand when we're

looking at specific use cases. You know, for

instance, IHE ITI has a consistent time protocol that

works great, you know, at the central station level.

But if we get down to the finer grain or the point-

(410) 974-0947

293


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

of-care device integration, we're going to need a

different level to get some of those finer grain use

cases.

MR. FITZGERALD: So we have a couple of

questions. Let's take the question over here first.

UNIDENTIFIED SPEAKER: It was more an

answer to your question, who is responsible? I think

that has to reside with the systems integrator. If

you look at the existing way that medical devices --

if you take a medical device, a bedside medical

device, and you look at the label on that device,

that's the persons or organization responsible.

If you then look inside that -- devices

from other manufacturers. So you already have the

framework where different devices from different

manufacturers are combined into a single system, and

I think what we're doing now is we're not looking at

the same box. I do, though, think there are issues

and complexities beyond the scope and responsibility

of the person or the organization that is doing

that -- taking that responsibility. So I think while

they take responsibility, the regulatory bodies have

also to protect them by -- you know, we talked today

about shared responsibility, and I think we're now

entering into an area where there are different

(410) 974-0947

294


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

parties out there that accept responsibility, and

that includes the user. So the patient can't just

turn around to everybody because they tripped over a

wire. You have to look at the involvement of the

different parties within that.

MR. FITZGERALD: Well, thank you. That

introduces a neat concept of shared risk space.

Let's take a question.

MR. ZAKIAN: So I'm going to readdress the

time synchronization issues and especially in medical

devices that are not going through monitoring

stations where NTP is normal, but more going through

serial-connected devices that go through MDDSs. Most

of the time the device stamp and the timing on that

is inaccurate because it's a device time that -- so

my suggestion is that you really need to have two

times that. You need to have the time stamp of the

device solely for audit trails and log -- you know,

log file reading on the device in case there is an

anomaly in the device. Yet, again, you can inject

the real time from an NTP, giving it the accuracy of

the asynchronous data collector.

MR. FITZGERALD: Excellent point, the

concept of trusted time and untrusted time.

MR. ZAKIAN: Exactly. And that's very

(410) 974-0947

295


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

doable.

MR. FITZGERALD: It is. You're right. It

is very doable. Let's take the lady. You can wait,

Rick.

UNIDENTIFIED SPEAKER: I'd like to ask the

panel to just talk a little bit about where the human

factors for testing comes and the whole risk

assessment process that is kind of looking at the

user actually using the device in the environment

intended.

MR. FITZGERALD: Well, volunteers to -- who

wants to address that?

MR. KELLEY: I think it's really addressed

at two different levels. The first is by the device

manufacturer during the development of a device.

Very early on, when they're establishing their user

inputs, their user needs, their design inputs, a key

component of that is risk analysis and also user

needs analysis as it relates to risk.

Second is going to be at the system level

or the system-of-systems level, as we've talked about

it, and I'm not sure how that gets to be done in the

context of a clinical environment where you have, you

know, ongoing clinical operations and needs in trying

to implement a new system and do, if you will, an

(410) 974-0947

296


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

ergonomic study of that. There's some real

challenges there.

MR. FITZGERALD: And perhaps we could say

80001 could assist with that. Rick.

MR. SCHRENKER: I want to get back to the

question about the risk management paradigm for a

second. Peter, in your one slide, there were medical

devices connected directly to the network, and that's

a very high-level picture with it. Have you or

anyone else on the panel thought about the

differences between, for instance, local control

versus -- I mean, some problems can, and from basic

control theory, should be addressed locally.

So maybe you don't have to go to the

network for every transaction and what the impact

that might have on risk management, or maybe the

network can inform the local environment for some

period of time and things like that. So is that

covered in the suggestion for a profile? Are those

the kinds of things that should come up? For

instance, local versus -- more local versus more

remote phones?

MR. KELLEY: I would see that as coming out

of the risk case scenarios that are developed and

then the communications that are associated with

(410) 974-0947

297


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

those as well. So you would create a scenario

perhaps with the medical devices connected to the

network. You may come up with a mitigation or

control mechanism where you would lock that local

control over it, over that particular hazardous

situation to prevent it from occurring.

MR. WIGGINS: So just to add a little bit

more on that, I think it's an excellent point, and I

think, to me, it gets back to really understanding in

detail the requirements of your specific use case.

And, you know, I know for a fact we had gone down

some designs and actually got to an end state where

we're basically in what we hope to be pretty close to

final validation and basically discovered that we

couldn't sufficiently mitigate our risk and basically

had to scrape the entire effort.

So I think it's -- your question is

directly to my point of we have to do a much better

job up front at understanding those detailed

requirements and latencies, a very key point to that,

before we can really make a lot of progress here.

MR. FITZGERALD: Thank you. Julian.

DR. GOLDMAN: I have a question regarding

the selection of use cases to generate the

appropriate requirements to bound the space in a way

(410) 974-0947

298


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

that would allow a system to be built that would be

at least modestly future-proofed. So I don't know

what that means, what kind of a word.

So let's say that you come up with a use

case and the data relationship, in terms of the data

granularity and some examples that you gave, John,

you can look at the data. The granularity will allow

a certain level of causality to determine what came

first, what came second. And that might be

appropriate for that use case.

And then perhaps you design a system around

it or you implement parts thereof. And then a year

later you have a more sophisticated use case, and it

has tighter timing requirements or greater

granularity or some other facet. But, you know, that

presents a challenge.

But on the other hand, instead of looking

at that one use case, you could step back and say,

well, what's the highest bandwidth I would reasonably

expect in this part of the system? You know, what's

the tightest timing requirements as far as causality

are concerned? If you look at an EKG, for example,

it inherently is an electrical signal that'll have

different properties than a blood pressure waveform

or a respiratory.

(410) 974-0947

299


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

So how do you balance, you know, what you

can max out on a single signal basis for what you --

based on what you know about the properties of that

versus mapping things to use cases, which always have

certain -- you know, a lot of variability in terms of

their requirements?

DR. ZALESKI: This is one question when the

business ones research the answer it. All right. So

a general answer. Well, I think that you need to

design based upon the acuity of the environment

you're delivering to. And I'll refer as an example

back to Dr. Piniewski's comments in the last panel.

One thing I picked up on, but I didn't want

to be obnoxious and get up at the microphone, was the

idea of heart rate variability and being able to pick

up on heart rate variability as a potential heralding

of the onset of septic shock owing to the

compensations, as an example. But to pick that up

requires sufficient frequencies and sufficient data

to be able to do a full assessment of the signal.

So in that case, and in situations that

involve essentially making high or high acuity -- I'm

sorry -- a high acuity environment involving real-

time decisions, I would say that second or sub-

second, potentially millisecond requirements might be

(410) 974-0947

300


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

necessary.

So you're asking a general question. The

general answer is, in terms of high acuity space, in

terms of the types of comorbidities and types of

challenges that you face in that type of a clinical

setting, I think high frequency is the answer. And

then the question is, well, what about this case,

what about that case? And we can discuss this over a

Glenlivet in about 60 minutes or so. But I think

that -- I think high frequency potentially might be

the situation.

DR. GOLDMAN: But I'm sorry, the open bar

is not including --

DR. ZALESKI: I'm buying.

(Laughter.)

DR. GOLDMAN: Thank you.

MR. MURRAY: You're buying for how many of

us?

DR. GOLDMAN: That's what I want to know.

MR. FITZGERALD: So how many other

questions do we have? Going once. Going twice.

UNIDENTIFIED SPEAKER: I want to make a

comment.

MR. FITZGERALD: A quick comment over here.

UNIDENTIFIED SPEAKER: Okay. So if I

(410) 974-0947

301


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

understood correctly, Julian's question was like what

kind of timings and parameters, how we choose them --

right? Is that the question?

DR. GOLDMAN: Yes.

UNIDENTIFIED SPEAKER: Okay. So I think

what we have to do is to build the model, and when

you have your model done, then you're going to

predict your output of your model and you're going to

compare with data. When that difference is basically

acceptable based on the accuracy you want to achieve,

then that would propagate back on your system

parameter selections.

DR. GOLDMAN: A somewhat different

approach, I think.

DR. ZALESKI: Yeah, I was looking at the

conclusion as opposed to the process.

DR. GOLDMAN: Uh-huh.

DR. ZALESKI: So yeah.

DR. GOLDMAN: Yeah.

MR. FITZGERALD: Okay, let's try that one

more time. Going once. Going twice.

UNIDENTIFIED SPEAKER: You have to answer

your own question.

MR. FITZGERALD: One in the back. Well,

he's challenged me now to answer my own question. So

(410) 974-0947

302


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

this has to stay here between just us, okay?

(Laughter.)

MR. FITZGERALD: All right? What risk

management paradigm is being used? Too frequently

it's the wrong one. It doesn't include the 14971

assumptions of a recumbent, perhaps unconscious,

unresponsive, and unconsenting patient. It tends to

be the risk management paradigm of the IT community,

which assumes consent, which assumes only loss due to

malfunction and bad reputation. That's my answer to

that question.

MR. MURRAY: And it only assumes multi-

point failures.

MR. FITZGERALD: Single-point failures.

MR. MURRAY: Single-point failures.

Forgive me. Not multi-point failures.

MR. FITZGERALD: So the other question.

Who is doing the risk management of these systems?

Well, basically it's Rick, Rich Schrenker, one of the

very few people that I've come across who is willing

and able to confront the 14971 implementation on a

system-of-systems basis. And I said one of the very

few people that I've come across because in my own

humble estimation, there is not enough risk

estimation and risk management being done in these

(410) 974-0947

303


Annapolis, MD 21409 (410) 974-0947

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

systems of systems. And I think many of the

questions that we see are symptomatic of an

inadequate hazard analysis, an inadequate

requirements basis. That has to change for this

whole thing to move forward. My humble effort at

those two questions. And enjoy the drinks.

(Applause.)

DR. GOLDMAN: Wait, we have announcements,

don't go.

MR. MURRAY: We have an announcement, you

say?

MR. MERKLE: Quick announcements, quick

announcements. First of all, thank you very much.

It was a very, very informative and fantastic first

day. So I'll make it short.

The Continua Health Alliance would like to

invite you all, all the attendees, to a reception at

the Sheraton Washington North at 4095 Powder Mill

Road at six o'clock, 6:00 p.m., where we can all

enjoy a drink and deepen our discussions and maybe

have some camaraderie networking. So you're all

invited. I hope to see you all there. Thank you.

Goodbye. See you tomorrow.

(Whereupon, at 5:30 p.m., the meeting was

adjourned.)

304


Annapolis, MD 21409

C E R T I F I C A T E

This is to certify that the attached proceedings

in the matter of:

WORKSHOP ON MEDICAL DEVICE INTEROPERABILITY: ACHIEVING SAFETY AND EFFECTIVENESS

January 25, 2010

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.

____________________________

RONALDO OTERO,

Official Reporter

(410) 974-0947

workshop on medical device interoperability:...

Documents