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?
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.
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.
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.
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.
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.
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?
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.
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
Further to my comments, here’s a very interesting pointer on continuous end-to-end Wireless Quality Assurance: http://www.7signal.com/
Given the IEC 80001 requirements and increasing number of WiFi devices WLAN vendor-independent monitoring and reporting is a fast rising priority.