I was in hog heaven at this year's AAMI meeting. Connectivity was a major theme, and during every time slot in the program there was at least one presentation dealing with connectivity. During my presentation Monday afternoon, there was one I really wanted to see that dealt with alarm notification.

Lots of discussion centered around the evolving role of biomeds and clinical engineers and the kinds of training they might need in the future. There were rumblings from some in the ACCE who wanted to hold their annual meeting at HIMSS next year rather than AAMI. There certainly is a life-critical systems role that needs to be filled, and clinical engineers could fill that role. To this observer, it seems that clinical engineers will slowly become marginalized if they do not move in the "systems" direction. Even biomed techs will need IT skills to manage and support increasingly complex and pervasive medical device systems.

During the GE sponsored breakfast, there was a session on managing RF in your hospital. Reportedly the perennial "WMTS versus ISM" debate reared its tired ugly head. For many reasons mentioned here in the past (just google "WMTS" in the search box on the left colum). The WMTS bands will never have the bandwidth or (more importantly) the management tools to support more than a small portion of the wireless medical devices in a hospital. Only the usual suspects can even afford to develop the prorpietary radios required for WMTS, which is why 802.11 has seen so much uptake with device vendors.

But the inherent limitations of WMTS do not make 802.11 a slam-dunk. In fact, recent experience has highlighted the need for more rigorous RF engineering, wireless LAN design, and ongoing RF and network monitoring to ensure a reliable network. Hospitals are perhaps the most hostile environment for wireless networking. When it comes to networks, hospitals are faced with both selecting a hardware vendor that best meets their needs and a VAR (value added reseller - the indirect reps used by IT vendors to sell their products) who really knows what they're doing. Only the best VARs can design and install a reliable network that supports all the big apps: data, wireless VoIP, positioning, and medical devices.

In a nod to presidential politics, "It's the workflow, stupid." To most, connectivity is about extracting data and moving it some place else. The real objective is to automate workflow - and how connectivity is implemented has a huge impact on what workflows it supports, and ultimately the usability of the system. A fundamental piece of this workflow is patient context, the association between a patient, their medical devices, and the data that comes out of them. Patient context remains a concept that's poorly understood by most users and vendors. Many still try to fudge patient context by associating the patient to a port number or bed location. Guess what? Patients move, and mobile devices especially, must establish patient context in the device itself to be safe and effective. I would love to see some of the fantasy-based risk analysis and mitigation documents done for certain connectivity features that I saw this week.

All of this gets to another big change reflected in this weeks conference. Stand alone embedded products are evolving into real systems that extend functionality way beyond the box itself. This "systemization" of medical devices requires some changes in thinking. No longer can you focus on building safe and effective boxes, and after the fact plugging them together with other stuff and be sure the result is still safe and effective. Nor can you manage and support interconnected devices simply by maintaining the device - the entire system must be configured and maintained as a whole.

One of the good things to come from the increased involvement of IT in device connectivity is their insistence on a test system to support the "production" system. They do this with all their software systems. An indicator that connectivity is an afterthought is the total absence of test fixtures for an integration lab. Another symptom is the scarcity of such labs in hospitals and the limited capabilities of most manufacturers' verification labs. As systems grow and become more complex, hospitals will increasingly demand support for these labs - in the absence of test fixtures, that means customers with clout will insist on indefinite loaners so they can effectively maintain their systems.

During the ACCE Clinical Engineering Symposium Saturday morning, Bridget Moorman referred to medical device connectivity as "brittle." I know more than one person had an epiphany upon hearing that term. Any change, no matter how small, along the chain from medical device to target computing device renders the device interface inoperable. Device firmware changes, pin-outs, cable connections, terminal server configurations, network configurations, and interface configurations - on either side of the interface - all result in failure. Planning for these interfaces (hopefully by the vendor before product development) must take this brittleness into account. At the very least, customers must be able to monitor their connectivity all the way to the device, not just a server or terminal server.

Finally we come to FDA regulatory issues. I met an FDA representative in the exhibits. She works on the Issues Management Staff, a tiger team that addresses patient safety related issues that reach a point where they must be dealt with. Can you guess one of the simmering issues that may soon become an Issue? That's right, medical device connectivity. Much of the current regulatory framework (both vendors regulatory strategies and how the FDA manages the process) is based on standalone medical devices, and "oh, by the way, it gets plugged into all this other stuff to do... stuff." We can expect to see regulatory perspectives shift increasingly to a systems view, especially when multiple vendors are involved.

The contortions many vendors go through to avoid FDA regulation is a symptom of this spreading systemization of medical devices. While the FDA has a responsibility to ensure safety and effectiveness, they are also responsible for accomplishing their mission in a way that doesn't drive undeserving vendors out of business or stymie the development of innovative solutions that promise even better safety and effectiveness. Don't expect them to accept the status quo for long. I ask everyone who's skirting the regs if they are committed to building a quality product, and the answer is inevitably yes. All it usually takes to get a 510(k) is compliance with a basic quality system (the FDA's Quality System regulation) and 60 days for the FDA to process your 510(k) paperwork. And yet the reticence to be regulated suggests that things like prototype code makes it into finished products all too often.