Why Connect Medical Devices

Why Connect Medical Devices?
September 27th, 2005 | Published in Healthcare IT, connectivity
Reader Charles F. posits the question above in a recent comment on the post Current
State of Medical Device Connectivity. I’ve reproduced his comment in its entirety:
Frequently missing from the device connectivity dialog is the all important
question “ok, you’re connected, so what?” If the point is simply to dump device
data into a database the point is being entirely missed.
Patient-attached devices are of value if ! and only if they can get their information
to someone who cares…WHEN they care. Designing otherwise is to contribute to
information overload and the long list of
things clinicians ignore until it’s too late. So, to improve device connectivity is just
moving the problem around. What’s needed is a comprehensive approach to device
data management that provides clinicians with the ability to recognize worrisome
trends across multiple parameters and systems and be notified of those trends
BEFORE the “mis-adventure” occurs. This, of course, begs the question of how
device data management is to occur. As device suppliers increasingly get into the
software business there is somehow an assumption on their part that their limited
view of the patient’s condition must be a highly valuable perspective worthy of
waking up the nearest attending physician. How long will THAT last? Device
connectivity is a huge step forward but only in the context of systems capable of
evaluating the data in real time and making prospective inferences….and then
figuring out who should know.
“So what,” indeed. The connectivity market requirement that is most embraced by both
vendors and users is dumping device data into some sort of software — be it for data
analysis and reporting in a diagnostic system, or documentation for paperless charting.
This capability is driven by growth of the paperless charting market. Medical device data
acquisition is a critical requirement for successful EMR adoption, and
a considerable challenge all on its own. This is important, but to Charles’ point, of little
value from a patient care and safety perspective.
Medical device connectivity has been rolling through the industry for 20 years, and has
finally hit a wall at the point of care. The point of care brings together a plethora of
medical devices (and no one vendor makes pumps, vents, and patient monitors); many
clinicians, caregivers, and diagnosticians; and patient data aggregated from many sources
presented in a clinical information system. There are no single vendor solutions here.
Dumping data into the electronic medical record (EMR) is at least something relatively
straight forward and within the control of a single vendor. Hospitals, who have to deal
with a large installed base of legacy devices (that frequently average 5 or more years in
age), networked in a myriad of private subnets or supporting device specific proprietary
serial interfaces (both protocols and pin-outs), and usually a few newer networked
devices (all incompatible, of course) face a significant need to move beyond point
solutions dressed up as expensive upgrades and find an enterprise solution.
Applications like patient centric alerts and medical device alarm management must deal
with complex workflows, multiple vendors, and numerous users. It is so natural for a
device vendor to see the world as though defined by their own product centric market.
Traditional clinical information systems vendors view market requirements from a
broader user’s perspective, but despair at dealing with a multitude of device vendors and
new regulatory hurdles (i.e., the FDA). Hospital leadership, having been burned before
on complex systems integration, is not likely to rush to buy into the first point of care
solution that comes along. There’s not even a name for this new area; point of care
automation really doesn’t express the breadth and complexity (nor the promise) of this
new frontier. Any suggestions?
The good news is that there are clear benefits to the kind of point of care integration and
workflow support that Charles alludes to; things like reduced length of stay (LOS),
improved patient safety, and reduced medical errors will drive this market segment to
broad adoption. The eventual market leaders in this new segment will surprise us all, and
represents a great opportunity for newcomers to grab a big piece of this market and
existing players to retool their business models to meet this new combination of
requirements. There is no doubt that early innovator hospitals are currently looking for
solutions, and that select vendors are working on solutions. Navigating the next several
years until the market has matured will be a challenge for buyers and sellers alike.
About the author
After almost 25 years in health care Tim remains with his first love, connectology, the
automation of workflow through the integration of medical devices with information
systems.
Market Trends Series #2: Patient Safety
October 1st, 2009 | Published in Patient Safety, connectivity | 6 Comments
This is the second post as part of an ongoing series that discusses the market trends that
are affecting the evolution of medical device connectivity (MDC) technology. I received
some good comments from my previous post – please consider sharing your thoughts,
ideas, and experiences.
The second trend I’d like to discuss is the shift towards patient safety as one of the key
market drivers for connectivity. It is probably not news to anyone that patient safety has
become one of the key drivers for many healthcare IT initiatives. But what is the
relationship between patient safety and MDC? Ever since the often referenced IOM
report, To Err is Human: Building A Safer Health System, hospitals and vendors alike
have increased their focus on driving towards significant reductions in medical errors.
The industry as a whole has made great strides, but still lots of work remains.
With device connectivity, my experience has been that for at least the past 15+ years, the
key driver has been making the nurse more efficient by eliminating the manual
transcription of device data into the patient’s chart. One of the related benefits is a more
come complete and legible patient record. However, one could argue that the more
legible patient record could be achieved if the vital signs from medical devices were
simply typed into the charting application manually (something that many hospitals are
actually doing today). So I believe that the nursing efficiency argument holds as the
primary driver – but that is starting to be challenged by the focus on patient safety as it
relates to connectivity.
Up to now, bedside patient monitors have been the priority medical device driver for
connectivity. Multi-parameter patient monitors produce approximately three quarters of
the total number of device parameters that need to be charted on a periodic basis. Other
devices that make up the remaining one quarter of the data set includes ventilators,
anesthesia machines (of course in the OR environment), standalone pulse oximeters, IV
pumps, standalone cardiac output devices, and even beds (weight, angle of inclination,
rail positions, etc.) However with the increased drive for patient safety in recent years,
we are starting to see hospitals discuss requirements for smart IV pumps to be interfaced
as a priority over other devices.
One of the reasons for this shift is likely due to the high number of visible errors involved
with high profile infused drugs such as Heparin. Simply put, hospitals are focusing more
on those devices that are directly related to patient safety and errors and IV pumps are
often in the mix. Hospitals have been migrating to smart IV pump technology. One key
market indicator is the rapid growth of smart pumps being purchased – now over 60% of
US hospitals have made the switch to smart pumps. For details – refer to this link.
Even though smart pumps are proliferating, challenges remain when it comes to the
integration of smart pump data to the EMR and smart pump alarms to alarm management
and notification systems. In reality, there are very few instances of IV pump connectivity
to EMR or alarm systems. Not only is there the issue related to patient ID and association
(for detailed discussion see this link). There are also the issues related to the unique
nature of the data produced by an IV pump. But it is a bit ironic that just as patient safety
is driving the adoption of smart pumps, the need to ensure safety is one of the factors
holding back the end to end integration to the EMR. Vendors have been very cautious on
all sides when determining how to integrate pump data. The stakes are high if the
integration does not work 100% - patient safety is at risk.
What really needs to be charted into the EMR from an IV pump is the total volume
infused (TVI), the infusion rate, and the drug dose. The problem is that EMR vendors
have been working on how to accept automated data from pumps – but some EMR’s are
not there yet.
One complexity is related to the fact that the EMR cannot just import the data values
directly from the pump devices. The EMR needs to perform a calculation of volume
infused taking into account what has already been infused over the last charting intervals.
Also, don’t forget that most patients are infused by more than pump device at a time,
especially in the ICU.
Another important challenge is related to bi-directional communication with an IV pump.

Data must be able to flow seamlessly from the IV pump to the EMR for documentation
purposes. But to really reduce administration errors and impact patient safety at the
bedside, automating the programming of the pump is required. The order for the infused
medication or fluid needs to be transmitted to the right pump at the bedside – and this
requires a capability to communicate bi-directionally with the pump device. The
workflow challenge for the nurse at the bedside is ensuring you have the right patient, the
right pump, and that the order matches the patient before it gets to the pump.
I believe that the focus on patient safety will continue to drive vendors towards providing
connectivity solutions that solve these types of complex problems. IV pump connectivity
and integration are the next big frontier in MDC. What do you think? Whether you are a
care provider or a vendor – agree or disagree. Do you think I missed anything?
About the author
Brian McAlpine is currently Director of Strategic Products at Capsule Tech's Andover,

MA office. He's been in health care for over 18 years, and has focused on medical
devices, technology, and connectivity most of that time. Brian can be followed on Twitter
at: brianmcapsule
Email Brian | All posts by Brian McAlpine
6 comments ↓
#1 Pete McMillan on 10.02.09 at 12:24 am
I do not support end-to-end integration of pumps to EMR. This would require

greatly increasing the complexity of the pumps (as if they were not complex
enough already), complicating their user interfaces, increasing the amount of
interaction required, and implementing specific workflows as you mentioned. On
EMR side, it requires interfaces that are custom built to suit different pump
vendors.
I would advocate somewhat “dumb” pumps that connect to a proprietary gateway

supplied by the manufacturer. The Gateway would maintain mapping of the pump
to patient (barcode? proximity sensors?), maintain a database of medications
infused, and perform running calculations of volumes infused. The gateway
would then forward the data to the EMR. This would save the cost and effort of
updating custom built interfaces in the EMR everytime a pump vendor changes a
part of the protocol, or building a new custom component in to the EMR when we
buy a different brand of pumps.
The ideal solution however, is to do away with even the gateways. The holy grail
would be if the pumps could be interfaced to the patient monitor (monitoring
vendors - don’t get excited. I am talking about real interfacing here, not the feeble
effort you currently make to get a tick in the tender compliance. Read on), and if
that interface could be bi-directional, and if the patient monitor is intelligent
enough to understand the data (rather than just relay) and calculate the running
totals etc. Currently, the patient monitor is the one that can be relied upon to
maintain the patient context at the bedside. Through the hypothetical bi-
directional interface, it could supply the patient context to the pump. Users could
select the medications from a list on the patient monitor, select rates and assign
them to the pumps. The patient monitor receives data from the attached pumps,
processes them and forwards them to EMR. Monitors could also relay pump
alarms using their current paging/sms interfaces.
With that scenario, the workflow becomes much simpler and interfacing pump
data to EMR would be less of a headache. Users would only need to be familiar
with the user interface of the monitor, not of each individual pump.
#2 Ken Fuchs on 10.02.09 at 5:10 am

Integration of pump data into the EMR is very important, but it certainly presents
many challenges.
As already mentioned association of the pump to the patient is a key issue, which
is exacerbated by the trend (primarily in the US) to embrace wireless pumps. This
drives the implementation towards using central pump gateways, making it even
more difficult to get the data back to the patient monitor (if this is what you want
to do) and implementing patient association since you have no idea where the
pump actually is located.
Concerning the use of patient monitors as bedside data collection hubs… This
implies that a patient monitor is at the bedside whenever you want to do electronic
data collection - and that is not always true. I am pretty sure that there are many
patients in the hospital that have IV pumps attached to them but who are on
telemetry monitors or are not attached to a patient monitor at all. However the
general concept of having something intelligent at the bedside providing a better
user interface for data collection than a 2-line LCD display on a pump seems to
make sense.
I do feel that the pump system (whether it is the device or the gateway) should be
responsible for calculating and delivering the key parameters such as volume
infused rather than the consumer of the data in order to minimize the probability
of calculation errors.
@Ken Fuchs:
” I am pretty sure that there are many patients in the hospital that have IV pumps
attached to them but who are on telemetry monitors or are not attached to a
patient monitor at all…”
Well, I am pretty sure there aren’t. Is it possible that you are confusing infusion
pumps with PCA pumps?
Infusion pumps are used for drugs where very precise dosing is necessary. And
the reason why very precise dosing is recommended for such drugs is because
they often have unintended effects at high plasma levels, or the required effect is
not achieved at low plasma levels (eg. inotropes). This means, patients receiving
such infusions need to be monitored. Such patients would hardly be ambulatory.
In any case, it is hard to imagine a patient walking around with a telemetry
transceiver and a pump stack.
#4 Brian McAlpine on 10.06.09 at 12:07 pm

