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.

Read More

Barcoding and Patient Context

One of the most important areas of connectivity, and one that frequently does not receive the attention it deserves, is establishing and maintaining patient context. Historically, connected devices identified data by location – tagging data with a bed or even port number – rather than the actual patient name or ID. Because patients are frequently moved during an episode of care – not to mention ambulatory – data that is only tagged with a location presents risks of misidentification. In an effort to improve positive patient identification, data is increasingly tagged with a patient identifier.

Besides patient safety, patient context also greatly impacts medical device workflow. (Medical device connectivity is workflow automation through the integration of medical devices and information systems.) How a vendor implements patient context can have a big impact on usability and customer acceptance.

Patient context requirements can vary, based on the type of medical device in question. What is not variable is the requirement to reliably establish and maintain context. Mobile applications (like smart pumps or patient monitoring) where the device may go in and out of network coverage while constantly in use present special challenges. This compares to a fixed or portable medical device, like a dialysis machine or diagnostic ultrasound, with an episodic use case during which neither the device or patient is moved. Another variable is whether the application is life-critical. Continuous patient monitoring and many alarms (e.g., smart pumps and ventilators) are life-critical applications with a higher threshold of requirements. This contrasts with connectivity for documentation like with point of care testing or spot vital signs capture. In all cases though, patient context must be safe and reliable. The above issues just help define how many hoops you have to jump through to be safe and reliable.

Read More

Hospira Acquires Sculptor

Today Hospira announced they have acquired Sculptor Developmental Technologies (press release). A subsidiary of St. Clair Health Corporation, Sculptor was a software engineering company formed by St. Clair Hospital in 1993 to create solutions that St. Clair couldn’t buy from vendors. Sculptor’s solutions include a barcode meds administration system, an enterprise report print management application, advanced printing for Eclipsys, fax distribution software and similar tools. Sculptor has an installed base of more than 125 hospitals in North America. The deal includes St. Clair Hospital serving as a development and test site for Hospira medication management products.

Obligatory chest thumping:

“This acquisition brings together two leaders in healthcare IT — Hospira has led the industry in barcoding medications and infusion technology; and St. Clair, through Sculptor, was the first hospital in the country to combine barcoding and RFID in a single mobile device for the real-time workflow needs of clinical staff,” said Richard Schaeffer, vice president and chief information officer, St. Clair Hospital.

Note the emphasis on workflow. Given the greater experience of Sculptor, this may end up being a better acquisition for Hospira than CareFusion was for Cardinal.

Read More

Drivers and Barriers in Medical Connectivity


I’ve been wrapping up a pretty big project and so posting has been light this week. I do have some things that caught my eye this week that I will post later this weekend. Earlier this week I was asked:

  • what connectivity capabilies are being built into medical devices now,
  • what factors are driving these changes, and
  • what barriers in your area(s), what are they?

The biggest trends driving what I call medical connectivity are EMR integration, workflow automation and alarm notification.

The basic capabilities required to meet the above include:

  • the ability to establish patient context, acquire and transmit data from the medical device
  • a server to capture, store, queue and transmit data (optionally, an HL7 interface for EMR integration, and logic to analyze data)
  • client applications (usually served up by the server) to enter, review and edit patient data.
Read More

Wireless IV Pump Market Overview

In Glaser and Cooper’s HIMSS session, “Clinical Engineering and IT — Partners for Patient Safety and Technology Effectiveness”, one of their examples of CE/IT convergence was the smart connected IV pump.  They established the terms Type I for pumps that contain a drug library or formulary, and Type II for pumps with Automated Drug Recognition.  They described Type II pumps as supporting right drug, right patient, and right drug library menu pick.  Future Type II features were identified as patient/bag matching, caregiver identification, and order settings pushed to the pump. You can read the HIMSS wireless pump posts below to see where the various vendors fall along this continuum.

Let me suggest a feature set for a Type III pump classification: remote primary alarm notification, alarm management and pump control provided directly to the caregiver, and tight CIS integration providing CIS generated alerts and remote device control (driven by Order Entry and CIS alerts).

Hospitals are required to use policies, procedures, and staffing levels based on the primary alarm notification of medical devices on their units.  Regardless of how “cool” secondary alarm notification features are, hospitals cannot depend on them.  Spending time and money to implement secondary alarm features is like wearing a belt with suspenders. Providing alarm and device management features to a nurse carried device could significantly improve patient safety, outcomes and satisfaction.  This remote capability means reducing missed alarms, increasing the ability to distinguish nuisance alarms, silencing alarms more quickly, and accessing pump status for all their patients at any time — from any location.  Besides the obvious safety impact, better alarm management means fewer alarms disturbing patients, especially at night.  This remote capability should also improve staff productivity.

Type I and II pumps require mission critical connectivity.  Occasional service interruptions of a few minutes are not critical. Type III features require life critical connectivity for primary alarm notification.  Life critical connectivity has big implications on server architecture and network design.  The life critical requirements for pumps are less than they are for continuous monitoring (there is no continuous waveform), unless your pump also does continuous monitoring.  Regardless, vendors must develop risk analysis based performance metrics for alarm delivery times, and then design a system to meet those requirements.

As pump technology evolves, pumps start to more closely fit the model for patient monitoring systems.  Many of the same questions arise when assessing needs and qualifying vendors.  Identifying requirements, while not always intuitively obvious, is not too difficult a task.  Qualifying vendors who meet those requirements, all in different ways, is more of a challenge.  Using your crystal ball to determine future requirements and care delivery models is also difficult.

All of this raises some interesting questions about core competency.  There is a vendor side of this CE/IT convergence that mirrors the convergence in the hospital.  Medical device vendors have certain core competencies: embedded software, electrical and mechanical engineering, manufacturing and assembly, working within a rigorous regulatory environment, and device service and support. Medical software vendors also have their core competencies: application software, software architecture, networking, implementation and configuration, system service and support.  As medical device vendors continue to move towards IT, they must make strategic decisions about what core competencies they want to “own” and which to buy — none can afford the time and money to build all the necessary competencies.  These choices is driven by competitive strategy, creating barriers to entry, time to market and cost.  The winners in this space will be the vendors with the best strategy and the best execution.

Read More