workshop on medical device interoperability:...

305

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 26, 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

306


Annapolis, MD 21409

PRESENTERS/MODERATORS: MICHAEL ROBKIN President, Consultant, Anakena Solutions SANDY WEININGER, Ph.D. Senior Biomedical Engineer, FDA/CDRH/Office of Science and Engineering SCOTT THIEL, M.B.A., M.T.(ASCP), R.A.C. Roche Diagnostics, Global Regulatory Affairs Diabetes Care, Regulatory Affairs Program Manager RICK SCHRENKER Systems Manager, Biomedical Engineering, Massachusetts General Hospital JOHN DENNING Independent Consultant LUIS MELENDEZ Assistant Director, Partners HealthCare Biomedical Engineering, Medical Device Integration and Informatics, Massachusetts General Hospital RENATE A. MacLAREN, Ph.D. Director, Regulatory Affairs, Integrated Medical Systems, Inc. ALASDAIR MacDONALD CEO, TeleMedic Systems, Ltd. DAVE ARNEY Student, University of Pennsylvania DAVE OSBORN Manager, International Standards & Regulations Department, Philips Medical Systems TODD COOPER President, Breakthrough Solutions Foundry, Inc. KEN FUCHS Principal Engineer, Draeger Medical Systems, Inc. PAUL SCHLUTER, Ph.D. Principal Engineer, GE Healthcare - Monitoring Solutions

(410) 974-0947

307


Annapolis, MD 21409 (410) 974-0947

PRESENTERS/MODERATORS: JOHN J. GARGUILO Computer Scientist, DoC/NIST TRACY RAUSCH Founder and CTO, DocBox, Inc.

308


Annapolis, MD 21409

INDEX PAGE

CALL TO ORDER - Julian M. Goldman, M.D. 310 PRESENTATIONS A Short History of Interoperability - Michael Robkin 311 Pieces of the Puzzle: Actors in Interoperability - Sandy Weininger 324 Making it Happen: Manufacturer Perspectives on Medical Device Interoperability - Scott Thiel 339 Q&A 355 SESSIONS Session 6: Software Issues Moderator - Rick Schrenker 362 Safety and Effectiveness Issues in Electronic Medical Records - John Denning 364 Medical Device Data Patient Context Challenges - Luis Melendez 371 Q&A 387 Session 7: Integration and Interoperability Issues in a Regulated Environment Moderator - Scott Thiel 391 Interoperability through Integration - Renate A. MacLaren, Ph.D. 391 Universal Interface between Medical Devices and IT/Communications Systems - Alasdair MacDonald 395 Toward a Plug-and-Play System for Medical Devices: Lessons from Case Studies - Dave Arney 407

(410) 974-0947

309


Annapolis, MD 21409 (410) 974-0947

INDEX (cont.) PAGE Session 8: Standards, Interfaces and Interoperability Issues Moderator - Dave Osborn 418 Impact of ARRA/HITECH on Device Connectivity: Safe? Effective? Say What?! - Todd Cooper 419 Connectivity? Integration? Plug and Play? What is the Interoperability End Game? - Ken Fuchs 429 Semantic Interoperability for Medical Device Data Interchange - Paul Schluter, Ph.D. 435 Helping the Cause of Medical Device Interoperability Through Standards-based Test Tools - John J. Garguilo 442 ICE-PAC Approach to Understanding Clinical Requirements - Tracy Rausch 449 BREAKOUT WORKING SESSIONS Introduction to Breakout Session #1 - Michael Robkin 456 Breakout Session# 1 458 Introduction to Breakout Session #2 - Julian M. Goldman, M.D. 460 Breakout Session #2 473 ADJOURNMENT 473

310


Annapolis, MD 21409

1

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.)

DR. GOLDMAN: It's good to see that so many

people are still here, and to those that bailed

early, we'll just give them assignments. So

presentations are being loaded now on the computer.

If there are folks out there who have presentations

and haven't brought them up yet, now would be a good

time. There's only another moment left. And our

first speaker this morning is Mike Robkin.

Mike Robkin is a principal of a company

now, Anakena, and he'll tell you the basis for that

name since it's a mystery to most of us. Before

this, Mike worked at Kaiser Permanente for about 10

years, where he was a principal enterprise architect.

And Mike and I started collaborating in 2004 on

interoperability of medical devices when -- as part

of a Kaiser contingent that started to really do some

foundational work.

And I think that one of the things that

Kaiser did that helped a lot was to start to

implement contractual requirements around

interoperability around that time, and that ended up

forming the basis for other work which subsequently

became the document known as MDFIRE, Medical Device

(410) 974-0947

311


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

Free Interoperability Requirements for the

Enterprise, which as I mentioned yesterday was a Mike

Robkin acronym-generating accomplishment. So the

work with Kaiser goes back to that date, the work

with Mike goes back to that time, and Mike has been a

really important and valuable member of a community

of people that are helping to move this work forward.

Prior to that -- so that 10 years of his

life was at Kaiser, and prior to that, Mike worked at

Hughes Aircraft where he was involved in systems

engineering, simulation, and standards. And so now

he has -- he brings that background to us, and I

think if your presentation is on here, then we're

ready to go. So let's welcome Mike.

(Applause.)

MR. ROBKIN: So thank you. I was asked to

deliver a short history of interoperability, which is

going to be perhaps a bit of a challenge, but I'll

try to keep it short and to the point. As Julian

mentioned, I have a background in both aerospace

systems engineering and in healthcare, so I will

hopefully bring out the most valid points. This is

not going to be a tutorial. I'm going to assume that

you guys understand the technology and the content

here, but it's going to give you a little preview.

(410) 974-0947

312


Annapolis, MD 21409

1

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 a lot of options available to us as a

community to achieving interoperability, and looking

back at the history of interoperability programs and

what has succeeded and what has failed will give us a

lot of good knowledge base to work from. The second

thing, the biggest conclusion I found, which I will

repeat, is that interoperability is not a technical

problem. Interoperability is a people problem or a

governance problem or a business problem. There are

very, very, very few technical problems that cannot

be solved.

So I did a lot of research, and I tried to

find the very first reference of interoperability,

and I believe I found it. The chimera, head of a

lion, head of a goat, sticking out of the abdomen,

head of a tail -- head of a snake instead of a tail,

and it breathes fire, which is an extra capability

not found in the components.

(Laughter.)

MR. ROBKIN: And exciting a chimera was an

omen of shipwrecks or volcanoes. So I can't imagine

that this -- that there's going to be a better logo

or mascot for interoperability than the first example

right here. Getting a little more serious, I found a

timeline of interoperability, so this Professor

(410) 974-0947

313


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

Parker did some research. He looked for references

to interoperability or related terms in the

literature. He looked at patents, conferences,

books, papers. He looked across all the mains, and

it was filtered a little by references and by

relevance. And he used a lot of online resources.

So the totals are obviously biased towards the

present, since current work tends to be online and

work from the '60s and '70s tends not to be. But for

the purpose of my talk, I will assume that the

relative proportions are valid.

You can see -- you can't see, actually. In

the corner, the bottom left-hand corner, in 1893 is

the first reference to interoperability, and I'll

show it to you. The rail car airbrake, compressed

air for the brakes of a rail car. As you can

imagine, lots of trains, hundreds of tons, one guy in

the front hits the brake, you want all the cars to

brake. And when this doesn't work, bad things

happen.

So it's the Safety Appliance Act, 1893.

This is the whole thing, eight sections, very simple,

says you need safety checks, you need automatic

couplers, it's illegal for a locomotive to receive

train cars that are not so equipped. Something about

(410) 974-0947

314


Annapolis, MD 21409

1

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 grab iron, don't know what that is. They

outsourced the standard, the American Railway

Association actually writes the standard which was

one number, it was the height of the rail bars, the

fine was a hundred dollars, and a few words about

safety. Now, this is the Act. This is the entire

Act. It's one page. Now, it's been updated so

there's a page worth of addendums, but the current

Act is one page. Covers all that. So here's our

first history lesson. Write the minimum amount of

the law that is necessary. This Act applied only to

the critical safety aspects of operating a railway.

They outsourced to an industry association

for setting the actual standard. Liability was

clearly defined. Compliance was not confusing. It

definitely added value. Rail has been one of the

safest forms of transportation worldwide for over a

hundred years. Now, there's a lot of other things

that are involved in making rail safe, but they had

nothing to with interoperability.

So there's thousands of pages of rules for

how to operate a train, procedures, training and

education, and how to organize a railway, but they're

not part of the interoperability of the rail cars.

So moving out from 1893, I looked through all these

(410) 974-0947

315


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

references, and I sorted them by domain. So what you

see here, from 1989 to 2004 is the proportion of

interoperability programs by domain. On the bottom,

you see a little slash with healthcare. Next up are

military applications for interoperability. The

green line in the middle, that's generalized

computers, PCs, mainframes, software, but pure

computer applications of interoperability.

Communication. That's not computer networking, but

telephones, cell phones. And on top of the other

category, that's topics like science, transportation,

government, first responders, things like that. So

what you'll see here, pretty obvious, is the military

was the single largest demander and receiver of

interoperability for a long time.

So what we take home is there's a lot of

people besides healthcare working on

interoperability. If we look at the military

programs, two sets of key words came out. First one

was C4I or C3 and Command Control. So these are

acronyms, and what they mean are the domain, the

science, the applications of getting information from

military units, from sensors, and then controlling

them, commanding them.

So it's all about coordinating and

(410) 974-0947

316


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

commanding the operation of military forces in

combat, which one can imagine is a very hectic, a

very unplanned, a very chaotic environment. The

second set of keywords was simulation and war. Now,

there's a reason these are connected. And I'll have

to give you a little more history to give you some

background for why these two are the most important

sets of keywords for military interoperability. And

this is why: this is what you might call a lack of

meaningful use of military assets. It's a picture

from Pearl Harbor. It's a very famous picture.

We're using this example. There are a lot more

recent examples from the government of a lack of

interoperability, but this was the first one, the big

one, and this set the tone for work in the military

around Command Control and around simulation.

I got this chart from a book. These are

all the interoperability failures that resulted in

Pearl Harbor. There are literally dozens and dozens

of ways Pearl Harbor could've been prevented, but the

organization of the U.S. military and the federal

government did not interoperate. This is an

organizational view of the failure of

interoperability.

Departments didn't talk to each other,

(410) 974-0947

317


Annapolis, MD 21409

1

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 didn't talk to each other, people didn't

understand what they were saying, people didn't care,

people didn't communicate, people misunderstood. So

I'm not going to go through that. If you're a

student of history, that book makes for interesting

reading. But the point is, the take-home lesson for

the U.S. military was interoperability was very

important. And they do not define it as ones and

zeros. This is 1941 technology. Another good book.

This was research that was done immediately after

World War II and then later. These are 25

organizational deficiencies that led to

interoperability failure at Pearl Harbor. I won't

read through these, but this take-home lesson is if

your organization or your industry or your company is

lacking interoperability, it's an organizational

problem, and there are at least 25 organizational

issues that could be the root cause of that failure.

All of these have healthcare analogies, but

I won't go through them. So good lessons. These are

big failures, these are big issues, and they have

almost nothing to do with technology. So why does

the military care about this? Well, what they do is

complex. Everything they do is complex. It's

nondeterministic, hard to apply formal methods in

(410) 974-0947

318


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

war. That's Schwarzkopf's map from Desert Storm, if

you're not familiar with it.

You can use formal methods on a component,

you know, on a bullet, on a gun, on material, but

when trying to decide how best to use that equipment

or what the enemy will do if you have a capability,

very hard to apply to formal methods. So they have

an enormously complex environment, they have

unpredictable problems, they have a huge Command

Control issue, and these are human problems, these

are organizational issues. And this is where

simulation came in. Sort of a baby view of

simulation. The point here is you see a real ship on

the bottom right, a simulated aircraft on the left,

and they can mix and match simulated components and

real components. They can mix and match simulated

traffic and real communication in almost any

combination.

So in this example, you might have the crew

of a real ship out somewhere and sending simulated

radar data to a simulated command and control device

operated by real humans who are sending their real

analysis of that data to the command staff, which

talks over a simulated radio to a simulated aircraft,

but these are real people. So they're using

(410) 974-0947

319


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

real -- they're acting just like they would in the

real world, but it's over simulated devices.

What this enables the Department of Defense

to do is simulation validation and verification.

This is a very simple view. The point is they have a

real-world view, sometimes actual people on the

field; they do analysis of that to get a conceptual

model of what they think the world looks like. They

put that into simulation, and then they combine the

simulation and the real world, perform actual

experiments, and this allows them to verify what

their concepts were. It allows them to verify the

simulations, allows them to verify their

organization, their processes, their controls. So

validating what can be validated and then to verify

the actual concepts. So war is kind of a hard

problem. Take-home lesson for all of us is that

other people have solved their problems in

interoperability. The caveat to that is they solved

different problems than healthcare.

The military has an advantage over all of

us. There's one customer, one client, and one user,

review of the control, almost everything. I had a

little moment of humor with guys that are talking

about time protocols and how difficult that is, and I

(410) 974-0947

320


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

realize that is a difficult problem. I understand

that. We talked about this, it must have been 20

years ago, on simulations.

It took about four hours to decide that all

simulations for the U.S. military would use NTP, and

they would all transmit over Greenwich Mean Time, and

that whole conversation literally took half a day.

It was done. The standard was set. It was 20 years

ago. So they can do this because there's one

customer, and they can enforce that standard which

enables interoperability down through their

instruments. Aircraft, we have a lot of aircraft

examples. There are two vendors for aircraft.

Customers really hate unplanned events, very bad

thing. So there are some good tools here, but I

think we all understand that healthcare is different.

We have a different set of problems. So getting into

some interesting details.

So I looked at the computer and software

references from that book, and these are the

proportions that these sorts of keywords were

mentioned in the interoperability program from 1989

to 2007. In some ways this is not very surprising.

Standards are very important. Semantics -- very

important. Object oriented came up a lot.

(410) 974-0947

321


Annapolis, MD 21409

1

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 came up a lot.

What didn't come up a lot was system

engineering, service oriented architecture is reuse,

formal methods, and certification. This is perhaps

not to say they're not important. This is only a set

of data -- but these are the big ones, probably

obvious to everyone in the room. Oncology, same

data, different meaning. So when Rick Schrenker says

my client isn't working, that has totally different

meaning than when Brad Thompson says my client isn't

working.

(Laughter.)

MR. ROBKIN: Even though in terms of ones

and zeros, it's the same. You'll have a much better

presentation on semantic interoperability coming up,

but for those of you who are not familiar, the old

OSI seven layer architecture's on the bottom. It

gets data passed back and forth. What semantic

interoperability gets to is the meaning. This is

what you need for interoperability, you need the

meaning conveyed, not just ones and zeros. Object

oriented, probably a phrase familiar to you guys. It

essentially means the same as a systems approach to

thinking about a component or a black box.

You all have had stereos. Only the

(410) 974-0947

322


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

interface is exposed in a stereo. Thank you, Julian,

for this example. There's an advantage to this.

This helps you future-proof your device. My home

stereo, I have an amplifier from 1982 and an iPod

from Christmas, and they work together. I don't need

to replace the amplifier because it only does one

thing, and it has standardized inputs and outputs.

Here's an example. This is the public view

of Bluetooth certification. This is from the

computer software interoperability. A remarkably

waterfall-oriented process that I won't go through in

detail, but to start with, Number 1, basically your

Bluetooth manufacturer determines where they want to

start, what they want to do. Upper right-hand

corner, they select the features and the test plan to

ensure compliance with those features. On the left,

upper left, they do some testing. Bottom left, they

publicize their compliance with those tests and they

pay a listing fee. Now, this was also touched upon

earlier. You have to remember a few years ago there

were some problems with Bluetooth interoperability.

Where that flaw was, was in the right side, was

selecting the requirements for the tests.

Now, they fixed that, but the point being

was that their original requirements were incomplete,

(410) 974-0947

323


Annapolis, MD 21409

1

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 all the testing in the world to meet the

requirements did not help them achieve

interoperability. Another view of a certification

program. I won't go into the details of Continua. I

just want to point out what Continua says is in-scope

is compliance in the performance testing, that the

device meets the standard, the interface standard

that was specified, and that it completes

interoperability testing. That is, the two devices

or when many devices talk to each other.

On the right side you see where it's out of

scope, non-functional testing. These are interface

testing, regulatory testing. These are functions

that have nothing to do with the device-device

interoperability. So this goal, this slide from

Continua, shows a very black box approach, a very

object-oriented approach, a systems -- approach.

What's inside the black box is not important for

interoperability. It's what the device receives and

sends. So I only showed you the chart up to 2004.

I'm sure you're all very interested to know what

happened recently, so on the bottom, healthcare; in

the middle, military; computers, communication, and

other.

So what happened in 2004? So the president

(410) 974-0947

324


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

said something about interoperability to healthcare.

So healthcare is now more than half the references to

interoperability. Number 7. Do you remember the

Graduate? What was the advice? Plastics. My advice

to you, healthcare. Thank you.

(Applause.)

MR. ROBKIN: Anakena is a beach on Easter

Island. It's the only beach on Easter Island, so an

entire civilization came and went through one beach.

That's where it comes from. I don't think we have

time for questions. Any other questions? One quick

one?

(No response.)

MR. ROBKIN: Okay. Next up, we have

Dr. Sandy Weininger. He's a Ph.D. in Bioengineering

from the University of Pennsylvania, now works for

CDRH and you chair the ASTM -- Committee. Didn't

know that.

DR. WEININGER: Well, first I want to

welcome everybody, and thank you all for coming.

John and I are your hosts, and we're really happy to

see you, and I again will reiterate that this is a

workshop, and we are the people in the world that are

interested in this, and it's really up to us to try

to figure out what the next steps are to make this

(410) 974-0947

325


Annapolis, MD 21409

1

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.

So I'm a safety guy, that's my job, is to

try to figure out what it means to be safe from an

interoperable perspective, and so I'm just going to

go through a few issues, which many of which have

already been touched upon, but I'll put down on paper

so we can bring it into focus a little better. Is

Doug still here? Rosendale? Where's Doug? Doug

isn't here but Doug -- so Doug works for the VA, and

Doug has stated that this is probably the most

challenging problem that humans have addressed

throughout history.

As Mike has said, the DoD has a very

complex problem in interoperability, but it's a

single purchaser, and they kind of know what their

objectives are, whereas in healthcare, there's

multiple purchasers; the patient, I would argue, is

actually more complex than the battlefield. That's

why medicine is an art more than a science. So from

an interoperability organizational perspective,

there's lots of different ways to look at the pie,

and certainly, the largest concept of

interoperability is sharing amongst enterprises. So

in Doug's case, it's the VA, VHA, sharing with DoD,

and if you will, also the private sector, because in

(410) 974-0947

326


Annapolis, MD 21409

1

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 case of a national emergency, all hospitals will

be drawn into service and must exchange information,

and that's his responsibility, as well.

Within a particular enterprise, hospitals have

different -- or an enterprise might have multiple

hospitals, and you might go to a particular hospital

to get your tests or whatever, and you would prefer

to have your information translated successfully from

one organization to the other within that enterprise.

Within a particular hospital, there are different

suites of care, and you would like to be able to go

from -- you know, when you get checked in, in the

morning to the next few sessions of labs and whatnot

in the OR, to have all that information translate.

Through the hospital you have

multiple -- you can get discharged from the hospital

into a home setting, and you would like the

information and the scripts to operate your devices

as well as what medicines you're on to be

successfully translated. There's the acute patient

care environment where you might have a much higher

bandwidth needs, entire coupling, and multiple other

venues. I'm not attempting to lay them all out here,

except to say that from the bottom where you're

talking about devices talking to each other in the

(410) 974-0947

327


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

home, transport, and then possibly acute care

environments all the way up to enterprises exchanging