In response to both Pete and Ken’s comments – first of all, thanks for
commenting.
I believe there are a couple of threads being discussed here. My original

comments about end-to-end integration of pumps to the EMR — was a general
comment about IV pump integration and did not imply how the connectivity to
the EMR is established. With the growth of wireless smart pumps in the market,
the only viable mechanism for integration to the EMR is via the vendor-specific
pump gateway using a protocol such as HL7. However, in reality almost all
implementations of IV pump integration to an EMR has been via a serial
connection form the pump to a bedside concentrator or term server. The main
reason is that the physical serial connection establishes the location of the pump
via a mapping of the term server to the bed or room location. Data from the pump
can then be sent to the EMR and the patient ID lookup can be accomplished in the
EMR application.
In response to Pete’s comment – “The Gateway would maintain mapping of the

pump to patient (barcode? proximity sensors?)” – so far, there has been few if any
workable solutions for accomplishing this association at the bedside. Yes, the
pump gateway can maintain the PID association mapping - but the association has
to physically be performed at the patient’s bedside.
Another thread being discussed here is using the patient monitor as the bedside
device integration hub. For many years this has been one of the solutions
available for integrating devices such as ventilators and anesthesia machines. This
has worked very well for all of the big patient monitoring vendors, but has left
many hospitals with long-standing issues to deal with after they have gone down
this path. One of the biggest flaws with this a strategy for hospitals is that
sometimes the hospital does not have the same patient monitoring vendor at all
beds. If that is the case, then the hospital is left dealing with all of the complexity
and supporting device integration solutions from multiple vendors. In addition,
from direct experience, often there are not device drivers available from the
monitoring vendor or the drivers have not been kept up to date with support for
the latest parameters a device can generate.
To address Ken’s point about patient’s that are on IV pumps that are not
monitored continuously or with a conventional multi-parameter patient monitor –
yes, he is correct. There are many situations where patients are not in a critical
condition but still have an IV pump for antibiotics or fluids. Many of these
patients are on general medical surgical floors and these rooms definitely do not
have traditional patient monitors (that can be used as a bedside device integration
hub).
Lastly, the IV pump system (device or the vendor gateway) should be responsible
for calculating and delivering the key parameters such as volume to be infused.
However, the EMR needs to be responsible for recording what has actually been
infused into the patient and documenting this requires calculations to be made in
the EMR application. The reason is that different care units and patient acuity
levels drive different charting intervals in the EMR. One unit may be charting at
q15 minutes and another may be charting at q1hour. Therefore, the EMR must
calculate what volume was actually infused into the patient over the last charting
interval. Regardless, there is quite a bit of complexity to deal with when it comes
to IV pumps. And the complexity is on all sides and will require cooperative
efforts to achieve end to end integration.
#5 Market Trends Series #2: Patient Safety | Medical Alert Devices on 10.10.09 at
8:11 pm
[…] (more…) […]
#6 Carla on 10.16.09 at 3:45 am
The patient record is an integral part of the health care system to document the
care the providers and their ancillary staff provide to the patient. In spite of the
recent technological advances in hardware and software applications for
computers, the patient record is predominantly paper, even in high technology
environments such as the intensive care unit (ICU). Even with ICUs that have
computerized or electronic medical records (EMR), no system exists today that
supports a totally integrated electronic medical record. The lack of a totally
integrated EMR makes it difficult to track the patients’ care from the ambulatory
to the inpatient setting and prevents improved medical decision making, which is
necessary for decision support and critical pathways.
Market Trends Series: Wireless Connectivity

September 17th, 2009 | Published in Uncategorized, Wireless Medical Devices | 11
Comments

 Fresh back from the MDC Conference in Boston last week - great
inaugural event and a perfect venue at Harvard Medical School. Thanks to Tim and the
conference organizers — I personally heard many very positive comments from a number
of attendees.
As the healthcare market continues to evolve, so do solutions related to medical device

connectivity. I would like to invite you to join me in a dialog over the next several weeks
- perhaps even on an ongoing basis - that will explore the trends that are affecting the
market of medical device connectivity. The idea is to have an open and interactive
discussion on where the technology is today, where it needs to go, and what is driving the
market. Remember that this is just my viewpoint as I see things based on my
experiences. Perhaps your experiences and perspective are similar or maybe they are
completely different.
So, let’s begin. The first trend I’d like to talk about is wireless medical devices and the
impact on connectivity. We all know that more and more medical devices are becoming
wireless and therefore more mobile, for example more and more smart IV pumps (smart
pumps) are being implemented every day. One key aspect of wireless technology is the
fact that wireless enables devices to become untethered, and therefore a mobile use case
is enabled. Wireless medical devices such as smart IV pumps and patient monitors add to
the list of connectivity challenges because, from a pure connectivity perspective, they
have basically eliminated one problem (the use of a serial data cable) and often create
others. Once a medical device is no longer connected to something that facilitates data
integration (like a bedside terminal server for example), then part of the connectivity and
integration problem often shifts onto the manufacturer of the medical device.
Enterprise applications need access to real-time device data and alarm data. Without
physical connectivity to individual medical devices at each patient’s bedside, the
enterprise application must access the data via a gateway (a central server) connected to
the hospital network with an HL7 outbound data interface.
Many of the large patient monitoring vendors did not experience any problems with this
shift to wireless devices - mainly because they had already developed and understood
device gateways and methods for handling the identification and mapping of patient data.
Most of the leading patient monitoring vendors have been integrating their devices to
EMR’s for at least the past 10 or more years. Monitoring systems have developed
methods to deal with data identification (ensuring the right data gets to the right patient’s
record) through some collaboration with the EMR vendors. But this is a whole new arena
when you consider IV pumps and many of the other common bedside devices. Dealing
with the identification of wireless device data from mobile and transient medical devices
brings a whole new set of challenges – and this is both a technical problem as well as a
clinical workflow issue.
There are quite a few device manufacturers that offer wireless in their devices. However,
there are really only a few vendors that have done wireless right. And by this, I mean
taking into consideration all of the requirements to operate on the hospital’s enterprise
WLAN and requirements for how the wireless device help facilitate integration to
enterprise systems such a EMR’s and alarm notification systems.
So what do you think? Are wireless devices causing you to think about medical device
connectivity differently?
About the author
Brian McAlpine is currently Director of Strategic Products at Capsule Tech's Andover,

MA office. He's been in health care for over 18 years, and has focused on medical
devices, technology, and connectivity most of that time. Brian can be followed on Twitter
at: brianmcapsule
Email Brian | All posts by Brian McAlpine
11 comments ↓
#1 Tim Gee on 09.21.09 at 8:34 am
Brian, I’ll kick things off with a few observations.
First, the delivery of health care is inherently mobile. Everything is moving:

patients, staff, and equipment. In a perfect world, all medical devices would be
battery powered with wireless communications. That’s clearly the direction the
market is going, as you observe.
The biggest challenge for wireless communications is establishing and

maintaining patient context. This must be quick and easy to do (i.e., good
workflow) and reliable as devices go in and out of wireless coverage and roam
across subnets.
I think the device category with the most experience in wireless and wireless
patient context is patient monitors. But I don’t think they started with gateways. It
seems to me that they had to create a central station app to enter and maintain
patient demographics for the patients on their unit, and then modified the user
interface on their patient monitors to facilitate the display and selection of the
correct patient name. Gateways came later for HL7 integration for ADT feeds and
flowsheet documentation.
I would also argue that establishing patient context right at the point of care,
where both the patient and medical device reside, is the safest most reliable way
to manage patient context.
Smart pumps handle patient context differently, rather than selecting a name from
a short list on the pump itself, users have to barcode scan the patient, pump and
themselves. There are many wireless smart pumps deployed, and many of them
have the means to establish patient context. However, unlike wireless patient
monitors where patients are routinely captured for patient context, only a very few
hospitals (my guess is less than 5 in the US) establish patient context on their
smart pumps.
Why? Certainly the technical approach to patient context used by these two
device categories is quite different, as the resulting workflow. The reasons for
establishing patient context also differ. For the sake of discussion, let’s say the
reason is the differences in the quality of workflows implemented in the two
different device categories.
#2 Shorts: MDC review; Radiology wiki; Insurance rates up | mobihealthnews on

09.21.09 at 10:36 am
[…] Wireless medical devices need to consider hospital’s WLAN: Medical

Connectivity’s Brian McAlpine shares his thoughts on the Medical Device
Connectivity event in Cambridge last week in a post over at MC, which conclude
with an assessment of wireless integration into medical devices done right:
“Dealing with the identification of wireless device data from mobile and transient
medical devices brings a whole new set of challenges – and this is both a
technical problem as well as a clinical workflow issue. There are quite a few
device manufacturers that offer wireless in their devices. However, there are
really only a few vendors that have done wireless right. And by this, I mean
taking into consideration all of the requirements to operate on the hospital’s
enterprise WLAN and requirements for how the wireless device help facilitate
integration to enterprise systems such a EMR’s and alarm notification systems.”
More […]
#3 Mikko Kaarela on 09.22.09 at 6:20 am
One of the key challenges in wireless medical device connectivity is Wireless

Quality Assurance (WQA).
In a hospital it is impossible to rely on dissatisfied users to complain when a “best

effort SLA” WLAN is down, as we are used to see in office environments.
Instead, need a monitorable SLA with performance criteria in line with
requirements of healthcare and a centralized 24×7 monitoring system that not
only alerts when things go wrong, but also collects diagnostic information for
WLAN experts. This enables to solve also intermittent radio interference issues
cost-effectively.
#4 Brian McAlpine on 09.23.09 at 10:59 am
In reply to Mikko’s comments: Thanks for the comments. I agree with everything
stated about the importance of managing wireless quality (WQA or also referred
to as wireless QoS). But I would extend this 24×7 monitoring capability beyond
what you have mentioned.
I have seen many different network management solutions deployed in hospitals

for monitoring network QoS (for both wired and WLAN). These solutions let you
know how well the wireless medical device is operating in the network
environment. If there is a problem with wireless - these systems are very good at
helping to pinpoint problem areas (coverage, capacity, up/down status of AP’s,
etc.) But what these solutions do not monitor is the status of the integration to
external systems - like the data connection to the EMR or the alarm connection to
an alarm management server. The WLAN may be working perfectly fine - but
that does not mean the end to end connectivity all the way through to the external
system is working. What is really needed is a solution for monitoring both the
network environment and the connectivity (interfaces) to external systems.
#5 Pete McMillan on 10.01.09 at 11:57 pm
I believe Mikko and Brian are talking about two different things here. One is our
responsibility, the other is the vendors responsibility.
As Mikko notes, the reliability of the enterprise WLAN is extremely important,

