March 2016

Middleware Matters
By John Zaleski, PhD, CAP, CPHIMS
For The Record
Vol. 28 No. 3 P. 28

Absent universal device standardization, hospitals require middleware. However, critical distinctions will define how those data can be used.

The health care industry is a long way from realizing universal interoperability of medical devices. Federal guidelines and reforms, technological advances, industry societies, and standards organizations, as well as various industry and business requirements, have motivated some manufacturers to develop interfaces. Certain vendors have gone even further and aligned output on frameworks such as the Integrating the Healthcare Enterprise Patient Care Device Technical Framework. Nevertheless, many medical devices still require that their proprietary formats be translated to something more standardized and common to the HIT system, both in semantics and messaging format.

Despite progress over the last 10 years, especially in the area of standard application-layer communication, it's unlikely that we'll see medical devices that universally operate and conform to a data communication standard as easily and freely as plugging in a USB anytime in the next decade.

Medical device data system (MDDS) middleware vendors rely on device drivers that use proprietary device query-response polling mechanisms to translate data from the islands of medical devices that do not conform to more universally accepted messaging standards. The MDDS middleware will continue to be necessary to pull data from certain classes of medical devices using the vendor's specification, then translate and communicate them to an EHR, data warehouse, or other information system to support use cases such as clinical charting, clinical decision support, and research.

Data from medical devices are combined with other data in the patient record, such as laboratory information, medications, patient demographics and registration, radiology images, clinical notes, and financial and insurance information to create a more holistic and complete picture of the patient's state. Because data drawn from medical devices can be more automated, translation and transcription errors are typically nonissues. Therefore, these data are usually more accurate and reliable in that they do not require interpretation. Furthermore, data from medical devices can be obtained at higher frequency and regular intervals, ensuring densely populated and complete measurements from patients over time.

The breadth and scope of MDDS middleware's capabilities helps hospitals, health systems, and other provider organizations uncover ways to leverage the data that flow from a device into a record system. The use of the data to improve patient care management and clinical decision-making comes immediately to mind, but those only scratch the surface of what's possible.

And while the capabilities of various middleware products overlap, there are key aspects of note for any enterprise embarking on deployment of MDDS middleware to capture medical device data for operational charting and research.

Minimal Capabilities
Minimally, MDDS middleware must retrieve episodic data from a medical device and translate it to a standard format. Additionally, middleware should be able to retrieve data at variable speeds to meet the requirements of various clinical operational settings (eg, operating rooms vs ICUs vs medical-surgical units).

Clinical charting intervals normally vary from 30 seconds to several hours based on clinical requirements. Higher-frequency, subsecond data include waveform measurements from physiologic monitors, pressure-volume loops from mechanical ventilators, and alarm-type data issued from medical devices. The use of data for display and analysis, predictive analytics, and to process data collected at the point of care to create new information also drives data collection rates.

While the ability to retrieve data at variable rates, including at the subseconds level, calls for technical capability on the part of the middleware vendor, it also requires regulatory capabilities in the form of FDA clearances confirming that the middleware has mitigated the risk associated with communicating higher-frequency data for alarms and analysis, including patient monitoring and intervention.

A Word on FDA Clearance
In the HIT space, FDA 510(k) clearance governs medical device connectivity and communication to MDDSs. MDDSs intended for active monitoring, as opposed to charting, have demonstrated the capability to reliably communicate data and alarms that are required for patient assessment and intervention.

The ability to extract data and translate it to a system of record is part of what the FDA considers to be an MDDS. The FDA requires that MDDS solutions carry an FDA Class I status for general documentation. Other aspects, such as alarms and active patient monitoring, are beyond the scope—transfer, storage, conversion, and display—of standard MDDS capabilities. According to the rule, if an MDDS is employed beyond its intended use, the burden for oversight and compliance shifts to the hospital, which will subsequently be classified as a manufacturer.

A Class II clearance can be achieved by a middleware vendor that demonstrates, from a risk perspective, that it has successfully mitigated data hazards for use in live interventions, which would be consistent with alarm communication or the creation of new data from raw data collected from medical devices.

For a middleware vendor to claim clearance for active patient monitoring, it must have all the checks and balances in place to ensure the receipt and delivery of all active patient data for intervention purposes, from collection point (medical device) to delivery point (the clinician). Again, the ability to deliver on the timing and receipt of data necessary for interventions and active patient monitoring is an important distinction.

Advice for Hospitals
For hospitals and health systems implementing a medical device integration (MDI) program, especially those that are breaking ground on a net-new program, the first step is education. The formidable task list that comes with any MDI program requires the input and expertise of a project team, which ideally should comprise leadership from myriad departments, including IT, networking, facilities, clinical staff (physicians, nurses, respiratory therapists), and biomedical engineering.

Every phase of deployment, from acquisition and rollout to implementation and transitioning to live operations, falls under the team's jurisdiction. The team determines hospital objectives and integration goals, as well as the devices, device types, business and clinical requirements, risk management issues, patient safety goals, and budget.

The team also will identify the departments or units the integration will first impact. Big-bang enterprise integrations are not unprecedented, but a phased rollout in a single department or set of departments with the highest acuity, such as the surgical suite, allows more time and space for assessments, lessons to be learned, and best practices to be developed, which can be applied as the integration spreads to the rest of the organization.

One aspect of integration that is often overlooked is the value of clinical workflow, which can vary among hospitals and individual units. Workflow is a key component that should not be minimized because it will largely define how data are collected, and what and how they're displayed. Therefore, hospitals should incorporate clinical workflow as quickly and as early as possible in the process.

Universal medical devices standards won't happen overnight—although it has been interesting to note manufacturers' slow migration to a more standardized approach. Logistics and practicality rule the day in a world with steep costs in investment, development, acquisition, and regulation. This reinforces the need to have a comprehensive and forward-looking approach to selecting an MDI and middleware provider that can support the health care organization's technical and clinical needs.

— John Zaleski, PhD, CAP, CPHIMS, is executive vice president and chief informatics officer of Bernoulli, a leader in real-time connected health care.