data can be thought of as interoperability and should

be kept in mind when we're thinking about how to make

sure things are safe.

That's really quite a scope of interests

that we have, but I have to try to consider -- this

is more of a conceptual diagram to show that, you

know, on the right is the patient. We are delivering

care to the patient, and that's where my job really

hits the road, it's trying to see -- keep that

patient safe, that is my job, and there are devices

which deliver therapy or monitoring to a patient, and

I have two interfaces here, and I have some type of

black box, I call it interoperability architecture.

And there is some type of desire and

workflow, so you can see that, you know, I'm really

down here in the weeds talking about this type of

interoperability, but that's purely for the sake of

trying to define what it is we want to accomplish.

So I said there's two interfaces. There's this

interface between what the clinician wants to happen,

and then there's an interface between this black box

thing which takes command from somewhere upstream and

applies things to the patient. So -- well, when

(410) 974-0947

328


Annapolis, MD 21409

1

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. Shuren was talking to you, he made a lot of

references to interfaces and to specifying what those

interfaces can do. And Mike just talked about a

whole bunch of different interfaces which have

specification. And so clearly, part of what we have

to do to try to achieve our safety objectives is

understand and define what those interfaces are.

We talked about interoperability from

several different perspectives. This might not be a

complete list, but I'll lay it out just so we can

continue to think more concretely about what it is

that interoperability is meant to accomplish. We

have activities which aggregate data.

Typically, in the home your devices might

populate your electronic health record or your

personal health record and get sent up to your

physician, might be two-way but might only be one-

way, sending information forward to an electronic

health record. There might be an exchange of

information. You might be transferring software

patches back down for a patient ID so that you

associate your devices with a particular electronic

health record, and there might be instrument control

going on where you actually say hey, pulse oximeter,

I need you to average at eight beats per minute or

(410) 974-0947

329


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

sixteen beats per minute because that's the type of

clinical application I have. Again, these have

implications for how we define the interfaces and the

types of -- devices which we're going to try to

capture so we can do interoperability. And I just

listed a bunch of different types of operations just

to try to represent the broad spectrum of things that

can happen.

There's configuration types of operations,

and that could be for a pump. There's pooling data

information out from the hospital information system

or the library, so again trying to establish what the

scope of the particular interoperable system that

you're having get weight and allergy information,

enable safety monitoring for different types of

things.

So there's lots of different intended uses

that can occur which we have to then associate with

the scope of our particular devices. And we all know

hazard analyses, it's simply a tool, but I think the

difference in what's going to happen here is we have

to understand what the scope of our responsibility is

and who is going to participate in that hazard

analysis because if you look at 80001, and I'll get

to that in just a second, starts talking about

(410) 974-0947

330


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

responsibilities, but if I just built a pulse

oximeter and I'm just delivering to you oxygen

saturation value, that's a fairly close scope, but if

I am building a pulse oximeter that I'm selling into

an interoperable world, do I then need to consider

what's going to be done with that information? Is

that part of my risk hazard analysis? Can I draw a

line around that, say no, no, I'm just doing what I

do, my saturation value, and whoever takes that value

can go off and do what they want with it.

So as Mike has said, you know, we're not

the first to try to do interoperability, although we

do have the responsibility of operating on a

physiologic system which is quite complex and not as

well defined as we would like. I mean, airplanes can

fly autonomously because we understand the physics.

I don't think we're there to the point of

understanding the physics of the human yet. We're

getting there, but we're not quite there yet. So it

behooves us to understand and try to lay out

exclusively, one purpose of this meeting, is to try

to collect hazardous scenarios. What can go wrong?

Let's, as a community, try to identify all the

different things that are going to break so that we

can a priori develop and understand mitigation

(410) 974-0947

331


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

strategies, and I can try to synchronize them, and I

don't have all kinds of unknowns going on. Then

along with that comes failure modes and mechanisms.

I mean, these are all risk control strategies which

we're likely all very familiar with. We need to

understand who the stakeholders are. Tim put up a

nice chart yesterday with a bunch of different silos.

Does everybody remember that?

So there was, I think there was ACC was in

there, and ISO and IEC and HIMSS and IG, and I think

even put FDA, and there were different colored bars

as to where that breakout was. I can't quite

remember what the bars were. But it seemed to me

what it lacked was all the spider's web of

relationships between those different silos. And we

need, we need to figure out what that umbrella looks

like and what that relationship is.

We need to understand what is the managing

structure because FDA isn't Big Brother. FDA is not

going to step in and say you must have the following

in place. That's typically not the way we operate.

But by converse, we need reassurance that that type

of thinking is happening out there so that we can

understand that to protect the safety of the public,

that's what our jobs are. So we have technology

(410) 974-0947

332


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

providers, we have technology maintainers, you know,

we're talking about a third layer -- which a lot of

times didn't even come in to our perspective when

we're looking at standalone independent devices. You

know, we're thinking about devices as sensors and

actuators and then some application which might build

on an infrastructure, so that application might just

be a software disk.

They don't make a hardware platform, they

don't make the sensors, they don't make the

actuators, and somehow magically, you know, it's all

glued together and it works, which enables us, the

community, to make a whole lot more devices available

and apply a lot more clinical applications which is a

good thing, right? I mean, you want to be able to

roll out clinical applications as rapidly as possible

in a safe, effective manner. So we still have these

lists, and other people have already brought these

up.

And so there are standards, there are

guidance documents, there are profiles; different

people call them different things, but these are

attempts to say here are the important issues and

here's how they should be addressed. And we heard

from the National Health Service that they use what's

(410) 974-0947

333


Annapolis, MD 21409

1

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 the assurance paradigm, and it's another

technique of trying to collect information to assure

the safety of particular products. It doesn't

have -- or correct me if I'm wrong, but it doesn't

necessarily have concrete, objective assessment

criteria. You must have timing, you know, within a

15-millisecond delay or something like that. It

doesn't go that far. It says you have to make the

argument.

So, again, we need to try to figure out

what are the guts that goes into making that

argument. And other folks are going to talk about

80001, so in the interest of time, we can just

understand it's about identifying the different

responsibilities, and again, I think what we can do

here, as a community, is be more explicit in what

that means so who is going to do it, what does the

big umbrella tent look like, what are the

relationships between the parties in that umbrella

tent, and what are their responsibilities?

So I had the notion or the thought that I

am now Julian Goldman, and I have Lego building

blocks in front of me. Anybody familiar with

LabVIEW? Who's a LabVIEW person? And so you can

take -- my form is a robotics kit where you take

(410) 974-0947

334


Annapolis, MD 21409

1

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 and actuators and put them together -- and

you have to be 12 to do this -- and you use LabVIEW

to program them up so you can have your robot chase

your cat. So now I'm Julian Goldman, and I'm in the

OR, and I have LabVIEW for the OR. So I have an

acute care system, and my patient comes in, and I'm

like all right, it's the day before the operation,

and I need to put all these different pieces together

to go off and accomplish a task, and I have the

brilliant idea that I'm going to implement not only a

new safety interlock using some types of physiologic

monitors, but also in the therapy --

UNIDENTIFIED SPEAKER: God help us.

DR. WEININGER: Well, somebody needs to

help us. So the question is --

(Laughter.)

DR. WEININGER: So immediately, things

spring into mind like will the hospital actually let

him do that because although M.D.'s have been

entrusted -- how can I say this properly? Where

M.D.'s are god and they can do whatever they want.

The stake isn't that hard.

UNIDENTIFIED SPEAKER: As long as they've

paid up their malpractice.

DR. WEININGER: Right, as long they've paid

(410) 974-0947

335


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

their malpractice. But hospitals have to pay that

malpractice for the M.D.'s, so they might have

certain constraints. So it's probably fine -- what's

that?

UNIDENTIFIED SPEAKER: Probably training

history.

DR. WEININGER: Training history. So

ideally, you would have that system maybe, you know,

worked up in an off site, so before you actually try

it on a patient -- maybe you'll simulate it in the

environment and do all kinds -- but the point is that

there is likely some responsible party which puts

some limits on how quickly and rapidly -- so, you

know, there are lots of different issues around those

types of things that I hope frankly will be here in

five years and we need to a priori tease out those

different types of scenarios and understand who is

going to ultimately be responsible for the safety of

the system.

So more about 80001. Talks

about -- strategies and acceptance criteria and all

of those things that we can make more explicit today.

And there's e-mails that you can send ideas and -- we

should.

I mean, I'm telling you, we are the mass in

(410) 974-0947

336


Annapolis, MD 21409

1

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 world which has a handle on this, and it's up to

us to try to figure out what the right things to do

are. Now, realize that FDA isn't just going to go

away, and so manufacturers have particular

environments for reporting. And so there are

incidents that have to be reported, adverse events,

incidents, and there's all kinds of regulations

around that, and again, here I am, Julian Goldman

with my flexible system put in place and sensors and

actuators made by a different manufacturer and maybe

this network thing, black box, that glues them all

together is made by a third-party manufacturer, and

how do I, as a regulator, if something goes wrong,

get to the root cause of that?

We don't necessarily have an NTSB, but we

could. Maybe that's something that we should call

for, but -- so there are likely functions in there

which can help tease out what goes wrong. And I

suspect that the big unspoken word in the room from a

manufacturer's perspective is liability. I mean, who

wants to open up themselves to liability? I mean,

why would I make any of my features available to

anybody else so they can come along and beat on it?

And I can get sued. I don't want to get

sued. Anybody involved in a cyber security issue in

(410) 974-0947

337


Annapolis, MD 21409

1

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 last few years has likely seen this stool. I

added a few components to this stool because even

though it said IT vendor, it was plural for vendors,

I'm having, you know, multi-vendors and multiple

device manufacturers, and there's probably multiple

health IT administrators, but at least from a

perspective that a device is used on any particular

person at any one time, so we need to define what

this stool looks like. I almost hesitate to use a

stool because in a stool, after there's more than

three legs and you pull out one leg, the stool

doesn't fall over, right? I mean, it's

relatively -- so maybe this is a good model. Maybe

we want such a robust system that I can pull out a

lot of legs and my patient is still safe. Can we

design such a system? Can we architect the big

picture? You know, do we point at everybody else?

If we're going to do that, we are not going

to have interoperability, I will almost guarantee

that, you know, so we -- again, these aren't new. We

need to come around the table which is thankfully why

we are all here today, I believe, to try and solve

the problem, to try to understand what that table

looks like, how high it is, what its dimensions are,

and what it's trying to accomplish. So with that, I

(410) 974-0947

338


Annapolis, MD 21409

1

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 very much, and hopefully, we're going to

have --

(Applause.)

DR. WEININGER: And now we're back on

schedule. So let's discuss -- we have a few moments

for questions, I think, and then -- let's take some

questions first. Questions? Not of a regulatory --

(Laughter.)

DR. WEININGER: So Julian's going to make a

few announcements, and then he'll introduce Scott

since he's --

DR. GOLDMAN: Yeah, I actually just wanted

to make sure that everyone here knew and appreciated

how many months of hard work went into planning this

workshop by both Sandy Weininger and John Murray.

Sandy -- what wasn't said is that both of them

started, actually hosted another meeting. There was

a meeting here at CDRH and specifically in 2004, in

November, on Medical Device Interoperability that

wasn't as widely publicized, but it was fairly well

attended; there were 75 people.

And so the work actually in this area, with

some of the same folks, really started in 2004, and I

want to publicly acknowledge just how hard John and

Sandy have worked to get all the approvals that were

(410) 974-0947

339


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

required through the Agency, getting by and its

support, and also the foundational work on moving

this forward that was started by Continua, a

regulatory working group, about a year and a half ago

or so, kicked off by Mike Robkin and who else was

that? Scott Thiel, right. Who we can't introduce.

So, anyway, it's really a tremendous amount, and

Sandy and John are too modest to tell you what

they've done, but I think everybody should know that,

and I would like to acknowledge that.

(Applause.)

DR. GOLDMAN: Here's Scott.

MR. THIEL: Somehow I think I got the ten

o'clock spot. My name is Scott Thiel. I'm chair,

current chair, of the regulatory working group in

Continua. I'm also a regulatory affairs professional

at Roche Diagnostics within their diabetes care

organization. I'm also one of the other bleary-eyed

folks who have suffered countless hang-ups in my

e-mail from sending and receiving so many large

documents over the course of time to try to get this

entire thing organized, and I, too, would like to

thank everybody for attending and the participation

that has gone on.

Honestly, I could probably stop with this

(410) 974-0947

340


Annapolis, MD 21409

1

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 right here because all of the points that I'm

making in my slide have been brought up from time to

time throughout.

It seems as though even though we have a

variety of perspectives gathered within this room,

that we all seem to be touching on a lot of the same

points, and that's a good thing, I think. I think

it's a good thing to see that the diversity that's

here is looking at this problem in many of the same

ways. So in order for me to get past my legal

counsel at Roche, I had to add a disclaimer to this,

so here's my disclaimer. These are my statements

that are in here, but I'm not the only one that came

up with these. This is based on information that

came in from the organizing committee, so thanks to

those folks, to the participants in the Continua

Health Alliance regulatory working group. In

particular, I had some direct feedback from Russ Gray

in the Anson Group -- Russ is not here -- and also

from Brad Thompson, Epstein Becker and Green.

It's also based on 20-plus years of

experience that I've had within the medical device

industry. And then some years prior to that, I also

was the user of a lot of these products as a medical

technologist, so I got to play overnight with a lot

(410) 974-0947

341


Annapolis, MD 21409

1

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 these products and experience the failures and the

struggles and the problems and the late-night 1-800

calls to -- gee, why is this doing this, this way?

My goal is to try to represent

manufacturers' needs, so what is it that a

manufacturer needs to have in order to develop and

manufacture these devices that will help us to answer

some of these questions? We want to get these

products into the marketplace. We can't have an

interoperable interface without any of the devices

there to actually realize that. And I'm hoping that

I will be able to cover both medical device as well

as non-regulated or non-medical devices in this. My

perspectives are going to be a little bit skewed

because most of my experience has been with medical

devices. But I think that a lot of what I've got to

say is going to be relevant for non-regulated

products as well. So I'll give a little bit of

background, we'll look at some developments in

pre-launch, post-launch, and then a listing of

questions and ambiguities.

So we've already heard from several folks

what some of the history is, but FDA has been set up

basically to regulate a single device system with a

relatively narrow scope of intended use and

(410) 974-0947

342


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

indication of use, looking at the single

manufacturer. That's not the environment that we're

talking about today. We're talking about multiple

manufacturers with potentially multiple intended uses

that could be tied together in any multiple way, and

that's not something that's currently set up to be

managed real well today.

I'd also like to recognize that prior to

this workshop, there has been an inordinate amount of

work done. There's been a lot of legwork that's been

done to lay some blocks, some groundwork that's been

done. A lot of this stuff you've heard already today

through HIMSS, MD PnP -- IET, IUC (ph.). If I've

forgotten, you know, some portion of the alphabet in

there, forgive me, but I don't know all of them that

belong in there, but I know that there's been a lot.

And there's more to do. Today's not the culmination

of all of this. This is just another stepping point

in this. Hopefully, this will turn out. If we all

work together with this, this will turn out to be a

nice chapter in this whole story so that we can

actually realize some of these things and not have

some of those horrific pictures that Julian shared

with us, of patients that are injured.

And I'm sure there are several others that

(410) 974-0947

343


Annapolis, MD 21409

1

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 bring pictures to bear that are home-use issues

that are the same type of thing. We've heard why

interoperable devices are needed. We've heard what

the devices answer, so the setting of the

stage -- we've heard from Sandy who some of these

actors are.

During some of the use case presentations,

we've heard here are some technical challenges that

we have, here are some clinical challenges we have,

here's safety and effectiveness challenges we have.

Later today, we'll hear some more of these types of

things. So what is it that manufacturers bring to

the table? They're pretty good at addressing how, at

least some of the how. How do you design and develop

a product to support an infrastructure and to support

a need, to develop a device, to answer a question, to

deliver some sort of therapy? We're pretty good at

gathering folks that have good technical savvy,

background, putting these pieces together, test the

living daylights out of the thing, and then put it

into the marketplace. But we've got to have some

good understanding of some key needs, and I'll come

back with a good understanding definition in just a

bit.

So, basically, manufacturers, all

(410) 974-0947

344


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

manufacturers, go through certain categories of

activities. And in the table in front of you, on the

right-hand side, there's just some general

categories. And it doesn't matter whether you're

making and mass-producing shoestrings or making a

ventilator, you're going to follow a lot of these

categories.

It's how much effort you put into these,

what's the risk analysis that's associated to it,

what are the requirements that go along with it. On

the column on the left, I've tried to identify, with

these general categories, if you're a medical device

manufacturer, how does that match up with the quality

system. So some of the language that medical device

manufacturer would be interested in is intended use,

indications for use, what's the validation, what's

the verification, who is generating these

requirements, how do you get a 510(k) through the

system, how do you do a PMA, those kinds of things.

So the development activities that any manufacturer

follows is pretty much the same. Pre-launch,

though -- and this is a very high level -- pre-

launch, manufacturers need to understand what the

customer needs, even sometimes to the point of

forecasting what that customer needs.

(410) 974-0947

345


Annapolis, MD 21409

1

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 there is, regardless of how quickly and

how nimbly a company will operate, there is a lag

time between when you identify what a need is and

when you can actually realize what that product is.

By the time you get there, especially in the way that

things are working today with cell phone and

technology, how quickly things are coming out, by the

time you get the product developed, many times you're

already past the need. Somebody else has already

answered that need or the need is no longer there or

the need has shifted radically enough that now your

product no longer meets the need sufficiently.

So as a manufacturer, we have to sometimes

be able to try to predict and we need the input from

a customer basis to help us predict that because we

don't know exactly how all of these products are

used. While we would like to spend more time out in

the marketplace with customers, we can't spend all of

our time out there because we have to spend some of

our time actually developing and manufacturing and

all these types of things. We also need to have a

predictable development and manufacturing

environment. This means a clear, consistent rule to

understand how we can legally classify and market a

device.

(410) 974-0947

346


Annapolis, MD 21409

1

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 the legal classification piece of this

comes into play for unregulated products because you

have to understand when your product is and when your

product is not a regulated device so you know whether

or not you need to go talk to FDA about this, whether

you need to file a 510(k) for this, how is it that

you want to market and develop this product such that

you no longer have to worry about am I playing in

regulated space or not.

You want to understand what that is, so

there have to be clear and consistent rules in place

in order to make that happen. There also have to be

reliable and consistent methods for confirming the

requirements -- so these are standards, these are

guidance documents, these are predicate devices in

the vernacular of device manufacturers; those are the

kinds of things that we need -- how we need to

understand how it is we're supposed to test this so

that we can plan adequately for it. If it's not

clear and consistent and reliable in the way we can

do this, then it makes it very difficult for a

manufacturer to sit down and say gee, I have

this -- I see this need that's out there. I think I

can have the technical solution to do this, but I

don't know exactly what it is that I'm supposed to

(410) 974-0947

347


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

meet, what standards I'm supposed to meet. I don't

know how I'm supposed to test this, what information

is actually needed in order to verify the product is

working the way that it's supposed to work.

If I don't have those things in place, then

I'm probably not going to spend the money to develop

the product in the first place. If I can't figure

out what my ROI is on this, then I'm not going to

bother stepping up to the plate and spending the

money on it. So those are the kinds of things that,

as a manufacturer, we need to have some level of

consistency.

I understand that we need to be more agile

and nimble in our development and process, but at the

same time we have to have a predictable environment

to work within; otherwise, we can't afford to

continue to throw money after these things.

Post-launch. Again, I don't think it

matters what type of product that is being

manufactured, you want to have reliable and timely

information about our product. This goes especially

for medical devices in order to be able to report

back to the Agency if there is a significant failure

with your product in the field, what is it that

you're going to do to fix it to make sure that no

