Historically, medical device data has been isolated, trapped in silos, each having unique communication protocols, physical connections, update rates, and terminology, but key advances have put medical devices on the precipice of an evolutionary leap from charting and documentation to active patient monitoring and intervention.
Tracked through multivariate, temporally trended information, clinicians can apply historical and real-time data to facilitate real-time clinical decision-making that is based upon changing and evolving trends.
The healthcare industry is a long way from realizing universal interoperability of medical devices. Though 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, many medical devices still require that their proprietary formats be translated to something more standardized and common to the health IT system, both in semantics and messaging format.
Medical device data system (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 it to an electronic health record (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 to create a more holistic and complete picture of patient state.
The breadth and scope of MDDS middleware's capabilities facilitates ways in which hospitals, health systems and other provider organizations can uncover ways to leverage the data that flows from a device into a system of record. The use of the data to improve patient care management and clinical decision making comes immediately to mind—but that only scratches the surface of what is possible.
Data Retrieval Capabilities
Minimally, MDDS middleware needs to be able to 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 (e.g., operating rooms versus intensive care units versus medical-surgical units).
Clinical charting intervals normally varies based on clinical requirements from 30 seconds up to several hours. Higher-frequency, sub-second data, includes 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, as well as the ability to process data collected at the point of care to create new information also drives data collection rates. The ability to retrieve data at variable rates, including at the sub-seconds level, requires technical capability on the part of the middleware vendor, but it also requires regulatory capabilities in the form of FDA clearances, which show that the middleware is able demonstrate that it has mitigated the risk associated with communicating higher frequency data for alarms and analysis—even patient monitoring and intervention.
Implications of Real-Time Intervention
Middleware can be leveraged to pull data from medical devices and combine it with other data in the patient record to create a more holistic and complete picture of the current patient 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, like clinical alarms, impact patient safety, any delay in their delivery to the 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.
FDA Clearance
In the health IT space, FDA 510(k) clearance governs medical device connectivity and communication to medical device data systems. One of the distinctions between medical device data systems that are intended for the use of charting and active monitoring is that those systems cleared for active monitoring 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 a MDDS. FDA requires that MDDS solutions to 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 MDSS capabilities. According to the rule, if an MDDS is used beyond its intended use, this shifts the burden for oversight and compliance onto hospitals that 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 the hazards of the data for use in live interventions, which would be consistent with alarm communication or creation of new data from raw data collected from medical devices.
For a middleware vendor to claim clearance for active patient monitoring, they must have all the checks and balances in place to ensure the receipt and delivery of all active patient data for intervention purposes from end to end—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.
Data Delivery, Communication, and Integrity
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 are impeded or otherwise delayed beyond a maximum acceptable limit on latency and throughput.
Two-way communication of data ensures that data delivery and verification does 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 are communicated per active patient.
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 be validated for all intended operational scenarios of the medical device, including failure modes. Data security, hostile attacks on data, medical device, and denial of service, and ransomware all have the potential to impact data integrity and these requirements must be fleshed out through specific scenarios and validated through testing.
Universal medical devices standards won’t happen overnight, though it has been interesting to note manufacturer's 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 medical device integration and middleware provider that can support the technical and clinical needs of your healthcare organization.
Post time: Jan-12-2017