The precursor to the Times story had appeared earlier in a number of places including here on October 5^th. At that time the issue was reported as a loss of data service as opposed to a loss of data, although it was noted that a reset could cause loss of the user’s contacts and calendar. On the 11^th it was reported here that the data may be lost for good, but then on the 13^th it was said here that maybe not all of the lost data was permanently lost. Apparently Microsoft/Danger was being run on a single server.

While there is no direct association of this situation with medical information (unless your doctor’s contact information was among the stored data), it should serve as yet another reminder that the connected world, and its operational software and hardware, is not without its own issues. When new medical applications are being discussed there seems too often to be a suspension of reality with respect to system functionality, data reliability, and data availability. Whether it is “just” an EMR/EHR, or it is more direct functionality (e.g. an alarm or communication system), or even a single device, it must be remembered that software anomalies (a nice word meaning it sometimes doesn’t work) are more common than rare, and that reliance on “the network” to perform as imagined can often be a false reliance.

In case there was any doubt of this, software is a fairly common cause of FDA mediated medical device recalls.  The FDA’s recall datebase has a Simple Search function. Entering “software” without date limits brings up 500 hits, the systems maximum. Limiting the search to 2009 (through 10/21/09) on the Advanced Search produces 62 hits. The most recent of these involves a “software bug” cryptically reported as “The … flag is configured incorrectly. The flag is not generated according to system requirements.” A “software update” is said to be forthcoming.

As I have noted elsewhere, the software industry really needs to be congratulated for its use of the term “upgrade” to mean fixing something that was never right in the first place. The second most recent recall had an equally cryptic explanation: “There is a potential safety issue with … 3.0.x software where study split operations are not correctly replicated to a secondary ’shadow’ archive”. (more…)

The second trend I’d like to discuss is the shift towards patient safety as one of the key market drivers for connectivity. It is probably not news to anyone that patient safety has become one of the key drivers for many healthcare IT initiatives. But what is the relationship between patient safety and MDC? Ever since the often referenced IOM report, To Err is Human: Building A Safer Health System, hospitals and vendors alike have increased their focus on driving towards significant reductions in medical errors. The industry as a whole has made great strides, but still lots of work remains.

With device connectivity, my experience has been that for at least the past 15+ years, the key driver has been making the nurse more efficient by eliminating the manual transcription of device data into the patient’s chart. One of the related benefits is a more come complete and legible patient record. However, one could argue that the more legible patient record could be achieved if the vital signs from medical devices were simply typed into the charting application manually (something that many hospitals are actually doing today). So I believe that the nursing efficiency argument holds as the primary driver – but that is starting to be challenged by the focus on patient safety as it relates to connectivity.

(more…)

Has anybody wrestled with the idea of placing patient-care applications on the laptop COWs (Computers on Wheels) in Hospitals?

There is a new series of USB-connected Ultrasound transducers that can do many ultrasound procedures, including Bladder Scanner functions.  It operates on any laptop, when loaded with the manufacturer’s software.  I can foresee many other patient-care functions vying to share the computers already in the patient vicinity.

Any guidance on this subject?

Here’s my reply:

As others have pointed out, you are right to be concerned about the safety of mixing regulated medical device applications and applications from any other source on the same computer. Moving forward without the proper information does expose your hospital to additional risk. At minimum you may be using the device “off label” if you unwittingly fail to follow the manufacturer’s instructions. (Note that the FDA’s interest in “off label use” centers on patient safety, where manufacturers may promote products for uses they were not designed and tested, or when manufacturers make an application with an easily cleared intended use knowing the market will buy and use the product for a more difficult intended use.)

You will need some information from your medical device vendor with the USB scan head and associated software.

Questions on General Purpose Computers

How specific are their specifications for the computer (hardware configuration, operating system, any additional libraries or applications) that is used to run their medical device?