(410) 974-0947

348


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

other failures like that occur. But it has to be

reliable, and it has to be timely. My daughter came

to me the other day, and she said, Dad, I'm missing

five dollars. And I said okay, well, when did you

first notice that you missed this five dollars?

Oh, two weeks ago. Oh, do you know where

you were two weeks ago? No, I was somewhere in the

house. Well, that's neither reliable or timely. I

can't do anything to help my daughter out in that

particular situation. The five dollars is gone. Who

knows where it went? It may have ended up in my

pocket. We also have to understand what acceptable

failure types and rates are so products can't fail on

the field that are going to fail on the field.

You're never going to have the perfect

product. I think everybody realizes that. But what

is an acceptable and a non-acceptable failure? What

types of failures are acceptable, what rate of

failure is an acceptable rate? So that we know that

when we're monitoring field information, when is it

that we're supposed to react quickly, when is it that

we can actually take that information and just put it

into some sort of life cycle management activity for

the next generation of product. We need to be able

to understand what is and is not acceptable on that

(410) 974-0947

349


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

case. Sandy mentioned this a little bit as well. We

need to have reliable root cause failure analysis

methodologies. The manufacturer takes a lot of that

responsibility on themselves, so they need to be able

to design the products so that they can do these

types of things.

But it would be nice to be able to do the

root cause analysis while it's in the hands of the

end user rather than having to wait for the end user

to ship the product in, and you lose some of that

context, you lose some of the information that may

have been valuable along with that, so how is it that

we can accomplish reliable and quick root cause

failure analysis?

How do you do these things in the

environments that we're talking about? Manufacturers

also want to have reliable and cost-effective methods

for updating product in the field, especially when it

comes to things like software. So it's very easy for

me to take my iPhone, plug it in to the computer, and

I get an automatic update. I don't even have to

think about it most of the time. It tells me oh, I'm

downloading this; please don't unplug me. Medical

device manufacturers have a bigger challenge in front

of them to be able to do those kinds of things. So

(410) 974-0947

350


Annapolis, MD 21409

1

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 is it that we can foster an environment that

allows for those kinds of things to actually take

place? These are just some of the questions and

ambiguities that have come out of conversations that

I've had with a lot of folks over a long period of

time.

They get to the point of what are some of

these issues that manufacturers have to address

throughout the product's life cycle, so-called

cradle-to-grave -- actually, I like the phrase that

was used better yesterday, the lust-to-dust phrase.

But in particular, with interoperable devices -- so

what is it that we have to address throughout product

life cycle management? A lot of times I like that

"ask our designers; okay, yes we can develop this

thing," but what are you going to do once you let it

out?

Now, that it's in the marketplace, now

what? How do you manage that product, how do you

maintain it, how do you update it? If we put some of

these things out in the marketplace, if we let the

lion out of the cage, then what are we going to do

with him? So we need to have a plan in place for

post-market things as much as we have for pre-market

things. We also need to take a look at what

(410) 974-0947

351


Annapolis, MD 21409

1

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 are practical for both regulated and non-

regulated manufacturers. Can they be the same

solutions, and how do the use case environment play

into this?

So -- how am I doing on -- I'm doing all

right? Okay. We'll run quickly through these.

These questions and ambiguities might be of use

during breakout sessions. They might be of use as

further conversation of what are some of the next

steps.

Indications, intended use, and indications

for use. How are we writing intended use and

indication briefs as a manufacturer for me to submit

to the FDA that says here's this product, it can

connect with multiple devices; gee, I don't know what

those multiple devices might be. Is it okay for me

to say it can connect with oh, anything, it has this

label on it, or anything that it might run into in

the marketplace.

How can we assess whether or not a product

is or is not a medical device if there's no clear,

final system? So, again, we're connecting one to

many, one to unknowns. How do we determine whether

it is or is not a medical device? How do I counsel

marketing and sales on what claims they can make? A

(410) 974-0947

352


Annapolis, MD 21409

1

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 this we'll be hearing from intended use, but I

can tell you right now that my marketing folks are

very, very, very creative people. They come up with

stuff that I have absolutely no idea where it comes

from. And, honestly, I'm disappointed if I come out

of a meeting with my marketing folks, and I don't

have a headache. That's their job. Their job is to

push me and to figure out ways to market this. But

they're going to come up with ways that I can't think

of right now today on how to market these things, and

I need to be able to guide them.

You know, one in particular is co-marketed

or co-rated products. Who is the customer going to

call? I think we've heard this a couple of times

when we collect field information. What manner will

the quality issues be communicated? So we're going

to put this on a multi-functional device that has

cell phone capabilities. Well, that means that they

probably also connect Facebook and Twitter, and

manufacturers are now getting some of these pages

that are out there.

I believe there was a workshop earlier this

year that talked about social networking, so what

level of responsibility does the manufacturer have to

monitor those particular channels in order to gather

(410) 974-0947

353


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

information? Are we responsible at all for those

types of things? We need to understand this. Again,

root cause analysis. Who to involve if there's no

clear root cause for discrepant information? What if

the manufacturers of the various devices don't even

know that they're connecting to each other

necessarily in the field and the fact that they've

got a communication protocol built into them that

easily links one with the other or their direct

competitors or they disagree? Is there a possibility

that, you know, we can come up with a solution for

this type of a thing?

In a field recall situation, which is very

similar to this, which company reports this? How do

we make sure it doesn't get reported multiple times

so that we're focusing all of our efforts on the

wrong problems? We want to make sure we're focusing

our efforts on the right problems. What are

acceptable test methodologies? Can these be

developed and applicable for all types of technology

for a given type?

In other words -- for an example, are all

types of wireless the same? Personal area network,

local area network, wide area network, do you do the

same type of testing, the same rigor in each one of

(410) 974-0947

354


Annapolis, MD 21409

1

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 areas? Probably not. If a third company

happens to come along and say, gee, it sure would be

nice if my customers that have this particular

disease -- have these five products that I know

communicate with each other because they're labeled

that way, but they got them all together in one handy

kit. Well, what happens now? Is that company now a

manufacturer themselves, are they a re-packager, are

they a kit assembler? Is it some other type of a

thing? If they send it out there, then how is that

they're supposed to ensure that these products -- is

it sufficient to simply say it had the same label on

it and that's good enough?

And how do you avoid creating new intended

use simply through the act of packaging these

products together? One specific example of this is

packing together a prescription use product with a

non-prescription use or an over-the-counter type

product. Can this be done without impacting the

status of the OTC device? So in other words, you

don't want to make an OTC device now all of a sudden

a prescription device and carry along with it all of

the burden that should go with a prescription device

but isn't necessary for the OTC device.

Is there special labeling? Who's

(410) 974-0947

355


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

responsible for manufacturing the distribution of the

prescription device that may go into this kit? End

users, meaning in this particular case healthcare

providers. Can they put these regulated and non-

regulated pieces together without themselves becoming

a manufacturer? Is this part of the practice of

medicine? Is it part of manufacturing? How does

this exactly play out in the regulations? Again,

those are just some of the questions that I'm sure

come to mind at least for some of my medical device

regulatory colleagues, maybe some of the other folks

that have been working in this space for quite a

while.

I know there are a lot more questions than

that, but hopefully this will stimulate some thought

and be able to get us active in the following use

case presentations and also in the breakout sessions.

Time for -- yeah. Thank you very much.

(Applause.)

DR. MUN: I'm Dr. Mun from HCA. I work at

the hospital level.

MR. THIEL: Okay.

DR. MUN: What we have seen, as a general

pattern, is that when a manufacturer wants to gain

market share, they talk -- when they gain market

(410) 974-0947

356


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

share, then they slowly fade away and they do other

things. So how will you change or -- what do you

suggest? How would we deal with that or will culture

at the manufacturer side change so that you don't do

that anymore?

MR. THIEL: I think it's a matter of -- and

this is just me talking, is I think it's more a

matter of understanding how is it we can actually

accomplish and claim interoperability at the level

that we want to talk -- that we're talking about here

today. How do you actually fit that into the

intended use statement type of situation? How do you

actually claim that you've got this so that it can be

an ongoing type of thing so --

DR. MUN: I understand that, but --

MR. THIEL: Yeah.

DR. MUN: -- at least the behavior. Maybe

it's the salesman's fault.

MR. THIEL: Yeah.

DR. MUN: You know, when they have a little

market share but they want to eat somebody else's

market share --

MR. THIEL: Um-hum.

DR. MUN: -- they always -- oh, yeah I can

interface with the other guy. But when they have a

(410) 974-0947

357


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

large market share, all of a sudden they release a

version which is no longer compatible with anybody

and --

MR. THIEL: Yeah.

DR. MUN: -- that seems to be, at least, a

perception, should we say.

MR. THIEL: Yeah, yeah.

DR. MUN: Thank you.

MR. THIEL: No, it's a good question to --

MS. BRADY: Turn the microphone back on.

MR. THIEL: Sorry.

MS. BRADY: I'll try to use my cheerleader

voice.

MR. THIEL: All right, Mary.

MS. BRADY: Yeah. Just to draw to

everybody's attention -- is this working? Just to

draw to your attention, in case you didn't know about

it, we did have a press release on Friday regarding

the 510(k) process, and we're going to have a public

meeting on that this next month on February 18th.

There will be a Federal Register notice

tomorrow on that, so I would encourage people who

have these interoperability questions, especially in

the area of 510(k), to please try to attend this

meeting or to have somebody from your company attend

(410) 974-0947

358


Annapolis, MD 21409

1

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 meeting. Thanks.

MR. THIEL: Thanks, Mary. Yeah, that's

good information.

UNIDENTIFIED SPEAKER: Scott, thank you

very much. It was a great presentation.

MR. THIEL: Thank you.

UNIDENTIFIED SPEAKER: I think one thing

that you highlighted that I'd really like to

underline is the shared specifications that --

UNIDENTIFIED SPEAKER: Can't hear you.

MR. THIEL: John, your mike's not on.

UNIDENTIFIED SPEAKER: We have a mike at

the desk. Push the button. Okay, the shared spec

responsibility. So, as an example, to -- for a

ventilator, to allow it to pause on X-ray, the

requirement on both the radiological system so the

ROE system and WIS (ph.) system as well as the X-ray

machine and the ventilator as well, it's a shared

requirement obviously. And who owns it? How does it

get spec'd? How does it get tested? You have two

different companies and two different spaces, et

cetera, and I can't underline more how that is so

important. I'm not saying that this is an impossible

problem to solve, but I think it's a completely new

space.

(410) 974-0947

359


Annapolis, MD 21409

1

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. THIEL: All right.

UNIDENTIFIED SPEAKER: How do we address

it?

MR. THIEL: I agree. I think it becomes

maybe not more complicated, but a different

perspective on the complication -- and we'll get into

the home use environment then -- because you've got

different risk factors that are involved with that as

well. But, yeah, you've got a shared space. It is a

challenge, I agree. Yes, sir?

DR. BLOCK: Frank Block from VCU. Just to

give a little historical background, back to the

early 1990s, many companies at that time were taking

their multi-parameter patient monitors and trying to

get them to talk to specific other devices with

specific modules, specific cables, specific protocols

and so on, and they would then file an FDA

application that says we're going to talk to the

specific model made by this specific company.

There was, however, another one of these

manufacturers who decided to do a little test, and

they filed a 510(k) that just said our monitor's

going to talk to a whole bunch of other devices, and

they sent it in to the FDA to see if it would go

through, and it actually did. So I don't know. I

(410) 974-0947

360


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

don't know where we are at that --

MR. THIEL: I've been told that we're down

to zero time, so I think we'll have to cut the

questions off now. Again, thank you very much, and

we're ready for our break now.

Oh, hold on. We've got one announcement

here, sorry. Okay, is John Denning here someplace?

John, we need your presentation to get loaded up

here, if you could, please? And then we've got a

break --

(Off the record.)

(On the record.)

DR. GOLDMAN: I have a quick request from

our infrastructure people. Yesterday we trashed the

room. Can we please not trash the room today, and

take your garbage and throw it out in the trash

receptacles.

UNIDENTIFIED SPEAKER: We don't have trash

cans.

DR. GOLDMAN: You have to take the trash

home with you.

(Laughter.)

DR. GOLDMAN: It's government trash, so we

can recycle it out. No, there are trash cans out in

the hall, so --

(410) 974-0947

361


Annapolis, MD 21409

1

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: No, you can't take

government property with you.

DR. GOLDMAN: Thank you. In general, you

can't take it with you. Thank you, Sandy. We will

try to be more attuned today or respectful of the no

trash policy, all right.

Well, the next session is going to be

moderated by Rick Schrenker, and I wanted to take a

few seconds to introduce Rick. Rick is the head of

the System Engineering Group within Biomedical

Engineering at Massachusetts General Hospital, and a

week ago, Rick marked his 20-year anniversary working

at Mass General. That's staying power. Before that,

yes, in Baltimore, he was at Hopkins at a decade

prior to that. Rick's been involved in a lot of

interesting areas that extend beyond the scope of

most typical biomedical engineering roles, including

his work in standards and now is the user rep, U.S.

user rep, for the 80001 standards work which -- so

anyway, I'm really fortunate to have learned a lot

from Rick at work and to work closely with him, and

also someone else on the panel, Luis Melendez. I'll

be here at halfway.

MR. SCHRENKER: Okay.

DR. GOLDMAN: Okay.

(410) 974-0947

362


Annapolis, MD 21409

1

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. SCHRENKER: Okay. The official title

of the session is Software Issues, and I'm going to

suggest, you know, sort of a background question is

just what is it about software, anyway, and just

leave it at that. I want to lead into the

introductions for -- following up on the last

presenters and some yesterday, and that was there was

reference to intended use which sort of talks back to

14971, and it reminds me -- in a way, it was starting

to roll around a little bit, in the last couple of

sessions, it reminds me of an insurance case workshop

that I think was right in this room a couple of years

ago with FDA, and there were lots of questions about

the FDA's interest in insurance cases. And a couple

of times I had to raise my hand and say -- the

interest was between manufacturers, very valid types

of questions: what are you going to expect of us if

we're going to be required to submit insurance cases

or if that's an option for us?

So this discussion, this conversation, was

going back and forth between people from FDA and from

manufacturers, and I'm over there, well, what about

us? I mean, you're doing this work for us, and we

sort of need some transparency, some way to look into

it because this stuff is more complex.

(410) 974-0947

363


Annapolis, MD 21409

1

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 there's no need for me to speak to that

anymore, but I thought a provocative idea -- and

we'll get back to it, but since I couldn't get it in

at the end, and that was there's a lot of talk about

intended use, and if people like us, at MGH and

Partners, and we heard from Kaiser yesterday, we want

to be systems integrators, believe we can do it, know

we can do it. We know about intended use probably

most of the time better than manufacturers or

regulators, but for us to do that, we need to know

intended design or the intent of design. We need to

know, you know, what you were thinking or some

indication of -- I mean, if you publish an interface,

for instance, that's fine, but I might need to know a

little bit more about that in your device. I'm not

sure, but I just want to throw out this idea that if

we're going to be integrators, we have to know what

you were thinking when you built it. The question

we're often dealing with is one around validation:

what did you do to validate the device because we

need to understand that within the context of our

operation.

Enough said. There are two other

presenters here. Get to that later if anybody else

wants to talk about it. The first presenter will be

(410) 974-0947

364


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

John Denning, an independent consultant, and he's

going to be speaking to Safety and Effectiveness

Issues in EMRs. And the second presenter is my

colleague, Luis Melendez, Assistant Director of the

Medical Device Integrations and Informatics Group, is

that right, Luis? Is that your -- and he's going to

be talking to Medical Device Data Patient Context

Challenges.

MR. DENNING: Thank you, Rick. I'll be

speaking to you on safety and effectiveness issues in

medical records, electronic medical records, and I

think you'll see that there's a lot of topics that

we've covered already, so I'll just sort of cruise

through those. One of the things that I'm seeing a

lot is -- I'm sure unless you're sleeping, you are,

too -- there's a tremendous focus on EMRs. Every

time -- I used to have to search for the topic, you

know -- the industry and whatnot. Now, it's just

everywhere. But the thing is, is that I wanted to

make sure to point out that it really took huge

financial incentives to really get that next group of

institutions to sign up to do this.

I mean, the -- flow really wasn't there for

a lot of vendors, and now it's really picked up, and

it's causing institutions that typically would not

(410) 974-0947

365


Annapolis, MD 21409

1

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 even considered it, they're now diving in and

choosing to implement. One of the challenges is, is

that there's really few success stories that exist

for documents in such a way that that second tier of

institution that's starting to implement -- and gain

benefit from.

I believe a big part of this is that -- I

think a tremendous part of this is that there's a

real lack of consistency across products so people

can't -- there's no comparability between the

products. Even though they may fit, they may conform

to a standard, but the way that standard's actually

implemented is so different between the products that

there really is an apples-and-oranges kind of

question. It was interesting. I had a sidebar with

Luis just a minute ago about the integration of

devices with EMRs. You know, this is a conference

surrounding interoperability, and it seems as though

the EMRs are always kind of shown as being -- it's

not the system of record, necessarily, but it could

be. In many cases it's assumed and implies it's in

the record. Precious few devices are integrated with

medical records, particularly at the point of care,

anesthesiology being one of the few exceptions as far

as disciplines.

(410) 974-0947

366


Annapolis, MD 21409

1

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 this final bullet point on here, just

there's considerable contention between the vended

products. If you're looking at things between PAPs

(ph.) and like a straight EHR that's not, you know,

one of the fully integrated vendors, and it's

fighting over the functions. Lab order management,

that sort of thing, is actually one of those

functions.

It's a big function, but it ends up

being -- no one's quite sure where it is, oftentimes

without the implementations, so it's not done

terribly wrong. My assumption is that everyone in

the room has heard about Senator Grassley's letter,

infamous letter, going out to ten institutions and

ten vendors in October. I don't think it's as

ominous as some of the media reports, but I think he

just wanted to get a lot of data about this because

the government is in the process of spending a

considerable amount of money. And it was followed up

with, just this month, 31 hospitals receiving an

equivalent letter to provide that information. So I

think it's going to be a somewhat bumpy road ahead,

or at least there's going to be complete -- about

EMR.

One of the things that Senator Grassley was

(410) 974-0947

367


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

looking for was information around licensing and

around the gag clauses and the types of releases that

the EMR vendors are able to enjoy, which I know

having spent, you know, the last day or so with you

all, devices certainly have -- are tested for a much

tighter -- to a greater extent are being released

even if they're in the unregulated space. So this is

just -- it's pretty much a complete release.

It says, you know, we'll both test this

product, you know, we'll test it before we ship it to

you and you'll have to test it and you have to report

to us any bugs that you find. It's pretty

astonishing. It's actually based upon my experience

working with many vended products. Things aren't

terribly well tested when they come out. So -- and

this one I thought was particularly good. This is

the new iPhone EMR app license, and this one

is -- it's a heck of an eye chart. The thing is this

one says basically there is -- it doesn't even -- it

says it may not even necessarily work for the

intended purpose. And the penalty is a $50 fine.

It's the maximum -- and this is for physicians using

the EMR via the iPhone. I just thought it was --

UNIDENTIFIED SPEAKER: Is that Airstrip or

whatever it's called?

(410) 974-0947

368


Annapolis, MD 21409

1

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. DENNING: No.

UNIDENTIFIED SPEAKER: Yeah, but this is

also a good example of a lawyer doing his job

properly. This is a proper job for that perspective.

MR. DENNING: Sure. And if the employee of

an institution is able to accept this as an unusual

licensing agreement, this is -- so it's not lawyers

reading it, and it took a lot of work to actually

copy the license out of the iPhone.

(Laughter.)

MR. DENNING: So what I wanted to do is

walk through a couple of the flows. We talked about

this as flow some in context. It's come up a few

times, and I thought it made sense, actually, to put

