Today I was contacted by a social media marketing firm working for a major MDDS vendor with an offer to contribute content that’s on topic for this site (that last part is important). I’m interested, and I imagine a lot of this blog’s readers will be too. As I will likely take them up on their offer, I want everyone to understand that there’s not any favoritism that plays into who gets to post on this site. So, the following describes the ground rules, the benefits of contributing, and issues an open invitation to contribute posts.
We’ve been fortunate to have a number of terrific contributing authors over the years, and some of them have written posts that continue to be popular to this day. On the About This Site page is a long standing open invitation to anyone who wants to climb up on the soap box and
spout off contribute to the conversation about medical device connectivity. I’ve also made contributing author offers personally to many folks on both the provider and vendor sides of the table. There are so many people who have incredible knowledge and experience to share. And most of these people don’t have the time or inclination to create their own blog. Now you have an outlet.
The fact that connectivity, and perhaps wireless connectivity in particular, allows for hacking for mischief, theft, politics, social protest and other forms and varying degrees of evil should surely come as no surprise. In turn, that a wireless medical device might be hackable should be somewhere on the mind of developers, users, and regulators. Thus the report from the recent Black Hat conference that someone hacked an insulin infusion pump, and in so doing was then able to alter its settings, should also not be particularly shocking, but should serve as yet another reminder, that security associated with connectivity has been and continues to be an issue, as was addressed by Tim back in 2006.
The report in this instance came from Jay Radcliffe who hacked his own insulin delivery equipment. In this instance the hacking avenue was the wireless remote that was part of the device. Perhaps the idea that a wireless remote could be emulated is even at the ultra low end of surprise. More generally, the multiple discussions of this report (e.g. here and here) have suggested that the technology being used by at least some medical device manufacturers does not offer an adequate array of security safeguards. Or the manufacturers haven’t fully utilized what is available in terms of alternate hardware, or they havn’t fully utilized the security features that were available even in the hardware that they were using.Read More
As medical applications for mobile devices have proliferated, regulatory questions have proliferated nearly as fast, at least in some quarters. The key questions are what kinds of apps are medical devices, and among those, which will the FDA focus on for regulatory action. To date these apps range from home use adviser’s, guides and “toys”, which may or may not have real health care implications, to serious medical devices which have clear health care functions, despite in at least some cases, pretending they do not really, perhaps in an attempt to avoid the FDA.
On July 19, 2011 the FDA announced its proposed official action in this regard, including defining “mobile medical applications” that are the subject of this action. (I will use the acronym MMA, although the FDA did not.) . This includes a new FDA web page for mobile apps (here), with links to a new Draft Guidance, information for consumers, and a press release. This action by the FDA has a parallel to the recent final rule on Medical Device Data Systems (MDDS), discussed by Tim here, which also addressed what is it, what is it not, and how that which is will be regulated.Read More
Last week there was an interesting discussion on the Biomed Listserv about network installation for patient monitoring systems. Emphasis highlighting key issues and best practices are mine. The discussion started with a question from Scott Skinner:
I’m curious if anyone has been successful using their own vendors to pull cables for monitoring installations. With the monitoring OEM we work with, they simply get a local subcontractor to do the cable pulls.
So this would involve breaking future monitoring packages up into two quotes: one for the actual technology itself (and associated installation and implementation), and then one for just the cable pull work. The latter would get bid out, and the OEM could compete against other vendors.
Of course, the OEM can just take the profit they would have made on the cable pull and add that to the cost of the equipment bid. One would need to find a way to watch that carefully.
Which lead to a critical observation from Craig Muehling:
We have started pulling our own cable for monitoring installations. I have one happening now and I’m not exactly pleased how it’s working out. I won’t mention and names, [vendor name removed] but they make their equipment charges per drop whether you have any drops or not.
I would still like our [networking] vendor to do the networking, ie: install and configure switches and physically plug patch cables into the switches. Seems easy, but the way they [the patient monitoring vendor] charge it’s really not much less than if they did the whole job. I think from now on, we will have to take on the entire networking job.
I have learned a lesson from this last installation and will scrutinize the quotes closer from now on, but with their charging structure
(supposedly) there’s not a lot of options. Either we do the entire job, or they make lots and lots of money for relatively little work.
Here’s how they do it at the Mayo Clinic, from Steve May:
We have our own low voltage and high voltage contractors for all in-house cable pulling, to include data pulls and all project related work, so cable pulling and wiring costs are never part of an installation package, but an infrastructure cost which we earmark as Capital expenditures and plan/budget annually. Bids & labor costs are renewed by Purchasing every 2 years and our preferred contractors are all able to bid on both project services & time & material services.
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.Read More
I will be on vacation for the next 8 days, returning September 2nd.Read More