and does require managing and monitoring wireless QoS. This is compounded by
the fact that today’s wireless networks were never really designed for “mobile”
use, but rather as replacement for wires. As long as you sit down somewhere
within the range of an access point, you can access the network wirelessly with
your laptop. The moment you become “mobile”, moving from access point to
access point - that’s where things become difficult. Unlike GSM networks or
DECT networks, the WLAN networks don’t care about a 30 second (or more)
break when transitioning between access points. This is slowly changing, but will
continue to remain a challenge.
That said, I firmly believe the enterprise WLAN should remain the responsibility
of the IT department. Device vendors should adapt to the enterprise networks by
developing workarounds, and not dictate to us how to manage our networks.
What Brian mentions in his reply is something completely different. Assuring and
monitoring end-to-end connectivity between two systems (eg. device and EMR) is
completely out of scope for an enterprise network (wired or wireless). Enterprise
network is the highway, not a package delivery service. End-to-end connectivity
monitoring needs to be managed between the vendors for devices and EMR. Eg.
The device should be able to detect that it lost communication to the EMR (or to
its own proprietary gateway), temporarily buffer the data and upload to EMR or
gateway upon reconnect. EMR should be able to receive the buffered data and
insert it at the correct time point. This is clearly the responsibility of the vendors.
Infact, my biggest gripe with Philips right now is that their devices cannot even
perform a buffered upload to their own proprietary central station over their own
proprietary network. Yes, there’s a long rocky road ahead.
#6 Matt Perry on 10.03.09 at 6:21 am
I think all these posts bring up very relevant points but I believe they are points
that are made with a retrospective view on what Wireless was (and to are large
extent still is). Most (all) vendors of the wireless architecture technology had
designed products and architectures that were aimed at a convenience based
connectivity medium. The valid comment about sitting under an AP maybe in a
coffee shop and it works fine but as soon as I try and roam things start to break
are a fundamental issue with today’s wireless architectures. There are however
vendors such as Aerohive that had the benefit of hindsight and with some clever
design built an architecture that for the first time will truly deliver on the mission
critical nature of un-wiring a hospital.
Aerohive is unique in the market place in offering wireless connectivity that is
both high resilient, high performing, multi-functional, simple to manage and can
provide defined service levels that can be monitored and instantly and
dynamically adjusted. The buffering issue that Pete saw could easliy be over
come with some patented technology imbeded in the Aerohive architecture. I did
not want this post to be a sales pitch but as a I go around hospitals all over the
world I see the most demanding set of end users any ICT dept could hope to work
for (the clinician) and think thank goodness I have something in my kit bag which
will take a little of the headache away http://www.aerohive.com
I would be happy to do a webcast to anyone listening to discuss this in an open

forum.
#7 Carla on 10.20.09 at 4:01 am
This will take like 2 decades to be in use
@Matt Perry:
Interesting. I would assume that you have a huge volume of peer-to-peer

broadcast traffic between your APs to maintain the “hive” relationship - how does
this affect the bandwidth? How fault-tolerant is the “hive” - if one or several APs
fail, can the hive survive? Do you require a higher density of APs to maintain the
hive (compared to, say, CISCO or Aruba)?
Have you validated your network with Philips devices? And how do you propose
to overcome the buffering issue I mentioned?
#9 Matt Perry on 10.26.09 at 10:40 am
On your first point (I will try an answer without trying to give everyone a sales
pitch) the “Hive” runs a protocol between APs in the same way the internet runs a
protocol between routers. The bandwidth comment is a smart question and of
course in building the protocol was something that was high on the list of “how to
build a scalable network”, suffice to say the load is tiny. The protocol is fully
distributed (like the internet) so failure of a single device does not affect any other
device or the network as whole (possibly only local connectivity at that point).
We also have many features that protect against both AP failure, power failure,
network failure and failure of upstream services.
The density of APs needs to be no more than Aruba or Cisco (or any other
vendor).
On your second point, we do have a working relationship with Phillips and have
their technology deployed on some Networks in hospitals. That said of course
Phillips make a huge range of medical equipment some of which for obvious
reasons of time and effort has not been run or tested on an Aerohive network. We
do work closely with the customer and Phillips in trying to assure the application
works as expected and if Wi-Fi is not access methodology that suits the
applications we will be the first to say so.
Regarding your specific issue with the lack of buffering capabilities of the Phillips
device I believe this sounds like a client side issue. You mention that it is a
proprietary network which I guess they have a good reason for doing but I hope
we can agree that ultimately the only way forward is build standards based
systems. Is the application even using IP?
The Aerohive system can control very well network to client traffic, and mitigate
certain issues traditionally seen with client to network traffic, though on this last
point further standards work is and needs to be done (the IEEE is working on
this).
I hope this helps and I would be happy to go into more detail if required.
Thank you, Matt. My question about buffering issues was motivated by your
quick assertation to the effect that: “The buffering issue that Pete saw could easliy
be over come with some patented technology imbeded in the Aerohive
architecture”. I am aware that it is a client side issue, and that was why I was
curious as to how your “patented technology” could help overcome that. As I
suspected, that was an unsubstantiated comment typical of a sales guy who
doesn’t know what he is talking about.
#11 matt on 01.11.10 at 4:21 am
Hi Pete, sorry I appear to have offended you that was certainly not my intent. I
may add though that I think your comment is a little inflammatory, I will choose
to ignore it and get back to the point in question.
I am unable to give a categorical answer to the issue you are seeing and given
your statement about the proprietary nature of the system in use clearly the fix lies
with Phillips. However I stand by what I have said in that there are things that we
can do to help issues around the client to infrastructure communication chain.
These include Dynamic Airtime Scheduling, Client Load Balancing, Per Client
rate shaping, Per Client QOS, Service Level Definitions, Service Level
Bandwidth Boost functions, Seamless Roaming to name a few.
The solutions we install also can route around failures in the underlying network
infrastructure, for example a path failure between a client device and
EMR/Gateway. Of course if the client end point is not available we cannot
magically fix that which goes to your point of wanting the client to start to buffer.
No network can do that, that is the responsibility of the client device and
application (and requires symmetrical communications - if your app uses UDP
that feedback loop is difficult to achieve).
We are innovating a great deal around the whole client end-to-end connectivity
issue, some of this work is in the standards body (IEEE and Wi-Fi alliance) and
some of it will remain the IP of individual vendors like Aerohive.
Happy New Year.
Matt Perry
Technical Director Aerohive
How Medical Device Connectivity Can Improve

Outcomes in the SICU
June 29th, 2009 | Published in Patient Safety, connectivity | 5 Comments
In this article I will walk through typical decision-making processes within the surgical
intensive care unit (SICU) related to respiratory weaning in order to highlight the key
requirements associated with that area and to illustrate the importance of medical device
connectivity in acute care environments as a necessary adjunct and enabler for complete
documentation and clinical decision making at the bedside.
Acquiring Medical Device Data is Key to Clinical Decision Making
Medical device connectivity in the ICU is essential to supporting a complete clinical

decision support framework. While electronic medical records in and of themselves offer
enormous workflow benefits, the documentation and charting systems are only as good as
the data they convey.
Due diligence by care providers can be augmented by automated and validated data
collection, achieved through a seamless form of medical device connectivity and
interoperability that is supported both inside and outside the enterprise, and follows the
patient from the home to the hospital. Yet, as we know, human beings are complex
systems of systems.
Decision making in the healthcare enterprise is often made on the basis of multiple
parameters and in the context of the patient presentation, setting, and specific conditions
relating to the reason for hospitalization and procedures. The data used in clinical
decision- making originates from many sources: devices in and around the patient,
laboratory and blood tests, films, and ancillary information available both prior to and
during the encounter. How often should data be collected? The assessment of clinical
needs change depending on the acuity of the patient and conditions present at the point of
care.
Updates per care unit drive the quantity of data captured within the bedside
documentation, either through flow sheets or paper records. But, the team supporting the
patient ultimately must define what is acceptable and required. To support clinical
decision making it will also be necessary to include other data from the electronic health
record. These include fluid intake and patient output, demographic data, laboratory blood
draw assessments, films, etc. Clinical decision-making must be made with data
measurements obtained from devices at the bedside and from the ancillary data taken
from the electronic medical record.
An Acute Care Scenario
We can learn something of what is required to manage patients effectively by following

them through several key departments within the hospital enterprise—a “day in the life”
of a patient. In laying out the details of such a scenario, I will draw upon my own
experiences at the point of care.
Perhaps there is no better place to consider than the intensive care unit (ICU). The ICU
environment cares for the sickest of acutely ill patients. Many patients within ICU
environments, and particularly surgical intensive care units (SICU), are technologically
dependent on the life-sustaining devices that surround them. Some of these patients are
indeed dependent for their very survival on such technologies as infusion pumps,
mechanical ventilators, and intra-arterial balloon pumps.
Consider a patient who enters the hospital for a coronary arterial bypass graft, and the
workflow and environment surrounding a typical encounter. To this end, I will refer to a
former patient, Mr. A. It was determined by Mr. A.’s cardiologist that he had 90%
occlusion, or blockage, of three of the coronary arteries supplying his heart muscles with
nutrients. As a result, Mr. A was recommended for immediate coronary bypass surgery
the following morning.
During the admission process, he is assigned an electronic medical record number along
with account and related personal and payer identifying information so as to enable
charting and tracking his progress throughout the hospital. As Mr. A. is prepared for
surgery, he is moved to a pre-operative waiting area. He receives drugs to reduce the
workload on his heart and to prepare him for the anesthesia. He receives sedation and is
wheeled to the operating room where his anesthesia and surgical teams prepare him for
the procedure. The anesthesiologist manages the patient’s airway, sedation, and monitors
vital signs.
In the case of patients receiving coronary bypass grafting in which the heart is stopped,
the patient is also placed on a bypass machine that oxygenates the blood and returns it to
the body. Vital signs are documented, either automatically or through a paper record, and
all drug infusions are recorded by dose, time, rate, and titration. Mechanical ventilators
breathe for the patient and replace the exhaled CO2 with oxygen. Upon completion of
surgery, the patient is wheeled to surgical intensive care, whereupon mechanical
ventilation is continued, vital signs are monitored, and drug infusions are administered.
These devices all create measurements that are used to govern, maintain, and document
the status and trajectory of the patient as Mr. A. recovers. Gradually, as the effects of the
anesthesia wear off and as heart function becomes more stable and strong, the patient
begins to breathe spontaneously. Gradually at first, but increasing over time,
measurements documenting the trajectory of spontaneous breathing are captured and used
to evaluate patient state and recovery. Laboratory blood gas tests are used to affirm
proper physiological, renal, neurological, cardiovascular, and pulmonary function over
time. All measurements are recorded within Mr. A.’s medical record.
Physicians write orders guided in part by the patient’s recovering state. These
measurements, if recorded automatically from the medical devices, can serve to greatly
increase the charting process at the bedside. However, as importantly, they can also serve
to guide in clinical decision making by providing the Intensivist, and other attending
clinicians, with key information on the state and systemic health of the patient in regard
to this immediate procedure.
Data taken from bedside devices can also assist in determining whether the patient is at
added risk due to co-morbidities or ailments that can be acquired while in the hospital,
such as ventilator- or community-acquired pneumonia or sepsis. The ability to assist the
bedside clinician is enhanced greatly through the added benefit of complete, dense, and
thoroughly documented information. Charting (or “flow sheeting,” to which it is
sometimes referred) involves the documenting of all information relevant to the care of
the patient, including vital signs, fluid intake and output, laboratory values, ventilator and
respiratory information, and other non-numeric data that provide insight into the care and
progress of the patient.
Yet, despite the inordinate amount of data collected at the bedside, these are but a shadow
of the patient—an approximation of the state of the individual and this state changes with
time. For example, tools and methods that can assist or guide in the weaning of the
patient from mechanical ventilation; determine whether the patient is at risk for
myocardial infarction or provide insight as to whether the patient is likely to experience
other complications, can greatly enhance patient care management and clinical workflow
within the intensive care unit, and can result in more homogeneous and stable outcomes
for patients. Let’s consider the process of weaning patients from post-operative
mechanical ventilation as an example.
Weaning the Patient from Post-Operative Mechanical Ventilation
To assist in visualizing this scenario, refer to the diagram of Figure 1, which illustrates the intra-operative (OR) and post-
operative (SICU) processes. Data are collected through a number of sources. As shown,
an anesthesia machine is employed to assist in the electronic charting and capture of
patient vital signs into the electronic medical or electronic health record. Once surgery is
completed, the patient is moved to ICU in which further monitoring and management of
the patient continue. Shown are a Swan-Ganz catheter and a mechanical ventilator. These
two modalities are used to collect key information required for weaning our patient post-
operatively: cardiac output, temperature, cardiovascular function, and respiratory state.
Figure 1: Diagram illustrating high-level intra- and post-
operative timeline and key medical devices employed in support of the patient.
The process of weaning a patient from post-operative mechanical ventilation is an