it on process flow, one that's more complex than, you

know, grooming a patient, that sort of thing. And

this is one that's really -- how would you go about

determining what type of care a patient should get

based upon what kind of information you have, and

it's more of a long-term relationship, and it weighs

in things like, you know, value, best practices, the

individual's risk assessment, and whatnot. I think

you can see there's some technology named, such as

like Business Rule -- but there's a lot of medical

devices that could be plugged into this sort of flow.

(410) 974-0947

369


Annapolis, MD 21409

1

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 trick is you have to take that flow and

you know, the 10,000, you know, real specific

business workflows that any big institution can come

up with, and you have to plug it into something that

looks kind of like this, you know, a general, you

know, business cheers technology-type architecture,

conceptual. But it's not terribly clean doing that.

And you also have to be sure that you're testing

everything.

Well, another view that I've rarely seen

used and figured it's worth putting in here -- oh,

also please note that the B model for quality testing

is the waterfall or usually is the waterfall,

so -- but what you're really testing is a hierarchy

of systems, and this is a pretty simple hierarchy of

systems. The larger healthcare institutions would be

a heck of a lot more complex than this. So one of

the things that I wanted to drive home, and these are

just quick observations, is the EMR products.

There's been little to no regulatory oversight of

these things, and it's actually been real interesting

working for software companies that are pure EMR.

There's pure software companies working for a medical

device manufacturer that went into the software

business, and that was like two different cultures.

(410) 974-0947

370


Annapolis, MD 21409

1

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 the people who work in the EMR space

oftentimes don't know a whole lot about the

regulations. I mean, they may have a few people

within the company, but it's not pervasive. That

knowledge is not pervasive in a software company.

Something that I want to make sure, at least touch

on, I think a lot of folks have started getting into

yesterday was around the sustaining of the EMR

investments over time.

These things require a lot of patches and a

lot of updates, and there's a lot of training usually

if you're going to do it right. Again, the smaller

institutions that don't have -- that didn't have the

resources to do EMR earlier who are now looking at

this and getting into it, they don't upgrade -- they

don't update a whole lot of things. So -- and a lot

of these healthcare organizations or IT shops operate

at CMM Level 1, and that's only because there isn't a

Level 0.

(Laughter.)

MR. DENNING: So here we are, we're

actually implementing really complicated stuff, okay,

and we're going to depend upon it for doctors and

nurses who are providing care and questioning how

they're going to deal with --

(410) 974-0947

371


Annapolis, MD 21409

1

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: And why are you

looking past the initial sales? I don't understand.

MR. DENNING: It's a good question. And I

also wanted to hit a little bit about the

nonfunctional requirements. I think that was a topic

that was discussed. It came up a lot yesterday, but

it wasn't called that. It was called a lot of

things. Why don't we do this? Why don't we have

that? We don't have nonfunctional requirements in

general, and I think that needs to be emphasized.

I think that as the device community wants

to work with the HR or EMR community to make sure

that their needs are met, the device community could

specify what those nonfunctional requirements are.

You know, oftentimes the stakeholders are accountable

for this, are very difficult to identify. They'll

step up and say hey, I'll give them to you. Your

needs will be met. Another aspect that is, I think,

quite different compared to the implementation of

devices is that EMR implementations are typically

multi-meter and often never fully completed. You can

tell, you can count the sockets or monitors, things

like that. You can't with the EHRs. So that's all.

(Applause.)

MR. MELENDEZ: Okay. First, I want to

(410) 974-0947

372


Annapolis, MD 21409

1

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 a few people, our hosts, our executive

committee. I really have overheard so many people

say that it's been extremely successful and just how

so many people have said we've got to keep in touch

because one of the pieces that were emphasized

yesterday is just getting all the people together in

a room and actually interacting is one of the most

important grass roots kind of piece.

We talked a lot about what Julian does.

I'll try to describe a little bit about what I do and

some of the challenges I've faced. The other group

of people that I want to thank are the EB specialists

and the IS folks that are here today because I've

been in similar circumstances numerous times in

operating rooms as compared to this kind of an

environment, but I think they were under a fair

amount of pressure, so thank you for helping out.

(Applause.)

MR. MELENDEZ: Okay. Boy, this feels, even

though I've never been, a little bit like -- because

I am a systems integrator. For the first decade of

my life, I was in product development, medical

devices, and from there I kind of evolved in a five-

year plan. Wanted to work in a hospital to see the

stuff in use. I was working for a company that made

(410) 974-0947

373


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

surgical cameras, insulators, light forces, so forth,

but I felt like I wasn't really well enough, familiar

enough, with how this stuff was used, so I had an

opportunity to go to work at MGH in the ORs.

It was a five-year plan, did that, and I've

now been there 14 years, and so it's a tough

environment to leave for a number of different

reasons, and no one's holding a gun to my head, so

very interesting place to work. So I'll talk a

little bit about patient context and some of the

challenges I've faced, and it seems like I'm not

bringing up a whole lot of things new because a lot

of this has been discussed already.

The interesting challenges to us has really

been how do we put all these pieces together and

really follow the information, the idea that we're

looking for from beginning to end and make sure that

it's presented -- with the kind of reliability that

is really needed in this kind of system. So one of

the early-on pieces that I realize are two really,

really important pieces. I'm going to talk about

one, among others, but one of them is this whole

patient context piece. It's really understanding

what patient, what human being that device is

attached to and the data that it produces, and then

(410) 974-0947

374


Annapolis, MD 21409

1

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 second piece, at least to my little narrow focus

of the world, is the device, itself, is really

understanding that you need to identify, but I'm not

going to spend too much time on that because I really

don't know all that much about it.

I made a good connection on that today, so

that's one of the values of participating in these

conferences. So I'm going to just box in what

medical device patient context is by just saying it's

some way of applying some, for a successful, patient

identifying information to the data that the device

produces. It can be used, as we talked about

probabilistic matching, as we talked about yesterday,

or index.

I'm just presuming that -- not presuming,

suggesting that we just tackle this particular facet

of this problem because it really enables a lot of

future capabilities that we just don't have today and

stuff that, primarily at the grass roots, are really

struggling with today. So a particular challenge is

it has to get there in the first place. A lot of

medical devices that we have available in our broad

spectrum inventory of medical devices at both

campuses -- I work at BWH and MGH -- is that the

medical equipment, by and large, doesn't get the

(410) 974-0947

375


Annapolis, MD 21409

1

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 context information in the first place, and

that's sort of Core Challenge Number 1 or maybe

Number 0. We have to be able to get to the medical

device in order for it to be able to provide it to

any of these future systems.

Those that do get it really have a kludgy,

somewhat clumsy, not well-developed products or

solutions to actually make this happen. I'll get

into a little bit about that, but I'm not going to

get into specifics. I forgot to include a

disclaimer, myself, that I'm not speaking for

Partners. This is just purely based on my experience

and some of my challenges and possible headaches, and

if I've got a headache, that generally means that

Julian's soon got a headache as well. And vice

versa, depending on some of the --

So one of the challenges I found is that

the lack of an accepted industry standard really has

produced or resulted with quite a number of possible

challenges or, I'm sorry, possible approaches. Now,

you would think that lots of choices is a good idea.

Oftentimes it is. I'll try to explain a little bit

about why sometimes it isn't. As a result of all of

these different possible choices, the system I'm

trying to put together is, at least in my opinion,

(410) 974-0947

376


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

unduly complex. It has many more components, many

more pieces and parts than I really am comfortable

with and, you know, as a system designer or a medical

device designer from eons ago, it's tough -- keep it

simple and leave out the last -- and I follow that

today.

And I do find that it's important to try to

keep things as simple as possible and try not to

bloat the environment too, too much. So I suggest,

similar to what happened that I had to deal with in

the OR, I don't know, back in 1997, 1998, or so, that

we establish some sort of performance standard. I

suggest that the FDA, I understand might be a little

involved -- suggesting here that the FDA really does

create some sort of performance standard for the

industry to get rid of all these variabilities that

I, as an end user, have to deal with that's sort of

analogous to what happened with electro B bars (ph.).

We used to be able to connect electro B

bars and plug them into an A/C power cord. A couple

of inadvertent events have happened to address that

particular problem, and all of a sudden we ended up

with some children that had died because wrong things

weren't able to connect to each other. It is, I

think, analogous but far more rudimentary that what

(410) 974-0947

377


Annapolis, MD 21409

1

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 potentially happen with medical devices and

data -- or data that could produce that aren't

properly associated with the patient. So why do

this? It comes around to patient safety. We have a

lot of concepts, ideas that are getting put in place

and some things that are happening today in

connection with safety that really rely on

understanding who the patient is, what devices

they're connected to, and what information is around

that you need in the environment.

Future possibilities, we're talking about

using decision support to determine the number of

times -- and that I understand, some of the grass

roots operations between the data and how it gets

used is a little nerve wracking to me because I

understand, am aware that medical equipment data are

going, how they're associated or how they end up in a

care provider's hands and -- to make the decisions.

It's a little scary sometimes. Because the

systems are overly complicated, or at least in my

opinion, the end users have to have more and more

training, and they have a number of systems they have

to interact with. So if there was one more or one

consistent user interface that was more globally

accepted and users would have to interact with fewer

(410) 974-0947

378


Annapolis, MD 21409

1

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 fewer systems, which I think is really important

to the end users, simplifies things. From a provider

organization, or at least my experience of dealing

with a provider organization, every manufacturer,

every IT vendor, every integration vendor wants to

come up with their own solution, their own answer to

the problem, and that makes it really, really

complicated for a systems integrator, like me, that

is trying to put all these spare pieces together into

one large system that end users can use.

I also see that we have a lack of reporting

means because often we don't have a vehicle to say,

okay, we have this particular problem, these data

weren't associated correctly, and that's just my

little story that I'll try to learn from and share

with my colleagues, but there's no formal recognized

and/or formal means of getting that message across at

a larger scale.

Okay, so this is kind of an overview of the

system we're trying to put together, that we have

this massive cloud over here which is, initially,

this slide was called a system of systems, but I

thought that that term was already overused

considering how many times I heard it yesterday, so I

changed it to complex system. So each one of these

(410) 974-0947

379


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

individual components is a system to itself, and if

you talk to any of the people that work on that one

system, those are unyielding and complicated, as it

is. Now, we put them into this massive cloud that we

call some sort of an enterprise information system

and then attach more things into it like human beings

and then a patient and then a number of other medical

devices within that environment, and then another

human being here, at the very end, trying to take

care of this patient.

It becomes a very, very complex

environment. We anticipate that we're going to have,

at least at the Partners' level, between BWH and MGH,

so we're going to have at least three different

infusion pumps or machines, two different patient

care monitors, and a number of other solutions like

for beds, for CRT or continuous read-on-read therapy

equipment, otherwise known as sort of a long-term

analysis, used in long-term patient care.

And then we have this, sort of what I've

been referring to as broad-spectrum connectivity

solution and/or almost everything else -- so we have

a number of other solutions. Each one of these

things is going to need some sort of a solution to

associate -- so hospital challenges are we've got a

(410) 974-0947

380


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

three-sided, I initially called it a stool as well,

and we've got this three-sided triangle. Oftentimes,

triangles don't have four sides or else they're known

as squares and/or parallelograms or rectangles,

but -- so we've got this user workflow, that's

really, really important. I'll get into how that

fits in. We've got these information systems, and

now we've got these medical devices all

interconnected one way or another, and unfortunately,

I have that job of figuring out how to do that.

We talked a little bit about yesterday,

we've got location versus the patient-centric data

association, which each has its individual challenges

in terms of legacy systems and recent developments.

Oftentimes, as Rick pointed out earlier, we have a

great deal of trouble finding out what's actually

underneath one.

As a design engineer for the first 10 years

of my life, I was able to talk to a manufacturer of

any product I wanted to OEM from or get -- original

equipment manufacturer -- get some pieces of

equipment from them. And if I asked them to tell me

a little bit about the hardening of their lower shock

or the control theory for their motor, I could get

that kind of information. I just can't get that

(410) 974-0947

381


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

today. I can't get that kind of information on how

do I put all these pieces together. That brings over

a little bit about what we've talked about with

80001. At least the earlier versions that I had read

about really didn't have the teeth that I would like

to see into it that really would help systems

integrators get the kind of information that they

need from manufacturers so that we can do better risk

analysis. And, fortunately, I've got Rick always

sort of on my little shoulder over here to help me

out to say, you know, have you thought of this, have

you thought of this, as I put all these pieces

together.

And as discomforting as it is to say, data

mis-association does happen. There's plenty of

instances where I've had to deal with something or

other that didn't go quite perfectly, and these

systems don't often tolerate some of the challenges

that patient care environments may have on short

notice.

We'll go back to this slide. I'm just

going to show a little bit of an overview as to how

the data flows from one side to the next. So the

patient shows up at the -- or some sort of admissions

department. There is a person doing some data entry

(410) 974-0947

382


Annapolis, MD 21409

1

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, and then there's -- we'll simplify this and

call these both Step Number 1, but there's some

physician that has to write an order to accept that

patient into the hospital. At some point or another,

after the patient is admitted to the hospital, that

enterprise information system, part of that huge

cloud that I was talking about earlier, has this EDT

system that it sends the information to. A little

bit of magic happens there, as far as I'm concerned.

All of a sudden, as long as I get it into EDT, it's

going to go to a zillion different places, which is

quite awesome, as far as I'm concerned.

So after it gets into this system, the

patient leaves that environment. The end user here

has to call up some sort of application within this

enterprise information system at their computer

workstation at the side. The patient then arrives to

the environment, and the user has to interact with

his computer to say yes, this patient is here so that

the bed management system actually recognizes the

patient is in that one location.

They then might have to barcode or somehow

otherwise recognize that this patient is in that

immediate environment and then tell the monitor

and/or whatever other equipment is right there at the

(410) 974-0947

383


Annapolis, MD 21409

1

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's bedside that that patient is verified.

This computer system, once this human has told this

computer system, yes, this patient is actually here,

then tells the clinical information system, that sub-

area otherwise known as the electronic medical

record, that that patient is there and I want to

start collecting data on it. So then that device has

some sort of communication with a proprietary medical

device, and this is still just to follow the

association of the data from that patient to get that

information back into the record. So the clinical

information system says, hey, I've got Patient John

Doe in this bed; do you, too, as well?

This proprietary manufacturer server then

speaks to the monitor and says, hey, do you have

this? The monitor then responds yeah, okay. So I

keep going. Goes back to here, sends the information

back to there, then forwards it on to the clinical

information system, and then lo and behold, Step 11

and 12, the information is now back at the clinical

worksite.

Now, from the end user's perspective, the

information went from this patient bedside monitor,

which happens to be within three to five feet,

maximum, of this -- most likely, depending on the

(410) 974-0947

384


Annapolis, MD 21409

1

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 setting, of this computer. So quite literally,

when I try to explain some of this to some of the end

users, they're absolutely astounded that the process

is that complicated and that a device that is within

three to five feet of that patient, the information

has to travel actually to a whole different city. In

Partners' respect, the medical campuses are in

Boston, and our data centers are either in Needham or

they're in Charlestown. So the information actually

has to start off at that patient's bedside, go to

Charlestown and/or Needham, and then back to

that -- to the computer which is three to five feet

from that PC. So even though from the user's

perspective, it looks like it's a simple from here-

to-here, how difficult can it be, it looks like that.

And if something actually goes -- this is

only if the processes are all correct. If something

actually goes wrong, now we've got these telephony

systems in here that -- which really introduce

complications in the process. Okay. So patient

context really does, as far as I can tell, enable

interoperability.

It differentiates the medical devices from

consumer electronics and/or information technologies.

I can lend my daughter my iPhone, and if she's got

(410) 974-0947

385


Annapolis, MD 21409

1

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 lab that I just heard about today, she'll be

putting stuff into my record. That's not quite

right. Medical devices really do have a

differentiation. Fusion pumps offer some challenges

because they need to be integrated with the other

hospital systems like AR systems, barcoding,

introduce another layer of complexity, as does

wireless connectivity. User overload is significant.

More and more systems are introduced by the month,

and people have to deal with them. There are a

number of other efforts that are working. So there

are a number of other groups that are working on

these challenges.

In summary, we have the medical devices and

information technologies really are converging.

There's no two questions about it in my mind.

Association of that patient context to the medical

device, I think, is crucial. I think it ought to be

a particular focus, and we need to get this all to

happen. The unregulated market is really creating

very disparate systems with little oversight in how

they integrate. And then I'd recommend some sort of

performance standard.

I'll leave you with one thought. It struck

me, as we were talking yesterday, I had to go home,

(410) 974-0947

386


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

back to my hotel room, and add this one little piece

because I remembered thinking about it somewhere else

and it came from Unix philosophy. And Unix is an

interesting operating system, I find; I'm more of a

Mac person. I got turned on to Macs only because

they run Unix as the -- but to do things, you know,

write things, create things, it will help to

extrapolate this into device interoperability a

little bit, but create the device, and it'll write

the program to do one thing and do it really well.

And then take that, as you're developing that, really

write the program and/or create the medical device so

that it will interact with others. You can't do it

all by yourself. And then you write programs and

handle text screens, and that just means -- some sort

of English because that's the universal language for

a universal interface. That means that medical

devices are going to be interacting with human

beings.

I also leave you with this picture because

I happen to climb mountains as a hobby. This is the

summit ridge of Denali, and these are a couple

partners that were with me, and we are tied together.

The only way that we're going to survive in this

environment is really to rely on one another and put

(410) 974-0947

387


Annapolis, MD 21409

1

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 kind of trust in one another that we will be

able to trust the other person in the other

environment and have enough training and cooperative

work to -- thank you.

(Applause.)

UNIDENTIFIED SPEAKER: Which one is Julian?

(Laughter.)

MR. SCHRENKER: So we have a few minutes

for questions.

MR. THOMAS: Bill Thomas. Very nicely

done. I really enjoyed both of them. I have a

couple of questions, and since I'm not a

manufacturer, I'd like to ask, as a manufacturer, if

I were one, why should I add capability to identify a

patient which only creates more liability for me?

Why shouldn't I put in place a proprietary server for

my device? I happen to have a client that's doing

exactly that because our big -- a lot of money for

very little cost.

What are the motivations to follow what you

have both -- and the incentives, the motivations and

the incentives to follow what you have both very

properly pointed out are essential in order to get

interoperability and to get what we perceive to be

the benefits of interoperability? Because if there's

(410) 974-0947

388


Annapolis, MD 21409

1

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 motivation, you know, just from a human factors

perspective, there will be no behavior, and with no

behavior, there will be no objectives reached.

MR. MELENDEZ: So that's a two-part

question. So first is why take on the risks of

adding patient identifying information to the

industry?

MR. THOMAS: If I don't absolutely have to.

MR. MELENDEZ: If you don't have to do it.

MR. THOMAS: Shift the burden to somebody

else.

MR. MELENDEZ: Sure. I guess I see that as

supply and demand as being one. And the second part

is a regulatory and/or a national objective. So if I

hear what you're describing correctly, supply and

demand, being from a provider's organization, we're

trying to demand that. And as we talked about it

yesterday, there's a fair amount of consumer-based

pressure. We see that as care providers, also, that

the consumer electronics market had really done to

medical environments.

People expect to have some sort of level of

functionality to make all this stuff happen. If we

don't make that happen, unfortunately, providers also

see some sort of pressures from the market that

(410) 974-0947

389


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

patients will go elsewhere, if people come up with

work-arounds and introduce solutions that aren't

really, really constructed well, which increase other

risks and so forth.

We see that with wi-fi connectivity in

vision care environments and so forth. So I think

it's a little bit of short-sightedness to say I want

to protect myself and not take care of the objective

as a whole, and the objective as a whole being a

good, proper working system than individual

components. The second question is to why an off-

force, the introduction or the -- that a component

doesn't have a server involved because it's

