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.

Increasingly companies are adopting social media policies that establish ground rules for employees posting to blogs, Twitter, Facebook, etc. Besides benefiting your employer, contributing posts also benefits the writer personally with increased awareness and respect among your peers. Contributors also get an author’s bio like this one for current contributor, William Hyman:

William Hyman is Professor Emeritus of the Department of Biomedical Engineering at Texas A&M University. He recently retired and has moved to New York City where he continues his professional activities.

Writers that want to remain anonymous can do so, to a degree. You can be anonymous like the blogger Tim at HIStalk. He doesn’t disclose his identity on his site, but he is not legally anonymous. This means that you can chose to not disclose who you are (or your employer), but if I’m legally compelled to disclose your identity I will. Some employers will appreciate this kind of anonymity because there’s little chance the writer’s opinions will be associated with the employer. Of course many employers, especially the smart ones, will want that employee-employer association to be known so that all the insight and intelligence the contributor demonstrates in their posts will rub off on them!

In the connectivity segment of the market, there are a lot of new entrants and many established companies flying under the radar of broad market awareness. Contributing blog posts about your experience or perspective (nothing too commercial please) is a great way to establish credibility and get the word out. The most effective use of blogging is engaging in a long term conversation with your readers. Most of my consulting business comes from this blog, in addition to the usual word of mouth and repeat projects. You put your content out in the blog, and readers come back with questions and requests for help with problems, advice, referrals to fill new positions, you name it. And I can’t tell you how rewarding it is to meet people at customer sites or events who are readers of this blog.

Unlike a magazine article, press release or white paper, contributing to a blog is typically not a one shot deal. A series of blog posts that address a body of topics or frames an issue gets read when it’s published – and after that – via search engine queries (that’s why it’s important to identify and use the right key words in your blog posts). Ideally, potential contributors will look at this as an extended conversation, or at least a series of posts that will span several months, if not indefinitely. Individual contributions are welcome, but they will have to be particularly thought provoking, entertaining and/or informative.

Why contribute posts to this site? Well, the site gets about 300 unique visits per day (less on weekends) and has  hundreds of subscribers to the RSS feed (the funny orange square icon on the right). Readership is evenly split between providers and manufacturers. As a contributor you will get access to the sites statistics where you can see how many times your post is accessed and by who (or at least their IP address or domain name).

So, if you’re interested in contributing, let me know. And if you’re a reader, here’s your chance to leave some feedback – what would you like to read more or less of on this site?

As an aside, if you’re interested in the blogs and news sites that I read, keep an eye on the Connectologist’s Shared Items box in the right hand bar. This is a list of shared items from my Google Reader. If you’ve got a blog or news site to suggest to me or your fellow readers, leave it in a comment to this post.

[Flickr photo of Selma by Netzanette]

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.

Not surprisingly medical device manufacturers have downplayed the risks of hacking. The manufacturer of the pump in question, Medtronic, responded through a diabetes oriented web site, but apparently not through an actual press release of its own. The responses included that Medtronic does take device security seriously (would you expect them to say otherwise?), and that no real-life events have ever reported. Of course a problem with the later is that stealth hacking, as opposed to announced hacking, could cause harm while going unreported. This is to not say they have, but only to note that “reported” is a limiting case.

Medtronic is quoted further as saying “Our job is to incorporate information security measures into our designs, vigilantly monitor potential threats and to always be proactively finding ways to make our devices more secure for you. That is what we have done and what we will continue to do.”

A curious post in response to this expected response from Medtronic was “Security violations are caused by sloppy implementation. The systems themselves are very secure.”  I’m not sure how much better that is supposed to make us feel. Equally curious was that this response referenced RSA as a security authority, with other posters then pointing out that RSA was itself hacked.

Hypothetically (that means I made up the following) assorted glitches and could-not-duplicate service events could be the result of hacking, i.e. if the hacker hacked, and then stopped hacking, whatever the effect of the hacking was could well stop also, and therefore be un-findable. Which reminds me of a hospital wireless interference anecdote I heard about bursts of interference, almost always during the night, and almost always for one or two minutes. The culprit was an old leaky microwave being used in quick mode. And why only at night? Because the cafeteria was closed then and therefore the microwave was a primary food resource.

The bottom line is that security is an ongoing issue that must be rigorously addressed by manufacturers, and in turn by the FDA who has to at least ask the what-have-you-done-about-connectivity-security, and insist on a firm answer. Further, I will ask the question that I asked about the challenges of hospital networking at an AAMI session last June in San Antonio. My question was, “Is the problem getting easier or harder?” The answer was a laugh.

[Thumbnail photo above (used with permission) shows the various sites used to inject insulin over a period of time - one month if I recall correctly. In the lower right corner is the Medtronic insulin pump dangling from a tube. - Ed.]