important one that consumes a fair amount of time and resources within the SICU
environment. Patients are typically weaned according to specific protocols that involve
monitoring their spontaneous lung performance and cardiovascular systems to determine
whether, during this weaning process, they are receiving sufficient support. While the
process is well defined, individual patients can behave differently depending on many
factors including physiology, anesthesia dosing, general health of the pulmonary and
cardiovascular systems, co-morbidities, etc.
Patients being weaned from mechanical ventilation post-operatively must meet specific
physiological criteria prior to being weaned and must be managed closely during the
weaning process to ensure that physiological parameters and other data are always
maintained within safe and approved thresholds. Examples of such thresholds include
chest bleeding less than 100 CCs per hour, warming to normothermia (normal core body
temperature), normal blood gas oxygenations in excess of 95%, normal ranges on cardiac
output and perfusion ratios, and normal blood gas results.
Data collected both during the post operative weaning process from bedside devices can
be compared with data from similar patients so as to provide for an a priori assessment of
whether the patient state is evolving normally during the process. Because a patient’s
lung function has been compromised due to the strong paralytic drugs administered
during surgery, patients tend to arrive dependent on the mechanical ventilator for
breathing.
Most (if not all) mechanical ventilators used in the intensive care unit support the
capability to communicate data through standard RS-232 ports. The type and quantity of
data relate to the settings, mandatory support levels, and patient (or spontaneous) levels.
As patients begin to recuperate, their spontaneous support levels evolve from zero to
some final value related to full spontaneous support. This is illustrated notionally in Figure 2, which shows patient spontaneous minute volume (that
is, the volume of air breathed in a minute’s time) as a function of time after arrival from
surgery. The time at which a patient begins to breathe is related to many factors, as stated
above. The ability to metabolize the anesthesia is one of these. A patient will begin to
breathe slowly and will gain his or her strength over time, as illustrated in this figure. The
time at which the patient begins to breathe on his or her own is loosely tied to several
factors, including their body mass and core body temperature. Of course, the assumption
is that the patient is not being maintained in a sedated state post-operatively. This can be
the case and for a variety of reasons. However, we will assume the most typical of cases,
in which a patient is being weaned gradually over time.

supportFields]><![endif]-->: Notional representation of patient respiratory recovery
as depicted by post-operative minute volume evolution over time.
Prior to weaning, a patient should achieve normal body temperature to ensure all bodily
functions can operate at their optimal levels. The following graph, Figure 3, illustrates a normal re-warming profile of coronary
bypass patients recovering from the effects of anesthesia [1]. The horizontal axis
represents time from arrival in SICU from surgery. Thus, from the perspective of our
patient, Mr. A., we should begin the weaning process as the patient approaches normal
body temperature, around 37C.

supportFields]><![endif]-->: Average time to achieve normal body temperature.
As the effects of the anesthesia wear off and the patient’s respiratory performance
returns, the evidence of this improvement and strengthening is visible from the data
collected through the ventilator. These data, when charted, provide a visible trend that
reflects the patient’s pulmonary and cardiovascular performance. These data can be used
to help guide the weaning process as well as confirm and feed back to the clinician the
patient’s response to stimulus and treatment during the unconscious state.
The time to achieve spontaneous breathing at a rate of 1 liter per minute was determined
in a study of bypass patients in SICU by the author, and is represented according to the
plot of Figure 4. In this assessment, the author hypothesized that the
time to re-awaken, defined as spontaneous breathing in excess of 1 liter per minute for a
period of 10 seconds or longer, was related to the amount of analgesia / anesthesia
administered during surgery. The typical anesthetics administered to patients include
propothol and fentanyl. The author further hypothesized a linkage between the fentanyl
dosing and the re-awakening time. The following plot illustrates a best-fit plot to the
original data (r2 = 0.61).

supportFields]><![endif]-->: Time to achieve breathing level of 1 liter per minute
post-operatively linked to analgesia and anesthetic dosing intra-operatively.
Thus, armed with information related to breathing (available from the mechanical
ventilator), core body temperature (available through Swan-Ganz or similar core
catheter), and intake & output information from surgery, the clinician can begin to
develop an understanding for the expected relationships these may play in terms of
guiding patient post-operative weaning. This information is available from previously
charted information, from direct medical device connection, and from the surgical flow
sheet.
Ultimately, the data collected through the mechanical ventilator are augmented by this
information to assist the care provider in guiding patient weaning, in ordering procedures
and changes to support that are consistent with the patient’s ability to respond, and help
reduce the risk to the patient. The plot of Figure 5 illustrates the mandatory (set) value of
respiratory rate and the spontaneous (patient) value of the same parameter during the
post- operative weaning process of a coronary bypass graft (CABG) patient [2]. The
spontaneous component of this plot is similar to the plot of Figure 2 in shape. As can be
seen, the mandatory value of respiratory rate setting is reduced in steps over time. The
spontaneous component shows growth to a final value near extubation time.
Measurement and collection of these data were through a standard RS-232 serial adapter
into a laptop computer.

supportFields]><![endif]-->: Mandatory and spontaneous respiratory rate plots for
patient in question.
We can illustrate with several diagrams where these data can be collected and compared
for decision making purposes. Figure 6 illustrates the fentanyl dosing in comparison with
the model developed from a larger sampling of patients to provide a rough guide as to
viability to wean in terms of expected time after arrival from surgery.
supportFields]><![endif]-->: Flow diagram illustrating comparison of patient-
specific fentanyl dosing with larger model to indicate relative time to excrete effects of
intra-operative drugs.

supportFields]><![endif]-->: Comparison of patient temperature to illustrate
approximate time required to achieve normothermia.
supportFields]><![endif]-->: Patient spontaneous respiratory rate in comparison
with mandatory settings to provide gauge on viability to wean.
Figure 7 and Figure 8 illustrate the time required to achieve normothermia
and the patient respiratory rate performance over time, both collected from bedside
monitor and mechanical ventilator, respectively. If we look at the time to reach
normothermia and the time required to dissipate the effects of fentanyl in relation to this
plot, we have the graph of Figure 9.
supportFields]><![endif]-->: Spontaneous and mandatory respiratory rate with
indicators as to when normothermia is achieved and drug effects have dissipated.
As we can see from , viability to begin trials for respiratory weaning
appears to be achieved after approximately 250 minutes. Of course, other data are also
used to assist in making this decision and to determine viability, and expert or related
systems cannot be used as a substitute for a bedside clinician. Yet, the possibility to assist
and guide the clinician in determining whether it is advisable to proceed can indeed serve
a positive end in guiding overall therapy.
Summary
As the patient re-awakens and approaches viability for extubation, it becomes even more
important to acquire and analyze measurements from medical devices as these are used to
determine whether the patient can be discontinued from mechanical ventilation. The re-
awakening time model is a simple but useful tool to guide clinical decision making in the
acute setting for a very specific class of patient. Thus, it facilitates the patient care
management process in enabling the clinical staff to predict with some reliability when
patients require attention during the normal course of care.
Medical device interoperability and integration with external systems becomes essential
to clinical decision making ability. There are a number of commercial technologies that
support basic interoperability and communication, and I have worked with a number of
them. The end in itself is never the ability to merely communicate with a medical device,
but, rather, to use the data as a means to assist in making clinical decisions.
Efforts to date in the electronic health record and health information technology areas
have focused on documentation, clinical workflow, order entry, notes, and charting.
These are all necessary enablers to assist the care provider as a “colleague.” However,
clinical decisions are made on the basis of all data presented to the clinician, and involve
both real-time and ad-hoc data presented in the form of reports, waveforms, trends, and
even hunches based on prior experience. This is the key– all data, communicated
intelligently, filtered and analyzed appropriately, presented clearly– so as to assist in
diagnoses, interventions, therapies, and long-term trending of patient state and care.
[1] Source: J. Zaleski, based on study conducted by author in surgical intensive care unit of
major teaching hospital. [2] Source: J. Zaleski
About the author
John R. Zaleski, PhD, CPHIMS, is formerly with Siemens Medical Solutions where he
managed the critical care eHR product line. He wrote the first book dedicated to medical
device interoperability with electronic medical records. He now manages biomedical
informatics research and clinical decision support for Philips Research North America.
Email John | All posts by John Zaleski
5 comments ↓
#1 Pete McMillan on 07.09.09 at 11:26 pm
John, thank you very much for putting this article together. It’s precise and well
researched, and is a great resource for non-clinical and technical personnel (read:
box-guys and IT geeks) to understand why clinicians demand the level of
integration data integration as they do. It is a vision that is readily achievable
today.
However, I do find it strange that in your diagrams an EHR is shown as the direct
recipient of device data. EHR could be the final repository for reports, but it
would be completely out of scope for an EHR to archive every bit of device data.
This should be done by a specialized departmental application (a critical care
CIS).
In our institution we have implemented a CIS system that handles those duties.
We had an old HP carevue system for ages, but last year we replaced it with a
Philips iCIP system. The Philips system has many advantages over carevue, the
most clinically significant of those being the ability to correlate different
parameters from different devices and create advisories. Our clinicians are
working with Philips specialists on creating advisories that highlight when each of
the ventilator weaning end-points are reached. The system is also able to monitor
protocol compliance (eg. pneumonia prevention protocol for ventilated patients)
and generate reminders for actions to be taken for these protocols. It can also
generate protocol compliance reports.
The system requires extensive customization since none of the advisories and
protocols installed by default satisfied our clinicians. The customization is
complicated, requiring both clinicians and our IT team to go deep in to the nuts
and bolts of the system, but at least it can be done. A nice GUI based interface
would have helped me keep the few hairs I have remaining on my head.
We export reports from the iCIP system to our EHR. We don’t believe that EHR
is the correct system to handle all these data streams. Show me an EHR that
allows the level of control and customization that a CIS system allows! Sending
data to an EHR is as good as writing it down on paper. A good CIS system, on the
other hand, can analyze that data and present the data to a clinician in a way that
is easily understandable and readily actionable.
Let me finish my rant by complimenting you on this excellent article. Well done!
#2 John Zaleski on 07.10.09 at 2:49 am
Pete–
Thanks for the comment and your salient points. I am very familiar with the
process of using a more localized system for managing departmental (or detailed-
level information), having managed a critical care product line for quite some
time. My diagram is abstracted to reflect that these data are stored in a repository.
In some cases, these repositories are collections of departmental systems
integrated with the larger EHR. The clinical information system is, indeed, the
correct starting point. Many EHR vendors with whom I am familiar are looking to
blur the lines between the departmental and enterprise systems. My diagram was
“designed” in deference to this point.
That said, I am quite familiar with ICIP, and acknowledge your various points in
that regard. In the department I run we are investigating future multi-parameter
protocols regarding instability that are truly the next generation beyond those in
current practice for consideration in future product lines.
Finally, I decided to write this partly to chronicle my own experiences and to

