User:Aloftsocial/Sandbox
Medical device connectivity is the integration of medical devices with information systems, which automates the workflow surrounding the medical device. This workflow automates data analysis or acquires and communicates data generated by devices to other information systems or users. Common workflows include:
- Admitting, discharge, and transfer functions;
- Managing patient context—which data goes with what patient and when;
- Routing data, such as nurse-to-patient assignments;
- Data export to other systems;
- Data analysis;
- Alarm and alert generation; and
- Message delivery and escalation.
First Examples
Some of the first examples of medical device connectivity were
Workflow automation at the point of care is also driving medical device connectivity. Many hospitals are looking to improve communications on nursing units and improve patient safety through better alarm notification[1]. This workflow automation entails interoperability between nurse call systems, communications systems, and medical devices to coordinate the delivery of care and respond better to significant events.
While the potential benefits of medical device connectivity are well-known, the best way to implement connectivity solutions are less clear. Challenges with connecting devices include legacy devices that were not designed with connectivity in mind. Some newer devices provide built-in network connectivity used with the vendor’s proprietary end-to-end connectivity system. There are also third-party solutions that offer very different approaches to connectivity.
Connectivity Methods
Medical devices currently targeted for connectivity include
Medical device connectivity requires a connection between the device and the target information systems. Legacy devices use a
With the exception of diagnostic imaging modalities and some clinical lab equipment, the data that comes out of medical devices is in a proprietary format. Devices with end-to-end connectivity systems aggregate data from devices at a server, which converts the data into a standard—typically
—and passes it on to another system. Devices that have only an RS-232 output must convert the serial interface to a network connection, where the data from multiple devices is aggregated in a server, which also converts the data into a standard for use by other systems.Efforts of the Integrating the Healthcare Enterprise patient care device workgroup, standards bodies like the Institute of Electrical and Electronics Engineers Inc 1073 workgroup, and HL7 are working to improve the plug-and-play capabilities of medical devices. Goldman’s MD PnP group is also driving connectivity with use case development and a new verification lab. But it will probably be years before medical devices like those mentioned above achieve the ease of connectivity currently enjoyed in radiology with digital imaging and communications in medicine.
Proprietary end-to-end vendor systems include a variety of “smart” infusion-pump systems, spot vital signs systems, and continuous patient-monitoring systems. Third-party vendors like Capsule Technologie (Andover, Mass) and Cain Medical,(London), offer connectivity to legacy devices with serial outputs; they convert proprietary serial protocols to HL7 and XML. Another group of third parties, represented by Sensitron (http://www.sensitron.com) and Care Fusion, acquire data from spot vital signs monitors using nurse-carried personal digital assistants (PDAs). A final group of third-party vendors provide enterprisewide connectivity and messaging infrastructures supporting medical devices; these companies include Emergin, GlobeStar Systems, and Ascom (also a wireless phone vendor). At the point of care, wireless communications vendors like SpectraLink, Vocera, and Ascom offer varying levels of workflow automation along with application programming interfaces to third-party connectivity solutions. Nurse call vendors are also getting into workflow automation with their own patient flow, messaging, and nurse-to-patient assignment software.[2]
Planning and Execution
Perhaps the most important part of connectivity planning and execution is needs assessment. Unlike many projects in health care, connectivity crosses multiple organizational silos in a hospital and must sync up multiple moving targets. These moving targets are changes that occur in care delivery methods, medical device upgrade and purchase plans, and information technology (IT). Any resulting solution must fit today’s environments and support future changes planned across overlapping areas. Even seemingly unrelated projects are interrelated, such as nurses carrying one particular PDA for spot vital signs capture and another PDA for the Baxter “smart” pump system, but perhaps in the future there will be an application that will allow both functions to perform on the same PDA.
Good planning for connectivity incorporates requirements from nursing, biomedical engineering, and IT into a series of road maps. Each roadmap starts with current requirements and captures planned clinical and operational changes into the future. A good time horizon would be one that equals the operating life your hospital expects from a new medical device. Each milestone on the road map needs an associated project description and list of requirements. If no one in your hospital can plan out as far as the estimated useful life of your medical devices, make sure constraints posed by keeping those devices are understood by all parties.
With the increased adoption of wireless medical devices, appoint an active and well-qualified radiofrequency safety officer[3] and include him or her in connectivity project teams. In addition to the usual registry and history of medical devices maintained by biomedical engineering, device network infrastructures and software versions should be fully documented. Connectivity road maps will force network design decisions that impact cost and patient safety. Biomedical engineering may also be represented during discussions involving physical plant changes ranging from electrical power, emergency preparedness, and renovation to new construction.
As medical device connectivity has evolved, administrative applications are giving way to those impacting patient care and safety. Systems have evolved from data gathering and export to alarm management. The future of applications lies in a connectivity application that will entail medical device interoperability. The future of medical device connectivity will decrease user errors and provide closed-loop systems to regulate the delivery of medications and fluids, improving patient safety and outcomes.[2]
Challenges
Today, patient care is more complex than ever before. Patient to nurse ratio is higher. Technological developments require nurses to learn more. Hospitals are rapidly requiring that all patient data be in the
When hospitals don’t have device connectivity, nurses are even more strained because they are spending more time documenting data, less time caring for patients. In the ICU the challenge is even greater because patients are connected to multiple medical devices and the nurse needs to chart more frequently. Manual transcription and entry into the EMR is simply not the best use of nursing time; especially when there is another option – medical device connectivity.
Medical device connectivity improves workflow because data from connected devices is automatically sent to the EMR. Device connectivity simply allows nurses to focus on what they do best – care for their patients. Device connectivity does more than just save nursing hours. It also:
- Increases staff productivity
- Eliminates medical transcription errors
- Leverages the existing EMR investment and
- Improves overall patient care and safety
Medical device connectivity simply helps nurses with the challenges they face today, and is essential to the care of their patients and has truly improved workflow.
With vendor-neutral device connectivity, it is a flexible and scalable design that eliminates the need for hospitals to have to set up an entirely new system whenever new devices are integrated or staffing changes occur.
History of Medical Device Connectivity
1970’s and 1980’s
Early systems evolved from research work performed in some of the large university teaching hospitals.[4] Eventually the market evolved from patient management systems (for example the HP Patient Data Management System or PDMS.) which were the first commercially available systems to provide any type of automated data capture between a medical device and a computerized system.
1992-94
Standalone or independent connectivity solutions — Early efforts started in 1992 with Hewlett-Packard’s CareVue(now Philips) using the HP CIS Gateway. Early ventilator interfaces were implemented with custom serial cabling pulled to each bedside to connect ventilators via serial home-run cables back to wiring closets. The HP CIS Gateway was the data consolidation point and an early version of HL7 (2.1) was used to interface to the CIS. Other vendors such as EMTEK, Clinicom , and CliniComp also developed similar capabilities in this timeframe. There were a handful of drivers written for only the most common mainstream ventilators. In the peri-operative market, most surgical/peri-operative CIS vendors leveraged the local PC platform for serial connections directly to a multiplexor card.
Patient monitoring-based solutions – In parallel to the standalone connectivity solutions, key patient monitoring vendors including HP, Marquette, SpaceLabs, and Siemens developed monitoring-centric connectivity. These early products were proprietary “plug-in” modules that connected the medical device serial ports to the patient monitor. In these deployments, the patient monitor became the central “hub” for data consolidation. Here is primary purpose of the interface was to display non-monitoring data such as ventilation parameters and waveforms in a correlated display along with the physiological monitoring data. Alarms are also processed via these types of connections and sent to the monitoring central station. However, these types of interfaces have somewhat diminished in value over time – mainly because ventilator devices now have very advanced graphical user interfaces (less of a clinical need to correlate device data on the monitoring display) and alarm management and directed notification systems (i.e. Emergin) are now mainstream products.
1996-98
Marquette Medical (now GE) released Octacomm [5] and Hewlett-Packard released HP DeviceLink and. Both of these products were based on an 8-port terminal server and this was the first instance of converting serial data to network (TCP/IP). Serial cabling included an identification module that provided the device type so that the correct device driver could be invoked. These solutions included a data aggregation server with an HL7 interface to the CIS application server. In this timeframe, McKesson DAS and others started to become popular but most of these solutions were still based on serial cabling end-to-end (and in some instances short haul modems). Around this same time, Capsule Technologie was founded in Paris, France.
2000-2003
As CIS applications started to become more pervasive, many vendors entered this market with various point solutions for medical device connectivity. But the two main methods continued to be either patient-monitor-centric or standalone solutions that leverage a terminal server/concentrator at the patient’s bedside. During this timeframe, products such as DeviceLink and Octacomm evolved into Philips DeviceLink II and GE Unity ID One notable change in the market during this period was the earliest release of intelligent IV pumps or Smart Pumps as they are referred to today. Smart IV pump devices are the result of pioneering work done by Nat Sims, MD and others at Mass General back in the 1987-1992 timeframe [6]. Alaris Medical was the first commercial vendor to use this “smart” technology. As these devices started to gain traction in the market, interfacing to CIS/EMR’s started to become a core requirement. This requirement started to challenge the strategies of the large incumbent vendors – mainly the patient monitoring companies. The main challenge to their strategy became a question of how to best connect the smart pumps to the CIS/EMR. Connecting IV pumps to the monitor did not make any sense either clinically or from a cost/complexity perspective.
2004-present
As markets typically evolve, in this timeframe some vendors disappeared or merged into larger companies and new companies entered this market. Wireless (802.11/WiFi) and mobility have created new challenges. The market started to realize that serial cabling is messy and cumbersome from both an aesthetics and clinical workflow perspective. In addition, location-based “tagging” of the data is starting to become more problematic. Mapping data to a bed label or room number worked when the medical devices remained fixed and hardwired – but more and more devices are now enabled with WiFi and as a result are very mobile.
New challenges (and opportunities) are: (1) in the area of eliminating all serial cabling via wireless enablement or via the device vendor providing an embedded wireless feature and (2) in associating the devices to a verified patient identifier.[7]
References
- ^ Impact of clinical alarms on patient safety.
- ^ a b Plug and pray? By Tim Gee 24x7 Magazine
- ^ J. Scot Mackeil’s September Soapbox in 24x7 Magazine
- ^ W.E. Hammond Patient management systems: the early years
- ^ Marquette solves medical industry's local device connectivity issues Business Wire, Jan 21, 1997
- ^ Ellen Kinnealey, BSN; Gayle Fishman, BSN, MBA; Nathaniel Sims, MD; Jeffrey Cooper; PhD; Harold DeMonaco, MS Infusion Pumps with “Drug Libraries” at The Point of Care – A Solution for Safer Drug Delivery
- ^ Barcoding and Patient Context