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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409 (410) 974-0947
PRESENTERS/MODERATORS: JOHN J. GARGUILO Computer Scientist, DoC/NIST TRACY RAUSCH Founder and CTO, DocBox, Inc.
308
Free State Reporting, Inc. 1378 Cape Saint Claire Road
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
2
3
(410) 974-0947
456
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
Annapolis, MD 21409
1
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
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
Free State Reporting, Inc. 1378 Cape Saint Claire Road
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