why connect medical devices
TRANSCRIPT
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 ofthings 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, anda 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.
#3 Pete McMillan on 10.05.09 at 2:45 am
@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
<!--[if gte mso 9]> <![endif]-->
<!--[if gte mso 9]> Normal 0 false false false EN-US X-NONE X-NONE <![endif]--><!--[if gte mso 9]> <![endif]--> <!--[if gte mso 10]> /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin-top:0in; mso-para-margin-right:0in; mso-para-margin-bottom:10.0pt; mso-para-margin-left:0in; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;}
<![endif]-->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
#8 Pete McMillan on 10.23.09 at 6:19 am
@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.
#10 Pete McMillan on 11.03.09 at 3:43 am
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 PerryTechnical 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 <!--[if supportFields]> REF _Ref233026844 \h <![endif]-->Figure 1<!--[if gte mso 9]> 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003200330033003000320036003800340034000000 <![endif]--><!--[if supportFields]><![endif]-->, 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 <!--[if supportFields]> SEQ Figure \* ARABIC <![endif]-->1<!--[if supportFields]><![endif]-->: 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 <!--[if supportFields]> REF _Ref106667499 \h <![endif]-->Figure 2<!--[if gte mso 9]> 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003100300036003600360037003400390039000000 <![endif]--><!--[if supportFields]><![endif]-->, 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.
Figure <!--[if supportFields]> SEQ Figure \* ARABIC <![endif]-->2<!--[if 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, <!--[if supportFields]> REF _Ref233027242 \h <![endif]-->Figure 3<!--[if gte mso 9]> 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003200330033003000320037003200340032000000 <![endif]--><!--[if supportFields]><![endif]-->, 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.
Figure <!--[if supportFields]> SEQ Figure \* ARABIC <![endif]-->3<!--[if 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 <!--[if supportFields]> REF _Ref233027374 \h <![endif]-->Figure 4<!--[if gte mso 9]> 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003200330033003000320037003300370034000000 <![endif]--><!--[if supportFields]><![endif]-->. 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).
Figure <!--[if supportFields]> SEQ Figure \* ARABIC <![endif]-->4<!--[if 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.
Figure <!--[if supportFields]> SEQ Figure \* ARABIC <![endif]-->5<!--[if 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.
Figure <!--[if supportFields]> SEQ Figure \* ARABIC <![endif]-->6<!--[if 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.
Figure <!--[if supportFields]> SEQ Figure \* ARABIC <![endif]-->7<!--[if supportFields]><![endif]-->: Comparison of patient temperature to illustrate
approximate time required to achieve normothermia.
Figure <!--[if supportFields]> SEQ Figure \* ARABIC <![endif]-->8<!--[if supportFields]><![endif]-->: Patient spontaneous respiratory rate in comparison
with mandatory settings to provide gauge on viability to wean.
<!--[if supportFields]> REF _Ref233027812 \h <![endif]-->Figure 7<!--[if gte mso 9]> 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003200330033003000320037003800310032000000 <![endif]--><!--[if supportFields]><![endif]--> and <!--[if supportFields]> REF _Ref233027819 \h <![endif]-->Figure 8<!--[if gte mso 9]> 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003200330033003000320037003800310039000000 <![endif]--><!--[if supportFields]><![endif]--> 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 <!--[if supportFields]> REF _Ref233028052 \h <![endif]-->Figure 9<!--[if gte mso 9]> 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003200330033003000320038003000350032000000 <![endif]--><!--[if supportFields]><![endif]-->.
Figure <!--[if supportFields]> SEQ Figure \* ARABIC <![endif]-->9<!--[if 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 <!--[if supportFields]> REF _Ref233028052 \h <![endif]-->Figure 9<!--[if gte mso 9]> 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003200330033003000320038003000350032000000 <![endif]--><!--[if supportFields]><![endif]-->, 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 [email protected] Investors Contact: Allan Kells (816) 201-2445 [email protected]
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 platformMindTMED 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