Regardless of how specific their specifications may be, you must use and maintain your system (the USB scan head heads, application software and general purpose PC) in accordance with the vendor’s directions for use, or you will be using the system “off label.” The actual specifications can be high level, indicating a PC of any make or model as long as it includes a specific processor class and minimum speed, and meets minimum required memory and disk space, and a minimum version for the operating system. Alternatively, the vendor may be obsessively specific, calling out computer manufacturer and model, the specific CPU, the required version of BIOS, and even specific versions of operating system components. (more…)

Acquiring Medical Device Data is Key to Clinical Decision Making

Medical device connectivity in the ICU is essential to supporting a complete clinical decision support framework. While electronic medical records in and of themselves offer enormous workflow benefits, the documentation and charting systems are only as good as the data they convey.

Due diligence by care providers can be augmented by automated and validated data collection, achieved through a seamless form of medical device connectivity and interoperability that is supported both inside and outside the enterprise, and follows the patient from the home to the hospital. Yet, as we know, human beings are complex systems of systems.

Decision making in the healthcare enterprise is often made on the basis of multiple parameters and in the context of the patient presentation, setting, and specific conditions relating to the reason for hospitalization and procedures. The data used in clinical decision- making originates from many sources: devices in and around the patient, laboratory and blood tests, films, and ancillary information available both prior to and during the encounter. How often should data be collected? The assessment of clinical needs change depending on the acuity of the patient and conditions present at the point of care. (more…)

Software designed to support the application of clinical protocols has been in the works from various vendors. Patient monitoring examples include Philips Protocol Watch, soft-launched back in February 2007, and . These applications automate what are otherwise onerous manual calculations with data acquired from medical devices and integrated with data from other information systems. This is workflow automation of the most important kind, diagnosis and therapy delivery. These applications are typically regulated as Class II medical devices.

Last week I spoke with Philip Settimi, MD, vice president of global strategic marketing for Hospira. According to Settimi, “EndoTool replaces spreadsheets of physician preferences and worksheets full of manual calculations for managing patient glucose levels.” Such manual methods are obviously inefficient, but also susceptible to human error. This approach provides an effective tool to impose a controlled and centralized tool for managing tight glycemic control (TGC). Endo Tool comes with a specific protocol based on sophisticated algorithms to support glucose management. The key: taking all that complexity (the calcs) at the point of care and automating those 33 different non-linear equations.

(more…)

Besides patient safety, patient context also greatly impacts medical device workflow. (Medical device connectivity is workflow automation through the integration of medical devices and information systems.) How a vendor implements patient context can have a big impact on usability and customer acceptance.

Patient context requirements can vary, based on the type of medical device in question. What is not variable is the requirement to reliably establish and maintain context. Mobile applications (like smart pumps or patient monitoring) where the device may go in and out of network coverage while constantly in use present special challenges. This compares to a fixed or portable medical device, like a dialysis machine or diagnostic ultrasound, with an episodic use case during which neither the device or patient is moved. Another variable is whether the application is life-critical. Continuous patient monitoring and many alarms (e.g., smart pumps and ventilators) are life-critical applications with a higher threshold of requirements. This contrasts with connectivity for documentation like with point of care testing or spot vital signs capture. In all cases though, patient context must be safe and reliable. The above issues just help define how many hoops you have to jump through to be safe and reliable. (more…)

[…] Gregoire said she expects full public access to hospitals’ track
records to be done without extra cost to the state treasury. She said
she will introduce legislation giving consumers information about
“adverse events,” such as infections or patient deaths, at each
hospital.”With full disclosure, the health care system can
learn from its mistakes and prevent new ones,” Gregoire said in a
policy paper released by her office.

Such reporting could motivate hospitals to undertake difficult cultural changes and invest in products that will improve patient safety. The best run hospitals, with the appropriate technologies, could better compete with hospitals in their markets if prospective patients knew hospitals’ adverse event track records.

