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.