provide a somewhat more complete reflection of the process and how various
seemingly unrelated events and occurrences need to be considered as part of
patient care. I wrote this with respect to the management of my patients during
clinical trials and this represents a composite view (at a much higher level) of
those patients.
#3 Adam Jung on 10.02.09 at 6:18 am
Thank you! This is a nice walkthrough of a workflow an data flow as well as the
critical concerns. One issue I’m having. For some reason, I’m not getting the
images. I’m using IE 7.0.5730.13CO. Can you tell me how I can get the images or
send them to me?
.NET Micro Framework: Good Choice for Medical

Devices?
January 12th, 2009 | Published in Wireless Medical Devices | 2 Comments
The cost of adding Wi-Fi connectivity to a medical device is more than the cost of the
Wi-Fi radio itself. To support the radio, the device may require more memory and
processing power than a base device with no Wi-Fi support. In addition, the device will
need connectivity software, such as a TCP/IP software stack.
The largest cost area, however, often is overlooked. It is the cost of making the Wi-Fi
radio run well on the device, where running well means providing secure, reliable
connectivity even when the device is in motion in an environment that provides
challenges to Wi-Fi connectivity, i.e., your typical hospital. The burden of ensuring that a
Wi-Fi radio supports all required features and runs well on the device falls squarely on
the shoulders of a software program called the Wi-Fi device driver.
Device drivers for a broad range of Wi-Fi radios are readily available on Microsoft
operating systems and Linux. For the embedded operating systems that run on most
medical devices, however, Wi-Fi device drivers are scarce. Rather than writing their own
— an expensive and time-consuming process — some medical device makers are
selecting Windows Embedded CE instead of an embedded OS. For resource-constrained
medical devices, however, CE is too “big”. For others, it’s simply too complex and
inefficient.
A more attractive alternative from Microsoft may be the .NET Micro Framework, which
Microsoft calls “an innovative development and execution environment for resource-
constrained devices”. The .NET Micro Framework is a bootable runtime module that
requires only 300 KB of memory but provides a full managed execution environment.
The module can run on top of an underlying operating system or can run natively on a
device.
According to Microsoft, a typical .NET Micro Framework device has a 32-bit processor
with no external memory management unit and as little as 64K of random-access
memory (RAM). Examples of .NET Micro Framework devices under development are
consumer medical devices, industrial automation devices, consumer electronics, and
devices that operate in your car.
One goal of the .NET Micro Framework is to bring the programming paradigm of
Microsoft’s .NET environment to the embedded world. Thanks to a “fully integrated
Visual Studio experience”, the .NET Micro Framework enables application developers to
use familiar .NET tools on desktop systems and then deploy the applications on
embedded systems. With Version 3.0 of the .NET Micro Framework, which was
launched at the end of October, those applications can take advantage of a richer set of
facilities for secure connectivity. In the middle of 2009, connectivity options will include
Wi-Fi, specifically 802.11a/b/g.
For more information on the .NET Micro Framework, visit

http://www.microsoft.com/netmf/default.mspx. For information on a Wi-Fi option for the
.NET Micro Framework, visit http://www.uframework.com.
About the author
Chris Bolinger is co-founder and VP of Business Development at Summit Data

Communications, Inc. Prior to Summit, Bolinger was Manager of Partner Marketing and
Software Product Manager in the WLAN unit of Cisco Systems, Inc. He earned a B.S. in
Computer Science at the University of Akron and an MBA at George Mason University.
Workshop on Wireless Tech in Healthcare

January 6th, 2009 | Published in Wireless Medical Devices | 7 Comments
On December 19, 2008, a group of about 50 people met to to discuss wireless medical
devices. The event was organized by Don Witters of the FDA, Elliot Sloane from
Villanova (and contributor to HITSP, IHE, ACCE and others), the wireless Czar of
Partners Healthcare, Rick Hampton, and ubiquitous industry standards maven, Todd
Cooper. The meeting was held in the new nursing school building at Villanova with a live
video teleconference connection to Carnegie Mellon University (CMU) in Pittsburgh.
The meeting was billed as a workshop on wireless technology in health care, with an
emphasis on what is needed for safe, secure and reliable deployment. (You can download
the agenda that was sent out here.) A wide net was cast, and participants represented Wi-
Fi infrastructure vendors (Cisco, Trapeze, Aruba, Motorola, InnerWireless,
MobileAccess), medical device vendors (Hospira, Philips Research, GE Healthcare,
Sigma International, Smiths Medical, Welch Allyn, Draeger), AAMI, ASHE, the Medical
Records Institute, Bosch, Verizon, ECRI Institute, NIST, various academics (Drexler and
U of OK besides Villanova and CMU). The only provider organizations attending,
besides Partners, were Memorial Sloan-Kettering, Kaiser and the VA. GlobeStar Systems
was the lone health care software vendor. Due to limited seating, not everyone who
wanted to attend was able to be accommodated.
Elliot kicked things off with a welcome and review of the agenda. Don Witters then came
up and set the stage from the safety perspective, and Rick Hampton did the same relative
to Partners’ position as a provider organization. We wrapped the first portion of the
agenda by going around the room in both locations introducing ourselves. The rest of the
day focused on two sets of break out discussions:
• Group A - identifying stakeholders, benefits, challenges, risks