financially beneficial to the company to make that

happen. I can't quite really answer that, but I can

tell you that I feel that every system I try to

introduce has got some financial tag to it, and it's

not inexpensive, and it's kind of odd to be able to

have these restrictions, constraints, financial

importance to be able to get to the data that is, in

essence, being produced right there from that device.

It's a good question -- and I've worked for

a large device manufacturer -- if someone was to go

in and -- you know, a couple of large purchasers, you

know, large customers are going through large buying

(410) 974-0947

390


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

organizations, and all of these companies, the folks

who work for the suppliers, manufacturers, I

wouldn't -- call me out on this if I'm wrong.

The sales look like hockey sticks at the

end of each quarter, right, and that's what people

buy. And if you have two or three large buyers that

come in and say yeah, you know, I want you to sign

this MD FIRE thing, you're going to do this six

months from now, and you put a date as to when

they're going to start complying. The execs of that

company are going to by allying with you because

their jobs are going to hang in the balance.

UNIDENTIFIED SPEAKER: Certainly, the

marketing execs are going to be -- sales and

marketing --

MR. MELENDEZ: All the way up to the CEO.

They're not going to make their numbers. And a

couple of big purchasers can really blow it up on

them. It's just a matter of actually strong-arming

them. And then the other piece is that they move as

a herd, so then they get -- advantage and the others

will follow.

UNIDENTIFIED SPEAKER: The problem is that

we're ganging up on manufacturers.

MR. SCHRENKER: We're running a little

(410) 974-0947

391


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

behind. You know, this is good stuff, so we can pick

it up later, but I really want to thank Luis and

John. Those were great presentations.

(Applause.)

MR. THIEL: All right. Next up, we've got

some presentations on integration and

interoperability issues in a regulated environment.

I don't see Bonnie Norman here to present, so

perhaps -- okay. So we'll start and we'll see if we

can add her at the tail end. Presenters that we have

up here, we've got Renate MacLaren, Director of

Regulatory Affairs, Integrated Medical Systems;

Alasdair MacDonald, the CEO of TeleMedic Systems; and

Dave Arney from the University of Pennsylvania. So

without further ado, we'll go ahead and start.

Renate.

DR. MacLAREN: Good morning. I'm just

going to tell you, first of all, about our device or

devices, and we took a little bit of a different

approach to what everybody's been talking about.

Let's see. So this is obviously the problem that

everybody has, the non-operability of -- non-

integrated operability of the devices. And our

company came out of Northrop Grumman, so we were

systems integrators to begin with.

(410) 974-0947

392


Annapolis, MD 21409

1

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 we took a systems integrated

approach in coordination with the U.S. Army, and we

developed a portable unit that had ICU capability and

integrated medical devices from different companies.

And these medical devices were hosted on our system,

and we developed a proprietary user interface

and -- excuse me -- a user interface and software so

that these devices can communicate with each other

into our central interface.

Sort of the benefits of our systems

integration was we were putting these all into one

single unit, and we had ease of use, a single unit, a

single interface. We had the safety of both the

operator and the patient, and our units were easier

to maintain, upgrade, increase reliability and reduce

the weight and volume and the clutter associated with

them. So what we did for our design approach is,

like I said, we used -- our customer was the U.S.

military, the Army, and we developed the system

requirements and system user interface, and then we

took, for a subsystem, for our medical devices, we

took already 510(k) cleared devices which we worked

with the OEM manufacturers of these devices, and we

integrated them into one.

We used -- adapter process, which was our

(410) 974-0947

393


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

own. And we took, our data adapters took -- and took

the messages from all the units, all the different

devices, and then we can communicate both ways with

the device and our unit, and we can control it. And

the way we designed it was we looked at the

regulatory standards, the consensus standards and all

the FDA guidelines, and we developed the system at

the same time as we were developing the subsystems

and the medical devices.

And we also ripped apart the medical

devices and repackaged them. And our goal was to get

both a 510(k) and -- on the market at the same time.

So some of our regulatory challenges were, since we

were integrating a ventilator, monitor, fusion pumps,

how are we going to classify this integrated device

that has multiple intended uses, multiple device

classifications, because originally we didn't have

that ADD associated with it, so that was a pre-1976

Class III device, and how were we going to handle

risk management. And we applied consensus standards

across the board for each device and as a system, and

then for our software, our software was the key

element of this device because it tied everything

together and allowed our users to interface the

devices. And our labeling, developed our labeling

(410) 974-0947

394


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

along with the device.

What we ended up doing to submit our 510(k)

was we approached it as a single integrated device

with multiple medical components that were hosted on

our system. The one that we just recently got

cleared was a Class II medical device because it

included only Class II devices.

And like I said, the software was the key

element. We included a very comprehensive 510(k)

submission that included consensus standards

compliance. We fulfilled the guidance documents, the

software guidance document. We included a complete

hazard analysis that included the alarms for all the

systems, all -- was basically subsistent at the

system level, hazard analysis, and we submitted a

completed manual with the device. And as a result,

we ended up with two 510(k) cleared CE Mark medical

devices, the life support purse, transport, and

trauma -- or trauma and transport, which was cleared

in 1998, before my time, and the LS1, which was

cleared in 2008. And they have essential interface,

or at least the newer unit has a central interface

that controls all the devices, including the fusion

pump on the front. And we had the capability of

attaching additional devices, which we will do in the

(410) 974-0947

395


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

future.

And we've also developed it so that we can

use a handheld device to control, remotely control

the device as well as the handheld device can control

other devices that are not necessarily in the area.

We're working on the handheld PDA connecting to

nurses' stations. Eventually, we'd like to connect

into the patient record system and other things.

Thank you.

(Applause.)

MR. THIEL: Alasdair MacDonald.

MR. MacDONALD: Hi. I'm Alasdair

MacDonald. I have a company in the UK, TeleMedic

Systems. I really enjoyed the aviation references

because in a previous life I flew small jets for the

Queen. That also means I'm quite a practical person.

Pilots are very practical; they don't get involved in

stuff that they don't need to. And I'd like to try

and think that we've taken a practical and simplistic

approach. And I'm going to try to talk about it in

generic form, but this is something you've done, and

it's the use of a common interface where the

interface is both hardware and software between

medical devices and IT communications in real

time -- or whatever.

(410) 974-0947

396


Annapolis, MD 21409

1

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 couple of things that haven't been

brought up is we talk about medical device

integration, but it goes beyond that because if we're

going to talk about when -- if we've got a

telemedicine situation, you're actually not

necessarily going to have a clinician in the same

environment as the patient. So we have to talk about

clinician interoperability, and it's all about people

processes as well as technology, and I think that's a

point that's been brought up. You know,

interoperability isn't a technical problem; it's a

problem with different people processes.

What do you see? I think we've all seen

this before. Even when I come back to it and look at

it again, depending on which particular thing I see

first, I either see the old hag or I see the young

woman, but the point is that we're all looking at

this from our own personal perspective. We've all

got our own view on something, and what we might see

is different from what somebody else might see. And

as my instructor always used to say to me, you might

believe what you thought I said, but I'm not sure you

realize what I said isn't necessarily what I meant.

The point that has come across in a number of the

presentations, we're talking about standards and, you

(410) 974-0947

397


Annapolis, MD 21409

1

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, why we need standards and risk and things like

that.

The way I see it is that standards offer us

a common view, a view that it might not be the view

that we agree with, but it's a view that we accept,

represents the industry, a common view that we can

then work to and define and classifications to and

tests to. So medical device interoperability, it's

not new. You know, we've had a number of medical

device manufacturers here that already have multi-

parameter devices. So if you've got multiple

parameters, you've already got device

interoperability between those separate components.

Not only that, the name on the front of the

device might be the manufacturer's, but the bits

inside might be from an OEM device manufacturer. But

it's the medical device manufacturer who has taken

responsibility for this device, this composite

device, this interoperable device. And all we're

looking at doing now is taking them out of the box

and distributing them and integrating them with lots

of other bits and pieces, and we have to look at that

as the device, the whole thing is a device. Medical

devices and IT systems -- we all use IT systems and

we've all got computers, and you've got a new piece

(410) 974-0947

398


Annapolis, MD 21409

1

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 software, and you load it onto your computer, and

it doesn't work, so you phone up the software vendor;

oh, it's your computer. So you phone up the computer

manufacturer; oh, it's the software.

We can't have that in the medical device

environment. Somebody has to take over all the

responsibility, and that has to be whoever the device

manufacturer is, and from what I just said, the

device manufacturer is the systems integrator, the

person who's put it all together. Now, physical

connection of the -- you know, to a medical device.

If you've got a computer and you're connected to a

medical device, can you do that?

Have you done a risk assessment on that, a

risk analysis? And who did that? I know a lot of

doctors who are computer literate, and they notice

that that device they've got there has an RS232

board, so I'm going to connect my computer to the

RS232 -- well, they didn't do a risk analysis on it,

they didn't know the implications of doing that, they

don't know what -- abuses are, and these are doctors.

And, you know, so the physical connectivity is a

serious issue, you know, stringent regulations, and

the thing we've been talking about quite regularly

through here is that there are a lot of standards,

(410) 974-0947

399


Annapolis, MD 21409

1

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 there's a standard for this and a standard for

that. But now we're talking about interoperability,

so we're talking about something that's going to

connect them all together.

Now, this country is renowned for the

patchwork quilt, and you know, the little old ladies,

they go home and they make their patches, and as long

as they all make them to the same size, when they

bring them in, they will be sewn together, and you've

got a beautiful quilt that's made up. But there has

to be a standard. What is that size because if you

don't, you're not going to get a quilt that fits

together properly.

The other thing is that a lot of systems

integration, you're taking existing legacy devices,

and you're integrating them in a way which is new.

And the medical device manufacturer never -- that was

never their intended use, to integrate it in this

way. But it's a good thing to do and

integrating -- but you're now introducing performance

outside the manufacturer's control, so you can't

realistically expect this legacy device manufacturer

to hold responsibility for this new device, but the

new device integrator, the systems integrator, will

expect, as a minimum, the device manufacturer will

(410) 974-0947

400


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

own up to the intended use level that their device

was made to. Communications. Now, I'm clearly from

across the water, and we've already seen instances

where we use the same terminology but actually it

means something completely different, and actually,

I've been coming to this country for a long time now,

and I'm fluent in American, so --

(Laughter.)

MR. MacDONALD: But there are some good and

very exciting -- it's interesting between our

language, which are not necessarily obvious, and they

can cause for a lot of humor from time to time. But

if you think that's a problem, you ought to try

calling a call center in India or whatever.

But when you get down to IT and

communications, the whole thing goes to a different

level. You know, if you think that talking to a

fellow human being is a problem, you don't talk to

communications and IT systems. The protocol is

different. They're all clearly defined, there are

standards, and the point somebody made was the thing

I love about standards is there are so many of them,

and that's a great thing, too.

Bandwidth. I've been in this market now

for quite a long time. I got into it, my brother-in-

(410) 974-0947

401


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

law is a doctor in Edinburgh, and they want to

do -- training in the community. And so I integrated

an -- onto a laptop computer and analog -- most of

what I've been doing since is remote stuff, and the

only ubiquitous form of communication is satellite

telephone, and if you've got a handheld satellite

telephone, it will only transmit -- 2.4K.

So those of you who think your 56K dial-up

modem is slow, think what a 2.4K modem is like. But

we can do real-time vital signs monitoring over that

bandwidth. And it's understanding how that relates

to intended use to what you're trying to do, the

environment you're working in. So there are so many

different components, so many different elements, you

know. We talk about the concept of shared risk.

When we talk about intended use, we talk now today

about labeling.

I think the labeling is very, very

important. You say this is the intended use in this

environment if you've got this bandwidth, but if you

haven't, you know, do we say oh, you can't use that

device? You know, I had a friend who had to give

somebody an emergency tracheotomy to save their life,

but they used a Swiss army knife to do it. Now, oh,

that's not an approved or standardized device, it

(410) 974-0947

402


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

wasn't sterilized, but it saved their life. If

you're in a remote community and you've got narrow

bandwidth and you can't get that 12BBCG in real time,

what can you do? If you can enough information to

establish actually, this isn't a heart problem, let's

try and identify what the problem is and save their

life. No, it's a different environment.

You need to think about that. So -- but

I'm not even going to reliability of communications

because, you know, I think we've all established

that, you know, hanging out the window to get a

signal and things like that, you're all aware that

it's a problem. So, again, we have to look at the

problem and address it as part of the risk analysis.

14971 has been brought up on a number of occasions.

You analyze the risk, you look at how you

mitigate the risk, and you would then say is the

mitigated risk acceptable for the situation, and do

you want to use this, and somebody has to make a

judgment decision on that as to whether they're going

to or not. So if we take -- we've got a patient and

we start with the patient. Quite often, people don't

start with the patient, but let's start with the

patient. And they can connect to a number of

different devices, and some devices, we don't even

(410) 974-0947

403


Annapolis, MD 21409

1

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 that yet. I like the analogy, I've used it

myself, of the hi-fi system. You know, if you've got

a good hi-fi system you bought, a good amplifier you

bought in the '70s before we had CD, we had MP3, you

can still be using it today because it's a standard

interface.

So we need to look at how do we say what is

going to be interfaced for things that haven't been

invented yet, and then let's connect them to a

device. So let that device be, itself, a medically

approved device because if you've got a Class II,

U.S. Class IIb, and you indicate a medical device

that can physically connect to other devices, then

the whole connectivity, whether it's wired, whether

it's wireless, whatever, the connectivity aspect, the

near patient aspect, is addressed.

And, you know, we also understand about the

software elements -- on that device and connectivity,

and we're going to come up with a whole new intended

use which we will put forward, but it may be a

variable intended use, as we sort of touched on. And

so just connect it to a medical device, and then once

you've got it connected, you can allow non-medical

devices, IT systems, to connect to that medical

device, which is -- it's actually just an IT device,

(410) 974-0947

404


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

itself, but it's a medically approved IT device. And

it's handling all of the stuff and all of the risk

side of it and the alarm side of it and all of the

different bits and pieces to medical standards. So,

you know, that device will allow access by a

commission through a viewing screen. In fact, you

can allow multiple access to that device

through -- you know, it could be wired, it could be

wireless, you know, any way you can connect to that

device, and you can see, in real time, if the

bandwidth allows, all of the vital signs.

Now, the other thing about it is these

vital signs that we're talking about, some of them

are static, some of them are dynamic. We had that

presentation yesterday where we were looking at the

disparity between dynamic and static.

But -- collected, in the same way as you go

into a recording studio, you know, the microphone for

instrument and, you know, each singer and all the

rest of it, each piece of data is in its own

individual data stream, but they are all collected to

a single time base so that you can cross-refer one to

another. So with dynamic data, you can look at an

event, and you can cross-relate it to another event.

The static data, you can collect and so on. But the

(410) 974-0947

405


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

point about the dynamic data is that it needs

more -- usually, it needs more interaction with the

device. When I first got involved in this, I was

using Spacelab's ECG and EKG, and when you

interrogate the device, you sell your packet of data,

and you have -- do not only acknowledge you received

it, but that you received it correctly. And you have

to do that within so many milliseconds; otherwise,

you didn't get another pack of data.

Now, my Windows PC, when I do

that -- because the operating system's busy tidying

up, and somebody over there was playing FreeCell and

all the rest of that. You can't have a multi-tasking

operating system that's working at this level, and to

take the analogy of the aviation analogy, if you look

at the medical situation, you've got air traffic

control, and it's controlling where people are and

who goes where and what.

Yes, you've got airplanes with autopilot

because there are certain things you can allow it to

do in flight, to get there in a straight

line -- small jets, with just one person on board,

they don't have autopilots, and the pilot's going to

be involved. However, that doesn't mean that they

can't have systems to help them. And the other thing

(410) 974-0947

406


Annapolis, MD 21409

1

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 just because you invented something, it doesn't

mean you've got the best idea on it. Quickly to wrap

up, that data, once it's in an IT device, once it's

in an IT device that is medically approved, it can

communicate to any available communication systems

out through the internet to a central data

depository. That is where you can than allow extra

systems, support systems. They can get a single

point of access to all of that data in a common

format.

They don't have to worry about interfacing

all the different individual medical devices. They

just interface with a generic data bank. We can then

pass that to patient record systems. Currently, we

can populate a patient record system, we can read

from a patient record system; a spirometer requires

patient data. You acquire the data from the patient

record system and combine the two, and we have the

results back in the patient record system. You can

then make that available to all of these different

areas across all of these different situations,

multiple patients, multiple times, simultaneously,

real time, whatever.

But here's a thought. We're not just

looking at how do the devices interoperate. It's how

(410) 974-0947

407


Annapolis, MD 21409

1

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 GPs interoperate, the doctors interoperate, and

the medical device, the emergency patient records,

how do they interoperate? And we haven't answered

that, as well, but we don't have time to talk to you

about it, so I'm happy to talk to you about that

after the -- thank you very much.

(Applause.)

MR. THIEL: Dave Arney.

MR. ARNEY: So my name is Dave Arney. I'm

a Ph.D. student at the University of Pennsylvania and

my advisor -- is also working on these things. So

we're going to talk about a couple of the case

studies that we built, trying to build plug-and-play

for interoperable medical devices. And I'd like to

talk a little bit about the architecture that we used

to build those and some of the challenges that we

discovered while we were trying to build these

systems.

We've been talking a lot over the last

couple days about interconnected and interoperable

systems. And I see these as somewhat different

things, and I think it's an important distinction.

The systems that we've been trying to build are

specifically interoperable systems.

Interconnected systems, on the other hand,

(410) 974-0947

408


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

are systems that share data among devices that

probably require individual drivers for individual

devices, have a relatively simple system connecting

them, and can be one ops systems that are built for a

particular purpose, may or may not be when it comes

to semantics, and all of the examples from

aviation/avionics are good examples of these kinds of

systems. Interoperable and plug-and-play systems, on

the other hand, a lot of you had to remove -- they

require common semantics. You need to be able to

send data on these devices since they have a common

format, so you need both the common protocol and the

common semantics for how you're finding the data to

send using that protocol.

And it thus requires stronger device

interface descriptions. The main advantage of plug-

and-play systems or interoperable systems over these

interconnected systems is that you can start plugging

together things and immediately start using a system

in devices that may never have been tested in that

combination before. When you use a pulse oximeter

that's never been used in this system before and you

can test them with -- so these tend to be much more

complicated.

You have to check whether these devices are

(410) 974-0947

409


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

actually going to work. It's harder to design and

build the infrastructure, but once you've built the

infrastructure, it's much easier to build

implementations or actual clinical systems. So

that's the vision. From my point of view, I'm a

Ph.D. student, I'm doing research in this area, the

interconnected systems, you know, seem relatively

simple. As we've been saying all along, there aren't

a lot of technical challenges there. They're hard to

build for other reasons. There are, I think,

interesting technical challenges in the interoperable

systems that we'll get to. And, personally, I really

appreciate it if, you know, you can always settle on

something on the interconnected level.

(Laughter.)

MR. ARNEY: Get that done so you can start

working on the interesting problem. Okay. So our

development process in building these cases. You

start with the clinical use cases. There's a little

bit different perspective. You start with the

clinical problem rather than saying that we want to

connect these devices to support whatever it will

support. We start with the problem and then trying

to see what kind of system do we need to solve that

problem.

(410) 974-0947

410


Annapolis, MD 21409

1

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 do hazard analysis or failure mode

analysis around that problem, come up with site

requirements, build a formal model from those

requirements, check properties against -- we derive

these properties from the hazard analysis and

requirements. We check the properties, verify the

model, generate tests so we can at least validate

implementations, and do code generations to generate

medical implementations. And, of course, we go

through Step 1 through Step 6, we're done,

straightforward, talk about them. There's a lot of

iteration, of course. So I don't know how visible

this is. This is the basic architecture. Should

