GE Healthcare Acquires Agility Healthcare

A unit of GE Healthcares global Diagnostic Imaging Services business acquired Agility Healthcare Solutions today for an undisclosed sum. This is the same group that did the deal with Anywhere several years ago, and most recently signed a distribution deal with CenTrak, which was announced at HIMSS 2008 (press release).

What started as a straight on asset management strategy has grown in scope.

Any hospital administrator knows about the daily headaches caused by the logistical coordination of providing patient care. For each and every patient interaction, patient, clinician, staff, space, assets & supplies must come together at the same time. Agilitys visualization system is the one tool weve found that lets us visualize these interactions to predict and prevent bottlenecks before they occur, said Jeffrey Burke, Vice President and Regional Chief Information Officer, Bon Secours Health System.

The RTLS (real time location system) market’s initial focus was asset management. The industry consensus at the time was that asset management was easy to understand and had an attractive ROI – most hospitals lease some of their equipment that ends up poorly utilized due to hoarding and misplacing equipment. An RTLS can significantly reduce the amount of equipment leased through increased visibility and thus, utilization. Sadly, the hospital market was not sufficiently compelled to adopt this application (regardless of the ROI) at the rate that entrepreneurs and venture capitalists expected.

The founders at Agility, being software guys from McKesson, started with software. After some initial experience in the market they decided to stick with software and resell whatever infrastructure best suited their customer’s application. And the applications the market pulled them to are the kinds of things Bon Secours is doing.

Share
Read More

The Value of Unique Device Identification

Blood-transfusion-ID-labels

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.)

Share
Read More

AT&T Jumps on RTLS Bandwagon

AT&T-logo

These days phone companies like AT&T are more like network services providers than old time POTS (plain old telephone service) monopolies. Most, if not all of their land-line voice traffic runs over IP networks and the wireless unit is moving to full IP networking for wireless voice when they move to LTE in a few years.

That said, the whole “public utility” thing is becoming more a liability than the license to print money that it once was. In response to this transition, AT&T has been beefing up their networking and IT hosting services. Now they’ve taken the plunge and announced an RFID managed service designed for hospitals. From this RFID Journal story we learn that AT&T will design, install and manage your WiFi network. For an extra fee, they’ll throw in some AeroScout RFID tags and provide Asset Visibility. It is not clear whether they’re using the Cisco or AeroScout positioning engine.

I can certainly see hospitals using AT&T’s wide area network services, and maybe even NOC (network operations center) services. As a relative newbie to hospital wireless network, I’m skeptical. Ditto for any near term success selling RFID. If you’ve had any experience with AT&T networking services, let me know.

[Hat tip: StatCom newsletter]

Share
Read More

Premier Claims Safety Improvements with Medical Device Unique IDs

asset-tag

Premier Safety Institute sent out the September issue of their (usually) excellent Safety Share newsletter today. Here was the lead item (emphasis in original):

A major move to improve the safety of medical devices – On September 21, Congress approved a law requiring the Food and Drug Administration (FDA) to put into place a unique medical device identification system.

Pshaw! The newsletter went on to report that Premier surveyed 1,000 hospitals in an effort to claim a safety benefit from implementing such a system. Let’s look at this survey (you can download your very own copy here.)

(Identification industry proponents refer to these unique identifiers for medical devices using the acronym “UID.”)

The first red flag is Table 1, listing the job types of survey respondents. It seems that biomedical or clinical engineers didn’t respond to the survey. As the one department in hospitals responsible for patient safety and medical devices, this group should be identified. Instead we’re left to guess if “clinical support” or “Facility/environment” somehow includes biomeds.

Table 2 includes the survey questions. Of note here is question 2, “Do you have a system or database, beyond the individual patient record, to track or record medical devices that are implanted in a patient?” Only 46% of respondents said yes. Question 3 asks how patient care equipment (i.e., medical devices like infusion pumps or patient monitors) is labeled: 65% handwritten or text, 28% bar code, and 2% RFID.

The fact that most hospitals don’t log implanted devices, beyond the patient chart, is embarrassing. How do these hospitals get accredited? Because biomeds tend to be so obsessive about documenting patient care devices, question 3 is worded differently. The end result is the same, regardless how the device is identified, biomeds do a good job of documenting and tracking devices – recalled or otherwise.

Question 4 asks how recalled devices are located: 42% manually review patient records (implants?), 58% and 40% review manual and electronic logs respectively (patient care devices?).

To this point, we have interesting data on sloppy recording of implanted devices. There is no data that shows problems with identifying or locating patient care devices. Nor is there anything in the survey that indicates that a UID would improve patient safety – implanted devices that are not logged are a problem whether they have the current “unique identifier” known as a serial number, or a UID.

Question 6 shifts gears asking, “to what degree do you believe that having a unique device identifier system would enhance patient safety by improving your current process for recording device information and tracking recalls?” This question conflates the numbering scheme with an improved process when in fact they are separate issues.

According to what Premier has to offer, the safety claim of a UID is bogus. Patient safety improvements are all dependent on improved hospital operations, and not on the numbering scheme used to identify medical devices.

Perhaps some supply chain expert can tell us why a UID would perhaps lower health care costs. While less compelling and sexy than improving patient safety, lowering costs is at least believable.

Pictured right is a typical asset tag. Tags like this, combined with medical devices’ current unique identifiers, can support all the patient safety improvements attributed to UID.

Share
Read More

AAMI 2007 – Day One, Clinical Engineering Symposium

Manny-Furst-Bridget-Moorman

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.

Share
Read More