AAMI 2007 – Final Thoughts

Posted by Tim Gee on Jun 22, 2007 in Patient Flow, Real Time Location Systems | 0 comments

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.

Masimo Prepares Respiratory Monitoring Technology

Posted by Tim Gee on Jun 22, 2007 in Company Profiles, Real Time Location Systems | 0 comments

A while back, Masimo acquired a Canadian firm that developed a novel bioacoustic respiratory sensor. The fruits of that acquisition are soon to be on the market (press release). In recent studies, “Masimo Acoustic Respiratory Monitoring technology (ARM) is “at
least as accurate as capnometry” and “significantly more reliable” for
monitoring respiration in spontaneously breathing patients.”

At the Rapid Response Systems conference last month in Pittsburgh, studies were presented indicating that the most important parameter for identifying patients with deteriorating clinical conditions is respiration. At the same time, those studies showed that respiration was the most poorly documented physiological parameter – by far. A common problem with respiration is manually assessing the respiration rate through observation, that's why many recordings show a standard 12 breaths per minute.

Masimo also indicates in this same press release that we can see a product built around this parameter:

Pictured right is the respiratory bioacoustic sensor. You can read a story in Anesthesia News, and one of the papers (pdf).

AAMI 2007 – Day One, Clinical Engineering Symposium

Posted by Tim Gee on Jun 16, 2007 in Real Time Location Systems | 2 comments

First up today, the Clinical Engineering Symposium: Medical Device Integration Projects. A panel of rock stars will present case studies on medical device connectivity. Steve Grimes kicked things off to a full house – SRO, actually.

Case Studies from Beth Israel Deaconess

First up will be John Halamka, CIO at Beth Israel Deaconess Medical Center. His themes are:

1. The importance of including medical devices in enterprise-wide EMR projects
2. The importance of including clinical engineers and IT people during the planning stages
3. The importance of looking to consensus-based standards

The American Health Information Community (known as “the community” rather than “a-hick”) identified 4 requirements to tackle in 2006 – a certification commission, standards, security and privacy, and a nationwide health information network architecture. Halamka noted there are over 700 health care standards that could be applied. He presented a nice model with a basic use case, actors, tasks and documentation – that is intended to lead up to the blessing of specific interoperable standards that will go into federal procurement standards (effectively a de facto standard). All of this has been worked through and presented to AHIC for formal adoption.

In 2007 the focus is privacy and security, emergency responder, PHRs, meds management, and quality (QI) – with the goal to again review, align and harmonize all of these areas into a common manageable process. Preliminary requirements for privacy and security are completed. For 2008 AHIC is looking at medical device standards, with focus on remote monitoring outside acute care settings.

The projects they’ve done at Beth Deaconess over the past few years include mobile glucometer interfaces to a lab system, an ICU information system (Philips monitors with MDsoft), anesthesia information system (Compurecord system from Philips), positive patient ID/eMAR (passive RFID for neonates and barcode), and active RFID.

The RFID deployment was justified on improved asset tracking -loss prevention, reduced time looking for assets, eliminating device hoarding. Their consensus on active RFID: not yet ready for prime time. Beth Israel went with WiFi based RFID and PanGo. He notes the higher access point (AP) density requirement – wireless data requires 1 AP visible per client, RFID requires 3 for even modest performance (and notes increasing co-channel interference issues with higher AP densities). They started with 450 Cisco APs, and they expect to add an additional 100 thin APs and one controller.

Tags were found to be a weakness – too expensive, too big, too short a battery life. With the release of third generation tags, most weaknesses are being overcome. Accuracy results: 33% of readings were room-level accurate; 50% of readings were off by one room; 17% were off by 2 or more or the tag was not even seen. This is great for finding IV pumps squirreled away nurses, but of little value for staff and patient tracking applications.

Note that this was a pilot evaluating just one vendor, and not RFID in general. They have decided to deploy the system house-wide for large assets and applications that require no more than 10 meter (30 feet) accuracy. The biggest surprise in the RFID project was with the Cisco wireless LAN. According to Halamka, there are two kinds of Cisco code: “safe harbor” code that is rock solid with basic functionality, and “bleeding edge” code that has all the cool advanced features and is almost completely unreliable. Cisco ended up putting a lot of their resources into kgetting and keeping Beth Israel operation.

Patient-Centric Medical Systems

Julian Goldman, director of the Medical Device Plug and Play lab in CIMIT presented next. With everything that’s going on in clinical engineering these days, he does not envy AAMI members, but he does admire them. His talk was titled, “can patient-centric medical systems integration improve safety at the “sharp edge” of health care delivery?” He reviewed CIMIT’s Operating Room of the Future (ORF) program, describing the workflow and how devices are integrated to support that workflow.

