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
170
Embed
WORKSHOP ON MEDICAL DEVICE INTEROPERABILITY: …s3.amazonaws.com/rdcms-aami/...Interoperability/... · WORKSHOP ON MEDICAL DEVICE INTEROPERABILITY: ACHIEVING SAFETY AND EFFECTIVENESS
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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