William Hyman is Professor Emeritus of the Department of Biomedical Engineering at Texas A&M University. He recently retired and has moved to New York City where he continues his professional activities.

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.

The Draft Guidance, dated July 21, 2011, defines an MMA as a ”software application that can be executed (run) on a mobile platform, or a web-based software application that is tailored to a mobile platform but is executed on a server”, where that software already meets the general definition of a medical device as found in 210(h)of the FD&C act. In brief, the relevant part of this definition is that a medical device is used in the diagnosis, treatment, cure, mitigation or prevention of disease.  If there was any prior doubt, this again establishes that software that is intended to do any of those things is a medical device, even in this case  if downloaded from the app store, and run on a smart phone. Intent here can  be a key issue in that general purpose software that might be used for a medical application is in general not regulated as a medical device, unless the software manufacturer promotes such applications. This guidance does not specifically address wireless safety considerations, classification and submission requirements related to clinical decision support software (once called expert systems), or the direct application of quality systems to software, all challenging issues.

That software can be a regulated medical device has been asserted by the FDA on a number of occasions, and they note in this guidance multiple examples of medical device software that has already been defined and classified. The FDA’s justification for doing this is also familiar; besides its congressional mandate, the FDA notes that “As is the case with traditional medical devices, mobile medical apps can pose potential risks to public health”. However the FDA makes clear here that the mobile device itself (the mobile platform) is not considered to be a medical device, even if it is running an MMA – unless the seller of the platform makes a corresponding claim for its medical use.

Among all mobile apps, the FDA in this guidance has defined the MMA subset that is the subject of the guidance. However we are reminded that other mobile apps may still be medical devices, and therefore potentially subject to regulation, but under the FDA’s “enforcement  discretion” they will not be actively regulated at this time. However manufacturers of even these devices are invited to register and list with the FDA, and it is suggested that they follow the FDA’s Quality Systems Regulations, even if they don’t register at this time. Enforcement discretion is one of my favorite regulatory categories because that discretion can end at any time, and that which was previously not being actively regulated can easily become actively regulated. A no doubt bad automotive analogy here is to the long alleged grace speed overage before being subject to a speeding ticket.  However true or not true this is, a ticket can still be issued for speeds over the limit but under the rumored true limit.

The guidance goes on to define the scope of regulated apps (MMA) , and who is a MMA manufacturer. I will not repeat this information here, except to note that the download store distributors, like the platform makers,  are defined as not being manufacturers. Further, it is the creator of the software concept and its specifications, not the code writer  who is on the regulatory hook. Good news for programmers who aren’t the originator of the device. Time here for some perhaps artificial humility in the form of, “Hey, I just wrote the code to make the software do what they said it should do.” Also of particular interest to some, devices that create alarms are expressly addressed as being included. This is consistent with the FDA’s attention to alarm issues, which will be the subject of a forthcoming multi-sponsored Alarms Summit.

The appropriate FDA classification for MMAs will vary depending on the actual intended use. Thus, there is no reclassification here as there was in the MDDS final rule.

This FDA action can be viewed as one of several efforts in which the FDA must address rapidly evolving technologies, and systems of technologies, that in some cases have been deployed ahead of the FDA’s ability to deal with them under existing regulatory frameworks. Or as perhaps in this case, where developers have charged ahead with product introductions with disregard for medical device regulatory requirements, either from not knowing these regulations, or intentionally ignoring them.

William Hyman is Professor Emeritus of the Department of Biomedical Engineering at Texas A&M University. He recently retired and has moved to New York City where he continues his professional activities.

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.

It works well because the contractors get familiar with our electrical & system standards, building layouts, construction management staff and our bigger customers (at our project reviews, meetings etc.) whom have special requirements like radiology, surgery etc. All our monitoring projects are hardware only, we are even trying to separate the installation engineering, documentation (which is usually terrible) like red lines drawings and wire lists. We’re also trying to separate the go-live training, to manage train-the-trainer, in-service and certifications by the manufacturer after installation.

And according to Chris:

We do not use third parties to pull cable for monitoring systems.  We pull all of our own cable.   I have about 8 personnel who are Fluke certified to pull and terminate copper and fiber.  Of course any of the technologist on my team can pull the cable.  We have a Fluke DTX1800 as our primary cable certification tool.  We have other tools to validate cable pulls and termination, but the DTX1800 certifies each cable.  Our Information Services department likes our capabilities to certify our own cable.  The IS department “farms out” their cable pulls and terminations to a third-party vendor.

