Market Trends Series #2: Patient Safety

This is the second post as part of an ongoing series that discusses the market trends that are affecting the evolution of medical device connectivity (MDC) technology. I received some good comments from my previous post – please consider sharing your thoughts, ideas, and experiences.

The second trend I’d like to discuss is the shift towards patient safety as one of the key market drivers for connectivity. It is probably not news to anyone that patient safety has become one of the key drivers for many healthcare IT initiatives. But what is the relationship between patient safety and MDC? Ever since the often referenced IOM report, To Err is Human: Building A Safer Health System, hospitals and vendors alike have increased their focus on driving towards significant reductions in medical errors. The industry as a whole has made great strides, but still lots of work remains.

With device connectivity, my experience has been that for at least the past 15+ years, the key driver has been making the nurse more efficient by eliminating the manual transcription of device data into the patient’s chart. One of the related benefits is a more come complete and legible patient record. However, one could argue that the more legible patient record could be achieved if the vital signs from medical devices were simply typed into the charting application manually (something that many hospitals are actually doing today). So I believe that the nursing efficiency argument holds as the primary driver – but that is starting to be challenged by the focus on patient safety as it relates to connectivity.

Up to now, bedside patient monitors have been the priority medical device driver for connectivity. Multi-parameter patient monitors produce approximately three quarters of the total number of device parameters that need to be charted on a periodic basis. Other devices that make up the remaining one quarter of the data set includes ventilators, anesthesia machines (of course in the OR environment), standalone pulse oximeters, IV pumps, standalone cardiac output devices, and even beds (weight, angle of inclination, rail positions, etc.)  However with the increased drive for patient safety in recent years, we are starting to see hospitals discuss requirements for smart IV pumps to be interfaced as a priority over other devices.

One of the reasons for this shift is likely due to the high number of visible errors involved with high profile infused drugs such as Heparin.  Simply put, hospitals are focusing more on those devices that are directly related to patient safety and errors and IV pumps are often in the mix. Hospitals have been migrating to smart IV pump technology. One key market indicator is the rapid growth of smart pumps being purchased – now over 60% of US hospitals have made the switch to smart pumps.  For details – refer to this link.

Even though smart pumps are proliferating, challenges remain when it comes to the integration of smart pump data to the EMR and smart pump alarms to alarm management and notification systems. In reality, there are very few instances of IV pump connectivity to EMR or alarm systems. Not only is there the issue related to patient ID and association (for detailed discussion see this link). There are also the issues related to the unique nature of the data produced by an IV pump. But it is a bit ironic that just as patient safety is driving the adoption of smart pumps, the need to ensure safety is one of the factors holding back the end to end integration to the EMR. Vendors have been very cautious on all sides when determining how to integrate pump data. The stakes are high if the integration does not work 100% – patient safety is at risk.

What really needs to be charted into the EMR from an IV pump is the total volume infused (TVI), the infusion rate, and the drug dose. The problem is that EMR vendors have been working on how to accept automated data from pumps – but some EMR’s are not there yet.

One complexity is related to the fact that the EMR cannot just import the data values directly from the pump devices. The EMR needs to perform a calculation of volume infused taking into account what has already been infused over the last charting intervals. Also, don’t forget that most patients are infused by more than pump device at a time, especially in the ICU.

Another important challenge is related to bi-directional communication with an IV pump. Data must be able to flow seamlessly from the IV pump to the EMR for documentation purposes. But to really reduce administration errors and impact patient safety at the bedside, automating the programming of the pump is required. The order for the infused medication or fluid needs to be transmitted to the right pump at the bedside – and this requires a capability to communicate bi-directionally with the pump device. The workflow challenge for the nurse at the bedside is ensuring you have the right patient, the right pump, and that the order matches the patient before it gets to the pump.