look very similar to that ICE picture that Julian was

showing yesterday.

The top, we have a caregiver; at the

bottom, we have a patient. The patient is connected

with a number of devices. Those devices communicate

through an adaptor to a network controller. Network

controller does things like keep track of the

connected devices, communicate for the black box

recorders and broad data. The devices may be

connected through a lot of different kinds of

interfaces. So if you've written in, kind of

randomly, ethernet -- wi-fi. So it can be wired, can

(410) 974-0947

411


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

be wireless, can be reliable or unreliable networks.

The part that I mostly focus on is what we

call the supervisor. So that has the user interface

of the caregiver, and it runs the actual programs

that implement these clinical scenarios and in a

multiple clinical scenario. Basically, what I'm

calling the supervisor is whatever box has the user

interface that runs the programs. That could be

hosted on another medical device. A key thing, I'll

talk more about it in a minute, is -- basically, a

minute -- is the device is transmitted to a device

model that describes the capabilities when they're

connected. And I promise I'll get to the use cases

on the next slide. So when you connect the device,

it says hi, I'm a pulse oximeter. I measure SPO2 and

heart rate. Here's my accuracy, here's my sample

rate. And then the clinical application

script -- and we can use a better acronym there,

Mike. Think about that.

The clinical application script, then,

looks at those device models and says does that meet

my requirements? The person who writes these scripts

also writes the set of requirements for the devices

that says I need SPO2 once every two seconds. You

connect the pulse oximeter that can supply it every

(410) 974-0947

412


Annapolis, MD 21409

1

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 second; that meets the requirement, you can go

ahead and use that device.

Okay. So our first use case I'm not going

to talk much about. It's this X-ray ventilator that

we've been talking about a lot. So the idea is that

we want to synchronize the X-ray machine with the

ventilator, so we can take a picture when the

patient's lungs are still. And here we did it so

that rather than sending a pause signal to the

ventilator, it actually synchronizes, and it's able

to trigger an X-ray when the patient's lungs are

empty or when they're full during the respiratory

cycle. It can do that up to, you know, depending on

which phase you're doing, it pauses longer at the

bottom of the cycle, up to about 30 breaths per

minute. So it can synchronize fairly well depending

on various exposure time while you're at the sites.

Oh, cool. So here's a lovely picture of our

implementation. You can see that we have a breaker

and ventilator in the background.

(Laughter.)

MR. ARNEY: And on the table in front,

there's obviously a little lung simulator, you know.

It's a little bellows that represents a patient. And

there's a webcam sitting in front of it. I realize

(410) 974-0947

413


Annapolis, MD 21409

1

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 this --

(Laughter.)

MR. ARNEY: It's a little webcam that

represents our X-ray. I'm hoping we have more

pictures of this. So the webcam represents the X-ray

because we didn't want to, you know, expose everyone

to massive quantities of radiation unnecessarily.

And another component that's on there is that we have

a button and this is to keep -- so the idea is that

when you want to take an X-ray, you set up your

system, you say take an X-ray at the peak of

inspiration; the patient's lungs are full. The

system says okay, I can do that. It checks

the -- settings, says that sounds possible and then

tries to do it. While the -- is running, someone has

to hold down this button to get the system

information to take the X-rays. We don't really like

the term. We call it a dead man's switch. The idea

is if someone walks into the room and you decide that

you don't want to take the X-ray, just let off the

button, and it won't trigger under any circumstances.

Okay, so another example is PCA monitor.

So we have patients who are on patient

control -- they're getting, you know -- drugs and

there's a common danger that they may receive an

(410) 974-0947

414


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

overdose of drug, become over-sedated, possibly stop

breathing. You want to try to avoid that. So what

we want to do is integrate the monitors that are

frequently already connected to the patients with the

controller running the supervisor so we can detect

when they start to get into trouble, stop the

infusion, and call the nurse.

Hey, cool. Some pictures. Okay. So on

the left, we've got the sort of high-level workflow,

and this comes from Tracy Rausch. This is sort of a

high-level workflow describing what happens when a

patient's put out on a PCA, so that's sort of our

starting point. You say here's this clinical

workflow, and how do we build a system to support

that? The upper right shows the basic control of the

system, so the green boxes are the places

where -- the main safety property that we want to try

to ensure here is that the patient can't receive

enough drug quickly enough to push them into an

unsafe zone. And one of the major challenges with

this, of course, is that we have to have some kind of

patient file.

We have to know how the patient's going to

respond to the drug. Those are difficult to come up

with. I'm sure many of you know. The basic idea is

(410) 974-0947

415


Annapolis, MD 21409

1

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 we have a patient who has physiological signals.

We measure those using pulse oximeters,

respiratory -- whatever else. The output go into our

supervisor program which does some processing -- the

bottom right shows our implementations through a

couple of different pulse oximeters that swap in and

out of a simulator and a computer that runs the whole

thing.

Okay, last slide. Some of the challenges

that we've noticed are that -- requirements aren't

monolithic. One of the most frequent questions that

we get about this system when we show it is will it

work with wireless? We don't really care if a

network is wired or wireless, particularly. What we

care about are the characteristics of that -- what's

the latency, how often does it lose things, is it

actually a real-time network, does it guarantee -- or

is it best effort? And for different clinical

applications, we have different requirements to run

the networks. The idea is to match the network to

the requirements for that particular scenario because

some devices are connected through an unreliable

network, some devices are connected through a

reliable one, and that could be okay.

So you could have some things that are on

(410) 974-0947

416


Annapolis, MD 21409

1

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 wired high-acuity network, you've got some things

that are connected through mil-acuity network, and

that would be okay for some applications. Next

challenge is the patient model. From a computer

science perspective, people are surprisingly

unpredictable. We would really, really like to have

a mathematical model that describes how the patient

will react to the therapy. So that's another --

(Laughter.)

MR. ARNEY: More realistically, what we can

do is come up with some relatively simple models that

describe a normal patient or a normally abnormal

patient. They try to catch, you know, that 80

percent or so of the most common things. But it can

also tell us when a patient is not in that category,

and our system just has to give up and say I need a

clinician. We can't handle whatever's going on with

this patient. Another problem is the compatibility

of these control programs. Say you have your

supervisor. You want to run two control loops on

that supervisor. How do you tell whether those

control loops are compatible or incompatible? You

don't want one to be raising blood pressure at the

same time that another's trying to lower it.

Fourth challenge, verifying safety

(410) 974-0947

417


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

properties, safety properties of the whole system,

safety properties of the individual devices. For the

individual devices, well, we treat this device model

that comes from the device as the contract from that

device. We're just talking about labeling, that sort

of more detailed description we get from that device.

Finally, regulatory challenges.

Clearly -- and we've talked about this

before -- verification of all communications and

devices just is not feasible. Another interesting

question, I think, is who is the manufacturer of this

system. We want to design these in such a way that

if the supervisor accepts a set of devices, then

we've already guaranteed, when we made that

supervisor program, that it will act as intended so

that if the device manufacturers are able to supply a

device model that accurately describes what the

device can do and if the supervisor manufacturer

trusts that description, then you know that it's

going to act as intended and we can connect them.

And I'm interested to hear -- in the regulatory

implications. Thanks.

(Applause.)

MR. THIEL: In the interest of time, we're

just going to have to move right on to the next set

(410) 974-0947

418


Annapolis, MD 21409

1

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 presentations, so save questions and answers for

the next breakout. I'm not sure where Bonnie is, but

we will get her presentation and go ahead and load

that online so that at least it will be available for

somebody to be able to look at.

MR. OSBORN: While everybody's getting up

here, we can go ahead and start off by saying we're

critically aware that we're the last presentations

between you and your lunch. So hopefully, we'll not

run over too much since we're already, what, 15 or 20

minutes behind. But I'll give you some of the

details that will impact the full-stage meaningful

use of this technology. After all, the devil is in

the details. We know that the technical problems can

be solved, but that doesn't mean they've all been

solved yet, and they're going to be solved. We're

going to get there. We've got a distinguished panel

with I don't know how many tens of years of

experience in this field. I haven't tried to count

it up. We're going to start with Todd Cooper. So

Todd, if you want to start this way. And he's going

to talk a little bit about the overarching impact

that we're seeing from all the money that's being

poured into this workshop.

(Laughter.)

(410) 974-0947

419


Annapolis, MD 21409

1

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. COOPER: Thank you very much, Dave.

And it's great to be here this morning, and if

Jennifer's still on, hi, Jennifer. She's been

telling us that she's been watching from afar. What

I will do this morning is give you a whirlwind review

of a document that we just completed actually

yesterday.

It was finally approved for publication at

the HPSP panel meeting, and what I will focus on,

though, are the regulatory issues that are surfaced

in that document, and also some of the difficulties

we had in keeping them in the document all the way to

the end, and some of the real strong pushback that we

got. As you all know, on August 27 of 2006,

President Bush issued his famous executive order, and

that was followed up or that resulted in the creation

of a number of organizations. One was the -- do I

have a mouse on here? Yes, the Office of the

National Coordinator for Health IT, and as a result,

also, there was a HPSP group, Health Information

Technology Standards panel. The charter of this

group was to look at the constellation of standards

around the health IT world and come up with standard

profiles to address very specific breakthroughs that

were identified for them to address. So that's what

(410) 974-0947

420


Annapolis, MD 21409

1

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 HPSP team has been doing for the last four or

five years. It feels like a very long time. I'm not

sure we've been having fun.

One of the tasks that they did is they came

up with a framework or process for which they would

go about analyzing these use cases that they were

given and creating various deliverables. So you

would start with a use case, ultimately they would

end up with an interoperability specification that

rely on various components: transaction packages,

transactions, components, together of which these are

called conscripts.

And all of these are built on either base

standards or what they called composite standards

where I take a problem and then I take the best

pieces of a number of standards that you actually

need to combine to be able to deploy a real world

solution. So that's what they've been up about for

the last four or five years. And then -- so as

device guys, we got involved at the very ground level

and thought great, finally devices, device

connectivity, device interoperability will have a

stage, will be on the stage for the national program.

2006 came in and the initial breakthroughs, and wow,

there were no devices anywhere. We thought every

(410) 974-0947

421


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

different angle we could. There was nothing device-

related in that. 2007, we thought great, finally

we've gotten past that first bolus of use cases

listed. The next one, boy, there was still nothing

there.

Finally, in 2008, we had one called remote

monitoring which was very specific, kind of a

continual base use case. But at least there were

devices there. There was something we could get our

hands on. And then finally, in 2009, we had the

common device connectivity, CDC -- that was

confusing -- use case that was given to us, and we

finally had something that really focused on the core

of acute care devices so we could look at addressing

this as part of the national program.

Then what happened? Well, the election

happened, and on February 17th, the ARRA/HITECH Act

was passed. All sorts of money started to rain from

the sky, or at least they're trying to figure out how

to rain it from the sky, still. And the whole HPSP

activity was thrown into a 90-day re-factoring around

the ARRA/HITECH legislation. So we had gotten

started. I think some of us in the room had

participated, a year ago, in the first analysis

session for the CDC use case, and we were maybe a

(410) 974-0947

422


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

week or two into it and this happened, and all of a

sudden everything, once again, was put on the back

burner. We kept saying, you know, devices are really

important; you really need to look at this. However,

given everything else, we couldn't get anybody to pay

us any attention.

We got no respect. So we kept saying well,

what about device connectivity? What about the CDC

use case? What about finishing the remote monitoring

use case? And as a result of all of this, we

realized sometime in the last summer, sometime after

we started discussing this, that we needed more than

just to use a standard HPSP process.

We needed to come up with something else,

and that's where we got the device connectivity

technical note. Why this technical note? One is

that there was a very general, a lack of literacy in

the health IT community. I remember in the meeting a

year ago, Mike Robkin had a little position paper,

just a very simple use case, but he brought up the

regulatory question. And we started to discuss that,

and all of a sudden we realized, you know, before you

can even discuss regulatory issues, you have to have

a basic understanding of what is a medical device,

what's not a medical device. How can I create a

(410) 974-0947

423


Annapolis, MD 21409

1

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 when I'm not necessarily realizing

that I'm creating a medical device? So this is a key

problem that we realized if we're going to work in

this space, we needed to address this.

Also, when we looked at the requirements

from these use cases, they were coming from many

different perspectives. Some of them were

overlapping. Some of them, there were just big gaps.

So you had to do this and you had to do this, and you

said yeah, but what about all the other pieces you

needed in-between to make it a safe and effective

solution? There was also a complete lack of

understanding with respect to regulatory

opportunities in this area.

And it was pretty interesting because many

times, the reaction we got was similar to your

friendly IRS agent coming and paying you a visit.

You say regulatory and you kind of get almost a

visible shock. And whenever -- we then said well,

you need to think about safety, you need to think

about how these interoperable systems will be

effective when you put all the pieces together. And

you kind of get this "huh?" stare back at you. So as

a result of this, it became very clear, pretty rapid,

that just to launch into a standard process was not

(410) 974-0947

424


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

going to cut it. We needed to kind of create a

technical note which painted the broader picture and

then kind of gave a more cohesive set of

requirements. So that's what we did. I'll just take

you very quickly through this.

Notice that in the front matter of this

technical note, we included some terminology, some of

those key definitions like what is a medical device,

what is a hazard, what is a risk, what is an alarm?

For example, what are the differences between alarms

and alerts is one of the key questions that came up.

So we have that. We then had a couple, a very short

section that said okay, what about devices in ARRA or

HITECH or meaningful use?

And so we created some analyses, some

tables in there that kind of pull that out as to what

is the role of device connectivity within the current

national program. So we had a couple of tables

there. Notice here that the dates are tied onto

this. You don't see 2011. Some people may say well,

you know, we just came out the end of last year with

these new rules that are being evaluated right now.

I don't see devices anywhere in the Stage 1 criteria,

why is that? Well, Stage 1 is 2011, and there are no

devices currently in 2011. However, we have been

(410) 974-0947

425


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

told -- I'm not sure we'll totally trust them -- that

when we see the 2013-2015 criteria come out for

meaningful use, that's when we'll see device

connectivity pick up and the items in this table will

start to show up. I do encourage you, though, to

please respond when these items are out for public

comment.

You can point out the need to include

device connectivity in there because our experience

to date is if we don't do that, if we don't make a

pretty loud voice, what will happen is it'll just get

put again on the back burner, and it won't see the

light of day. Other sections in here, one is a

general device connectivity landscape, general design

considerations. So what are some of the things that

you have to keep in mind when you talk about

integrating devices into a health IT enterprise.

Another is what are the different classes

of applications or how does device connectivity

factor into clinical pathways and workflow

automation. And there's a section there on ICE and

highly integrative patient-centric point of care.

These all painted, though, kind of the broad picture

to help people who do not have an idea about device

connectivity, what we are talking about, what we're

(410) 974-0947

426


Annapolis, MD 21409

1

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 familiar with. I then added one, basically

because of Mike Robkin's initial use case, a

regulatory consideration section. This is not

supposed to give you any guidance. It's not supposed

to go and be a long treatise, as you can tell by the

number of pages. It isn't, in terms of these issues.

However, you should at least have a clue that there

are some things you should be thinking about.

You know, when you try to integrate these

systems, when you try to develop the technological

profiles that you'll use to deploy device DHR

interoperability, for example. Here, you can see

these are very familiar. We've talked about them

today and before, and for years in the past. The

main point here was we were able to keep it in the

document, even up to the very last staff internal

review last week.

One of the key comments that came back was

we still don't understand why this should be in this

document. We should take this out. I was able to

keep it in there, but that's the kind of pushback

we're still getting even from that level. Charting

the path forward, if you go into this next section,

there's a consolidated list of connectivity

requirements based on the requirements given to HPSP.

(410) 974-0947

427


Annapolis, MD 21409

1

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 created a roadmap that says over the next few

years, here is how we should address these

requirements. And we also identified gaps, there's a

gaps table, and it said here are some of the base

standards, the composite standards of profiles that

need to be developed to be able to move forward. And

then also it identifies the organizations, many of

whom are represented in this room, as well as some of

the timeframe in which they need to be provided.

What it does not do is address regulatory

issues. I knew better than to even try to get it on

that table. For example, I mentioned education. A

key issue here is just to be able to bring the

awareness and understanding of what it means to

integrate medical devices, medical applications, into

these systems. We've talked a lot about CEIT

convergence; 80001 has been a discussion in here.

80001 is actually on that roadmap because

one of the requirements we had was for a wireless

connectivity, and guess what, right now the only

real, the best solution we see coming down the pike

is for addressing wireless connectivity in the near

future, on an enterprise basis, is 80001-1 plus the

wireless technical report. The guidance is being

developed. What about the regulatory model for how

(410) 974-0947

428


Annapolis, MD 21409

1

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 address this? We have talked, I think -- I wasn't

here yesterday, but rumor has this has been a topic

that we've put on the table. This is something that

has to not only be addressed in terms of how these

systems can be combined safely and effectively but

then communicated.

And, finally, in terms of the deliverables

that we have, the capabilities and constructs from

HPSP and other government organizations, they need to

be able to support that to the greatest degree

possible. Very quickly, and I got to think, some of

the key contributors -- John Donnelly's not in here,

but Ken Fuchs and Tracy Rausch, John Rote's (ph.)

here in the front, was a key contributor, and John

Zaleski, also.

I really appreciate it. Many people

reviewed the documents and helped out, but I really

appreciate those of you who put the time in to make

it happen. And, hopefully, by the end of the week,

the final document will be published on this site.

Thank you very much.

(Applause.)

MR. OSBORN: Thank you, Todd. Since we're

running so behind, Ken's already up here. We'll see

if we can get your presentation up. And Ken's going

(410) 974-0947

429


Annapolis, MD 21409

1

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 talk a little bit about the debate between what is

an interconnect versus an interoperable device, what

levels or radiations of what it is we're trying to

accomplish.

MR. FUCHS: So I think a lot of this has

been touched on already, and I think that we have to

be a little careful with our terminology because -- I

mean, our goal here is to talk about

interoperability, and it's really, as Dave Arney

talked about, a lot different than connectivity.

We have all these organizations in terms

integrating the healthcare enterprise, workshop

interoperability, connectivity conference, integrate

a clinical environment. Todd was talking about the

CDC, the connectivity document from HPSP. ISE talks

about healthcare connecting, medical plug-and-play.

We have, at least there's one connectivity consultant

I know about -- and she's not here. And as of

December 1st, actually, I know two connectivity

consultants.

The other one's my son, but he works in the

financial services industry, and he just got a job on

December 1st, and his responsibility is to connect

trading systems to traders. And his business card

says connectivity consultant. Here, if you want to

(410) 974-0947

430


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

do integration, you can go to Black Box because they

do integration, and you know, what we're talking

about here is a lot more than just integrating

because as a matter of fact, we don't want to be

doing integrating. We want Luis to not worry about

integrating. We want him to be worrying about

getting solutions done and making some progress

forward in getting clinical applications out there.

So as I thought about this, I see a number of

different levels of interoperability, and they

increase in complexity and maybe these with

integration.

This is just kind of a thought I have in

terms of trying to organize this in some conceptual

framework. And at the very bottom is physical

connectivity, and we have standards for that.

That's, at this point, basically a given. Next level

would be maybe qualified interoperability. That's

kind of where we're at today. You know, everybody

has -- we have these solutions. People talked about

solutions where they did connect stuff together.

But what's the problem, right? We have a

solution from IMS, a nicely integrated system with

remote control. Where's the problem? The problem is

that it probably took man-years and man-years of

(410) 974-0947

431


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

effort to make that happen, and I think we need to

get beyond that. We have supactic (ph.) and semantic

interoperability, and we have different organizations

at every level trying to create standards because we

definitely need standards. We need to build on

standards to get where we want to go. And finally,

we have AA&A interoperability, which is for

authorization, authentication, and association. And

the association we've also talked about, trying to