He talked about systems integration and medical device interoperability to create safety-interlocks and high reliability systems for care. The identification of “exception conditions” across a broad care delivery effort like surgery is perhaps more valuable than automating normal tasks and procedures. After numerous examples of interoperability that exist in our daily lives, he contrasted that with the almost total absence of interoperability in health care. Finally Julian described numerous interoperability projects and experiments – none of which are available commercially. The reason for the absence of these interoperable safety-interlocks was laid at the feet of vendors – and at the same time, Goldman appealed to hospitals to work together to “motivate” vendors to commercialize these kinds of capabilities. Be sure to check out his site for lots more information.

Connectivity Case Study – Kaiser

Bridget Moorman, Clincal Systems Engineer at Kaiser, was up next to talk about her project at Kaiser. They’re attempting to integrate medical devices with their Epic EMR on an enterprise scale – a daunting task. Bridget laid out the key requirements medical device connectivity, describing things like, “want[ing] seamless interconnection and data flow from biomedical devices to clinical information systems.” The means to effectively manage connectivity deployments was also discussed. She also presented a nice model for considering infrastructure hardening requirements for medical device connectivity.

Bridget next delved into standards: 11073, HL7, DICOM, CANopen, Continua Health Alliance, and XML. She reviewed numerous device vendor solutions (GE, Philips, Welch Allyn, Capsule Technologie, Sensitron, HCTSi iSirona, LiveData, iMetrikus) she has in her lab.

Perhaps the most important topic presented was a description of the “device interoperability” contract language that Kaiser has recently specified in their purchase contracts:

• Supliers will warrant that their products will interwork or interoperate with KP’s Epic systems and with other designated third party products
• Supplier will finalize any integration with third party products before delivery to kaiser and will do independent testing of the interoperatbility at CIMIT or the Sidney Garfield Center
• If unsuccessful interoperation, will reimburse Kaiser for product cost
• Do not specify interface standard due to current volatility in standards definition and development

This is radical stuff that places the systems integration role firmly on the shoulders of the medical device vendor.

After presenting an enterprise connectivity architecture, Bridget offered some great observations about connectivity pitfalls and lessons learned:

• IT folks frequently don’t understand clinical variable context, e.g., temp versus core temp
• Need for dual systems operation and limited HL7 message availability
• Limited or no availability of “test” devices – connectivity test systems rather than the actual device
• The duplication and complexity of interfaces and components to make medical devices with serial ports network-aware – creates problem-identification challenges
• Brittle interfaces where problems can ripple on either side of the interface when changes occur in either the device, interface system or CIS/EMR
• Prevalence of proprietary end-to-end solutions from device vendors
• The paucity of connectivity monitoring and management tools to help identify and fix signal propagation problems (due to limitations in devices and connectivity systems)
• Very limited interface configuration capabilities – scalability, message modification, number of ports, etc.
• Insufficient wireless capabilities – health care delivery is inherently mobile, connectivity must be too
• Establishing and maintaining patient context – older technology associates data to patient using port numbers or bed locations, and not actual patient name and ID

A sample device connectivity architecture was presented, highlighting the complexity and additional steps and vendors necessary to get device data into the EMR. Many device vendors have dragged their feet in adding network connectivity to their devices. The reliance on dongles or warts (modules that connect to the device’s serial output and convert data to network connection) is suboptimal, resulting in another unnecessary component to be configured, and maintained – when they get knocked off or banged against the wall or door jam. The best solution is an embedded radio and/or Ethernet port. Many device vendors need to redesign products with more microprocessing horsepower to enable better interfaces.

Bridget described their experience with Nuvon for remote monitoring of the device – connectivity system – EMR chain, including network connections. Kaiser is looking at this to help simplify the connectivity service tree (a sample of which was presented). She closed her presentation reporting that hospitals can expect to pay $10,500 per bed to export device data to HIT systems via HL7. This cost includes hardware, software and biomedical engineering labor costs. Any costs to purchase new medical devices to facilitate connectivity (like new Dynamaps with IrDA capability) is not included.

Medical Device Interoperability

Rich Schrenker, Systems Engineering Manager at Mass General, presented an very thought provoking look at interoperability – what it is and what it can be. After reviewing various interoperability definitions from the IEEE, HIMSS, the MD PnP lab, and the USB Implementers Forum Personal Healthcare Device Class – all different – Rick noted that connectivity remains a largely unsettled market.

In thinking about connectivity, Rick considered systems engineering and creating resilient systems. He noted a challenge in the following quote from S Dekker, Resilience Engineering:

“One marker of resilience… is the distance between operations as management imagines they go on and how they actually go on… Understand the gap between the system-as-imagined and the system as actually operated requires investment not only in understanding how the system really works bu also how it is imagined to work. The latter can sometimes even be more difficult.”

