EMRs, Medical Device Connectivity and Beyond
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.
Finally, remote-care systems like VisICU’s eICU or Cerner’s Remote ICU need to acquire medical device data for display and analysis.
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.