I’ve mentioned before (here, here and here for 3 recent examples) how transparency pressures will shine a bright light on adverse events through increased reporting. This won’t be an easy transition, but the industry will be better for it. I mean we’re here to save lives, right?

With the U.S. market in the midst of a hospital building boom, the environment at the point of care is changing. Variable acuity units (aka, universal beds or rooms), distributed nursing units, and other big changes are being adopted now. These changes will impact market requirements for both medical devices and health care IT.

You have been warned.

Is there a need to better track the use of medical devices? You bet. Besides tracking implantables for post market surveillance and recalls, tracking medical devices used at the point of care can reduce the risk of infections like methicillin-resistant Staphylococcus aureus (MSRA) through physical contact and cross contamination. There are no national hospital reporting requirements, and few state requirements for these infections. This story in the Baltimore Sun reports on a news study released by the CDC on MSRA infections:

“This is the first time that we’ve been able to measure the number of infections,” said the study’s lead author, Dr. R. Monina Klevens, an epidemiologist with the federal Centers for Disease Control and
Prevention. “We were surprised that the rates were so high. It’s a call to action.”

Industry consultant Brad Sokol developed a Medical Device Pedigree for tracking the use of devices and related patient outcomes last year. You can get the low down on Sokol’s pedigree from this presentation (pdf) on the FDA web site.

His theory predicted 13,000 to 26,000 thousand deaths from infection caused by contaminated medical devices and instruments. In the new study, “Of those infected with MRSA, almost 1,600 died, about 18 percent of the total. Extrapolating those figures to the entire U.S.
population, researchers said some 94,000 people might be infected, with 19,0000 deaths.” It would seem that Sokol was right on target.

The paucity of quality and outcomes reporting by providers is slowly changing as hospital and physician data is published by CMS and other federal agencies, state governments, hospitals themselves, and others. But we have a long way to go.

Much of the debate about Unique Device Identification (what the industry refers to as “UDI”) for medical devices is misdirected. There is too much talk about needing a unique identifier, as if the law did not already mandate one (see this, and here).

MDDI magazine ran a story that revealed the real UID agenda, From Information Silo to Bridge: The State of UDI. The real issue here is the need to track medical devices - especially implanted devices - to determine their performance. From the MDDI story:

When it comes to devices, comparisons with other products are inevitable. For example, the Advancing Patient Safety Coalition recently compared medical devices to peanut butter. Specifically, in a letter to congressional members dated June 18, 2007, the  coalition stated, “We can simply and quickly identify each and every jar of peanut butter that might have salmonella and remove them from store shelves in hours, but we cannot do that reliably today with potentially life-threatening defective medical devices.” Similarly,
during a 2006 CDRH public meeting, Larry Kessler said that the medical device industry is “probably a decade or more behind the grocery industry” in terms of product tracking.

By equating medical devices with peanut butter, the authors imply it is the device vendor who is responsible for this sorry state of affairs. In fact, the guilty party is the equivalent of the grocery industry, health care providers.

There is no doubt that better tracking of medical devices would improve recalls, provide better post-market surveillance to better reveal safety issues, and reduce avoidable infections. But we don’t need some new fangled UID standard affixed to medical devices to do it. Here’s what’s really missing:

1. A mandate that providers track, record, and report the use of all medical devices (and associated clinical outcomes data) without exception,
2. A repository where data is aggregated across providers, devices and device vendors, and
3. Someone to analyze this data and report it to the public, providers, patients, and vendors for appropriate responses and follow up actions.

This makes forcing device vendors to replace the currently mandated unique identification (you’ve probably heard of them, serial numbers) with a “new” and “improved” UID seem like the side show that it really is. Let’s assume that AdvaMed doesn’t muster the political leverage to forestall the UID, and in a few years some standards body promulgates a new UID standard. Okay, the easy part is done, now for the hard stuff.