I like that we pull our own cables, this way my team knows exactly where all the runs are located, for each area, and they are confident that the job is done right.  We have had to work side-by-side on many projects with the outsourced vendor for the IS cable pulls.  Their technicians ave laughed a few times because we have pulled many cables at one time during an install and tested each one and they all passed the certification process.  They laughed because they said when they pull that many cables at once, they usually have around a 10% failure rate (bad termination or poor fiber signal).  I also think pulling our own cable makes us better at understanding networking.  It certainly aids in troubleshooting.

All of our UPS’s are networked [i.e., monitored] and that way we get paged and e-mails if a UPS is starting to fail or the room temperature where the UPS is located gets too high.  We have remote sensors that attach to the UPS for monitoring environmental conditions. Our Philips Monitoring Network uses Cisco routers and we have downloaded a very nice application that monitors all of the routers and switches in the network, again paging us if there are problems. 

I believe that pulling our own cable is just an extension of managing our networks for which we have responsibility (CCTV, Card Access, miniPACS, etc…). Last year we saved over $340,000  by pulling our own cable versus outsourcing including overtime labor for some of the larger projects.

And J. Scot Mackeil suggests the following best practice:

Have ALL the data cables that carry life critical monitoring data around the facility be a unique color per hospital policy.  When my hospital started installing spacelabs IP networked monitors and replacing the DEC net stuff, I insisted we adopt such a policy and stick to it. Every medical monitoring network run and patch panel from the servers to the local closets to the wall plates to the monitors is done in HOT PINK Cat 5 cables.

There is no way the IT or facilities guys can mistakenly disturb a life critical monitoring application as our cable color screams out loud and clear, “don’t mess with me!”  Our connections to the cloud are by VLAN and in the racks, we have 24 port ethernet hubs, installed so we could isolate from the network in the event of a major IT failure.

This approach works great for private networks like those required by patient monitoring systems. The industry trend, however, is to converge private medical device networks with the enterprise network. Medical device systems running on enterprise networks have a whole different set of best practices.

Jerry Messina noted that, “Some vendors will not certify the network if they or their contractor does not do the cable pulls.” And Ray Brown expanded on Jerry’s observation with the following:

I got a question or two about cable pulls. I was in a Biomed / IT meeting earlier today, and I wanted to see if the following was specific to just Missouri, or if it was USA-wide. Also, let’s pick two different types of data runs, and I’ll be specific – GE PACS, and
Philips Intellivue networks.

Is there a rule on the books that, “if you run wiring to any Biomed equipment that affects a patient or patient care, the FDA requires those lines have to have certification, and you must keep a copy of the certification for 25 years.”

I know Philips especially wants their lines certified before use, but keeping the certificate on hand for 25 years? This information came to my Director via the Missouri State Engineering Association, and I just wanted to see what else was on the books.

The FDA is a convenient lever for many situations, but one not always applied correctly. My response follows:

In general, FDA regs look at two things, 1) the processes a manufacturer follows to design and manufacture medical devices, and 2) the safety and efficacy of medical devices via the FDA’s classification related regulatory clearance/approval processes (Class I, II and III). As a health care provider, the FDA has no regulatory oversight over you unless you do things that meet the legal definition of a manufacturer.

Manufacturers submit entire medical device systems to the FDA. These systems are described by (among other things) marketing claims/intended use statements, product and system specifications, and resulting verification and validation testing. It is this totality of the product/system, as it is intended to be used, that is cleared or approved by the FDA.

Complex systems that include networks and interfaces to other devices and/or systems end up blurring the lines between what is and what is not a part of the regulated medical device. For example, if a medical device system runs on a network (physically separate or as a VLAN on your hospital enterprise network) the network is part of the medical device.

The buyer of these systems should maintain their systems within the specifications used by the manufacturer in the design and installation of the system. Not conforming to these specifications result in a medical device system that is different from what was designed and tested by the manufacturer, and different from what was cleared or approved by the FDA. It is those vendor defined specifications that received FDA clearance, that must be maintained over the useful life of the system.

Thus the principal reason to conform to manufacturer’s specifications is to ensure safe and effective operation of the system.

There is no FDA regulation that says customers can’t install systems themselves or change something in a system, but to do so in a way that fails to meet the manufacturers specifications would likely render the system an “off label” use. There is no legal “certification” process that hospitals must meet, nor are there any requirements to maintain “certification documentation” for 25 years.

When manufacturers install complex systems in a hospital they do (sometimes a considerable amount of) verification testing after the installation, to ensure that the system — and the broader network and IT environment in which it is installed — meets the specifications for that system defined in the design documents of that product. This process is sometimes referred to by the vendor as “certification”, but is not recognized as some kind of official or endorsed certification by the FDA or anyone else.

