There were about 25 attendees today; mostly regulatory, quality and security experts along with a few representing hospitals, and a connectologist or two. We ran from 11am until almost 7pm. (You can read my run up to this meeting here.)

As security expert and clinical engineer Steve Grimes noted, we are an industry in transition with medical devices and information systems merging into some Borg-like creature to deliver safer and more automated care. Device vendors and biomeds are struggling with the general purpose computing environment; hospital IT is learning the demands of clinical care; while third party vendors (think vendors like Microsoft, Cisco, phone companies) try to meet market requirements of a demanding niche market (health care). The problems that were discussed reflect needed education and improved communications between the various stakeholders.

Manufacturers (of medical devices) want to be able to sell a networked device or medical system with a defined set of features in compliance with regulations to a user who is capable of understanding the accompanying documents and who actually understand the documents. Users want to be in compliance with regulations, and they want devices that will all be compatible with other devices and other equipment – interoperable.

There was lots of talk about the "dead hand of regulation" and "piercing the veil of commerce" (the application of regulations to users after the sale). There was virtually no support for new regulations. The group seemed to favor an advisory or consensus process standard - best practices - that could be used by all stakeholders, including organizations like JCAHO for accreditation purposes. The approach that got the most support was a life cycle risk model that incorporated skill based roles. The result would be a comprehensive process or recipe that would coordinate efforts by vendors, hospitals and any third parties (contractors, systems integrators, consultants) that might be hired to fulfill formal roles defined in the process. The German group SC62A presented a "new work item proposal" on networked PEMS (Programmable Electrical Medical System) that could serve as a template for the broader life cycle scope that was discussed. You can download a pdf file of the document here.

So what of these dire problems that all of this is supposed to solve? Patching the Windows operating system used in various embedded devices and computers was one of the first examples that were discussed. John Murray with the FDA's enforcement group described how they figured there would be more connectivity-like issues in the future and chose not to use new regulations as a first response. The FDA applied the existing regulatory framework and told industry to get their house in order - which is pretty much what's happened. Other connectivity problems include protecting medical devices from malicious code. Another biggie was medical devices not fully supporting general purpose computing configurability; surprisingly many of those network and security options are actually used and they are not supported at the risk of lost sales - and of course this becomes apparent when both the buyer and manufacturer make assumptions that blow up at installation. Down time, scheduled and otherwise, is a frequent bone of contention - any device that generates life critical alarms across a network cannot be down, not even when its scheduled for just 2 hours once a month. Finally, what happens when a third part component of a medical device system (like a PC, router or WLAN card) fails 3 years after installation? Give the short life cycle of these types of products, a replacement will not be available.

The industry has an inclination to apply an embedded system business model (limited configurations and parameters) to systems integration. Systems integration happens in a general purpose computing environment and this environment can't be proscribed because of the variability in ways IT systems have been built up over time and communicate with each other, both intra and inter hospital.

More tomorrow...