associate that device to a patient. It's difficult,

and when you throw wireless at it, it's really,

really difficult.

So these are all issues that people are

working on, and we're working -- a lot of work in

IHE, continuing courses working on that. HPSP, as we

just talked about in the ICE group. The other thing

that I feel more and more strongly about, and

actually, you know, at some point I just thought,

well, we get a standard out there, we're good. And

I've kind of learned over the years that that's -- we

need to do more.

We need to do profiles, and now I think we

need to also look at some way of certifying these

implementations because even if you have a profile,

and in IHE we do connect-athons and we test, but even

(410) 974-0947

432


Annapolis, MD 21409

1

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's not really adequate. We need strong ways of

certifying these to make sure that they're actually

going to work when it's all done. And I know

continuous working in this area, CCHIT is working in

this area and eventually others. And I just want to

mention that when we talk about wi-fi, wi-fi was a

mess until the wi-fi lines got involved and started

certifying implementations. There's a standard out

there, but there was no real connectivity. And I

won't talk about interoperability at that level. It

was really just connectivity that wasn't working.

And somebody mentioned today that -- also had an

issue with their requirements, they had to get that

straightened out before they also got systems that

could talk to, to connect to each other.

I'll now kind of move into a discussion,

just a little bit more about the IHE group. I think

it's been mentioned a number of times. I spend a lot

of time, along with Todd and Paul and John and Steve

Merritt (ph.) and a lot of other people in the IHE

PCD group, which is for patient care devices. And a

lot of our work starts with use cases.

We have a number of current use cases that

we've analyzed and have profiles for, and they

include -- and they've been focused, primarily, I

(410) 974-0947

433


Annapolis, MD 21409

1

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, at the interface between devices and the

enterprise. So these are more EMR, EHR oriented

types of interfaces that are potentially a little

easier to define and implement than some of the more

tightly coupled point-of-care interfaces, but we're

also starting to look in that area. We have ways of

getting vital signs from the devices to the

enterprise. We have a patient identity binding

profile. We have a way of subscribing patient data

which hopefully would help in some of the things that

John Zaleski was talking about yesterday. We have

ways of getting alarm information out to the

enterprise. We have a control loop to verify that an

order that was sent from the pharmacy system directly

to a pump is properly implemented.

Paul Schluter will about the Rosetta

project soon. We have a user handbook that's

targeted at the implementers, and we also have a

group working on interoperable devices and getting

profiles for that. Other development we've had is

device point-of-care profile. We have a medical

equipment management profile, and that's targeted at

biomedical engineers and clinical engineers in the

hospital trying to manage thousands and thousands of

devices using IT systems, and we're also working on

(410) 974-0947

434


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

waveform communication.

There's another list of things that we're

thinking about. These things come from the user

community and the vendor community. The people that

are signed up and involved in this group, they

provide their suggestions, and we basically have a

vote and decide what's going to happen next. This is

a scene of the connect-athon, so part of the process,

after we've gone through collecting use cases and

developing a technical spec, is to actually have

vendors get together and test these across the table

from each other. Two weeks ago we were in Chicago

doing this, spent a week doing it, and that's good,

it's a good start.

We at least kind of -- a lot of stuff, but

it's not necessarily going to guarantee that these

systems are going to work together when they're

implemented. This is when we actually demonstrate

this at HIMSS, if you're going to be at HIMSS this

year -- please come by and visit. We have a bigger

and better booth.

Seems to always be growing. And, you know,

this is not done in isolation. We work -- a lot of

the work is done based on HL7 standards, based on the

IEEE 11073 work. We've been working with Continua on

(410) 974-0947

435


Annapolis, MD 21409

1

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 remote monitoring profile. We've been working

with HPSP and we have -- and Tracy will be talking

about our work with the ICE group. Thank you.

(Applause.)

MR. OSBORN: Okay, let's set it up for our

next speaker. John is going to be talking about --

UNIDENTIFIED SPEAKER: No, you're going to

go next, Paul.

MR. OSBORN: Got the wrong order.

So -- actually I think it makes better sense. So

Paul's going to talk about the whole questions of

semantic interoperability, the difference between

nomenclature and semantics.

DR. SCHLUTER: Thank you. What I'm going

to talk about next is one of the initiatives of the

IGPCD effort. As Ken mentioned, the Rosetta

Terminology Mapping Project is a way of capturing

vendor terminology and then mapping them to a single

industry standard nomenclature based on the IEEE

11073 communications standard.

We're currently using this to transfer your

real time medical device data via a gateway to an

EMR. The same nomenclature can be used for device-

to-device and other connectivity things, but our

initial focus has been getting the data to an EMR in

(410) 974-0947

436


Annapolis, MD 21409

1

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 rich, accurate, and consistent manner.

So semantic interoperability, I'm sort of

thinking what use case to put here because semantic

interoperability affects almost every aspect of data

communication and interoperability, no matter whether

you're a patient in an ambulance, you have a Holter

recording, you're a patient on a monitor, or you're

submitting clinical data for clinical research

trials. The key thing is that in our application,

we're looking to convey near real-time medical device

data from device to device or a system that might be

like a monitor to a central station, or from a device

to an enterprise and using a gateway. That's what

we're currently doing most of our work in the IGPCD

effort. The same nomenclature can also be used for

moving enterprise documents once it gets to the EMR.

The objective here is to communicate

medical device daily use in a single unified

nomenclature and semantic model; that is, the word

for heart rate, the computer code for heart rate used

by all centers in all receivers is the same. But in

addition to that, it's more than just a list of

terms.

When I say ST deviation, maybe I want to

say oh, I want to report that in microvolts or

(410) 974-0947

437


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

millivolts, so what we've done here in the Rosetta

effort is to combine the nomenclature with other

essential co-constraints like units of measure, lead

sites where a measurement may be taken, or even more

importantly, enumerated value such as what is the

current pump status for an infusion pump, is the

cassette door open. All of those have to be agreed

upon by all the multiple vendors, and it's often very

challenging to get agreement there, but I think, as a

group, we have done very well, leveraging a lot of

the very good work in the IEEE 11073 standards. This

next slide -- oh, it's been slightly -- that's okay.

Mine looks all blue. You know, this next slide sort

of shows the overall process that we took. The

vendors, we had eight of them, Vendor A, B, C. All

submitted spreadsheets containing their current

gateway code or display codes plus their effort or

attempt to map it to 11073.

Those are all confined into a single table

we call the Rosetta Terminology Mapping table or we

just call it RTM for short. And at that point we

began quite a significant series of discussions in

terms of harmonizing the use. Maybe somebody

misunderstood how a term was used or there was a

discussion about units of measure.

(410) 974-0947

438


Annapolis, MD 21409

1

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 we had quite a number of meetings just

trying to resolve that and in the end producing what

we call the harmonized table. That's where we're all

signing out of the same hymnbook, the HRTM,

containing about 440 distinct terms that you might

find in a clinical monitoring scenario. It probably

covers maybe 70 percent of the terms most of our

gateways send today, but we found that we need to do

a little more work in the ventilator space since

those devices and their clinical applications are

quite complicated. With that table of names of

things and enumerations and units of measure, we then

have a very rigorous definition of the vocabularies

that can be used to send off device observation data

to an HL7 Version 2 message like we're doing in IGPCD

for the past three years, as well as other encoding

such as HL7 Version 3 and 11073 plug-and-play device

connectivity. The key hallmarks of our effort, open

consensus process based on an open consensus

standard. Everybody gets to say their piece about

this.

The other key thing, observation

identifiers and key constraints because when you look

at some measurement like heart rate and you also know

per minute, it's very clear what that means. They're

(410) 974-0947

439


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

more interestingly title lined. Is that a rate or a

volume? By specifying the unit of measure that goes

with that, it's a very clear, unambiguous

understanding of how that term should be used in

addition to the descriptive text in the standard,

itself.

Another thing we found again with

ventilators is that the standards, we need to update

them. There's been a lot of progress in the

ventilator area for the past five years since the

publication of the standard. We've determined -- in

fact, have a special working group on that -- to

augment the existing standard to support ventilators.

And finally and most importantly, the HRTM or the

whole Rosetta project provides the necessary database

information that John Garguilo at NIST and other

certification agencies can use for rigorous semantic

testing of messages. Now, this next slide -- this is

sort of my last slide, plus I want to go to one other

topic, well -- is the harmonized Rosetta.

Just to give you a little idea of what's

here, like I said, we use the IEEE codes, also UCOM

units of measure, which is used for Version 3 and

Dycon now. One thing we did is we really wanted to

be sure that we got the physics and chemistry and

(410) 974-0947

440


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

understanding absolutely right. So we have

dimensional analysis of it that allows us to look at

all terms that have the same dimensionality which is

often tied deeply to the physics or chemistry behind

something, and enumerated values, measurement sites

and the numeric codes, everything you need to really

check the essentials of any observation reported in

our HL7 messages.

So here the rep ID is MBC ECG heart rate.

Dimensionality is inverse time, you know, per minute

or something and, in fact, the units are beats per

minute or UCOM, a more textural representation, beats

per minute in different flavors. But it got really

interesting when we got to ST deviation because

traditionally, that's represented as millimeters of

deflection on a paper tracing. However, it really is

a voltage, and so that's what we decided as a group

to do. That debate took half a day, and it also took

coordination with Dycom, who made the same leap of

faith, saying let's call it a voltage because that's

really what it is and we will emblazon it in the

Rosetta as this is how you should send it.

So here we have millivolts and microvolts,

and here in red, on this screen, we voted off

millimeters, so on the HTML version of the table,

(410) 974-0947

441


Annapolis, MD 21409

1

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 in red, and we call that voting it off the

island. And there were about ten other things.

There are quite a number of, like, traditional uses

of units and measure that are incorrect in the

literature. We corrected that.

And then finally, another example: gas

monitoring, calling it concentration. It's often

either percent or partial pressure. Rosetta allows

that, but makes it very explicit that the units that

we specify have different dimensionality and that

receiving application should be very aware of this.

Let me see. And I won't talk about this too much.

There are related efforts that we've also done here.

We have a current working group on ventilators,

related to Rosetta. We're now publishing all new

nomenclature standards in 11073 as XML. This started

with the older, annotated ECG done through the FDA

HL7 project. And now, we have all three, all four or

five major pacemaker vendors having to develop their

own nomenclature, harmonizing it with the Heart

Rhythm Society, and that's now available, almost.

And another one is a Continua IG and

continual interface where Continua has decided to use

the same PCDO1 technical framework for communicating

home healthcare data over the internet using the

(410) 974-0947

442


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

11073 nomenclature and its personal health

extensions. And to keep my talk short, I think I

will end with this last bullet and skip my

discussion, and just say another really critical

collaboration here is the excellent tooling developed

by UNIS (ph.) to actually test our messages to a very

high degree of rigor so it's very hard to send a

wrong message.

And I think that's one of the key things we

need if we're going to have an interoperable

standard, is that we can rigorously test our messages

and test every little aspect so it's virtually

impossible for somebody to send an incorrect message

due to misunderstanding or a coding error. Okay, so

I think I'll stop here due to the time. Thanks.

(Applause.)

MR. OSBORN: Thank you, Paul. And we're

set up now to talk about the whole question of how do

we test, validate, and/or certify.

MR. GARGUILO: Thank you, Dave. I will

start out with NIST doesn't certify, so --

UNIDENTIFIED SPEAKER: Do you validate?

MR. GARGUILO: We do validate, we do

verify. I know it's a touchy word in medical

devices. I want to provide a perspective across what

(410) 974-0947

443


Annapolis, MD 21409

1

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've seen is the three themes of the last day and a

half, and defining and discussing use cases, talking

about the needs of standards and specifications to

address those, and then how do you constrain or build

profiles against those, so we want to look at some

testing areas.

So very quickly, I just wanted to point out

the domain that we're looking at within medical

devices are both at the device level, so if you have

some agent and manager devices communicating, and

then from a gateway which maps that information out

into the enterprise, and that may include work with

personal health devices. So we're working closely

with several entities. We are not clinical engineers

or clinicians, but we certainly need to be attached

on that end to understand the use cases and real-life

situations that are very important so that we can

address the testing aspects. I want to just jump

into quickly what we're focusing on, and I think it's

an area that addresses some of the discussion that

has gone on in actually many of the sessions, and it

revolves around constraining information, so we've

heard many folks talk about the standards; I won't

reiterate those.

Primarily, what we're talking about 11073

(410) 974-0947

444


Annapolis, MD 21409

1

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 X73 and HL7 at the enterprise level. But

essentially, the way we look at testing is constrain

that information so that we can get down to the test

assertions and then do an adequate job where we're

trying to be more formal and adding rigor to the

testing.

So, typically, you'll have a user or a

device which has a black box where you've made a

message, and we feel that, as a start, based on the

use cases and the scenario that that message is

exchanged in, you'll want to look at things like how

can we profile the standard, how can we reduce the

optionality. Standards are very wide open, there are

a lot of options that can be addressed, and we really

need to constrain those. And then within domains,

for example, we just heard about IAG. How do you

take framework specifications and narrow those down

to the set of use cases that you're addressing or, as

IAG calls it, integration profiles. And those are

defined within various domains; you may have

cardiology, radiology, patient care devices, et

cetera. Are there specific terminology or

nomenclatures used in those frameworks, and are we

interested in looking at specific values that may be

addressed in a test case?

(410) 974-0947

445


Annapolis, MD 21409

1

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 these are the areas that we really want

to focus on and drive how we define our validation

context so that we can test. So how do we do that?

We look at components of testing, and really, we look

at things in sort of a services way, what are the

various services that are needed to carry out the

testing, how do we validate and verify that the

information being exchanged is correct? And there

are many pieces that come in to this box here. We

could talk two days about a test architecture, and I

won't go into that at this point because I know

between me and lunch is an ICE-PAC.

(Laughter.)

MR. GARGUILO: So just to further narrow

that point down, here's an example from the IAG PCD

world, using HL7 standards and some of the

nomenclature that Paul Schluter just spoke of. So

you have HL7 standard message definitions that

basically are turned into what are your transactions

that are going to be exchanged. You have HL7

standards, value sets of those, so you might have HL7

tables to find that are very specific for a device, a

class of device, or even an instance of that device

in the use case or the scenario. And you have

nomenclature defined across the standard, so as Paul

(410) 974-0947

446


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

just alluded to, the 11073 nomenclature, and then you

have very specific assertions that are down to maybe

the test level, what are very key points or even

specific values that you're interested in.

So we turn those into defining constraints,

and then those become files that are used in the test

system, to the validation engine. These are

basically what we call validation context files. So

we're able to drill down from really a specification

level down to a test case level of what it is we will

test against.

It's important to note that we really look

at testing from three primaries, not to say that

these are the only environments, but we really focus

on three primary environments, what we call instance

testing. That might be just a slice in time of a

message, so you're basically validating an instance

of a message. Does it meet the standard, does it

meet the constraints that I just mentioned on the

previous slide. And then we build on that, and we

get into things like looking at a system as an

isolated system against your test environment, your

test system, and how does that isolated system

operate. So you may have certain inputs, you may

look at certain outputs, depending on what the

(410) 974-0947

447


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

scenario describes. And that also starts looking at

underlying protocol conformance and functional

behavior because the system is being looked at as a

black box and things are going on functionally.

To add to that, you then look at multiple

systems on the test, so you have sort of a peer-to-

peer relationship. You can add one to many, and the

test system has to be part of that, maybe set as a

proxy or seeing messages and validating on the fly or

doing various other things as the requirements are.

So I just wanted to point out how we view

environments.

This is an example of what that might look

like in an instance testing, so this is basically, as

we heard earlier, two weeks ago there was a

connect-athon. We're really looking at static

messages and validating those messages between, I

think it was 18 vendors, across four integration

profiles. So you have a message coming in and a

management system of the test that basically was run

through a test execution component, and it uses

various services to validate the message and then a

report would come back. If you look at it from a

isolated point of view, you have a system under test

here sitting off, and then it's interacting with the

(410) 974-0947

448


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

system through some router logger proxy which is

through the network, so it adds that layer of

information. And then if you talk about more peer-

to-peer or multiple systems, you would have several

systems under test.

Much in the same way, you'd be interacting

with the management system, which executes and is fed

some information to pull off the testing. But I

included some additional services over here on the

left. These are not all the services, but there's a

huge architecture that needs to be identified which

identifies all of these things.

And as you start getting into more robust

and more completely defined use cases, you can start

building things like test agents that simulate an

actor in a particular scenario. The ultimate actor,

of course, is a reference of limitation that can be

used for a particular standard or set of standards.

So I want to leave it at that. I wanted to keep it

kind of brief of what we're after. Here are some

sites of some tools we have. The first two are what

we used in the IAG, what is called a pre-

connective -- before the vendors get together,

validating message in the connector file, and then

the top link is our medical devices site. So thank

(410) 974-0947

449


Annapolis, MD 21409

1

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 very much.

(Applause.)

MR. OSBORN: Thank you, John. Tracy. It's

all about the ICE-PAC.

MS. RAUSCH: And I'm treating you guys to

lunch, so -- but about, I guess it was October of

2008, there was a joint meeting between the ICE group

and the IAG folks, and we said okay, we're talking

different languages, and we don't know how to make

these two work together because the ICE group tends

to come from a very clinical focus where this side

tends to come from more of a technical connectivity

and interoperability focus.

And I several times sat in the room and sat

at the table and knew that two people were saying

exactly the same thing and they were arguing. So

when Todd and Julian said well, we should have a

joint, you know, group to talk about this, they both

turned and looked at me, so I don't know how that

started. So ICE-PAC is a joint working group between

the ASCN ICE standard and the IGPCD, and it also

includes a bunch of 11073 because it tends to be some

of the same people. The whole purpose of this group

is to produce requirements for standards at a systems

level, so the requirements that came out of ICE, how

(410) 974-0947

450


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

does, you know, the IAG groups do profiles, how does

11073 modernize itself to fit to these profiles. And

another area that was brought up was how do you

identify hazards where clinical practice needs

systems engineering. And this is all about how do

you engineer in the prevention of errors; it's not

how do you react to the errors, but how do you just

stop them from occurring altogether, using

interoperability.

This is the boxes that I told you guys

about yesterday that -- we were sitting at the table,

I believe Rick Schrenker was there and Jennifer

Jackson and Julian, and these are the six boxes that

were drawn. The names have changed as many groups

have added, but there's always been these six boxes

of what to do. This is an iterative process that you

move through.

You get a clinical story, you get a

clinical scenario from a doctor; how do you make that

into something that's an actual requirements document

for a bunch of engineers to be able to understand

what's going on? The next step of that is you move

to clinical workflow, and then you do what is called

a workflow analysis, and I would have loved to show

you in the presentation, but the workflow analysis

(410) 974-0947

451


Annapolis, MD 21409

1

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 we have for the example of infusion therapy is,

when it prints out, it's about a four foot by six

foot piece of paper. But it's actually hanging on my

office wall right now. But it's a little difficult

to actually explain everything that's going on, but

we're using a methodology to go through and do this

analysis of the workflow.

The next step of this is actually a risk

analysis. So let's go through the workflow and

the -- diagrams and find out where are our

weaknesses, where are there points that actually

could occur that a commission would make a mistake?

Where can we engineer this in? If a technology

failure occurs, do you need an interlock that

basically protects the patient? And the next part is

a state diagram and basically, a technical solution.

See anything on the bottom yet?

So Dave, when you get there, you

know -- and we have several state diagrams, too, but

we're mostly focusing on the top three boxes today.

So we gather requirements from clinical systems.

We're providing traceability of this system. Where

are you getting the requirements for this systems

level approach to understanding the system of what's

going on. And you're providing the systems all the

(410) 974-0947

452


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

risk analysis. This isn't always done on normal

medical devices. You provide an analysis for your

device, but what's the analysis of when you put your

device with five other devices, what occurs? And