System specifications for any product change over time, usually because parts used in the system become unavailable and the manufacturer has to find replacements that change specifications. It is also possible for hospitals to go outside of specifications with relative safety, if they follow a risk management process similar to the one used by manufacturers. Such an effort is not a trivial task, and is rarely undertaken by hospitals. (Specifications are often unknowingly changed frequently by hospitals, but that’s another issue.)

Regarding your specific cabling example, the manufacturer writes a specification for that cable, perhaps something like, “shielded twisted pair Cat 6 cable”. There may also be specifications about physically routing the cable (distance from EMI sources) and/or specifications for testing the cable run after it is pulled for attenuation, noise, etc.

Provided the manufacturer gives you all those specifications, you can certainly pull cable and do other installation tasks yourself. By following the manufacturer’s specifications (including testing), you can remain fully in compliance with what was approved by the FDA. If the manufacturer choses not to share those specifications with customers, that is their choice and not something mandated by the FDA.

UPDATE: The title for this post was revised to better indicate the subject, which is the installation of patient monitoring system networks.

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?

The past few weeks I’ve been talking to people asking about publishers and such. I’ve got a few leads, but if you can suggest anyone to contact please let me know.

Here’s what I’ve been able to noodle out:

• First off, the definition: connectivity is workflow automation through the integration of medical devices and information systems
• The environment for connectivity can be divided into three areas: acute care (hospitals), ambulatory care (mostly physician offices), and home/ambulatory
• Applications can be divided between monitoring (both monitoring the patient and monitoring therapy delivery) and diagnostic studies
• One must also take into consideration the infrastructure to support connectivity, stuff like serial interfaces/device drivers, terminal servers, networking, server-to-server integration, client applications – what’s needed, and how to manage and support it
• Since connectivity is workflow automation, there should probably be a discussion on how to capture workflow and evaluate connectivity workflow provided by vendors
• Finally, standards and regulatory issues come to mind as a major topic

The areas like medical device interoperability (especially safety interlocks) and wireless sensors are two areas aren’t big now, but probably will be soon. Patient safety and risk analysis probably also deserve a separate focus besides what comes up in monitoring (surveillance and alarm notification) and infrastructure. Another topic that’s hanging out there is the process of requirements gathering, planning, vendor selection, technology assessment, installation and implementation.

Potential audiences include providers and vendors. Since vendors must deal with market requirements (i.e., what providers need and want) and their own product development issues, perhaps the book should focus on providers. Ideally such a focus would be of interest to both providers and vendors. A separate book could address vendor specific issues.

The scope of a book on connectivity is huge. I lack both the time and ego to do something like this myself. I figure to edit/co-edit and write a chapter or two myself. I can think of several terrific contributors (you’ll be getting a call at some point). Who would you suggest, and for what topic?

Somehow, I don’t see an endeavor like this making the New York Times best seller list – or being particularly profitable. I do believe there is a need for such a book to guide providers and help communicate best practices. Any thoughts on business models – traditional publisher, electronic (i.e., free) publishing, partnering with a magazine, selling them out of the trunk of my car, whatever – let me know.

Update: Thanks to librarylindy on Flickr for the use of her photo – I thought it really captured the gravitas and intellectual power of a book author.

A bleary eyed day 3 of HIMSS. There’s a lot of energy at the show this year – the exhibit hall is full with both attendees and exhibitors. Many write about the theme or hot topics at events. HIMSS has gotten so big, with such depth, that its easy to find that your interests are the hot topic at HIMSS. There have been some interesting announcements, which I’ll post on in the coming days. Many vendors have refined or shifted their strategies in ways that will impact their future products and customers.Yesterday I caught up with a very old friend. We started attending HIMSS over 20 years ago. He observed that some things never change.

There’s still a tremendous amount of spin and vapor ware. Sure there are new vendors and fresh faces but an alarming number of vendors still can’t describe their product in understandable language or articulate their value proposition beyond an alphabet soup of acronyms, “glamor words” and jargon. In meeting with one vendor yesterday, I asked repeatedly, “what is this?” In frustration I asked, “how would your marketing guy describe this?” His reply, “I am the marketing guy.” Uh, open mouth, insert foot…

Pictured at top is the only mobile device at HIMSS (or anywhere else) purpose built for health care from Intellidot.

There will be big news among RTLS/RFID vendors and I’m expecting some announcements from a number of connectivity companies.

As in years past, I’m attending as a contributing editor for MX Magazine. As such I’ve been inundated by PR folks for appointments. For the first time, I’ve used an online schedule to coordinate things. HIMSS only comes once a year, and I always try to make the most of it.

Meet the Bloggers

I’m very late with a post this year, but there will be a meet the bloggers gathering during the HIMSS opening reception – that’s Sunday between 5 and 8 pm (here’s a link). Look for the big blue and orange sign with “Meet the Bloggers” and come by and say hi.

Enjoy!