WEBVTT 00:00.000 --> 00:05.020 Welcome, everybody, to the Open Ventilator Remote Monitoring Project. 00:05.020 --> 00:07.040 This was a project that we did. 00:07.040 --> 00:19.840 The open source community came together to create software to remotely monitor do-it-yourself, rapidly manufactured ventilators during the COVID-19 pandemic. 00:20.040 --> 00:24.060 So, by way of introduction, my name is Sam Cervantes. 00:24.060 --> 00:28.900 I'm the Chief Technology Officer at MakerGear 3D printers based out of Cleveland, Ohio. 00:28.900 --> 00:33.140 And also leading the project with me is Dave Guthrie. 00:33.140 --> 00:38.240 He's the Medical Device Cybersecurity Program Manager at Mass General Brigham Healthcare. 00:38.240 --> 00:43.920 So, we're going to give you a little description of our project, what we did, and how we went about it. 00:43.920 --> 00:45.660 So, over to you, Dave. 00:46.060 --> 00:50.600 Okay, so this has been the year of COVID. 00:50.600 --> 00:53.440 We've all been impacted by this global pandemic. 00:53.440 --> 00:58.560 And early on in this pandemic, there were fears of massive shortages of ventilators. 00:58.560 --> 01:05.740 For example, Governor Cuomo of New York predicted there would be 26,000 people who could die from ventilator shortages. 01:05.740 --> 01:09.520 In Italy, they stopped intubating patients over the age of 60. 01:09.520 --> 01:16.460 And the New England Journal of Medicine predicted a need of anywhere from 160,000 to over a million. 01:17.040 --> 01:19.160 So, there's a global pandemic. 01:19.300 --> 01:24.240 Early on in this, Massachusetts has hit pretty hard by this as far as the United States is concerned. 01:24.240 --> 01:31.500 Mass General Brigham is the largest healthcare provider in Massachusetts and has a significant need for ventilators. 01:31.840 --> 01:44.860 So, Mass General Brigham reaches out to the tech community to develop new technologies, new processes, and has to be rapidly deployable in order to meet this predicted growth in rate of infections. 01:44.860 --> 01:48.380 And you need to do this in a massively condensed timeline. 01:48.380 --> 01:51.500 So, typical medical device development takes two to three years. 01:51.500 --> 01:54.040 This needed to be done in two to three weeks. 01:54.060 --> 01:55.020 Crazy! 01:55.940 --> 02:03.620 So, Mass General Brigham reaches out to the open-source community to develop rapid prototype ventilators. 02:03.620 --> 02:05.600 Open-source community responds. 02:05.760 --> 02:09.920 This is an example of just some of the resources that the open-source community has provided. 02:09.920 --> 02:13.600 And Sam is going to go into this in more detail later in this presentation. 02:14.160 --> 02:17.460 So, now you have the open-source community at the ready. 02:17.460 --> 02:23.340 Working groups are starting to form to develop hardware systems, control software, and remote monitoring software. 02:23.340 --> 02:27.660 All of these are being done in parallel under this condensed timeline. 02:28.180 --> 02:31.920 So, what's the initial need and scope of this project? 02:31.920 --> 02:34.760 So, you have this predicted ventilator shortage. 02:34.760 --> 02:38.740 You have a need for these rapid prototype ventilators that the community is now building. 02:38.740 --> 02:42.320 However, most of these ventilators lack built-in monitoring. 02:42.320 --> 02:50.520 And clinical representatives need to have central monitoring and express this need to have central monitoring similar to central nursing station networks. 02:50.520 --> 03:01.580 So, in a hospital, you typically would have a GE network or a Philips network or a Neon Codin network or some other monitoring network where you have bedside physiological monitors going out. 03:01.580 --> 03:10.100 And you have a network where you can go back to a central nursing station and oversee the data and the alarms of all of these patient rooms. 03:10.100 --> 03:15.240 And you have ventilator systems that can then plug into these bedside monitors to jump onto this network. 03:15.240 --> 03:18.480 And then you can monitor these ventilator systems as well. 03:18.480 --> 03:21.020 Well, you can't do that with these rapid prototype ventilators. 03:21.020 --> 03:25.440 So, you have these open source teams actively developing these ventilators. 03:25.440 --> 03:29.640 And now you need to have remote monitoring and central monitoring of these systems. 03:29.640 --> 03:31.760 That's where this team comes into play. 03:31.760 --> 03:35.120 And it initiated in April 2nd of 2020. 03:35.260 --> 03:39.420 So, what's the clinical request and the need for this remote monitoring software? 03:39.420 --> 03:42.340 So, you have this rapid prototype ventilator groups. 03:42.420 --> 03:46.040 They're not integrated into central monitoring traditionally with hospitals. 03:46.040 --> 03:50.380 So, you need a method of monitoring of all your ventilators on a given floor or a given unit. 03:50.380 --> 03:54.140 You have to have a central dashboard with visual learning that's easily interpretable. 03:54.140 --> 03:58.280 You have to be able to ingest device data from all these ventilators. 03:58.280 --> 04:07.160 So, not just your patient device data, but also device status data and alarm states and alarm data from ventilators if available. 04:07.160 --> 04:12.040 And again, you have to do this in this wicked condensed timeline of two to three weeks. 04:12.040 --> 04:15.600 And you shouldn't cause patient harm or interruption in patient care. 04:15.600 --> 04:19.100 Because if you do that, you're defeating the purpose of helping clinical staff. 04:19.100 --> 04:23.220 And instead, you're getting in the way and potentially causing patient harm. 04:23.220 --> 04:26.600 So, this is where Sam's company, MakerGear, comes into play. 04:26.600 --> 04:28.840 They have a 3D printing company. 04:28.840 --> 04:35.980 And they have software that has the ability to integrate with physical hardware as well as providing a centralized dashboard. 04:35.980 --> 04:45.100 So, this was the initial code base that was hacked and adapted by the remote monitoring team to develop this ventilator monitoring system. 04:45.120 --> 04:51.480 So, now what happens is we're actively developing all of these rapid prototype ventilators. 04:51.480 --> 04:58.540 And the remote monitoring team is working on integrating with these ventilator teams in order to build a central monitoring system. 04:58.540 --> 05:05.620 However, simultaneously, hospitals are procuring ventilators left and right. 05:05.620 --> 05:09.760 You're trying to build up your ventilator inventory from traditional commercial vendors. 05:09.840 --> 05:16.580 And what happens is there was not a need to then deploy these rapid prototype ventilators. 05:16.580 --> 05:21.120 Because you're sharing up your inventory of already off-the-shelf commercial ventilators. 05:21.220 --> 05:28.860 And the problem, though, is a lot of these new ventilators may not have been the same model that you already built out integrations for. 05:28.860 --> 05:35.260 And so, the amount of time to design these integrations was extremely costly, resource-intensive. 05:35.260 --> 05:37.960 And you just can't do that in an emergency response situation. 05:37.960 --> 05:42.360 So, you have new commercial ventilators that can't integrate into your central monitoring system. 05:42.360 --> 05:47.540 On top of that, you have infection control restrictions because this is a global pandemic. 05:47.540 --> 05:51.140 So, you have closed doors for infection control reasons. 05:51.140 --> 05:55.240 You have ventilators inside of these rooms that can't be centrally monitored. 05:55.240 --> 05:57.960 And now you have alarms going off with these ventilators. 05:57.960 --> 06:02.300 Now clinical staff are having trouble hearing alarms through these closed doors. 06:02.300 --> 06:14.300 So, this is where our team now pivots and we are requested to create a method for monitoring these commercial ventilators in a central means that don't typically integrate with the other traditional central monitoring systems. 06:14.300 --> 06:16.280 So, what's our plan of attack? 06:16.300 --> 06:20.320 So, MGH Biomed, for example, researched off-the-shelf sound monitoring solutions. 06:20.320 --> 06:23.700 They vectored in on one product, the SoundEar. 06:23.700 --> 06:29.800 So, the SoundEar can deploy a one-to-one system per patient room per ventilator. 06:29.800 --> 06:34.320 It's a self-contained consumer off-the-shelf system that can monitor sound pressure. 06:34.320 --> 06:41.960 So, you can hook a SoundEar with a microphone up to the speaker on the ventilator that auditorily alerts the alarm. 06:42.120 --> 06:46.680 And then when the sound pressure is exceeded, when that alarm goes off, the SoundEar can then trip. 06:46.680 --> 06:57.680 So, we were then requested to integrate with this SoundEar and provide a central means for monitoring the SoundEar and be able to create a central dashboard for when it trips. 06:57.680 --> 07:01.880 And now, I'm going to pass it over to Sam to go into the architecture. 07:01.940 --> 07:02.720 Thanks, Dave. 07:03.620 --> 07:11.360 So, I'm going to talk a little bit about the technical aspects of the project and how we went about pulling this off. 07:11.580 --> 07:15.640 And then also, later on, some of the future goals. 07:15.640 --> 07:20.100 So, this right here, this is the user interface for the clinician. 07:20.280 --> 07:23.460 This is the whole goal of the entire project right here. 07:23.780 --> 07:27.100 So, this is what the nurse is going to see at the nursing station. 07:27.100 --> 07:30.160 We've got one little box here for each ventilator. 07:30.160 --> 07:35.540 So, we've got, in this case, 48 ventilators monitored from our single dashboard. 07:35.540 --> 07:42.320 So, this is every ventilator on the entire floor of the hospital monitored from one central dashboard. 07:42.560 --> 07:47.480 So, we've got three states of a ventilator right here that we can display. 07:47.960 --> 07:50.460 The normal state, the happy state, is green. 07:50.460 --> 07:53.560 That means we're able to ping the ventilator. 07:53.560 --> 07:56.940 We're getting a good status report back and there's no alarm. 07:56.940 --> 07:58.200 All is good. 07:58.560 --> 08:03.080 The second state is this gray strikethrough box right here. 08:03.480 --> 08:07.660 That means we're not able to even connect with the ventilator. 08:07.660 --> 08:10.040 So, a technician needs to go check on the ventilator. 08:10.040 --> 08:12.380 So, there's a fault in the system somewhere. 08:12.900 --> 08:16.160 The third state is this red box here. 08:16.160 --> 08:18.840 And that will actually flash, you'll see in the live demo. 08:18.840 --> 08:23.960 And that means an alarm is currently being triggered on the ventilator. 08:23.960 --> 08:26.220 So, the nurse needs to go check on it. 08:26.220 --> 08:33.980 So, at a glance, the nurse can see right here, okay, I need to go check on two different ventilators right here, room seven and room four. 08:33.980 --> 08:35.740 I need to go check on those. 08:39.960 --> 08:42.440 Okay, so how do we go about doing this? 08:43.700 --> 08:47.780 Typical deployment process for software like this is two to three years. 08:47.780 --> 08:49.200 We had two to three weeks. 08:49.200 --> 08:50.860 COVID-19 emergency. 08:51.340 --> 08:53.920 So, how do we go about pulling this off? 08:54.260 --> 08:59.560 Basically, we had to pull all the rapid prototyping software development strategies. 08:59.560 --> 09:01.100 We had to move fast and break things. 09:01.100 --> 09:04.580 We rely heavily on the open source community and the maker communities. 09:04.880 --> 09:11.880 Distributed development, we had software developers all over the country pushing to our GitHub repo. 09:11.880 --> 09:17.560 We had to hack and fork existing products to get something out in just a few weeks. 09:17.560 --> 09:30.620 We used things like 3D printing and quick turn PCBs off the shelf hardware to get something that we could very quickly snap together, bolt together, and ship a solution to our customers in just a very short amount of time. 09:31.020 --> 09:33.540 We had to rely on remote lab testing. 09:34.120 --> 09:37.360 And as much as we could, you know, source locally. 09:37.360 --> 09:40.740 Component sourcing was a key thing. 09:40.740 --> 09:48.200 We had to design our system around the components that we could actually source that were in stock and locally available. 09:48.520 --> 09:54.420 We might have wanted to use a PLC or a custom circuit board, but we didn't have time. 09:54.420 --> 10:02.560 So, we had to use things like off-the-shelf Raspberry Pis and Arduinos that we could get in quantities of thousands that were actually in stock. 10:03.780 --> 10:08.880 So, basically, we had to move heaven and earth to ship something in a very short amount of time. 10:08.880 --> 10:14.420 Like Dave said, the initial code base was hacked from MakerGear software. 10:14.420 --> 10:16.820 So, MakerGear manufactures 3D printers. 10:17.000 --> 10:19.980 Been doing so for about 10 years out of Cleveland, Ohio. 10:19.980 --> 10:26.400 And it just so happened that MakerGear had some software for remotely monitoring 3D printers. 10:26.420 --> 10:32.460 And as it turns out, a 3D printer is an awful lot like a do-it-yourself ventilator. 10:32.460 --> 10:39.680 A 3D printer has an Arduino and a Raspberry Pi, and a ventilator has an Arduino and a Raspberry Pi. 10:39.680 --> 10:50.400 So, we were able to adapt and import the software to quickly meet the needs of the pandemic. 10:50.400 --> 10:53.080 So, this is the overall architecture here. 10:53.080 --> 10:55.500 So, you'll see the dashboard is what we saw before. 10:55.500 --> 10:59.000 The dashboard is the kind of central brains, if you will. 10:59.440 --> 11:02.180 All information flows towards the dashboard. 11:02.660 --> 11:05.980 So, this is the clinician interface here. 11:06.600 --> 11:12.100 So, the dashboard is going to get its status data in real time from the ventilators. 11:12.100 --> 11:14.540 You'll see three ventilators displayed down here. 11:14.540 --> 11:17.400 Each ventilator is in a different configuration. 11:18.220 --> 11:20.080 And you'll see the cloud up here. 11:20.080 --> 11:25.080 So, the cloud is there only to serve up the application to the browser. 11:25.080 --> 11:27.940 And the cloud doesn't store patient data. 11:27.940 --> 11:32.740 The cloud simply stores configuration data for the app. 11:32.740 --> 11:33.980 A very limited amount of data. 11:33.980 --> 11:35.940 We don't send patient data to the cloud. 11:36.760 --> 11:41.720 So, how does the dashboard get its information from each of the ventilators? 11:41.900 --> 11:48.940 It was kind of a tricky problem for us because each ventilator... there are a number of different types of these DIY ventilators out there. 11:48.940 --> 11:53.240 And we wanted to make a universal system to pull data from every ventilator. 11:53.240 --> 11:56.120 Some ventilators are controlled by an Arduino. 11:56.260 --> 11:59.920 One of the MIT designs was controlled by an Arduino. 12:00.760 --> 12:03.900 Some ventilators were controlled by a Raspberry Pi. 12:03.900 --> 12:06.380 I think the JamBest design used that. 12:06.620 --> 12:08.780 And then some ventilators are a little different. 12:08.920 --> 12:16.300 So, we wanted to have a sound ear, a separate appliance to listen to the sound the ventilator is making. 12:16.300 --> 12:18.240 And then trigger it a lot based on that. 12:18.240 --> 12:27.940 In order to interface with all these different types of ventilators, we decided to put a Raspberry Pi in between each ventilator and the dashboard. 12:28.640 --> 12:33.160 So, the Raspberry Pi could serve as a kind of universal network interface. 12:33.740 --> 12:37.020 And on the Raspberry Pi, we have a library. 12:37.820 --> 12:44.560 And so, we can write modules for this library to basically ingest data from any system. 12:44.560 --> 12:52.420 So, the system we set up, the dashboard we set up, can basically take data from pretty much any device with any output capability. 12:52.420 --> 13:04.400 If it's a serial out, if it's a SPI or a UART out, or whatever, analog out, digital, we can take that data from the ventilator and relay it to our dashboard here. 13:04.440 --> 13:06.360 So, this is the overall architecture. 13:07.780 --> 13:14.380 And the specific instance that we tested in the lab was this particular architecture here. 13:15.320 --> 13:18.820 So, the ventilator is obviously going to be in the patient's room. 13:19.240 --> 13:28.940 And then also in the patient's room is the SoundEar device, which listens for an audio alarm from the ventilator. 13:28.940 --> 13:31.960 So, the ventilator is going to emit a beep, and you'll hear this in the demo. 13:31.960 --> 13:33.340 It's going to emit a beep. 13:33.340 --> 13:36.720 The SoundEar is going to detect that audio beep, that sound pressure. 13:36.840 --> 13:42.780 If the sound pressure is above a certain level, it's going to send a signal to the Raspberry Pi, the network adapter. 13:43.020 --> 13:49.260 And then the Raspberry Pi is going to then send the alarm to the dashboard that we saw earlier. 13:51.100 --> 14:10.900 We should note here that we used the zero-tier software-defined network, which provides a very secure network in the hospital, and even outside of the hospital if we need to, to provide connectivity between the Raspberry Pi and the interface here. 14:10.900 --> 14:12.060 And of course, you've got the cloud here. 14:12.060 --> 14:14.740 And again, we're not storing patient data on the cloud. 14:14.740 --> 14:24.540 The cloud is just there to serve up the static assets, the application, if you will, to the dashboard, and also very limited configuration information. 14:26.020 --> 14:33.520 And again, this is what the nurse is going to see at his or her station right here at the dashboard. 14:35.280 --> 14:38.700 Software stack, we're getting a little bit into the weeds here. 14:38.700 --> 14:42.320 We tried to use as much open-source software as we could here. 14:42.320 --> 14:47.020 Ruby on Rails, reliable, secure, open-source, very quick to deploy. 14:48.220 --> 14:55.040 Raspberry Pis and Arduinos, again, open-source, off-the-shelf, quick to deploy. 14:56.540 --> 15:05.500 And then everything we did is open-source under a GPLv3 license, so you can pretty much use it for whatever purpose you'd like. 15:05.500 --> 15:09.660 GPLv3 is a very permissive license. 15:09.980 --> 15:12.920 You can use it for commercial and or non-commercial. 15:13.300 --> 15:19.560 We wanted hospitals to be able to use this very quickly, and you can see our GitHub link here below. 15:19.560 --> 15:21.480 Everything we have is up on GitHub. 15:23.240 --> 15:24.860 We did a lot of testing. 15:24.860 --> 15:30.380 At-home testing, workbench testing, we did lab testing. 15:30.540 --> 15:36.520 We did not get to the point where we actually tested it in a hospital, but we did a lot of lab testing in a clinical lab. 15:36.940 --> 15:39.320 And it actually worked pretty well. 15:39.420 --> 15:44.680 We got a very solid proof-of-concept alpha. 15:44.980 --> 15:49.400 We didn't quite make it through the beta phase, but we got a pretty good alpha prototype. 15:50.360 --> 15:59.740 One of the lessons we learned was that the validation and the regulatory process was actually very involved, as you might imagine, from medical product. 16:00.200 --> 16:13.160 A lot of us come from a typical software development background, but a medical device has a much more involved regulatory and approval documentation process. 16:13.160 --> 16:16.880 We just wanted to give you a flavor of what that is right here. 16:17.080 --> 16:30.280 The main three documents are the requirements, which have to be formatted in a certain way, the architecture, which again needs to be formatted in a certain way, and then the hazard analysis, which is pretty involved. 16:30.280 --> 16:37.240 Basically, for the hazard analysis, we had to brainstorm every possible way that this product might fail. 16:37.240 --> 16:45.940 It would either fail to communicate an alarm to the central station or fail in some other way. 16:46.800 --> 16:54.160 Every method we predicted that it might fail, we had to put a contingency plan in place for. 16:54.820 --> 16:56.120 Very detailed, again. 16:56.120 --> 17:06.760 I just wanted to give you a brief overview of what this... for those of you who haven't done a medical product before, just a brief overview of what that involves. 17:06.760 --> 17:12.320 It's a very rigorous process to prepare for FDA approval and hospital approval. 17:12.320 --> 17:14.320 Just a little taste of that right here. 17:15.940 --> 17:18.500 Again, this is the detailed software architecture. 17:18.780 --> 17:20.300 If you want to take a look at that. 17:20.400 --> 17:25.100 All these documents are up on our GitHub wiki, so you can check those out there. 17:27.240 --> 17:39.560 Another important thing here to do is to do a secure code review to just kind of get a good confidence level, since this is potentially a critical application that we don't want to fail. 17:39.560 --> 17:47.680 The staff at MITRE did a very nice job and lent their support, so we're very grateful to them. 17:47.680 --> 17:53.100 They used an automated code service called VeriCode and also a manual code review. 17:53.100 --> 17:56.280 Still ongoing, but they were a big help with that. 17:56.280 --> 18:00.660 Just to give you a taste of the automated code review. 18:00.660 --> 18:06.860 This was a code review on, I think, a Ruby on Rails portion of the application. 18:07.080 --> 18:16.280 Basically, you see here, we don't have any severe alerts, but we had a couple of medium alerts. 18:17.560 --> 18:27.660 We had some automated testing code that spit out automated test data, so we need to remove that before deployment. 18:27.760 --> 18:29.620 One little minor thing here. 18:29.620 --> 18:31.080 A few things to fix. 18:31.260 --> 18:33.080 Manual code review. 18:33.380 --> 18:34.500 Again, just a few things. 18:34.500 --> 18:35.640 Nothing critical. 18:35.640 --> 18:37.020 A few things to fix. 18:37.020 --> 18:44.500 We just want to give a little insight into how we went about testing and validating our code. 18:44.500 --> 18:46.520 We learned a lot in this project. 18:46.520 --> 18:57.600 We did have a few medical experts on our staff, both from the software development side and a lot of medical experts from the regulatory and healthcare field. 18:57.700 --> 19:02.040 A lot of us were software developers, so these are some of the lessons we learned. 19:02.040 --> 19:17.280 The most inspiring thing, I think, was we had a lot of world-class experts to come together very quickly to donate their time, their nights and weekends, to really come together and work for this good cause. 19:17.280 --> 19:20.000 So that was really inspiring. 19:20.000 --> 19:24.500 The biggest hurdles we found were not necessarily the technology. 19:24.500 --> 19:33.000 As technologists, I don't want to say it was easy, but the technology was the easiest part in a lot of ways. 19:33.000 --> 19:39.620 The validation and approval were much more rigorous and time-involved than we anticipated. 19:40.160 --> 19:45.500 All that being said, FDA approval is daunting, but it's not impossible. 19:45.500 --> 19:48.840 And there are experts out there that are willing to help, and that's what we found. 19:48.940 --> 19:54.700 A lot of really good people with a lot of deep FDA experience out there that are willing to help. 19:54.960 --> 19:57.740 So it's not undoable. 20:00.000 --> 20:07.120 We found it's very important to be aware of HIPAA and personal identifiable information. 20:07.120 --> 20:11.500 So that's one reason we chose not to send patient data to the cloud. 20:12.580 --> 20:16.020 It's very important to be cognizant of HIPAA. 20:16.020 --> 20:33.400 Another important lesson we learned was that hospitals are reluctant to use open source software without the strong backing of an organization to own the technical support and the liability aspect of it. 20:33.400 --> 20:44.280 So in the future, we're looking for potentially a sponsor for the project to own that deployment and technical support aspect. 20:44.680 --> 20:48.880 And ultimately, we learned we didn't have a ventilator shortage in the U.S., which is great news. 20:48.880 --> 20:51.480 So ultimately, our software was not needed. 20:51.480 --> 21:03.640 We're very happy that we could be there and rise to the nation's call as an insurance policy, but ultimately, there were plenty of ventilators, from what the experts tell us, in the U.S. 21:03.640 --> 21:06.600 to go around for people who needed them. 21:08.240 --> 21:10.060 So FDA approval. 21:10.740 --> 21:17.940 We just wanted to give you a little flavor of kind of the difficulties we found in the FDA approval process. 21:18.200 --> 21:24.160 Big disclaimer, I'm not a lawyer or a medical expert, so please don't take us as medical advice or legal advice. 21:24.300 --> 21:27.480 Seek expert advice for your own project. 21:27.480 --> 21:31.200 But it's just a high-level overview of some of the things I learned. 21:31.700 --> 21:44.040 In a normal timeframe, non-COVID, non-emergency timeframe, say last year, a typical approval process for a system like ours would be about two to three years. 21:44.040 --> 21:53.760 It's a lengthy submission process, and once you get that approval process, you can use your product for a long period of time. 21:53.760 --> 22:04.520 During the emergency, for example, the COVID emergency, the FDA allows a couple types of new approvals. 22:04.520 --> 22:08.500 One is what's called EAU, Emergency Use Authorization. 22:08.960 --> 22:11.260 Typically, it can be fast-tracked in two to three months. 22:11.260 --> 22:17.600 It's much quicker, but EAU is only valid for the duration of the emergency. 22:17.600 --> 22:28.000 So if we were to get EAU for our software system, we would not be able to use it after the COVID emergency. 22:28.120 --> 22:31.260 And then Compassionate Use is potentially even quicker. 22:32.360 --> 22:42.380 And that's a... I'm not an expert on that, but it's a slightly quicker process, even more limited in scope, even more limited in approval, but potentially quicker. 22:44.300 --> 22:51.700 Again, not a legal expert, not a medical expert, but these are just some of the things that we learned in the process. 22:51.860 --> 22:57.200 There was even a little bit of discussion as to how to classify our software system. 22:57.200 --> 22:58.940 Is this a medical device? 22:59.000 --> 23:02.440 Is it a modification to an existing medical device? 23:02.440 --> 23:04.000 Or is it not a medical device? 23:04.000 --> 23:09.340 Is it a baby monitor or a pager or like a cell phone type device? 23:09.340 --> 23:12.480 So we did have some ongoing debate about that. 23:13.960 --> 23:16.200 So current status of the project. 23:16.460 --> 23:19.860 We've drafted up our validation documents for approval. 23:20.400 --> 23:22.940 We have a working demo proof of concept. 23:22.940 --> 23:23.860 I called it Alpha. 23:23.860 --> 23:24.340 It works. 23:24.340 --> 23:25.040 We tested it in the lab. 23:25.040 --> 23:26.300 We had a code review. 23:26.500 --> 23:30.080 We do not currently have a customer for the project. 23:30.080 --> 23:32.120 Our project is currently parked. 23:32.120 --> 23:39.780 So if you have a potential use for the software, do let us know. 23:39.780 --> 23:44.340 We would love to see our software be used for a good purpose. 23:44.720 --> 23:46.160 Future plans. 23:47.040 --> 23:57.880 One thing we discussed is additional audio alerting at the central nursing station that may require, in addition to the visual alerting that we already have, that may require a separate hardware appliance. 23:58.880 --> 24:09.200 And potential AI machine learning to detect different types of audio alarms from different types of medical devices. 24:09.880 --> 24:14.280 We're going to search continually for new customers. 24:15.040 --> 24:19.740 Potential customers may be hospitals with limited resources. 24:19.880 --> 24:24.160 Smaller hospitals in remote areas or developing countries. 24:25.140 --> 24:34.720 And then potentially healthcare organizations with needs to monitor other devices, like pulse oximeters or things like that. 24:34.720 --> 24:41.940 And we're continuing our search for a corporate sponsor, an entity to own the maintenance, installation, support, and liability. 24:41.940 --> 24:46.680 So we're just a group of distributed open source software developers. 24:46.820 --> 24:49.960 We don't have an organization behind us. 24:50.520 --> 24:56.840 And then potentially a future FDA application, again, if we find a customer for this. 24:58.080 --> 25:03.780 So Dave's going to talk a little bit about the power and the possibilities. 25:03.920 --> 25:12.440 Yeah, so when you think about this system, the real power is in the possibilities of all the integrations that this system can provide. 25:12.440 --> 25:19.360 You have rapid prototype ventilator monitoring systems that we've discussed, such as bringing in device and patient data. 25:19.360 --> 25:26.460 You have commercial ventilators that are not traditionally integrated with central monitoring systems that you can monitor through sound. 25:26.460 --> 25:29.020 So you can get ventilator alarms from commercial ventilators. 25:29.020 --> 25:35.280 And now with the sound monitoring, you can monitor any medical device alarm that is based in audio. 25:35.280 --> 25:47.800 So you think about all the infusion pumps or other devices that you have all throughout your hospital or remote care sites that potentially do not have integrations into your central monitoring system. 25:47.800 --> 25:49.660 This could be huge. 25:49.660 --> 25:56.360 So this project has great potential to have a massive impact in the healthcare ecosystem. 25:56.360 --> 25:59.680 Now for the fun part, we've got a live hardware demo. 25:59.680 --> 26:04.040 So we're going to show you the system in operation. 26:04.080 --> 26:12.300 So Dave in Massachusetts has what would be in the patient room. 26:12.300 --> 26:18.920 On this picture is what's on the bench here in Massachusetts. 26:19.100 --> 26:24.320 So the way you're going to see in the video is going to be from that camera that you see in the forefront of the picture. 26:24.320 --> 26:34.020 So you have the speaker in the background next to the cyber lizard who has a microphone next to the speaker. 26:34.060 --> 26:37.800 That microphone is plugged into the sound ear. 26:37.800 --> 26:42.620 The sound ear is then going to calculate the sound pressure. 26:42.780 --> 26:45.340 And it has what's called a sound buster port. 26:45.340 --> 26:51.180 That sound buster port changes voltage if the audio alarm pressure is tripped. 26:51.240 --> 26:55.900 So then the sound buster port comes out of the sound ear into this Raspberry Pi. 26:56.020 --> 27:03.860 And then the Raspberry Pi itself will then go out through the network cable over to a switch that's on my bench here. 27:03.860 --> 27:11.260 Out over the open internet through the encrypted zero tier tunnel over to Sam where he's running the dashboard. 27:12.340 --> 27:22.540 And what I'm going to be doing also is running a ventilator recording of the audio alarm that we used to train this system. 27:22.540 --> 27:24.360 So Dave, you've got the ventilator system. 27:24.360 --> 27:26.800 You've got the patient side system in Massachusetts. 27:26.800 --> 27:28.080 I'm in Ohio. 27:28.080 --> 27:30.620 I've got the clinician dashboard. 27:30.620 --> 27:41.900 On my clinician dashboard here, I can see a green box, which means I'm able to get a good signal from Dave's device in Massachusetts. 27:41.900 --> 27:45.700 Again, all this is communicating over the zero tier secured network. 27:45.800 --> 27:48.180 We're across the country. 27:48.180 --> 27:52.460 We might as well be across the floor in the same hospital. 27:52.560 --> 27:57.200 But I'm getting a good signal back here from Dave's ventilator. 27:57.200 --> 28:03.820 So Dave, if you want to go ahead and trigger your alarm there, we should see an alarm indicated here. 28:05.860 --> 28:06.960 There we go. 28:07.740 --> 28:13.360 The flashing red means the nurse at their dashboard needs to go in and check the patient room. 28:13.880 --> 28:17.180 And as soon as we shut it off, the alarm should go off as well. 28:21.490 --> 28:24.370 Okay, so that's our demo. 28:24.370 --> 28:27.450 So like you see, it's a basic working system. 28:27.450 --> 28:38.110 It's fairly simple at this point, but we do have the capability to monitor up to 40 ventilators from one dashboard, and it's extensible. 28:38.110 --> 28:44.030 So we have libraries that can easily incorporate any number of devices. 28:44.030 --> 28:51.490 Pretty much any device that's got some kind of hardware, digital or analog output, we can tie this into our system. 28:51.490 --> 28:54.690 Very, very adaptable system. 28:55.250 --> 28:58.270 So just some acknowledgments for all of our developers. 28:58.270 --> 29:04.050 I was really honored to be a part of a team of so many people much smarter than myself. 29:04.390 --> 29:08.350 Really fun and really great to work with this team. 29:08.350 --> 29:13.850 David and I led the project, but we have a bunch of other open source contributors here. 29:13.850 --> 29:22.130 Everybody volunteered their time and effort, sacrificed their nights and weekends to really just, you know, contribute to the COVID cause. 29:23.810 --> 29:29.890 Working to express my appreciation for everyone's time and effort here. 29:29.890 --> 29:34.950 Really inspired to see so many people come together on such a short time frame. 29:34.950 --> 29:36.230 Thanks to everybody. 29:36.230 --> 29:37.790 Organizations here. 29:37.790 --> 29:45.330 I just want to thank all the organizations, GHS and FDA for their infrastructure and their funding. 29:45.330 --> 29:57.230 Maker Gear for contributing development time from a number of engineers and also open sourcing the code base and contributing hardware resources. 29:57.350 --> 30:03.250 Massachusetts General Hospital and their affiliates for everything they've done and expertise they've provided. 30:03.250 --> 30:09.990 MITRE for its code review and consulting and just expertise and late night phone calls. 30:10.230 --> 30:14.270 Protocol Labs for special thanks for contributing some funding. 30:14.790 --> 30:15.730 Sound Ear. 30:15.970 --> 30:27.550 So we contacted Sound Ear, one of the manufacturers of our sound interface device, and we asked them for help on a very short time frame and they were incredibly supportive. 30:27.810 --> 30:33.230 Not only did they give us technical support, engineering consultation, they open sourced a portion of their code for us. 30:33.250 --> 30:34.450 You'll see that on GitHub. 30:34.450 --> 30:41.750 So I cannot have... I cannot imagine a better response from a manufacturer in a time of crisis. 30:41.750 --> 30:48.450 They were incredibly forthcoming and I cannot thank them enough for helping us to integrate their device into our system. 30:48.670 --> 30:53.250 And last but not least, VeriCode for their automated security review. 30:53.250 --> 31:00.790 So if you would like to become a contributor or customer or sponsor, you know, please reach out to us. 31:00.790 --> 31:03.790 You can find me or Dave on LinkedIn. 31:04.270 --> 31:11.450 And I just want to give an extra shout out to everybody who worked on this project and an extra thanks to everyone. 31:11.450 --> 31:17.490 It was really inspiring to see so many people involved in this and in such a selfless way. 31:17.490 --> 31:21.870 It really gives me hope for the future that we can really nip this thing in the bud. 31:22.050 --> 31:23.250 So thanks to everyone.