• Group B - Identifying/categorizing critical wireless medical device/network
security dimensions/factors for CIA&S (confidentiality, integrity, availability and
safety)
• Group C - CIA&S, performance metrics that could/should be cataloged (e.g.,
QoS, bandwidth, etc.)
• Group D - System design and life cycle maintenance, verification and validation
strategies, and sources to assure CIA&S in future applications
Throughout the day discussions sought to identify wireless problems and get to root
causes.
Framing the Issues
Don Witters noted how the physics of radio frequencies (RF) creates a “commons” where
RF commingles, and how this can become a no man’s land with no clear regulatory
responsibility at the industry level, and inadequate implementation and management at
the customer level. This was perhaps the most concise statement of the wireless medical
device “problem” made during the workshop.
Apparently playing devil’s advocate, the question was asked if wireless, and the risks that
go along with it, was necessary or even desirable. In light of the way that health care is
delivered, and the overwhelming market requirement for mobility, abandoning wireless
technology in medical devices was rejected as impractical. Wireless benefits mentioned
included the elimination of the infection risk posed by cables (which are almost always
reused, rather than disposable), and problems with tripping over or pulling out things like
catheters, sensors, power cords and CAT-5 cables. Cable and plug variability across
vendors and products also results in cable proliferation and the need to manage and find
the right cable for a particular use.
Once it was agreed that wireless is here to stay, the discussion moved to framing the
discussion of risks inherent in wireless technologies. Some of the areas mentioned
include security, availability, quality of service, coexistence, electromagnetic interference
(EMI), and privacy. Regulatory and legal risk were mentioned, although these are
consequences rather than actual risks inherent in wireless. More technical risks
mentioned were electromagnetic compatibility (where EMI might get modulated and
mistaken for actual physiological data), latency, jitter and other risks resulting in data
corruption. Many of these risks were more formally described as CIA&S -
confidentiality, integrity, availability and safety.
Paul Frisch noted that he has seen users come to equate the data accessed wireless from
the medical device with original medical device data, not taking into consideration
inherent risks that might result in lost or corrupted data. A similar education issue
(assuming the wireless medical device is designed properly) revolves around the potential
EMI from other devices like cell phones that may impact the operation of medical
devices.
Don Witters described an informal model for framing risk. At the low end there is
communications indirectly related to patient care, that may be only somewhat sensitive to
timing and time criticality relative to the application. In the middle there’s
communicating that is directly related to care delivery (coordinating care, wireless
medical devices), and at the upper end, direct control of a device wirelessly. These three
levels of risk can be deployed anywhere, from acute care to patients on golf courses. This
discussion did highlight the need for the evolution of thought and experience in applying
risk management to wireless medical device systems - or arguably, to any kind of
medical device connectivity.
Chris Lavanchy from the ECRI Institute noted a general bias towards high risk areas
when considering wireless medical devices and safety. He suggested that we not exclude
general IT wireless requirements that must also be met. This observation highlights the
frequent “talking past one another” that occurs between hospital IT and medical device
vendors, who sometimes think that their requirements are paramount, to the exclusion of
the other guy’s requirements. Much like some CIOs think that their choice of enterprise
IT standards should be more important than selecting the most effective medical devices,
some medical device vendors think they can dictate enterprise IT choices to CIOs
regardless of the duplication, complexity or costs imposed on the enterprise.
Later, Paul Sherman with the VA noted that discussions of health care sometimes seem
based on an informal goal of perfection, or zero risk. (This seems to be the case when
patients accept high risk procedures and then sue when those risks are realized.) No
technology, especially wireless, is perfect. Sometimes wireless takes an unfair hit because
it is not perfect.
Julian Goldman noted that, “the safest medical device is the one you never take out of the
box.” Use of any medical device comes with some degree of risk. He explained that the
goal is not to completely eliminate risk, but to understand, mitigate and mange the risk.
“There are too many things we could be doing that would significantly improve patient
care and safety,” said Julian, “but are resisted, partly due to an aversion to the perceived
risk associated with those new applications.” This is a common criticism of even the most
basic kinds of medical device interoperability, like safety interlocks. According to Julian,
“Even straight forward applications like wireless remote control of medical devices are
resisted because of perceived risk. But if the patient is in isolation, or undergoing
radiation therapy, the benefits of this remote control - that probably spans several feet at
most - could greatly outweigh perceived risk.”
Later Julian noted another aspect of risk, how risk can be divided between the operational
side and those focused on innovation. Operational risk is focused on the use, fix/repair,
maintenance and support of existing products in the field. Here the product is what it is
and the focus is on maintaining the risk model that was developed and realized in the
product development process. The risk model for innovation is one in which there are
many unknowns. The challenge is to develop a solid risk model and then realize both
your innovation objectives and a physical manifestation of the risk model as a safety
product. These two spheres have the same goal of patient safety, but how you achieve
those goals is wildly different.
Scope
The issue of focus or scope came up repeatedly during the day. For example, in
reviewing potential stakeholders, the resulting list was so comprehensive as to likely
preclude reaching a meaningful consensus on solutions in a reasonable period of time.
Focus also became an issue when discussing existing customer issues with currently
released products in contrast to solving current and anticipated problems with as yet
undeveloped new technologies. More than once, an attendee tried to steer the discussion
back to “solving Ricky’s problems,” (with existing wireless products installed at
Partners) rather than exploring greenfield technology development solutions.
The goals of safe and reliable operation, coexistence and interoperability were identified
as 3 key objectives. The need is to figuring out a way to get solutions installed in health
care provider organizations that are stable. There was a group consensus that we should
focus on the acute care setting, rather than smaller or more nascent markets like home-
based remote monitoring. The hospital market is feeling the pain of these issues first and
foremost.
The group further described a need for broadly understood and adopted approaches to
communications availability and failure modes, so that heterogeneous systems can be
more robust and reliable. The in-development voluntary end user standard IEC 80001
was mentioned, and the group seemed to agree that this was an important part of the
solution - but only a part. The question of how risk is to be assessed in this system of
systems is still open. Suggestions were made that there may be a need for simulations
and modeling, standardized tools and test plans. Disruptive technology introductions
were noted as potential “flies in the ointment” of any grand solution.
Many of the engineers in the group wanted to start right off with use cases. I’m a big fan
of use cases and use them frequently in my consulting practice, but they are best suited
for product development. The wireless problems that are most acute are those with
existing products that are already installed. It is with released product that we have
system of systems, coexistence and interoperability problems.
Best Practices
As with connectivity (and life in general), we frequently don’t know what we don’t
know. Don Witters noted that medical device vendors launching their first wireless
product rarely know what they’re getting themselves in to, and that IT departments also
lack the background and experience to understand the requirements for effectively
deploying and managing wireless medical device. What is needed here is the
development and proliferation of best practices, adopted by both vendors and end
user/buyers.
Regarding hospitals, it was also noted that most lack a position responsible for RF
spectrum management. This position keeps track of all the intentional RF sources in an
enterprise. This catalog of enterprise RF uses, frequently organized by the spectrum and
protocols used, is then used to guide an assessment of the external RF environment.
Every hospital needs to know all of the licensed RF users in their community that could
possibly impact their RF applications. All of the appropriate registrations, licensing and
notifications must be completed to ensure the best RF coexistence between the hospital’s
RF applications and those found in the surrounding community. Continuous vigilance is
also needed to monitor the enterprise RF environment for unintentional interference, EMI
from faulty equipment, or intentional interference from a source outside the hospital. And
finally, all of these responsibilities of the RF coordinator rest upon a foundation of
education and awareness that must be inculcated among hospital staff, clinicians and
senior management. All this is a tall order, so it’s no wonder that hospitals haven’t been
rushing to create this new position and get it staffed.
There is a related but different set of best practices for medical device vendors with
wireless medical devices. A chief need of the industry is a means to develop and spread
the adoption of a common set of best practices. There will be multiple sets of best
practices, probably developed and endorsed by different organizations. Of course it’s
critical that all these efforts be complementary and work together to solve some of these
problems on an industry wide basis.
COTS - Components Off the Shelf
The suitability of incorporating COTS into medical devices was another common issue.
On its face, the use of unregulated COTS in medical devices appears iffy at best, and
irresponsible at worst. Steve Baker noted that his use of COTS are all verification tested
to the intended use. In fact most electromechanical medical devices - and virtually all
medical device systems - make extensive use of COTS. And the FDA’s regulatory
framework provides considerable support for the safe and effective incorporation of
COTS in medical devices.
In an observation related to the issues around COTS, Joe Morrissey with Motorola noted
that not all the stakeholders in wireless medical devices want to get wrapped up in these
issues. For example, cellular carriers or the WFA (Wi-Fi Alliance) don’t want to go so far
as to be regulated by the FDA or become subjected to the level of risks that medical
device vendors assume. Paul Frisch, from Memorial Sloan-Kettering suggested that if the
regulatory and risk burdens for COTS vendors become too high, they’ll actively try to
limit their exposure by doing things like labeling their products as “not intended for
medical use.”
Later in the day the question was asked, “Is there too much reliance on off the shelf
technologies?” Attendees most interested in developing new greenfield technologies were
most responsive to this, implying that the use of COTS was inherently inadequate. This
brought discussions to the fore about the evolution of the Medical Implant
Communications Service (MICS) and a proposed wireless sensor frequency allocation.
Certainly the exclusion of COTS from medical device systems would eliminate some
problems. Such a move, say creating a dedicated technology for wireless medical
devices, would pull those devices off the enterprise network and place them firmly back
in the control of the medical device vendor. Such a move would still face the current
problem of coordinating medical device vendors product efforts so they can safely
coexist on the same infrastructure, in this case one dedicated to medical devices. An
effort like this would take several years to complete and we would still have to deal with
our current problems in the mean time.
Another challenge is that the wireless “commons” that Don Witters mentioned at the
beginning of the conference will still remain. A dedicated wireless medical device
technology would face the same challenges dealing with interference and coexistence in
the RF spectrum.
Assuming that it’s possible for a new standard or technology dedicated to medical
devices to solve most of the problems discussed at this workshop (I can’t think of any,
how about you?), the costs to develop and incorporate that technology into medical
device systems will significantly add to the cost wireless medical devices. With debates
about rationing health care and the inevitable aging population, do we really want to
chose to increase the cost of health care, especially if we don’t really have to?
Systems of Systems
The creation of unintended (as far as the medical device vendor and FDA are concerned)
and accidental “system of systems” really came to the fore in the discussion in break out
session B. When considering the challenges inherent in wireless medical device systems,
the desired end result (from end user/buyer’s perspective) is a system of systems.
Imagine the scenario where a vendor, end user/buyer, or systems integrator takes a
regulated medical device and “extends” it by integrating it with other different medical
devices, or features based on general purpose IT technology. When end user/buyers do
these kinds of things, they either meet the legal definition of a medical device
manufacturer (which is based on what you do, not what you call yourself), or use the
medical devices “off label,” i.e., outside the vendor’s specifications or intended use, as
approved by the FDA. These resulting systems of systems almost always exceed the
medical device vendor’s intended use, and by doing so, use the system in ways for which
the medical device was never designed or tested.
Think of what GlobeStar Systems or Emergin does for alarm notification. Integrating
medical devices into EMRs for documentation or configuring a device based on an order
from the CPOE system. Such systems of systems have used in the industry for several
years. The quality of these implementations has varied greatly, and the majority of those
engaged in these activities have not been submitted for regulatory approval. Not
surprisingly, there have been patient injuries and deaths attributed to some of these
systems - which is why the FDA has a growing interest in this area.
As the chief instigator of IEC 80001, the FDA is seeking to improve the safe use of
networked medical devices (that, as a consequence of systems integration facilitated by
networking, become systems of systems). The FDAs proposed rule on Medical Device
Data Systems (MDDS) is also intended to address parts of this problem directly (the
MDDS), and indirectly by signaling to the market that systems of systems providing
remote surveillance and alarm notification will be regulated as preamendment Class III
devices. This meeting is a further effort intended to nudge the industry in the direction of
further improvements.
An excellent system of systems conference dealing with many of these issues was held in
June of 2007. The co-chairs were Julian Goldman and Insup Lee, from the University of
Pennsylvania School of Engineering.
There was also a great discussion about who assumes what risk for systems of systems.
Different answers were posited based on who’s involved - medical device vendor, COTS
vendor, clinician, biomed, IT, regulator, etc. A simple way to look at this is to focus on
who’s making changes to a regulated medical device. If the medical device vendor does
it, they assume the risk. If a third party vendor like a systems integrator or software
vendor makes the changes, even simply by adding on to the medical device system, that
third party picks up much of the medical device vendor’s risk, and also takes on
regulatory risk - either the work required to gain approval, or the risk of enforcement
actions.
Providers have so far gotten a free pass from the FDA when it comes to effectively
becoming a medical device manufacturer by creating systems of systems. A review of
comments submitted to the FDA on the proposed MDDS rule shows a number of
provider authored responses. Surprisingly, they don’t want to be held to the same
standard (regulatory approval) that they insist their vendors meet when doing basically
the same things. This is understandable when I put myself in their position; as a
prospective patient in their hospital their position is untenable.
Measuring Performance
Break out session B, facilitated by Rick Hampton, looked at performance metrics and the
role they may play in a solution. Presently, measuring performance of most everything -
the RF environment, wired and wireless networks, and medical device systems - is ad hoc
and defined on an institution by institution and/or product by product basis.
Most analysis is done at a specific point in time and there is generally insufficient
continuous monitoring or real time analysis within the enterprise. This is especially true
when one includes medical device systems with networks. This is an obvious issue with
wireless; because RF is “invisible” changes that occur must be monitored.
A description of a broader sphere of knowledge and coordination emerged with the