I believe that the focus on patient safety will continue to drive vendors towards providing connectivity solutions that solve these types of complex problems.  IV pump connectivity and integration are the next big frontier in MDC. What do you think? Whether you are a care provider or a vendor – agree or disagree. Do you think I missed anything?



  1. Pete McMillan

    I do not support end-to-end integration of pumps to EMR. This would require greatly increasing the complexity of the pumps (as if they were not complex enough already), complicating their user interfaces, increasing the amount of interaction required, and implementing specific workflows as you mentioned. On EMR side, it requires interfaces that are custom built to suit different pump vendors.

    I would advocate somewhat “dumb” pumps that connect to a proprietary gateway supplied by the manufacturer. The Gateway would maintain mapping of the pump to patient (barcode? proximity sensors?), maintain a database of medications infused, and perform running calculations of volumes infused. The gateway would then forward the data to the EMR. This would save the cost and effort of updating custom built interfaces in the EMR everytime a pump vendor changes a part of the protocol, or building a new custom component in to the EMR when we buy a different brand of pumps.

    The ideal solution however, is to do away with even the gateways. The holy grail would be if the pumps could be interfaced to the patient monitor (monitoring vendors – don’t get excited. I am talking about real interfacing here, not the feeble effort you currently make to get a tick in the tender compliance. Read on), and if that interface could be bi-directional, and if the patient monitor is intelligent enough to understand the data (rather than just relay) and calculate the running totals etc. Currently, the patient monitor is the one that can be relied upon to maintain the patient context at the bedside. Through the hypothetical bi-directional interface, it could supply the patient context to the pump. Users could select the medications from a list on the patient monitor, select rates and assign them to the pumps. The patient monitor receives data from the attached pumps, processes them and forwards them to EMR. Monitors could also relay pump alarms using their current paging/sms interfaces.

    With that scenario, the workflow becomes much simpler and interfacing pump data to EMR would be less of a headache. Users would only need to be familiar with the user interface of the monitor, not of each individual pump.

  2. Integration of pump data into the EMR is very important, but it certainly presents many challenges.

    As already mentioned association of the pump to the patient is a key issue, which is exacerbated by the trend (primarily in the US) to embrace wireless pumps. This drives the implementation towards using central pump gateways, making it even more difficult to get the data back to the patient monitor (if this is what you want to do) and implementing patient association since you have no idea where the pump actually is located.

    Concerning the use of patient monitors as bedside data collection hubs… This implies that a patient monitor is at the bedside whenever you want to do electronic data collection – and that is not always true. I am pretty sure that there are many patients in the hospital that have IV pumps attached to them but who are on telemetry monitors or are not attached to a patient monitor at all. However the general concept of having something intelligent at the bedside providing a better user interface for data collection than a 2-line LCD display on a pump seems to make sense.

    I do feel that the pump system (whether it is the device or the gateway) should be responsible for calculating and delivering the key parameters such as volume infused rather than the consumer of the data in order to minimize the probability of calculation errors.

  3. Pete McMillan

    @Ken Fuchs:

    ” I am pretty sure that there are many patients in the hospital that have IV pumps attached to them but who are on telemetry monitors or are not attached to a patient monitor at all…”

    Well, I am pretty sure there aren’t. Is it possible that you are confusing infusion pumps with PCA pumps?

    Infusion pumps are used for drugs where very precise dosing is necessary. And the reason why very precise dosing is recommended for such drugs is because they often have unintended effects at high plasma levels, or the required effect is not achieved at low plasma levels (eg. inotropes). This means, patients receiving such infusions need to be monitored. Such patients would hardly be ambulatory. In any case, it is hard to imagine a patient walking around with a telemetry transceiver and a pump stack.

  4. In response to both Pete and Ken’s comments – first of all, thanks for commenting.

    I believe there are a couple of threads being discussed here. My original comments about end-to-end integration of pumps to the EMR — was a general comment about IV pump integration and did not imply how the connectivity to the EMR is established. With the growth of wireless smart pumps in the market, the only viable mechanism for integration to the EMR is via the vendor-specific pump gateway using a protocol such as HL7. However, in reality almost all implementations of IV pump integration to an EMR has been via a serial connection form the pump to a bedside concentrator or term server. The main reason is that the physical serial connection establishes the location of the pump via a mapping of the term server to the bed or room location. Data from the pump can then be sent to the EMR and the patient ID lookup can be accomplished in the EMR application.

    In response to Pete’s comment – “The Gateway would maintain mapping of the pump to patient (barcode? proximity sensors?)” – so far, there has been few if any workable solutions for accomplishing this association at the bedside. Yes, the pump gateway can maintain the PID association mapping – but the association has to physically be performed at the patient’s bedside.
    Another thread being discussed here is using the patient monitor as the bedside device integration hub. For many years this has been one of the solutions available for integrating devices such as ventilators and anesthesia machines. This has worked very well for all of the big patient monitoring vendors, but has left many hospitals with long-standing issues to deal with after they have gone down this path. One of the biggest flaws with this a strategy for hospitals is that sometimes the hospital does not have the same patient monitoring vendor at all beds. If that is the case, then the hospital is left dealing with all of the complexity and supporting device integration solutions from multiple vendors. In addition, from direct experience, often there are not device drivers available from the monitoring vendor or the drivers have not been kept up to date with support for the latest parameters a device can generate.

    To address Ken’s point about patient’s that are on IV pumps that are not monitored continuously or with a conventional multi-parameter patient monitor – yes, he is correct. There are many situations where patients are not in a critical condition but still have an IV pump for antibiotics or fluids. Many of these patients are on general medical surgical floors and these rooms definitely do not have traditional patient monitors (that can be used as a bedside device integration hub).

    Lastly, the IV pump system (device or the vendor gateway) should be responsible for calculating and delivering the key parameters such as volume to be infused. However, the EMR needs to be responsible for recording what has actually been infused into the patient and documenting this requires calculations to be made in the EMR application. The reason is that different care units and patient acuity levels drive different charting intervals in the EMR. One unit may be charting at q15 minutes and another may be charting at q1hour. Therefore, the EMR must calculate what volume was actually infused into the patient over the last charting interval. Regardless, there is quite a bit of complexity to deal with when it comes to IV pumps. And the complexity is on all sides and will require cooperative efforts to achieve end to end integration.

  5. The patient record is an integral part of the health care system to document the care the providers and their ancillary staff provide to the patient. In spite of the recent technological advances in hardware and software applications for computers, the patient record is predominantly paper, even in high technology environments such as the intensive care unit (ICU). Even with ICUs that have computerized or electronic medical records (EMR), no system exists today that supports a totally integrated electronic medical record. The lack of a totally integrated EMR makes it difficult to track the patients’ care from the ambulatory to the inpatient setting and prevents improved medical decision making, which is necessary for decision support and critical pathways.


  1. Market Trends Series #2: Patient Safety | Medical Alert Devices - [...] (more…) [...]

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=""> <s> <strike> <strong>