So we're going to talk a bit in the next 10 minutes or so, talk about a journey of the last 10 years and some of the innovations that have occurred to enable care everywhere as has been described. I'm clicking by the way, but maybe I'm using the wrong finger, maybe I'm using the wrong finger. There we go. A few years ago or so in October of 2014, I was taking one of those rare breaks from the OR and received a call from the Office of Science and Technology Policy at the White House because Ebola had showed up on our shores and there were a lot of concerned folks about how we would address that. Well the reason they reached out is because of our research program on medical device interoperability and cyber security and the fact that we typically work with a lot of partners and collaborators and they asked, what could you do? I said, well, what are the parameters? And it was pretty easy. You have 20 days and no money, so of course I signed up. And the project ended up being called Open Medical Device and Data Integration Platforms to Support the Management of Ebola Virus Disease. At the end of the 20-day period, we had a multi-day collaboration in our lab and we worked together to produce demonstrations, all of which can be seen online if you just follow these links on the slides later. One of the things that we learned from all of this work were the potential benefits of remote control, that with remote control of medical devices, even from directly outside of the patient's room, you could do simple things like bump up FiO2 or perhaps adjust an infusion rate of an IV pump. And by doing those simple things, potentially reduce room entries, reduce PPE consumption and a lot of obvious things that flow from that. A vital part of the project was the support of the FDA. And as you can see in this letter from Dr. Jeff Shuren, the Director of the Center for Devices and Radiological Health, the FDA was a partner from the beginning, which was an important message to industry, many of whom initially said, there's no way we're going to do this and risk getting in trouble with the FDA. That's not a process we follow to get together with a lot of people in an emergency and prototype new medical devices. Not going to do it. But as soon as the FDA was physically there and wrote letters of support, everyone jumped in. Well, you fast forward a few years to early 2020 and our COVID-19 public health emergency. And of course, many of you in this room did things like this, moving IV infusion pumps to the hallway with a few miles of extension tubing, pulling on the ventilator tubing to try to get the control panel outside the room and all the other things for the same purpose, of course. Pretty tricky. But interestingly, and probably not widely known, is the fact that the FDA jumped in with both feet. And by March of 2020, they had released guidance documents, which are called immediate in effect guidance, which permitted manufacturers to add remote control to existing products, existing infusion pumps, ventilators, and monitors, as long as the device was already on the market. The FDA was empowered and facilitated by a number of things, one of which was the engagement with the Ebola project. Another is a portfolio of existing and new standards, which make it much easier for manufacturers to develop safe products. So on the left, you see a standard for the integrated clinical environment, or ICE, which is an architecture standard to enable connecting medical devices into smarter and safer systems, including remote control. There are nomenclature standards from 1173, IEEE in the middle. And on the right was a new standard that we wrote on an emergency basis within AAMI on emergency use guidance for remote control of medical devices, and had that published and freely available for use by manufacturers. Well, interestingly enough, as all this was happening, Nihon Koden had already conceptualized adding remote control to a critical care ventilator, the NKV-550, that had just been cleared right before the pandemic, and hadn't been used, deployed yet, or sold yet, but we deployed that at MGH. What I'd like to point out is the idea that in this setting, in this configuration, you have the bedside ventilator, of course, and then you have the remote control component, which is a graphical user interface connected with a 10-meter cable. The cable implementation is important because it's controlling where you could put the user interface, the remote interface. It can't be more than 10 meters away, thereby assuring that you still have relatively quick access to the patient and maybe line of sight to the patient and the environment. Well, once the FDA released its guidance, Medtronic was able to release a tool called OmniTool that allowed for network-based control of a ventilator for the PB980, which, of course, is widely used in critical care settings. So as soon as that was becoming available, they shipped us one of the units with a remote control capability. We set this up in our lab, and we added a webcam. And then this is a screenshot of my computer from home, and you can see that there was the ability to control the ventilator with the same user interface and a webcam so that one could see what's going on. And we performed a number of evaluations in the lab, shared that information back with the company and with hospitals all over to help facilitate rapid, safe deployment, with a lot of questions about how to do that safely. So I'd like to talk about the conceptual framework now for remote control. You might have near-patient remote control, a term we've had to make up for the standard and for all this work, and we've already talked about what that means. And then the notion of far remote control, which might be control from anywhere to anywhere over the Internet. And we could make some assumptions about the complexity of that, but we'll talk about it. But in order to talk about remote control, which implies someone at the other end controlling, you need a certain critical ingredient, and that is a device that is externally controllable. The manufacturer had to build in that feature or capability or add it. So you need a controllable device, of course, in order to remotely control it. The interesting thing, though, is if you have an externally controllable device, it may not be a person that's controlling it. You might have something installed next to it, a computer, that's now performing control of that device. So maybe you can implement an algorithm for, you know, peep, whatever, fill in the blank, or maybe for closed loop sedation, controlling an infusion pump and reading information from an EEG monitor. So external control could enable a host of things, whether it's smarter and autonomous systems or manual control, far and remote, or even autonomous control from far away. This is some of the work that we did. This was under, I won't say Dr. Pamplin, I'll say now Colonel Pamplin's leadership at Tattrick. So this is the simulated field hospital at Fort Detrick. Here's a simulated casualty connected to a neurowave infusion pump, that NKV-550 ventilator, a Philips monitor, and all interconnected on an ICE-compliant, that's the standard part, platform from DocBox called the APRE platform, which enabled, down here, Dr. Colombo, Chris Colombo at home, being consulted from that environment, seeing the patient data, talking with the crew, helping them to manage a critical issue, and remotely controlling the ventilator and infusion pump. And then another patient who needed to be medivac-ed, simulated medivac-ed, in this M4 medical evacuation pod designed to go under a drone, and in this case, the casualty is connected to a MOVES SLC ventilator and the infusion pump and the DocBox platform, and this is the view remotely as all that was being managed and supported. So naturally, all the things I showed you raise a lot of basic kind of safety questions, all of which we've been tackling. No one is ignoring these things. Like how much information do you need to increase FiO2 remotely? Well, maybe a phone call with the data, and if you had a remote control and you can twiddle the knob, you'd increase FiO2, but how much data do you need to adjust a ventilator to address asynchrony? Well, now you probably want real-time waveforms and a host of other information. So all this is kind of self-evident, but it's all being studied. What do you need for network performance? Will it fail safely if and when the connection fails? How about permission and access, right? If the remote control is right outside the patient's room in the ICU, you may not need to log in because it's the same as walking into a room, but if it's on your app or across the country or God knows where else, you probably want secure login. So a lot of the things we're talking about, and as Jeremy mentioned, is the notion of smart and autonomous medical systems, and so one can think of this whole emerging area in that context. Things that would include SAMs might be automated closed-loop control of IV anesthesia, closed-loop therapy for fluids and vasopressors, of course remote control of devices, and think about the AI that will be connected to these devices.

medical device interoperability

cybersecurity

remote control

AI-driven systems

healthcare delivery