Medical device manufacturers in markets that have managed to resist creating connectivity solutions are facing increased pressure from providers adopting EMRs. I mean, what’s the use of automating the EMR if users have to write down numbers read from medical device displays and then manually type them into the EMR? That’s certainly not “automation.” This feature is already a required and necessary feature in some device markets, and rapidly becoming a necessity in many other device markets.
Manufacturers in this situation (needing an interface to EMRs for clinical documentation) often come to me with a plethora of questions. Before we get started, let’s frame the discussion. In this post you will be introduced to a framework for clinical documentation connectivity. I do not get into details on product design or features. Rather we look at a basic framework and external factors that come to bare on any manufacturer contemplating a connectivity feature for their products. What follows is a sketched in foundation or starting point for manufacturers to use to plan for and implement what is probably the most basic connectivity application.
Let’s run through the basics.
What are the basic components of a clinical documentation solution for a medical device?Read More
Yours truly was quoted in an article in FDC Reports’ newsletter The Gray Sheet (subscription only) last week about connectivity. The story was inspired by a comment from Bill Crounse, the director of Worldwide Health at Microsoft, during the World Healthcare Innovation and Technology Congress held in Washington, D.C., earlier this month. He said, “”I no longer believe that technology is really the issue that prevents us from getting things done. We have the technology … We’ve cracked the code on things like mobility and wireless devices and broadband. The remaining barriers are really all-around barriers to adoption.”
The story provides an overview of connectivity in both acute care and remote monitoring, from both vendor and customer perspectives. The story closes with this observation:
“The medical device companies are becoming chimeras, where they’re part IT company, and they’re part embedded system company,” Gee noted. But, as long as their mindset remains that of an embedded system company trying to protect the “black box” of proprietary system design, it will be difficult to move forward, he said.
Jason Williams expresses a similar lament about the lack of connectivity in a great post on NeoTool’s blog titled, Bridging the Device Divide. In a comment to the post, standards guru Todd Cooper observes:
Bottom line is that medical device vendors make more money with either proprietary connectivity or strategic partnerships, and end users – provider orgs – do not demand open standards-based connectivity. It is often called out in RFPs – but gets dropped in the decision making process. K-P [Kaiser Permanente] is one of the few org’s drawing a line in the sand on PnP med dev connectivity. “Collaborative partnerships” are the status quo and have been the basis of controlling and limiting device connectivity both at the PoC and to the enterprise.
Todd’s referring to Kaiser’s new purchase contract language that specifies medical device vendor responsibilities for supporting connectivity. You can read an except of the contract language in this post. Rumor has it that Philips has recently declined to meet some of those requirements; it will be interesting see if Kaiser sticks to their guns and drops Philips as their patient monitoring vendor going forward.
In Jason’s blog post he quotes Robert Nadler who says, “…our business is building medical devices, not EMR solutions.” I don’t think medical device vendors will have the luxury of maintaining that point of view for much longer. I spoke with David Freeman and Munesh Makhija of GE Healthcare’s patient monitoring group a few weeks ago. They attended the CMEF and saw an exhibit floor filled with vendors who are doing the same color displays with waveforms that GE is doing – at 30% lower cost. Rather than playing the manufacturing cost game, GE is looking to software to add clinical value and differentiate from low price competitors. Philips seems to be taking a similar approach with their acquisitions of Emergin and VisICU.
The days of staying in that nice familiar embedded device comfort zone are limited. This has always been the case as connectivity transforms medical device product categories. Remember E for M? They were once the market leader in cath lab recorders. They too decided they didn’t want to do software. They contrast nicely with Marquette Electronics who saw connectivity as an opportunity and redefined the product category – driving E for M out of business and capturing a major share of the cath lab market. (Another great example of leveraging connectivity is Alaris.)
You can access both Jason’s and Bob’s excellent blogs from the Blog Roll in the right hand column of this web page.Read More
Great news in Healthcare IT News:
LiveData has been awarded a $70,000 Small Business Innovation grant in order to
develop a plug-and-play feature to implement standards for OR workflow
and medical device interoperability. The plug-and-play feature will enable devices to work together, to
create safety interlocks, and help ensure that clinicians make
decisions based upon all available information.
LiveData’s provides data integration, mostly in the surgical suite. Unlike video systems from Stryker and many others, LiveData combines real time medical device data with IT systems (EMR, PACS, etc.) and video.
LiveData will team with Draper Labs, Massachusetts General Hospital and CIMIT to do feasibility work in the medical device plug-and-play architecture called the Integrated Clinical Environment or ICE. LiveData will provide the software foundation for the grant project.Read More
Yours truly was quoted in a HealthLeaders technology story about, you guessed it, medical device connectivity.
Information technology consultant Tim Gee has a nontechnical description of the current state of connecting medical devices to clinical information systems: “It’s a mess.” Not that direct data capture from medical devices is impossible; some hospitals have been exporting data from devices into clinical information systems for years. But as Gee and other experts point out, the effort can be so confounding that many hospitals don’t even try. Even in highly automated inpatient settings, a common method of data capture from the plethora of monitors, pumps and ventilators is good old pen and paper. Someone, often a nurse, writes down the value and either logs it on paper or re-enters the data online.
The writer, Gary Baldwin, must have caught me on a bad day, it seems I couldn’t say anything nice about anyone.
Trinity exemplifies the industry’s challenge in capturing data directly from medical devices. The health system maintains more than 2,000 physiologic monitors and 9,750 IV pumps, says Kini, adding that the equipment comes from at least five different manufacturers. In this scenario, the key problem, Gee contends, is the absence of industry standards for how data is formatted and exported from the devices. Even devices from the same manufacturer may vary, he says. “Unless a device has the identical model number, the protocol may change,” he says. “To the medical device vendor, their product is the center of the universe. The idea of connectivity is one that vendors have to be pushed kicking and screaming into by their customers.”Hospitals have been willing accomplices up to now, Gee acknowledges. “Most hospital IT departments don’t think about data capture from devices,” he says. “They suffer from the same perspective vendors have. The IT department figures nurses will just type in the data.”
Gary also interviews Julian Goldman, who lends his more soothing perspective to the challenges of connectivity.
Be sure to read the whole thing.Read More
Getting device data into an EMR or departmental information system is a common objective for medical device connectivity. Manual data capture is fraught with delays, errors and lost data — replacing the paper chart with an EMR only makes manual problems worse. Proper device data acquisition can be a critical factor in EMR adoption.
Improved alarm notification is another driver for medical device connectivity. In 2003 JCAHO included “clinical alarm systems ” into their National Patient Safety Goals. Vendor standardization does not help here; no single vendor makes patient monitors, pumps and ventilators. The environment here is complex because the workflow includes not just a myriad of devices, but nurse call, phones and even overhead pages.
All three of these applications must connect to the same sets of medical devices. However, all three acquire their data in different ways. And of course, the data required is beyond any one vendor’s ability to serve up a “single vendor solution.” What to do? A series of point solutions for each of these three applications (as they’re adopted) will create a huge complex mess.
Workflow automation is the primary driver for medical device integration. The goals of connectivity can be increased productivity and/or patient safety. Recent studies highlight the need for careful planning and execution when adopting connected devices. Even though you may be focusing on a particular activity or device (like vital signs collection or smart infusion pumps), it’s best to go beyond the immediate device and plan your project from the perspective of the clinical area where the solution will be used. Planning must take into account users, workflows, the environment, target information systems and both short and long term goals.
Non-ICU patient care areas have spot vital signs monitors, continuous monitors, and infusion pumps, wound suction and feeding pumps — not to mention meds delivery, nurse call and wireless phones. Caregivers have to use all these devices and most everything they’re connected to (i.e., EMRs and other clinical systems). The goal is to create an efficient work environment that maximizes patient safety, task duplication and complexity. Context is critical; solutions must fit and be adopted in their environments as planned. Look at related workflows and other devices used by the same staff or with the same patients. How will device connectivity workflow integrate with planned IT workflow? Do both device and IT workflows improve efficiency and safety?
Regulated medical devices have a formal “intended use” defined by the vendor and approved by the FDA. Care must be taken to evaluate product features relative to the intended use to avoid liability, this is especially important in alarm notification. Hospitals must staff and manage units based on the primary alarm notification method described in the device’s 510k. You cannot staff or manage patient care areas based on secondary alarm notification features because they do not support the intended use of the device.
First generation alarm notification products using pagers lack closed-loop feedback and are inherently unsafe. There is a lot of change coming soon to this area. Baxter is the first vendor to provide primary alarm notification in a nurse-carried device — too bad it just works with pumps.
Think long term; nothing is worse than spending a bunch of money only to have to replace your connectivity solution because it doesn’t support the next set of devices or applications you want to integrate. Vital signs captured into your EMR may be the issue today, but what about continuous monitoring (telemetry) and IV pumps? How is medical device use going to change over time? How are care models going to change the workflow and devices found in patient care areas in the future?
Vendor selection is also critical. Do you go third party or stick with a device vendor’s proprietary point solution? How many vendors will your integration project require; do the resulting workflows make sense to users? Will third party solutions integrate with future device vendor’s products and support new features? Does the vendor really have a core competency in WLANs and enterprise class servers? Will your initial deployment scale enterprise wide? How will you handle devices that come from multiple vendors like pumps, vents and monitors?
Infrastructure is where your medical devices and information systems meet. Most device-based systems are currently deployed as private networks. Private networks can ensure reliability and performance, and can protect vulnerable devices from computer viruses and worms. Over time more pervasive deployment and greater levels of integration will make separate networks problematic. Network requirements can differ greatly. Due to the highly mobile nature of health care (outside of the ICU), most medical devices should be wirelessly enabled.
Real time surveillance or any primary alarm notification requires high availability with a very low latency network. Beware; a medical device connectivity solution with one set of features can have very different network requirements from a similar system with more advanced features. Let’s use a couple of currently available smart pump solutions as an example. The first has no patient context at the device, an anonymous patient database, and secondary alarm notification. The second solution supports patient context at the device, a patient identifiable database, and primary alarm notification. Both systems include wireless pumps, a server and wireless PDAs. The first system can run on a mission-critical infrastructure exposed to the normal variations of hospital network performance, the second requires a high availability low latency life-critical infrastructure — the difference between the two can represent a significant hidden cost in both hardware and staff (8×5 vs. 24×7).
Planning for a successful outcome entails interviewing users, syncing up with current and planned patient care models, evaluating existing and planed devices, digging into IT infrastructure, systems and plans, and looking over the short and long term. The result should be a needs assessment and strategic plan with phased implementation. Common sense (or at least your CFO) may demand a business case demonstrating return on investment.
The consequences for poor planning can be unrealized benefits, staff frustration (or outright obstruction), schedule slips, and sometimes significant unanticipated costs.Read More