First Connectivity Cover Story in Leading HIT Mag

Connectologists rejoyced this month (September, 2008) when Healthcare Informatics magazine published Biomed Joins the Party – Savvy CIOs are considering biomedical devices in their overall strategic plans (link). To my knowledge, this is the very first cover story in a major health care IT magazine about medical device connectivity. As an aside, diagnostic imaging pubs have been writing about connectivity in their market for many years.

Contributing editor, Mark Hagland, casts the drama that is connectivity as “two worlds colliding,” – the worlds of IT and biomedical engineering. He builds his story around the integration of medical devices to support EMR charting. In fact, medical device connectivity started almost 20 years ago with the integration of Apple IIs and IBM PCs (not to mention a few funky HP mini computers) in diagnostic areas like the cath lab and in the ICU. Probably the biggest wave of connectivity to date has been PACS (picture archiving and communications systems) and the adoption of DICOM. Now the health care industry is zeroing in on connectivity at the point of care with patient monitors, smart infusion pumps, point of care testing, and yes, EMR integration (by far the most expensive point of care application).

Using Trinity Health as his template, Hagland describes an ideal approach to medical device connectivity: the involvement of IT, clinicians, and biomedical engineering.  The 40 odd hospitals in Trinity’s system have over 110,000 medical devices. Trinity has used this approach to more effectively manage these colliding worlds:

The biomed integration initiative actually began several years ago in an effort to cut costs, Fierens [the hospital exec over Biomed] reports. But as Project Genesis [their EMR project] has moved ahead, and as the technology in the biomed equipment area has advanced, the broader goals of improved care quality and workflow have come more fully into focus, he says. The biggest challenge, says Fierens, is that “you’ve got to balance the economics with the infrastructure and support, along with the service element, along with the clinical outcome you’re trying to support.”

The route to medical device connectivity for hospitals is neither clear or straightforward.

…there is the task of linking clinical informatics goals with biomedical equipment strategy. And that’s where [CMIO] Kramer comes in. Indeed, Kramer says, “a critical success factor is creating a compelling vision for automation-enabled patient care, and then translating that several levels down.” Such an approach requires a lot of collaborative thinking and work.

From the provider perspective a “compelling vision” is one that has significant clinical benefits realized through improved outcomes and patient safety, reduced operating costs, and greater resource utilization. Haglan’s story mentions closed-loop meds administration with smart pumps as an example. All the collaborative thinking and work comes in navigating the proprietary end-to-end solutions from vendors and the different approaches to connectivity necessitated by devices without connectivity (those with serial ports) and devices with connectivity solutions from the device vendor.

Reading between the lines, it is clear that providers aren’t keen on spending lots of money on connectivity as plumbing. Connectivity that is in the service of tangible clinical benefits is of great value, hospitals will gladly pay for that. When it comes to hooking up existing devices to pump data into a paperless chart, cost is much more of an issue.

All of this is driving change for those in the industry that focus on the point of care. Think about how diagnostic vendors have changed over the past 15 years. Many have been transformed from standalone embedded systems companies to chimera-like organizations that retain embedded systems expertise and also contain major enterprise software businesses. Similar changes have occurred on the provider side with many radiology departments now sporting their own IT resources.

This is health care we’re talking about so there was also mention in the story of resistance to change, especially on the part of providers:

“There’s still a lot of resistance, on both sides,” she says, referring both to biomedical engineers and to IT professionals. “A lot of people don’t want to have to do it. It’s a very different kind of business, involving finding equipment, maintaining it, and so forth. And especially in large departments, nobody really wants to take it under them. So it’s not actually a happy union on either side.” Still, Drazen believes that the IT complexity of new biomedical devices will compel the entire biomedical engineering department to come under the CIO in most organizations. “As everything becomes electronic, the hassle factor of not integrating things becomes pretty high,” she notes. “So it’s got to happen.”

Not so directly mentioned is the resistance to the changes connectivity represents on the part of vendors. Much like providers, vendors are human, no really. The tendency is to solve new problems with previously successful solutions. Given the fundamental differences between embedded systems and connectivity, the old medical device ways often don’t translate well. Requirements gathering, engineering skills, regulatory strategy, marketing, sales, service and support are all impacted by connectivity – frequently in ways that are not intuitively obvious (until, that is, you’ve learned something the hard way). With connectivity, like many things in life, you don’t know what you don’t know. This is true for both providers and vendors.

Another area where change is resisted by vendors is in product strategy. The proprietary end-to-end solution has been the default product strategy among vendors for many years. In mature markets – of which many health care market segments qualify – this can be a prudent and effective strategy. But there are some health care markets that are far from mature. And even in some mature markets, proprietary connectivity adds considerably to the cost of solutions, and I mean R&D cost and average selling price – not to mention increased time to market.