And from “To Err Is Human,”

People… become accustomed to design defects and learn to work around them, so often they are not recognized… Accidents are more likely to happen in certain types of systems. When they do occur, they represent failures i the way systems are designed. The primary objective of systems design ought to be to make it difficult for accidents and errors to occur and minimize damage if they do occur.”

The point of care is rife with users who are accustomed to bad design – too many rounded corners, too little consideration of the other things clinicians do that is beyond your own device. Sadly, this accommodation becomes requirements and sales objections for newer products that do not include those design defects.

Rick notes a major shortcoming of our health care delivery system: “No substantial perspective on the entire system of health care or training in the use and implications of systems tools and information/communications technologies for managing and improving the system is included in medical education… [and] engineering careers in medical care insitutions are nearly non-existent…”

In a market dominated by proprietary medical devices, Rich suggested open engineering and leveraging commons-based peer production. Like the open source software business model, why can’t more providers actively collaborate to encourage vendors to develop better products and evolve widely held best practices.

In considering connectivity and interoperability, Rick wrapped up with the following:

“When health care providers begin leveraging interoperability to construct systems of components in configurations not specifically intended by manufacturers and approved by FDA, they will be engaging in design and integration activities the likes of which are currently under regulatory control. That will be addressed, and ultimately somebody will be doing the necessary point-of-care engineering, whether experienced, familiar, informed by history and safety-conscious, or otherwise.”

Pictured right is presenter Bridget Moorman with Manny Furst, who presented on Monday.

GE Unveils Carescape

Posted by Tim Gee on Jun 14, 2007 in Company Profiles, Patient Flow, Real Time Location Systems, Standards & Regulatory | 0 comments

GE Carescape is the main focus of a front page story
in Healthcare IT News (dead tree edition that came today). GE
Healthcare brings out the big guns to describe the Carescape solution.
Let's start with the problem as they define it:

According to David Freeman, chief marketing officer of monitoring
solutions for GE Healthcare, “…traditional patient monitoring
(measures) have not been keeping pace.” Amen to that. But it seems to
me that a major factor in this “jungle of technology” is the proclivity
for vendors like GE – virtually all medical device vendors, in fact -
to build end-to-end proprietary systems. This megalomaniac vision that
places the vendor's product (and not anyone else's) as the center of
the universe is perhaps the biggest factor in patient safety problems
at the point of care. The traditional solution for this problem is to
buy everything from one vendor – except there is no one vendor who
makes everything, not even GE.

The solution is, “a new product portfolio called CARESCAPE. Its goal is to provide a
wireless infrastructure that offers clinical decision support, advanced
parameters and device integration and control at the patient’s bedside.”

What exactly all this means, time will tell. Perhaps I will be able to get some details next week at the AAMI conference in Boston.

Surgical Sponge Counting System Gets FDA Approval

Posted by Tim Gee on Jun 13, 2007 in Company Profiles, Patient Safety, Real Time Location Systems | 0 comments

ClearCount Medical Solutions announced that they received FDA approval its RFID-based SmartSponge System for use (press release – pdf).

ClearCount has a recently improved return on investment due to the draft CMS rules for reimbursement for 2008 where they will no longer reimburse hospitals for preventable adverse events. Number 3 on the list is, “objects left in after surgery.”

Pictured right is the ClearCount tag. You can read more about ClearCount here.

Congress Contemplates Reporting of ED Boarding Statistics

Posted by Tim Gee on Jun 11, 2007 in Real Time Location Systems, Remote Monitoring, Wireless Medical Devices | 2 comments

According to this story in the New York Times, “More than half the doctors from New York State, New Jersey and
Connecticut who responded to a survey conducted in April by the
American College of Emergency Physicians said that boarding had
increased significantly in recent years.” Boarding is the practice of treating patients in hallways of busy Emergency Departments, frequently while waiting for an in-patient bed to become available.

You can chalk up this survey as another example of the increase in reporting of patient safety and outcomes:

Ms. [Julie] Lloyd [a spokeswoman for the American College of Emergency Physicians] said the survey was the first by her group, or any other she
knew of, to try to assess the number of deaths resulting from boarding.
She said in an e-mail message that a key point in legislation before
Congress “is to collect boarding statistics, which heretofore have
remained the province of the hospitals.”

Public reporting of boarding seems to be in our future, nation wide.

Don't kid yourself, boarded patients have died, in New Jersey and beyond. There are no statistics on this because hospitals don't code the cause of death to reflect the preventable adverse event that killed them like, “death from inattention due to boarding.” Harsh? Perhaps, but this is a long standing problem in which most hospitals still wring their hands and ask, “what can we do?” Here's what they did at Stony Brook hospital:

[Hat tip: FierceHealthcare]