How best to integrate med device data

Once obscure research tools, medical devices today are nearly ubiquitous in healthcare. An acutely ill patient, for example, can be monitored by dozens of medical devices, creating thousands of data points daily.

Historically, medical device data has been isolated or trapped in silos. It has unique communication protocols, physical connections, update rates and terminology. Key advances have put medical devices on the precipice of an evolutionary leap from charting and documentation to active patient monitoring and intervention.

One area of increasing risk is managing patients on opioids, particularly those patients who are afflicted with obstructive sleep apnea. Continuous monitoring of these patients has become a growing recommendation.

For hospitals and health systems, especially those breaking ground on a net-new medical device integration (MDI) program, the formidable task list requires the input and expertise of a project team. Ideally this should be comprised of leadership from myriad departments, including IT, networking, facilities, clinical staff and biomedical engineering.

This team will be responsible for every phase of deployment: acquisition, rollout, implementation and transition to live operations. The team will determine the hospital’s objectives and integration goals, as well as the devices, device types, business and clinical requirements, risk management concerns, patient safety goals and costs.

Tracked through multivariate, temporally-trended information, clinicians can apply historical and real-time data to facilitate clinical decision-making that is based upon changing and evolving trends.

This reinforces the need to have a comprehensive and forward-looking approach to selecting an MDI and middleware provider that can support the technical and clinical needs of a healthcare organization.

Middleware can be leveraged to pull data from medical devices and combine it with other data in medical records to create a more holistic and complete picture of a current patient’s state. Combining analysis with real-time data at the point of collection creates a powerful tool for prediction and decision support.

This raises critical questions that pertain to patient safety and the level of risk assumed by the hospital. How do patient documentation needs differ from real-time patient intervention needs? What is real-time data flow, and what is not?

Because data used for real-time intervention, such as clinical alarms, impacts patient safety, any delay in its delivery to correct individuals can have deleterious effects. Thus, it is important to understand the implications of requirements on data delivery latency, response and integrity.

The capabilities of various middleware solutions overlap, but there are basic architectural and regulatory considerations that must be considered outside of the specifics of software or physical access to data.

The ability to retrieve data at variable rates requires technical capability on the part of the middleware vendor, but it also requires regulatory capabilities in the form of Food and Drug Administration clearances.

The ability to extract data and translate it to a system of record is part of what the FDA considers to be a medical device data system (MDDS). The FDA requires MDDS solutions carry an FDA Class I status for general documentation. Alarms and active patient monitoring are beyond the scope of standard MDDS capabilities. According to the rule, if an MDDS is used beyond its intended use, this shifts the burden for oversight and compliance to hospitals. The hospital is then required to test and demonstrate the efficacy of the system, which effectively classifies the hospital system as a medical device manufacturer.

A Class II clearance with indications for use that support active patient monitoring and alarm communication can be achieved by a middleware vendor. The middleware vendor demonstrates from a risk perspective that it has successfully mitigated the hazards of the data (relative to assured delivery, latency, data integrity) for use in live interventions. This is consistent with alarm communication or creation of new alerts or notifications 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 active patient data for intervention purposes from collection point to delivery point. These technical capabilities include:

Assured delivery of data. To support active patient monitoring and verified delivery of data, the communication pathway from the bedside medical device to the recipient must guarantee delivery of the data within a specified time frame. In order to guarantee delivery, the system must continuously monitor that communication pathway and report if and when data is impeded or otherwise delayed beyond a maximum acceptable limit on latency and throughput.

Two-way communication of data. This capability ensures data delivery and verification do not impede or otherwise interfere with the medical device operation. This is of particular importance when exploring external control of medical devices or when alarm data is communicated per active patient monitoring.

Ensuring data integrity. In middleware systems cleared for active patient monitoring, the ability to transform the data is possible. Algorithms for performing transformations, calculation of tertiary results, and otherwise interpreting data must pass muster and validate all intended operational scenarios of the medical device, including failure modes. Data security, hostile attacks on data, medical devices and denial of service, and ransomware all have the potential to impact data integrity. These requirements must be fleshed out through specific scenarios and validated through testing.