This Viewpoint discusses medical device cybersecurity vulnerabilities and the threat they pose to patient safety.

INTRODUCTION:The need for remote ventilator control has been highlighted by the COVID-19 Public Health Emergency. Remote ventilator control from outside a patient's room can improve response time to patient needs, protect health care workers, and reduce personal protective equipment (PPE) consumption. Extending remote control to distant locations can expand the capabilities of frontline health care workers by delivering specialized clinical expertise to the point of care, which is much needed in diverse health care settings, such as tele-critical care and military medicine. However, the safety and effectiveness of remote ventilator control can be affected by many risk factors, including communication failures and network disruptions. Consensus safety requirements and test methods are needed to assess the resilience and safety of remote ventilator control under communication failures and network disruptions. MATERIALS AND METHODS:We designed two test methods to assess the robustness, usability, and safety of a remote ventilator control prototype system jointly developed by Nihon Kohden OrangeMed, Inc. and DocBox, Inc. ("the NK-DocBox system") to control the operation of an NKV-550 critical care ventilator under communication failures and network disruptions. First, the robustness of the NKV-550 ventilator was tested using a remote-control application developed on OpenICE - an open-source medical device interoperability platform - to transmit customized high-frequency and erroneous remote-control commands that could be caused by communication failures in a real-world environment. The second method utilized a network emulator to create different types and severity of network quality of service (QoS) degradation, including bandwidth throttling, network delay and jitter, packet drop and reordering, and bit errors, in the NKV-DocBox system to quantitatively assess the impact on system usability and safety. RESULTS:The NKV-550 ventilator operated as expected when remote-control commands arrived as fast as once per second. It ignored erroneous commands attempting to adjust invalid ventilation parameters. When facing commands that set the ventilation mode and parameters to invalid values, it reset the ventilation mode or parameters to default values, the safety implication of which may merit further evaluation. When any network QoS attribute (except for packet reordering) started to degrade, the NK-DocBox System experienced interference to its remote-control function, such as delays in the transmission of ventilator data and remote-control commands within the system. When the network QoS was worse than 500 ms network delay, 100 ms network jitter, 1% data drop rate, 12 Mbps minimal bandwidth, or 1e-6 bit error rate, the system became unsafe to use. For example, ventilator waveforms visualized on the remote-control application demonstrated freezes, out-of-synchronization, and moving backwards; and the connection between the ventilator and the remote-control application became unstable. CONCLUSION:The presented test methods confirmed the robustness of the NKV-550 ventilator against high-frequency and erroneous remote control, quantified the impact of network disruptions on the usability, reliability, and safety of the NK-DocBox system and identified the minimum network QoS requirements for it to function safely. These generalizable test methods can be customized to evaluate other remote ventilator control technologies and remote control of other types of medical devices against communication failures and network disruptions.

Clinical alarm and decision support systems that lack clinical context may create non-actionable nuisance alarms that are not clinically relevant and can cause distractions during the most difficult moments of a surgery. We present a novel, interoperable, real-time system for adding contextual awareness to clinical systems by monitoring the heart-rate variability (HRV) of clinical team members. We designed an architecture for real-time capture, analysis, and presentation of HRV data from multiple clinicians and implemented this architecture as an application and device interfaces on the open-source OpenICE interoperability platform. In this work, we extend OpenICE with new capabilities to support the needs of the context-aware OR including a modularized data pipeline for simultaneously processing real-time electrocardiographic (ECG) waveforms from multiple clinicians to create estimates of their individual cognitive load. The system is built with standardized interfaces that allow for free interchange of software and hardware components including sensor devices, ECG filtering and beat detection algorithms, HRV metric calculations, and individual and team alerts based on changes in metrics. By integrating contextual cues and team member state into a unified process model, we believe future clinical applications will be able to emulate some of these behaviors to provide context-aware information to improve the safety and quality of surgical interventions.

Introduction: The first meeting of the Integration of Continuous Glucose Monitor Data into the Electronic Health Record (iCoDE) project, organized by Diabetes Technology Society, took place virtually on January 27, 2022. Methods: Clinicians, government officials, data aggregators, attorneys, and standards experts spoke in panels and breakout groups. Three themes were covered: 1) why digital health data integration into the electronic health record (EHR) is needed, 2) what integrated continuously monitored glucose data will look like, and 3) how this process can be achieved in a way that will satisfy clinicians, healthcare organizations, and regulatory experts. Results: The meeting themes were addressed within eight sessions: 1) What Do Inpatient Clinicians Want to See With Integration of CGM Data into the EHR?, 2) What Do Outpatient Clinicians Want to See With Integration of CGM Data into the EHR?, 3) Why Are Data Standards and Guidances Useful?, 4) What Value Can Data Integration Services Add?, 5) What Are Examples of Successful Integration?, 6) Which Privacy, Security, and Regulatory Issues Must Be Addressed to Integrate CGM Data into the EHR?, 7) Breakout Group Discussions, and 8) Presentation of Breakout Group Ideas. Conclusions: Creation of data standards and workflow guidance are necessary components of the Integration of Continuous Glucose Monitor Data into the Electronic Health Record (iCoDE) standard project. This meeting, which launched iCoDE, will be followed by a set of working group meetings intended to create the needed standard.

INTRODUCTION: The National Emergency Tele-Critical Care Network (NETCCN) was developed to address limited and geographically unevenly distributed critical care (CC) providers during COVID-19 pandemic surges. Although designed for on-demand access to CC experts, for pandemic response, NETCCN continues to evolve and must be flexible and adaptable to future mass casualty/disasters. We report a pilot using tele-critical care (TCC) through NETCCN in emergency medical services (EMS). METHODS: We deployed a mobile device enabled cloud based, easy to use and learn, secure, HIPAA compliant TCC app developed for NETCCN in an emergency medical services (EMS) pilot designed to facilitate rapid communication via text, voice, video and file sharing between paramedics in the field, and emergency medicine specialists. A 30-minute session trained participants on the app, including account creation, login, and functions. EMS providers were encouraged to replace existing telephone communication triage protocols with the NETCCN mobile app. We collected the number/nature of consults, and narrative feedback. RESULTS: The pilot ran for 30 days and was used on average 3 times/week. No patient data was entered into the system, and the app was solely used for its communication features. The most common use case was terminating resuscitation. Debrief and feedback confirmed that the app was easy to use, not significantly affected by connectivity issues, and elicited several barriers to adoption by EMS providers: 1) manual input of patient data 2) perception of being micromanaged. Overall impression of the app and its utility was positive by both remote and EMS providers, and discussion elicited strategies to improve adoption: 1) incorporate TCC into protocols for interfacility critical care transport 2) automate patient data entry (e.g. scan driver's license)). CONCLUSIONS: We demonstrated that the NETCCN TCC app is quickly and easily usable in the EMS setting, but that further optimization is required to promote adoption. Novel non-disaster use cases like this can provide means to stabilize and sustain a system designed primarily for infrequent “as needed” response. Additionally, feedback and problem solving for these novel use cases can be an effective way to enhance system flexibility with dividends for future disaster use.