description of a number of unmet industry needs. There is presently no mechanism for
documenting and disseminating knowledge on existing protocol vulnerabilities. There is
no framework for developing a consensus on reasonable failure modes - not to mention a
mechanism to coordinate the implementation of common failure modes across medical
device and infrastructure vendor’s products. Numerous comments about baselines for
performance metrics highlighted a need to achieve consensus and propagate best
practices that extend from medical device system design and specification, to end
user/buyer implementation, management and support.
There is no “one” answer to most - if not all - of these wireless issues. In one of the break
out sessions (Group D), Don asked the rhetorical question, “What is the measure of
quality of service?” This was an exploration into the question of whether a single
standard or specification can be applied across large portions of the industry. Lots of
things were suggested: packet loss, latency, jitter, the number of retries. The discussion
quickly evolved into segmenting specifications by application, with Steve Baker
describing the advantages of basing QoS requirements on the inherent requirements of
the application. In his example, wireless voice over IP (VoIP), Steve described a latency
threshold of 50 ms because any gaps in a transmission that length or shorter can’t be
discerned by the brain/ear. Translating that framework to an application like telemetry
begs the question asked by Steve, “How many seconds of data can you lose before you
miss a diagnostic heart beat or an alarm?” The resulting time frame becomes your QoS
specification. It was also noted that the design solution for a particular application can
influence specifications based on how a design mitigates certain risks or offers greater
performance in some areas.
The straw man of setting specifications for the industry was ultimately rejected by the
group. It seems there’s no substitute for knowing what you’re doing and taking a rigorous
and methodical approach to developing medical devices. There was an intriguing
question posed near the end of this discussion about whether a single defined strategy or
process could be developed that everyone followed for creating specifications for QoS
and other important performance metrics. This appears to have potential, but the entity
that would develop and promulgate such a process is not clear. The FDA’s Quality
System regulation already defines a process. How much more proscriptive can we be
without limiting innovation?
Elephants in the Room
Discussions about solving complex problems, like ensuring the safety of wireless medical
devices, can be thought about at two levels. The actual topics discussed and debated are
tangible and easy to grasp issues. But sometimes more interesting than what is stated
outright are the implied issues that are not mentioned - not that there’s some hidden
agenda being pursued by some shadowy cabal. Such figurative elephants come about for
many reasons, and were in fact in attendance at this meeting.
The biggest elephant (in a shocking pink, no less) is the transition of medical device
systems deployed on private vendor controlled networks to their deployment on hospital
controlled enterprise networks. It is this transition that currently results in much of the
problems and challenges discussed at this workshop. This transition is also creating many
inefficiencies and hidden costs for vendors and providers alike.
By deploying regulated medical device systems on enterprise networks, providers are

(often unwittingly) assuming a big part of the responsibility for managing and supporting
the medical device. When end user/customers go “off the reservation,” i.e., go outside the
intended use of the system, they assume liabilities otherwise assumed by the medical
device vendor. Examples of going off the reservation include running medical device
systems on network infrastructure not supported by the medical device vendor,
configuring the network in a way that’s not supported by the medical device vendor, or
installing network infrastructure upgrades or new products that have not yet been
verification tested by the medical device vendor. You can read more about this elephant
here.
The current regulatory framework was never directly discussed. Arthur Gasch, with
Medical Strategic Planning, suggested that the regulatory framework hasn’t kept up with
technology. He used WMTS as an example saying that there’s really no standard there. It
was noted that WMTS was meant to be open and that the manufacturers were supposed
to develop a framework for coexistence, management and monitoring tools. Of course,
this never happened and WMTS became a band used solely by proprietary solutions. You
can read more about WMTS here. I suggested that the current regulatory framework is
fine, and it just needs to be enforced on those that are not in compliance. This suggestion
was rejected as impractical (although there was no discussion as to why this might be the
case).
Another rather large elephant had to do with the commercialization of standards - which
is complicated by the fact that we’re talking about regulated medical devices. Sadir Matta
of Cisco mentioned the WFA as an example where industry standards by themselves
were insufficient in providing the desired compatibility between wireless clients and
access points. Jim McCoy with InnerWireless noted how the WFA took the 802.11
standards and effectively tightened them up through their test and certification process.
Jim suggested that our industry needs a similar mechanism that narrows those
configuration options. Kamran Sayrafian with NIST also mentioned the IEEE (standards)
and WFA (test and certification) as providing two important pieces of the total solution
for the successful operation of Wi-Fi based products in the real world.
Steve Baker from Welch Allyn noted that, “As a patient monitoring vendor, I can make
my products work on any wireless network. What I can’t do is get my products to work
with other vendor’s medical devices.” Coexistence between different networked medical
device systems (both wired and wireless) is problematic because there is no industry
“common approach” to minimize network coexistence issues (the product definition end
of the problem), nor is there a mechanism for vendors to get together to do coexistence
verification testing - without risking antitrust risk exposure or disclosing proprietary
product info to competitors (more the product support end of the problem).
Conclusions
The issues addressed in the workshop can be usefully divided a number of ways. Existing
products and future, as yet undeveloped products, can serve to segment and coordinate
approaches to the problems discussed in the workshop. Market segmentation can also be
useful. The acute care market (hospitals, out patient surgery clinics and the like) is by far
the biggest market. The remote monitoring market (chronic disease management, health
and wellness, elderly age-in-place) is on the horizon, but without a meaningful level of
reimbursement remains more potential than real. While there’s some overlap, most
medical device vendors are either playing in the acute care or ambulatory market. Same
goes for much of the technology. Cellular carriers, Bluetooth enabled sensors and
gateway devices are creatures of the remote monitoring market, while Ethernet, Wi-Fi
and proprietary technologies (WMTS) have been widely adopted in the acute care
market. All this slicing and dicing should help formulate solutions that are narrow enough
to actually get formulated and implemented, and not hindered by trying to build
consensus across a group with interests that are too numerous and divergent to produce
more than the most generalized and broad prescriptions.
Existing standards development organizations (SDOs) are already well positioned to

work on addressing the problems discussed at the workshop for nacent technologies and
products that are yet to be created. SDOs will need to clearly define the market segments
they target, so efforts among SDOs can be coordinated and efficient.
Existing products can’t be helped by SDOs because the die is already cast, the products
are in production or already installed. Imposing new standards would just force providers
to replace all the perfectly good equipment they already have - an expensive approach,
and one that would take years to implement - leaving us with the current situation.
What’s needed is more than standards. Matt Grubis with GE noted that, “We’ve been
talking about 802.11, but there’s a lot of new technologies in the pipeline. We need to
solve this problem for today and into the future, rather than tailor the solution to a
specific technology like 802.11. Later Matt reinforced his observation that we need a
framework that’s not tied to a specific technology, because that’s always changing.
The folks from CMU suggested that we look to some kind of organization like an
industry alliance. They noted examples in a number of industries like the electrical utility
industry.
Postscript
This post is based on my notes and recollections of the meeting. I am responsible for any
errors, omissions or mis-characterizations of what is reported above.
As always, you the reader are encouraged to join the conversation - via the comments
below - with observations, opinions, and most certainly, corrections of my faulty
memory.
I want to especially encourage the attendees of the workshop to add their observations
and conclusions from the workshop. Out of a full day jam packed with substantive
discussions, I’m sure there’s a lot that didn’t get into this post.
And as always, shamelss commercial plugs will be deleted per the comments policy
(found here). Commercial plugs that, you know, actually contribute to the conversation
are encouraged.
UPDATE: I’m told that there was someone from Emergin at the workshop, thus
rendering GlobeStar one of two software vendors. I did see an unclaimed name badge for
Emerin at the beginning of the day and didn’t hear anyone from Emergin during the
introductions. Hence my assumption.
About the author
After almost 25 years in health care Tim remains with his first love, connectology, the
automation of workflow through the integration of medical devices with information
systems.
Email Tim | All posts by Tim Gee
7 comments ↓
#1 Shahid N. Shah on 01.07.09 at 4:13 pm
Thanks for the update, Tim, nice summary. Was there any discussion or mention
of open source software that might be used to bridge the divide among different
vendors?
#2 Bridget on 01.08.09 at 10:31 am
Tim -thanks for the thorough round-up - very interesting, indeed. To me, the
wireless issues are future as I used to deal with the ‘wired’ issues especially
network issues at the OSI level 2 and 3 assumptions made by medical device
integration vendors, IT, medical device vendors and Biomed. Wireless adds
another dimension which thankfully I hadn’t dealt with yet…well, I dealt with it
at the routers and wired aspect, I guess. (competition for port space by medical
device information bound for a CIS and a VOIP device)
#3 Craig Bakuzonis on 01.09.09 at 7:11 am
Thank you for the comprehensive summary - this is good information for our IT
group.
#4 Bruce Alexander on 01.09.09 at 7:45 am
Tim, Thanks for the great re-cap. I was unable to attend this meeting. I agree with
many points that the group discussed. In particular a point made by Steve B of
Welch Allyn and reinforced by folks from CMU. Steve commented that he can
make his products work on any network, but can’t get them to work with other
vendors products. The CMU Comments supported this by suggesting an industry
alliance. This idea is very similar to why the Wi-Fi Alliance (called WECA at that
time) was developed. However we had a similar problem in the WI-Fi org, that
Steve mentions. How do you develop such a test program and still protect
individual company Intellectual Properties. This has to be done as a team. The
Wi-Fi org managed to get past this issue, and the healthcare industry needs to
commit to the same type of thing. Without it we will continue to struggle.
#5 william on 01.13.09 at 6:17 am
Three things not mentioned that may also be important are:
(1) Do all venders really want open compatibility versus you-have-to-buy-all-

your-stuff-from-me?
(2)Singular examples of wouldn’t it be good if device A could tell device B this
one thing (and device B could understand what it was told and act on it)can be
misleading. A telling B x is far different than A, B, C… telling M, N,O…
u,v,w,x,y,z, and everything being designed and configured to actually use that
information (beyond just recording it in an EMR). The next question is going to
be not “can they talk to eachother?” but “do they care what eachother is saying?”
(3) Besides frequencies, what about bandwidth? At some point there is only so
much traffic you can support. What is that point? Hotels have discovered this and
are busy increasing capacity to meet business, recreation and conference uses.
You can’t always keep adding 802 apps.
#6 Paul Sherman on 01.22.09 at 9:19 am
Hi Tim;
Thanks for the recap, it sure saved me from relying on my meager notes (I was a
participant)
The commenters have brought up some good points. As this group moves
forward, we’ll welcome input from folks involved. We’re still very early in the
process. One feeling I came away with was that many of the pieces are in place to
create a medical-grade wireless network for the areas of the hospital that require
it. For example, Steve Baker of Welch Allyn published a paper last April showing
how it can be done. The next part is to consistently bring those pieces together in
such a way that hospitals can easily construct and manage that life-critical system.
#7 Can We Fix Wireless in Health Care? :: Medical Connectivity on 03.24.09 at

12:25 pm
[…] devices. What with IEC80001 moving forward (due to be finalized next year)
and the recent series of wireless medical device workshops, people in hospitals
and among vendors are asking more of the hard questions about wireless. […]
Source: Cerner Corporation