• Who’s going to mandate that providers do all this tracking and reporting?
• Who pays for all the fancy new IT and labor required to track and report this data?
• What entity(s) will assume responsibility for maintaining this repository of medical device usage - and outcomes?
• Who will enforce the implementation and conformance of this reporting by providers - and what penalties will be incurred for non-compliance?
• Who’s going to manage the recall communications and follow up?
• Who’s going to assess post market surveillance data and issue recalls? (That’s pretty easy, the FDA would clearly handle this - but they’ll need more money.)
• What about patient privacy, who will be responsible for maintaining it, and will patients be able to opt out?

The scope of the UID system that’s required to achieve the benefits many have attributed to this “great leap forward” becomes more clear. In fact, you could implement all the tracking and gain the very same patient safety improvements using the industries current UID, vendor serial numbers.

I should also note that vendors are currently required to maintain device history records that would benefit greatly from data held by providers (patient data for implants, near miss events, outcomes data) that is currently unreported. A simple mandate requiring providers to report this data to device vendors, and an open source software project driven by a foundation or university is a more direct and efficient solution.

All this really doesn’t have much to do with a fancy new identification number, does it?

Pictured right are some blood transfusion ID labels from the UK Blood Transfusion & Tissue Transplantation Services web site. The tracking of blood products might serve as a benchmark for UDI efforts.

UPDATE: From iHealthBeat, “Sen. Edward Kennedy (D-Mass.) on Thursday sent a letter to HHS Secretary Mike Leavitt urging the agency to finalize rules to implement the Patient Safety and Quality Improvement Act of 2005, Health Data Management reports.”

And this from FierceHealthcare:

Over the past week or so, the mainstream news media have crackled with the news of staph infections (including MRSA) found in  community schools. Prompted by this, Rep. Tim Murphy (R-PA) has filed a bill tha would require all hospitals in the U.S. to report infection rates t HHS. Under the terms of the bill, HHS would make such information available publicly on its website.Such a measure would trump existing infection tracking underway in the states. Right now ninetee states require infection reporting, but not all make the information public. (Murphy’s home state of Pennsylvania does make hospital-acquired infection reports available at www.phc4.org.)

Yesterday I noted that the Biomed Listserv has moved to new digs. In addition to a new hosting service, there is a message limit of 450 words - sadly, only enough for one or two points for me. I learned about this limit when my message bounced, so I’ve posted it here.

James asked about RFID in hospitals: who’s got it, what they’re doing with it, recommended vendors, and problems people have had. The following are my two cents.

Besides infant abduction systems (which tend to rely on monitored choke points rather than positioning throughout the unit), there are only about 200 hospitals that have deployed active RFID in the US. Of that 200, most are pilot deployments - limited to specific areas or departments. There’s currently about 10 to 20 house-wide RFID installations. This is not the rush to adoption that many (especially some of the vendors) expected.

There’s been a bit of a shake up among RFID vendors over the past year, and some very interesting new vendors have come to market. One of these vendors, RadarFind, introduced their system at the last AAMI conference in Boston. (You can read a bit about them here.) All in all, the vendor situation is unsettled.

Things to keep in mind:

• Different applications require different levels of performance, especially positioning accuracy. Positioning accuracy varies considerably among the different RFID technologies on the market. A thorough needs assessment to identify positioning applications and requirements for each application is the first step to selecting the right vendor.
• The details around knowing where someone or something is at a given point of time vary with different applications. If you’re looking for that Newport vent that just got recalled, knowing the general vicinity is fine. If you’re trying to improve utilization in your operating rooms, location data is just the beginning - you need an application that uses location data to optimize a much bigger set of processes. Thus, the workflow to which your positioning data would be applied is also an important requirement to gather.

My view of current RFID offerings is that the technology has not matured to the point where you can treat RFID as a generic multipurpose piece of infrastructure that can be leveraged by most any application that uses positioning data.

Let me know if you’d like help with an analysis of vendors, needs assessment, or planning/vendor selection.

Pictured right is the back of an Awarepoint positioning receiver - they plug into 110 volt wall outlets.