The sad fact is that for most vendors, connectivity features cost more and take longer to develop than expected. And the resulting solutions frequently generate less revenue and profit than anticipated – sometimes a lot less. On the customer side, providers need patient centric instead of vendor or device centric solutions.

The term “connectivity” brings to mind things like networking and systems integration. An important, and easily overlooked part of connectivity is workflow.

Most hospital organizations that begin work in this area focus on the “plumbing” issues — the wiring, infrastructure, and other technical aspects of the integration challenge, — “and that’s a mistake,” says Tim Gee, principal with Medical Connectivity Consulting in Beaverton, Ore., and a specialist in medical device integration issues. All the talk should be around workflow, he suggests. Even though “the plumbing piece is problematic, and it’s a hassle,” says Gee.

Moving bits onto networks and configuring HL7 interfaces is the easy part. Designing and implementing a solution that automates workflow in such a way as to improve productivity is the real challenge. Two connectivity market segments serve as cases in point. Both point of care testing (POCT) and smart pumps have yet to get workflow right. Besides all the complaints I’ve heard about POCT usability shortcomings, only about half of the test results ever make into the patient chart. Of all the networked smart pumps installed, the number of sites in the U.S. that capture patient context for patient/caregiver identified CQI data are less than a handful.

I disagree with one interviewee that, “biomedical-device integration remains at or near the starting gate is the range of governance, management, and other people-related challenges involved.” First off, connectivity in diagnostic areas (cardiology and radiology especially) is very mature and widely adopted. Ditto for critical care areas and the surgical suite. The market segment at hand, the one that’s having growing pains with connectivity, is the point of care.

The biggest barriers to adoption at the point of care are device centric proprietary end-to-end solutions that are unable to provide the kind of patient centric view that users desire, and the divide between devices with built in connectivity (typically a network connection and workflow support via server software provided by the device vendor) and devices with serial ports (for which a variety of third party solutions like Nuvon, Capsule Tech, iSirona and Cerner are available).

Perhaps a more interesting way to frame these barriers is to consider connectivity as a platform. Provider CIOs are keen on enterprise solutions rather than a myriad of point solutions from a variety of vendors. Enterprise solutions are typically more cost effective, and certainly easier to implement, manage and support. While we can thank the IEEE and Bob Metcalf for Ethernet, where is the “Ethernet for connectivity”? Interesting questions indeed.

With his usual aplomb and understatement, Cardinal exec Dan Pettus observes:

Vendor executives, another key stakeholder group in moving towards device integration, say they’re ready to work with one another and with their customers to make it happen. “Device-EMR integration has been spotty to date, and the reasons are obvious,” says Dan Pettus, vice president of connectivity and IT support at the Dublin, Ohio-based Cardinal Health. “The standards implemented in the marketplace in the last 20 years have not been well adopted, and there have been several attempts to get medical devices to fit within a tight standard that would allow more plug-and-play capability,” Pettus notes. He adds, however, that CIOs are increasingly recognizing the need to bring vendors into the process as partners.

Cardinal has certainly done their best to create their own end-to-end solution with their Pyxis, Alaris and Care Fusion acquisitions.  Regardless Cardinal’s past, Dan certainly recognizes the status quo of one-off proprietary APIs and interfaces between each device vendor and connectivity vendor is unsustainable in the long run. Such an approach costs too much, and does not provide the usability, clinical benefits and patient centric capabilities that the market demands.

The story closes on a positive note, observing that the substantial clinical advantages of connectivity will continue to motivate vendors to create solutions and providers to keep buying them. On the provider side, Trinity Health’s Browne notes:

“CIOs need to help people understand the possibilities through some real-life scenarios. You should be developing relationships among all three internal stakeholder groups — your biomed support people, informatics people, and clinical leaders – because this is one of those areas where no single domain expert or leader can advance this on their own.”

Share

One comment

  1. I agree totally, the #1 priority is workflow. We focus on Epic Systems implementations as well as Meditech implementations. The EMR implementation is difficult because it requires a significant change in workflow processes and involves learning new ways of processing, storing, communicating and retrieving information.

    It is impossible to implement systems that alter how critical patient care activities are performed without considerable input and advice from the people on the ground executing those activities (i.e., physicians, nurses, pharmacy, ancillary clinicians and unit clerks).

    Particularly with the proliferation of mobile clinical point of care applicationis, the hospital CIO is faced with significant challenges, e.g., what devices, how many, where to deploy, how to train clinicians, how to support multiple applications on the wireless infrastructure and most importantly, how to anticipate and manage workflow changes. What is best from logistical and financial standpoints?

    Workflow must change with any new technology. It is most important.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>