this also -- it provides traceability for mitigating

this risk. So we put this technology or this

application in place to stop this from occurring.

And you're designing for the system, you're

not modifying the system because modifying the system

causes unintended consequences because your biggest

part of your systems is doctors and nurses, and most

of us know how cooperative that occurs most of the

time. If you've been in the clinical environment,

nurses are absolutely famous for finding work-arounds

of things that they don't like.

General building blocks and interactions

that I talked about yesterday, and basically, you

know, that hypothesis that the general building

blocks make up a specific system and the system can

be safe if the blocks and the interactions are safe.

This is the high-level diagram of an infusion

process. I'm not going to show you the rest of it.

It's about 15 pages long. Each box of this has

several blocks that actually drop down inside of

what's going on. This page right here is one of the

(410) 974-0947

453


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

famous parts of an infusion process, the five R's of

infusion delivery. That's the decision process that

a nurse makes to go through the decision system. And

this is kind of my slide. They're moving to the

right with technology, but there's only one line of

that 5R process that where smart pump technology

actually comes into play. So you go back, it's this

line right here is where smart pump technology's at,

although that entire page is the nursing process to

actually set up an infusion pump.

So now they ask you can we give him six

infusion pumps. All of a sudden this is what the

decision looks like, and I'm not even going to get

into what the ventilator decision tree looks like

because it's ugly. Well, yes, but it kind of looks

like that. So, basically, some of the critical

findings that we found to do these interlocks -- is

contextual data is very important, what's going on in

the patient, what's going on around him.

And the need for device characteristics to

make these interlocks and have these decisions is

very important; accuracy, precision, the source of

the data, and more characteristics are coming out.

And the other part is understanding what the quality

of data is. It's not only the communication quality,

(410) 974-0947

454


Annapolis, MD 21409

1

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 what's the quality of the sensor you're getting.

Do you want to pause an infusion pump because the

pulse oximeter fell off their finger, or do you want

to know that the pulse ox came off the finger. And

the last part of this is that there is a definite

need for risk mitigation when you start including

these systems together, and I touched on that a

little bit yesterday, so that's all. Do you have any

questions?

(Applause.)

MR. OSBORN: Do we have any announcements?

UNIDENTIFIED SPEAKER: First announcement

is lunch is ready. Please come back at 1:30, if you

can. Then we'll only be about a half hour behind

schedule.

(Whereupon, a lunch recess was taken.)

(410) 974-0947

455


Annapolis, MD 21409

1

2

3

(410) 974-0947

456


Annapolis, MD 21409

1

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:30 p.m.)

MR. ROBKIN: All right, thank you. Thank

you for coming back. I hope you enjoyed the lunch.

A little bit of housekeeping before we start the

breakout sessions. So now we begin a much more

interactive session. This is the real meat of the

program. This is your opportunity to report back to

the committee, to the conference, to the FDA, to

everyone else in the industry what you thought, what

you discovered, what you think, and what you think we

should all do.

We've broken up these breakout sessions by

industry. We did it this way because we hope that

people with a common background and a common interest

would have a more productive time if they got

together and were able to discuss the issues they

heard and the potential solutions.

So we have the breakout sessions up on the

screen. What we'd like you to do is find your

breakout session. Based on the interest, we're going

to put high-acuity regulated manufacturers over in

this corner of this room. The other areas, you can

see, there will be an FDA escort for you outside

after I shut up, and they'll take you to your room.

(410) 974-0947

457


Annapolis, MD 21409

1

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 some volunteer facilitators. They're there

to help capture what you tell us, and we've asked

them to report back. Because we're a little late on

the schedule, what we've decided to do is give you

guys more time for the breakout sessions, and we'll

do the report outs Wednesday morning, first thing, so

that'll give people an evening to digest what's been

reported.

So in your breakout session, please feel

free to discuss what you think the issues are, that

you've heard, or maybe the issues that you didn't

hear. We're especially welcoming of any ideas you

have for how to move forward, solutions, how to make

progress, any ideas you have inside the box or

outside the box.

Anything else? There will be one breakout

session here, people on the phone. So regulated

manufacturers, in general, high-acuity, please stay

here in this corner. If you're interested in

research or policy, that's Room 2049. Dr. Goldman

will be your skill facilitator.

DR. GOLDMAN: That's the little room across

the hall, 2049.

MR. ROBKIN: Care providers, hospitals,

that's 3201. Tracy Rausch has volunteered to

(410) 974-0947

458


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

facilitate that discussion. Infrastructure, so

that's networks, cell phones, hardware manufacturers,

computer hardware, 3209 with Tim Gee. And regulated

manufacturers, since there are so many of you, we've

segregated those of you who consider yourself low-

acuity and perhaps ambulatory as opposed to critical

care, hospital; and Jeff Secunda and Brad Thompson

will be facilitating, and you're in Room 4101. We've

left ourselves open for the second round of breakout

sessions. We're interested to see how the first

round will go and what the results will be.

UNIDENTIFIED SPEAKER: How much time do we

have now?

UNIDENTIFIED SPEAKER: It's 20 of.

MR. ROBKIN: So we'll give you an hour, so

that's 2:45 for the first breakout sessions and good

luck. Yeah, please come back here for announcements,

2:45.

(Breakout Session #1.)

MR. ROBKIN: All right, thank you again for

coming back. I know it's been a long day.

Hopefully, you had enough time to get here -- a few

announcements before we begin. Tomorrow, please do

not bring your luggage to the FDA. You won't be able

to bring it past security, so hopefully, your hotel

(410) 974-0947

459


Annapolis, MD 21409

1

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 your rental car or something will be able to

accommodate you. And clean up the room when you

leave. That's what Sandy said. Clean up the room.

UNIDENTIFIED SPEAKER: Not your hotel room,

this room.

MR. ROBKIN: This room. So Sandy will be

in charge of maintenance for this room. And any

volunteers who wish to supervise Sandy.

UNIDENTIFIED SPEAKER: We'll do an audit

when he's done.

MR. ROBKIN: Oh, okay. That's good. The

shuttle buses will be downstairs at 5:10. There will

be a group photo of all of us in the atrium at five

o'clock.

UNIDENTIFIED SPEAKER: Downstairs where?

Where's the shuttle bus? What atrium?

UNIDENTIFIED SPEAKER: Same place as

yesterday.

MR. ROBKIN: I don't know.

UNIDENTIFIED SPEAKER: Same place as

yesterday.

MR. ROBKIN: I hope the same place as

yesterday. Is there also a group photo tomorrow

morning?

UNIDENTIFIED SPEAKER: Yes.

(410) 974-0947

460


Annapolis, MD 21409

1

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: What time?

UNIDENTIFIED SPEAKER: First thing. Nine

o'clock.

MR. ROBKIN: Okay, nine o'clock. Okay. So

once again, 8:50 tomorrow morning, atrium, group

photo, please. Right here. 5:10, shuttle buses, I

hope, in the same place they were in yesterday. Five

o'clock right out here, group photo. So for this

afternoon, we got some feedback that the groups, some

of the groups, have not quite finished their

discussion, so what we propose is that you go back to

your groups that you were in, unless you didn't like

your moderator, then feel free to pick a different

group.

(Laughter.)

MR. ROBKIN: And we would ask you to focus

your discussion on paths forward, on solutions, on

next steps, on things we can do to actually do

something about the issues we've all identified. We

have one particular path forward that we'd like to

discuss with you, and hopefully, you'll be able to

add some meat to it, and Dr. Goldman will tell us

about this particular path.

DR. GOLDMAN: All right, the path. How did

you like the carrots? Pretty good, huh? Okay, so

(410) 974-0947

461


Annapolis, MD 21409

1

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 path. There has been quite a bit of side

conversations and discussions about a crazy idea to

try to drill down deeper into what we're all here

for, which is to clarify the regulatory issues around

interoperability.

And the pathway we've been using to do that

in looking at the safety and means to achieve safety

of a system or the efficacy of a system for whatever

our goals are. Well, one idea that's been floated

for a while is that we have a prototype regulatory

submission of an interoperable system.

So a system may be real or it may be,

referring back to one of Mike Robkin's slides where

he showed a slide at elements with real components,

real devices and people and some aspects that were

simulated or mocked up or otherwise, you know,

prototyped, so perhaps have an ecosystem of devices

and capabilities and bring that through kind of a

research or a prototype regulatory review, the

details of which I'm not going to present. I'll just

present them in concept. I'm not qualified to

present the details. But the concept would be that

perhaps there could be a system of several devices

that could be used in a high-acuity area, for

example, to achieve a certain use case or cases.

(410) 974-0947

462


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

Perhaps another one that's for a low-acuity area,

with a number of devices. Maybe some of those

devices are actually available in the market today or

maybe some of those devices are not.

For example, if there's a decision support

device that's responsible for taking information from

the other devices and that decision support device

would then provide clinical decision support, maybe

that doesn't exist yet so maybe we just make believe

that exists. And that allows us to focus not on

things like how the decision support is accomplished,

but algorithms along those lines.

But again, around the interoperability, you

know, the ability of a system to acquire the data

that it needs to provide decision support that can

convey its output if it's done in a way that's based

upon components that would be interoperable and so

forth. So that's the general notion, and in various

conversations, there are folks here that represent

companies that said they would be interested in doing

that if they have products that might be suitable or

they could mock up a product, or they could take a

product they have today and make believe that they

have an interface that performs through an existing

standard for interoperability, though maybe it really

(410) 974-0947

463


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

doesn't yet, and that's where the whole notion of

this is being -- kind of a collaborative research

approach to prototype a system.

And then really to find out, then, if it

would pass muster or what it would take to pass

muster or just to answer regulatory questions. So

again, that's not my area of expertise. I'm trying

to convey this at a high level of general notion.

And then, so one way to approach this, this would be

initially a vehicle to carry a lot of the ideas

forward that have been brought up.

So what we've been discussing are

those -- the facilitators have been discussing during

the break is how to carry this forward into the next

session. The idea would be that if we kept the same

grouping, we could change it as needed, but let's

assume for a moment that we keep the same grouping as

the prior session, so we would have the grouping of,

the Number 1 on the list is Regulated Manufacturers,

High Acuity. So that group would reassemble, but the

group would reassemble and then generate ideas for

how to use this prototype regulatory review, which

devices might they want to use; who is willing to

step up and participate in the work, at least

preliminary expression of interest; and which

(410) 974-0947

464


Annapolis, MD 21409

1

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 would they like or they think need to be

answered.

And then the Research Policy group is

likely to, you know, do a much more refined job in

terms of delineating what could be accomplished, but

they may not select the devices, and the research

group may, you know, come up with questions around

how we can look at the safety and performance of a

system like that.

So that's been the idea, and we discussed

this among the facilitators and also among some of

the FDA personnel here to make sure they didn't

seize -- those that we left in the hallway, those

that didn't walk into the room and are still sitting

here. So that's it. We'd like to, you know, open

the floor for any comments on -- and let's look at

the list we have now in terms of sessions. Note that

the third one, Care Provider/Hospital, we added

slash-EMR based upon their conversation that it

seems -- it was mentioned that having an EMR-centered

perspective on interoperability might be very useful

because they're getting different issues from that

perspective that might be appropriate. So this is a

proposal, and let's open the floor to refine that

list before we break out, and please comment on this.

(410) 974-0947

465


Annapolis, MD 21409

1

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 only been discussed among the facilitators and

probably another 15, 20 people in here, but not

everyone, so please go up to the mike and

let's -- for a comment.

UNIDENTIFIED SPEAKER: Yeah, I don't

understand exactly --

DR. GOLDMAN: Isn't that working correctly?

UNIDENTIFIED SPEAKER: I think it's working

fine. I can hear myself.

(Laughter.)

UNIDENTIFIED SPEAKER: What I'd like to ask

you very quickly is -- okay. What I'd like to ask

you is whether you really intend to have a review,

either an FDA review or a review by folks that, you

know, regulatory affairs folks, consultants,

regulatory consultants, something, a mock review of

this system that you're putting together?

DR. GOLDMAN: Oh. Well, the notion of a

submission implied a review as well. I didn't say

that explicitly, but you brought that out.

UNIDENTIFIED SPEAKER: And do we have the

FDA's buy-in on this? I mean, did Donna-Bea say

sure, send it on in or --

DR. GOLDMAN: I'm happy to speak for the

FDA.

(410) 974-0947

466


Annapolis, MD 21409

1

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: Fine.

MR. MURRAY: George, remember the purpose

of this workshop is to think up genius ideas.

UNIDENTIFIED SPEAKER: Not to work?

MR. MURRAY: So Donna-Bea doesn't know

about this yet.

UNIDENTIFIED SPEAKER: Oh, oh. Sorry.

DR. GOLDMAN: Donna-Bea isn't here.

MR. MURRAY: If we can't think openly and

think about how we think we should proceed, then

we'll be locked into the old ways, so --

UNIDENTIFIED SPEAKER: I'm fine with it. I

think it's an excellent idea. I just wanted to know

the mechanics of whether or not somebody would

actually review it.

DR. GOLDMAN: Donna-Bea will be -- she's

not here, right? So Donna-Bea will be reviewing it.

Anyone else who isn't here will be assigned to

review.

UNIDENTIFIED SPEAKER: You have to

understand, neither one of these two guys reports to

Donna-Bea, so they can say anything they want.

(Laughter.)

DR. GOLDMAN: Which makes them that much

(410) 974-0947

467


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

wiser.

MR. MURRAY: I want to point out that

George -- one point and now he doesn't.

(Laughter.)

DR. GOLDMAN: Anyway, I think what John

said is really important. This is an idea, but it's

an idea that's been floated around and discussed

within FDA for, you know, on and off as a

possibility. It's not outrageous. It would not

result in regulatory approval, so to speak, except

above this prototype of this concept and drill down

to some of the issues. But I think that's what the

breakout session is for, what kind of questions you

ask, what kind other people can add. I'm just trying

to present it as a high-level -- John, do you want to

add some more?

MR. MURRAY: I think Julian left out a lot

of details.

DR. GOLDMAN: Thank you very much for your

comments.

(Laughter.)

MR. MURRAY: There's a lot more to

this -- there's a lot of fat as to interoperability;

what it is, what it isn't, but there's a whole

regulatory idea. We're going to get to that. So

(410) 974-0947

468


Annapolis, MD 21409

1

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 I was thinking is that we need to explore what

the best regulatory pathway is for this -- and the

most effective way to do it is to use the tools that

FDA already has available to us because the FDA is

generally not receptive to new tools.

UNIDENTIFIED SPEAKER: Wait a minute.

MR. MURRAY: Because they're required to

follow the law. How's that? Is that better? So my

suggestion was that we can use a 513(g) or we can use

a pre-IDE or whatever, you can go and investigate

what regulatory model is best for this, which I call

"the thing" now, a product of some kind, and the

whole idea is that why not go use the regulatory

tools that are available to explore the different

pathways that can be created. It may involve a de

novo process, or we can create our own classification

of this product in a special controls document which

allows you to do all kinds of other flexible things.

But it's a lot more complex than just -- what was the

word I heard, a fake submission?

(Laughter.)

DR. GOLDMAN: I didn't say fake.

UNIDENTIFIED SPEAKER: Prototype.

MR. MURRAY: Prototype.

DR. GOLDMAN: I said a thing, a thing.

(410) 974-0947

469


Annapolis, MD 21409

1

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. MURRAY: I think there's a lot more

information that needs to be talked about in this

breakout than just what the regulatory issue is. Are

we going to get to that?

DR. GOLDMAN: Well, we have different

groups. We'll talk about the --

MR. MURRAY: Okay.

DR. GOLDMAN: So why don't you go through

some of the things you think we should cover? We'll

add it to the list, make sure we cover it.

MR. MURRAY: I mean, is the intention of

this breakout session only to talk about regulatory

submission, you know, the pathway or is it to talk

about --

UNIDENTIFIED SPEAKER: Different pieces.

MR. MURRAY: -- what the thing's going to

be?

DR. GOLDMAN: Yeah, what the things are

going to --

MR. MURRAY: What the risk model looks

like? Who's going to be in control of it?

DR. GOLDMAN: Which devices might be used.

UNIDENTIFIED SPEAKER: And what the

intended use is going to be.

DR. GOLDMAN: Predicate devices.

(410) 974-0947

470


Annapolis, MD 21409

1

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. MURRAY: I've caused enough trouble.

UNIDENTIFIED SPEAKER: Isn't it premature

to decide on the regulatory pathway before deciding

what the thing is going to be and what components

it's going to have?

UNIDENTIFIED SPEAKER: I think it's the

options for regulatory --

MR. MURRAY: I don't think that's possible,

and the reason I don't think it's possible is because

the way I understand the law works, you can't come to

the FDA with a random kind of thing and figure out a

pathway unless you know what that thing is, so the

thing has to be pretty well established before you

can actually find out which pathway it goes down. So

you can't figure out a pathway before you know what

the intended use is, what the thing looks like,

different kinds of things like that.

UNIDENTIFIED SPEAKER: That's what I mean.

You need to put that together before.

DR. GOLDMAN: Let's get back to the chicken

and the egg for a second. Sorry, didn't

see --

UNIDENTIFIED SPEAKER: One of the things

that came up in the low-acuity group was the mix of

medical devices and consumer devices for maintaining

(410) 974-0947

471


Annapolis, MD 21409

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

an interoperable system. Is it fair to assume that a

thing that we could consider would be a mix of

devices and get some guidance on what is regulated

and what is not?

DR. GOLDMAN: Well, it could be two things.

UNIDENTIFIED SPEAKER: Then you go through

the approval process.

DR. GOLDMAN: It also could be two things.

UNIDENTIFIED SPEAKER: It could be two

things.

DR. GOLDMAN: Could be two things. So

since I like to speak for the FDA, so something that

has come up in these discussions in the past has been

that we've talked about well, maybe we can

bring -- the FDA has said, let me start

again -- well, just bring, you know, gather some

companies, bring forward a regulatory submission, and

let's see how it goes because we have a system in

place, and we think it will work, and just bring it

through. The problem is that most of the -- if you

do, if you can find ten devices, maybe ten different

types of devices and three devices of each type, all

of which are interoperable that you can bring through

today, good luck because they don't exist.

So we have a chicken and egg problem where

(410) 974-0947

472


Annapolis, MD 21409

1

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 don't exist, but the FDA paradigm is for

you to bring products through, through a regulatory

process. So that's the problem. That's one problem.

So one pathway to this is this framework

that we just discussed, which is that it's a

prototype that's essentially an exploration of the

pathway in collaboration with the FDA. And we will

probably have to fake it in terms of conformance to

interoperable interfaces or conformance to

certification of those interfaces as interoperable.

So there are things that won't exist in the devices,

and we'll have to make assumptions, and so ideas have

been tossed around that we can also -- one can

generate test results of tests that would've been

performed on interoperable interfaces, and we almost

have a very complete set of data. That's something

which you really can't generate today because the

interfaces aren't there yet. So these are just ideas

that have been proposed, and I'm going to a level of

detail I didn't intend to, but that would be it.

So this is for everyone to play with and

see if we can come up with a set of candidate devices

and things we would wish to learn and are willing to

step up and stay with this and maybe work on it and

provide some resources. And I think it would be a

(410) 974-0947

473


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

really unique opportunity to drill down to a level

that we've never been able to before. And the time

seems to be running, so -- I didn't lock everything

up, John. Let's --

MR. MURRAY: It was my fault, Julian. I

apologize.

DR. GOLDMAN: So on behalf of the FDA, why

don't we get down to business?

MR. ROBKIN: We're breaking. Your only

request is to be ready for the group photo before

five o'clock. And we will do the report backs from

today tomorrow morning, so enjoy your breakout

sessions and please come back for the group photo.

(Breakout Session #2.)

(Whereupon, at 5:00 p.m., the meeting was

adjourned.)

474


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 26, 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