Cerner Receives FDA Clearance for Medical Device Connectivity Solution
Cerner CareAware iBus(TM) Solution Enables Bi-Directional Flow of Information Between
Medical Devices and Electronic Health Records
KANSAS CITY, Mo., Jan. 11, 2010 (GLOBE NEWSWIRE) -- Thousands of medical devices are used in
hospitals, physician offices and homes to help clinicians provide better care to patients. Medical
devices are used to monitor patient vital signs, infuse medication and even help patients breathe.
These devices capture important information about patient health, but oftentimes that information
resides in disparate systems outside of the patient's electronic health record (EHR). To solve this
problem, Cerner (Nasdaq:CERN) created the CareAware(R) device connectivity architecture to
connect medical devices to the EHR, enabling bi-directional data sharing between medical devices
and the patient record. The Cerner CareAware iBus, a solution that connects medical devices to the
EHR to support the entire care process, recently received 510(k) pre-market clearance from the
U.S. Food and Drug Administration and is now available in the United States and all U.S. territories.
"For the last two decades Cerner has been an active leader in developing device connectivity
solutions," said Tom Herzog, Cerner vice president for IT and healthcare devices. "In 2007, we
launched the next generation of device connectivity solutions known as the CareAware MDBus(TM).
Recently we expanded upon the architecture of the CareAware MDBus solution and are excited to
introduce the Cerner CareAware iBus solution. The CareAware iBus solution is an interoperable
platform developed in conjunction with our clients and certified device partners to create a standard
for medical device connectivity, interoperability and workflow transformation."
The Cerner CareAware iBus solution provides true plug-and-play capabilities for connecting any
medical device to any EHR system. Once a device is connected to the Cerner CareAware iBus
solution, it is immediately recognized and can begin transmitting data to the EHR. This connectivity
architecture places the EHR at the center of all information created and stored on the patient to
create a Single Source of Truth(TM). The solution also allows waveform data to be transmitted
directly into the EHR. The Cerner CareAware iBus solution also provides the ability to correlate and
trend various sources of information including various waveforms, heart rate and blood pressure.
This trending information allows clinicians to analyze the patient's data in the context of other
clinically relevant data for a specific time period.
The Cerner CareAware iBus solution improves clinician workflow and improves patient safety by:
* Reducing the need for clinicians to manually enter device data into
the EHR, allowing clinicians to spend more time on patient care and
reducing the chance for transcription-related errors;
* Decreasing the chance of medication errors related to intravenous
infusion via direct association of the patient, the infusion pump
and the provider's order from the EHR;
* Helping clinicians make informed decisions about patient care by
providing them with access to up-to-date information about patient
status gathered from multiple medical devices;
* Providing the ability to automatically perform calculations on data
being provided by medical devices; and
* Reducing the amount of time clinicians spend on patient-to-device
association, a process that happens through the plug-and-play
connectivity feature of the Cerner CareAware iBus solution.
The Cerner CareAware iBus solution also allows a healthcare organization to efficiently manage the
various medical devices deployed throughout its facilities. IT teams can use the solution to monitor
device performance, connectivity status and device utilization all within one view.
Cerner will demonstrate the ability of the Cerner CareAware iBus solution to connect to multiple
medical devices and EHRs at the Integrating the Healthcare Enterprise (IHE) Connect-a-thon in
Chicago, Ill., on Jan. 11-15.
About Cerner
Cerner is transforming healthcare by eliminating error, variance and waste for healthcare providers
and consumers around the world. Cerner(R) solutions optimize processes for healthcare
organizations ranging in size from single-doctor practices, to health systems, to entire countries, for
the pharmaceutical and medical device industries, and for the healthcare commerce system. These
solutions are licensed by more than 8,000 facilities around the world, including approximately 2,100
hospitals; 3,300 physician practices covering more than 30,000 physicians; 500 ambulatory
facilities, such as laboratories, ambulatory centers, cardiac facilities, radiology clinics and surgery
centers; 600 home-health facilities; and 1,500 retail pharmacies. The trademarks, service marks
and logos (collectively, the "Marks") set forth herein are registered and unregistered trademarks
and/or service marks owned by Cerner Corporation in the United States and certain other countries
throughout the world. Nasdaq: CERN. For more information about Cerner, please visit our Web site
at www.cerner.com.
CONTACT: Cerner Corporation

Media Contact:
Sarah Bond
(816) 885-8020
sarah.bond@cerner.com
Investors Contact:
Allan Kells
(816) 201-2445
akells@cerner.com
Telemedicine
With growing healthcare costs and limited ability to reach millions who need healthcare, the healthcare
industry is challenged to provide solutions built on the latest technologies that enable affordable healthcare
and increase the reach of healthcare services, surpassing physical boundaries.
Today healthcare delivery is focusing on prevention rather than cure. Healthcare providers need devices
which will help them to continuously monitor as well as communicate with patients that aren't physically
close to the service.
In developing countries the challenge of any healthcare provider is to bridge the gap between the remote
(rural) areas and the urban areas, where most of the specialist doctors are concentrated.
Whether it is any developed nation or any developing nation, the challenges have a commonality of
connecting the healthcare provider continuously to the patients without raising healthcare delivery costs.
Technologies like internet and mobile, combined with product innovation, can help solve these challenges
for healthcare providers. Such solutions provide a fantastic opportunity for hospitals and medical institutions
to penetrate markets like rural areas, busy professionals, and housewives. These solutions innovatively
address the shortage of trained staff and qualified doctors.
By leveraging reliable remote support, doctors and hospitals can now increase the coverage of their
healthcare services and help connect with individuals, where ever they are.
• How can my customers widen their geographical coverage though better technology?
• How can my customers exploit reliable and cost effective technology to provide remote support?
• How can I create a competitive advantage for my customers through an innovative solution?
As an innovative medical solutions provider, if these are some of the questions troubling you, MindTree's
innovative MindTMED platform has the answers for you.
The MindTMED platform is a solution that allows a doctor to connect with his patient without concern for the
physical distance between them. MindTMED is a ready to deploy solution that can help any hospital or
doctor remotely diagnose the patient's condition, prescribe relevant medication, and continuously monitor
the health and its progress while maintaining and updating electronic health records for all patients.
MindTMED platform
MindTMED leverages highly reliable voice and video communications technology in a single box. The
platform seamlessly connects to almost all medical devices like ECG, NiBP, Temperature, SPO2, etc. at the
patient's end and transmits relevant data, images, etc. to a remote doctor's site. The doctor can carry out
accurate diagnosis and even prescribe relevant medication to the patient. The system is capable of a LIVE
feed so the doctor can continuously monitor the patient's progress.
The MindTMED platform provides a robust mechanism for medical data transmission, thus ensuring
maximum fidelity of the remote data for the doctor.
Key features
• Single aggregator box for video conference, internet/broadband, and medical device connectivity
• Connectivity interfaces - USB, Serial port, Bluetooth for medical devices
• Connectivity interface for LCD panel, LCD monitor, or TV
• Storage for patient records and patient review records
• Automatic Image size throttling based on available bandwidth
• Low bandwidth requirement for video conference
• Security for patient data while in the box during transmission
• Smart card interface for maintaining patient's vital information for insurance purpose
MindTree's offerings
• MindTMED is a ready to deploy platform for installation at any healthcare site
• MindTMED can be used as a platform to easily build a customized solution for generic as well as
specific client requirements
• Medical solution providers and OEMs can license the reference design for creating their very own
telemedicine platform
Key benefits for healthcare industry
• Significant increase of geographical coverage
• Maximum resource utilization - no need for additional hospital staff
• Electronic health records
• Secure and reliable archival of all communication/transaction for secondary medical opinion or
training the medical interns
• Low-cost technology
• Ease of use for the patient to allow quick and easy consultation from any remote location
Key benefits to OEMs

• Proven platform that is demonstrable
• Highly cost effective since reference design is owned by MindTree
• Customizable across languages, UI, functionalities, and devices supported
Why MindTree
• Strong medical domain expertise
• Expertise in the latest technologies
• In-house R&D team for best-in-class reference design
• MindTree commitment, continuous support, and roadmap for IP development
• A breadth of hardware and software experience coupled with customization, integration, and UI
development

Why Connect Medical Devices

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Why Connect Medical Devices

Uploaded by

Copyright:

Available Formats

Why Connect Medical Devices?

September 27th, 2005 | Published in Healthcare IT, connectivity

About the author

Another important challenge is related to bi-directional communication with an IV pump.

About the author

Brian McAlpine is currently Director of Strategic Products at Capsule Tech's Andover,

Email Brian | All posts by Brian McAlpine

#1 Pete McMillan on 10.02.09 at 12:24 am

I do not support end-to-end integration of pumps to EMR. This would require

I would advocate somewhat “dumb” pumps that connect to a proprietary gateway

#2 Ken Fuchs on 10.02.09 at 5:10 am

#3 Pete McMillan on 10.05.09 at 2:45 am

#4 Brian McAlpine on 10.06.09 at 12:07 pm

I believe there are a couple of threads being discussed here. My original

In response to Pete’s comment – “The Gateway would maintain mapping of the

[…] (more…) […]

#6 Carla on 10.16.09 at 3:45 am

Market Trends Series: Wireless Connectivity

As the healthcare market continues to evolve, so do solutions related to medical device

About the author

Brian McAlpine is currently Director of Strategic Products at Capsule Tech's Andover,

Email Brian | All posts by Brian McAlpine

#1 Tim Gee on 09.21.09 at 8:34 am

Brian, I’ll kick things off with a few observations.

First, the delivery of health care is inherently mobile. Everything is moving:

The biggest challenge for wireless communications is establishing and

#2 Shorts: MDC review; Radiology wiki; Insurance rates up | mobihealthnews on

[…] Wireless medical devices need to consider hospital’s WLAN: Medical

#3 Mikko Kaarela on 09.22.09 at 6:20 am

One of the key challenges in wireless medical device connectivity is Wireless

In a hospital it is impossible to rely on dissatisfied users to complain when a “best

#4 Brian McAlpine on 09.23.09 at 10:59 am

I have seen many different network management solutions deployed in hospitals

#5 Pete McMillan on 10.01.09 at 11:57 pm

As Mikko notes, the reliability of the enterprise WLAN is extremely important,

#6 Matt Perry on 10.03.09 at 6:21 am

I would be happy to do a webcast to anyone listening to discuss this in an open

#7 Carla on 10.20.09 at 4:01 am

This will take like 2 decades to be in use

#8 Pete McMillan on 10.23.09 at 6:19 am

Interesting. I would assume that you have a huge volume of peer-to-peer

#9 Matt Perry on 10.26.09 at 10:40 am

#10 Pete McMillan on 11.03.09 at 3:43 am

#11 matt on 01.11.10 at 4:21 am

How Medical Device Connectivity Can Improve

Acquiring Medical Device Data is Key to Clinical Decision Making

Medical device connectivity in the ICU is essential to supporting a complete clinical

An Acute Care Scenario

We can learn something of what is required to manage patients effectively by following

Weaning the Patient from Post-Operative Mechanical Ventilation

To assist in visualizing this scenario, refer to the diagram of <!--[if

The process of weaning a patient from post-operative mechanical ventilation is an

Figure 2<!--[if

Figure 3<!--[if

Figure 4<!--[if

Figure 5<!--[if

Figure 7<!--[if

Figure 7<!--[if gte mso

As we can see from <!--[if supportFields]&gt; REF _Ref233028052 \h &lt;![endif]--

About the author

Email John | All posts by John Zaleski

#1 Pete McMillan on 07.09.09 at 11:26 pm

Figure 2<!--[if

Figure 3<!--[if

Figure 4<!--[if

Figure 5<!--[if

Figure 7<!--[if

Figure 7<!--[if gte mso

As we can see from <!--[if supportFields]> REF _Ref233028052 \h <![endif]--