1
00:00:00,000 --> 00:00:05,020
Welcome, everybody, to the Open Ventilator Remote Monitoring Project.

2
00:00:05,020 --> 00:00:07,040
This was a project that we did.

3
00:00:07,040 --> 00: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.

4
00:00:20,040 --> 00:00:24,060
So, by way of introduction, my name is Sam Cervantes.

5
00:00:24,060 --> 00:00:28,900
I'm the Chief Technology Officer at MakerGear 3D printers based out of Cleveland, Ohio.

6
00:00:28,900 --> 00:00:33,140
And also leading the project with me is Dave Guthrie.

7
00:00:33,140 --> 00:00:38,240
He's the Medical Device Cybersecurity Program Manager at Mass General Brigham Healthcare.

8
00:00:38,240 --> 00: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.

9
00:00:43,920 --> 00:00:45,660
So, over to you, Dave.

10
00:00:46,060 --> 00:00:50,600
Okay, so this has been the year of COVID.

11
00:00:50,600 --> 00:00:53,440
We've all been impacted by this global pandemic.

12
00:00:53,440 --> 00:00:58,560
And early on in this pandemic, there were fears of massive shortages of ventilators.

13
00:00:58,560 --> 00:01:05,740
For example, Governor Cuomo of New York predicted there would be 26,000 people who could die from ventilator shortages.

14
00:01:05,740 --> 00:01:09,520
In Italy, they stopped intubating patients over the age of 60.

15
00:01:09,520 --> 00:01:16,460
And the New England Journal of Medicine predicted a need of anywhere from 160,000 to over a million.

16
00:01:17,040 --> 00:01:19,160
So, there's a global pandemic.

17
00:01:19,300 --> 00:01:24,240
Early on in this, Massachusetts has hit pretty hard by this as far as the United States is concerned.

18
00:01:24,240 --> 00:01:31,500
Mass General Brigham is the largest healthcare provider in Massachusetts and has a significant need for ventilators.

19
00:01:31,840 --> 00: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.

20
00:01:44,860 --> 00:01:48,380
And you need to do this in a massively condensed timeline.

21
00:01:48,380 --> 00:01:51,500
So, typical medical device development takes two to three years.

22
00:01:51,500 --> 00:01:54,040
This needed to be done in two to three weeks.

23
00:01:54,060 --> 00:01:55,020
Crazy!

24
00:01:55,940 --> 00:02:03,620
So, Mass General Brigham reaches out to the open-source community to develop rapid prototype ventilators.

25
00:02:03,620 --> 00:02:05,600
Open-source community responds.

26
00:02:05,760 --> 00:02:09,920
This is an example of just some of the resources that the open-source community has provided.

27
00:02:09,920 --> 00:02:13,600
And Sam is going to go into this in more detail later in this presentation.

28
00:02:14,160 --> 00:02:17,460
So, now you have the open-source community at the ready.

29
00:02:17,460 --> 00:02:23,340
Working groups are starting to form to develop hardware systems, control software, and remote monitoring software.

30
00:02:23,340 --> 00:02:27,660
All of these are being done in parallel under this condensed timeline.

31
00:02:28,180 --> 00:02:31,920
So, what's the initial need and scope of this project?

32
00:02:31,920 --> 00:02:34,760
So, you have this predicted ventilator shortage.

33
00:02:34,760 --> 00:02:38,740
You have a need for these rapid prototype ventilators that the community is now building.

34
00:02:38,740 --> 00:02:42,320
However, most of these ventilators lack built-in monitoring.

35
00:02:42,320 --> 00: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.

36
00:02:50,520 --> 00: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.

37
00:03:01,580 --> 00: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.

38
00:03:10,100 --> 00:03:15,240
And you have ventilator systems that can then plug into these bedside monitors to jump onto this network.

39
00:03:15,240 --> 00:03:18,480
And then you can monitor these ventilator systems as well.

40
00:03:18,480 --> 00:03:21,020
Well, you can't do that with these rapid prototype ventilators.

41
00:03:21,020 --> 00:03:25,440
So, you have these open source teams actively developing these ventilators.

42
00:03:25,440 --> 00:03:29,640
And now you need to have remote monitoring and central monitoring of these systems.

43
00:03:29,640 --> 00:03:31,760
That's where this team comes into play.

44
00:03:31,760 --> 00:03:35,120
And it initiated in April 2nd of 2020.

45
00:03:35,260 --> 00:03:39,420
So, what's the clinical request and the need for this remote monitoring software?

46
00:03:39,420 --> 00:03:42,340
So, you have this rapid prototype ventilator groups.

47
00:03:42,420 --> 00:03:46,040
They're not integrated into central monitoring traditionally with hospitals.

48
00:03:46,040 --> 00:03:50,380
So, you need a method of monitoring of all your ventilators on a given floor or a given unit.

49
00:03:50,380 --> 00:03:54,140
You have to have a central dashboard with visual learning that's easily interpretable.

50
00:03:54,140 --> 00:03:58,280
You have to be able to ingest device data from all these ventilators.

51
00:03:58,280 --> 00: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.

52
00:04:07,160 --> 00:04:12,040
And again, you have to do this in this wicked condensed timeline of two to three weeks.

53
00:04:12,040 --> 00:04:15,600
And you shouldn't cause patient harm or interruption in patient care.

54
00:04:15,600 --> 00:04:19,100
Because if you do that, you're defeating the purpose of helping clinical staff.

55
00:04:19,100 --> 00:04:23,220
And instead, you're getting in the way and potentially causing patient harm.

56
00:04:23,220 --> 00:04:26,600
So, this is where Sam's company, MakerGear, comes into play.

57
00:04:26,600 --> 00:04:28,840
They have a 3D printing company.

58
00:04:28,840 --> 00:04:35,980
And they have software that has the ability to integrate with physical hardware as well as providing a centralized dashboard.

59
00:04:35,980 --> 00: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.

60
00:04:45,120 --> 00:04:51,480
So, now what happens is we're actively developing all of these rapid prototype ventilators.

61
00:04:51,480 --> 00:04:58,540
And the remote monitoring team is working on integrating with these ventilator teams in order to build a central monitoring system.

62
00:04:58,540 --> 00:05:05,620
However, simultaneously, hospitals are procuring ventilators left and right.

63
00:05:05,620 --> 00:05:09,760
You're trying to build up your ventilator inventory from traditional commercial vendors.

64
00:05:09,840 --> 00:05:16,580
And what happens is there was not a need to then deploy these rapid prototype ventilators.

65
00:05:16,580 --> 00:05:21,120
Because you're sharing up your inventory of already off-the-shelf commercial ventilators.

66
00:05:21,220 --> 00: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.

67
00:05:28,860 --> 00:05:35,260
And so, the amount of time to design these integrations was extremely costly, resource-intensive.

68
00:05:35,260 --> 00:05:37,960
And you just can't do that in an emergency response situation.

69
00:05:37,960 --> 00:05:42,360
So, you have new commercial ventilators that can't integrate into your central monitoring system.

70
00:05:42,360 --> 00:05:47,540
On top of that, you have infection control restrictions because this is a global pandemic.

71
00:05:47,540 --> 00:05:51,140
So, you have closed doors for infection control reasons.

72
00:05:51,140 --> 00:05:55,240
You have ventilators inside of these rooms that can't be centrally monitored.

73
00:05:55,240 --> 00:05:57,960
And now you have alarms going off with these ventilators.

74
00:05:57,960 --> 00:06:02,300
Now clinical staff are having trouble hearing alarms through these closed doors.

75
00:06:02,300 --> 00: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.

76
00:06:14,300 --> 00:06:16,280
So, what's our plan of attack?

77
00:06:16,300 --> 00:06:20,320
So, MGH Biomed, for example, researched off-the-shelf sound monitoring solutions.

78
00:06:20,320 --> 00:06:23,700
They vectored in on one product, the SoundEar.

79
00:06:23,700 --> 00:06:29,800
So, the SoundEar can deploy a one-to-one system per patient room per ventilator.

80
00:06:29,800 --> 00:06:34,320
It's a self-contained consumer off-the-shelf system that can monitor sound pressure.

81
00:06:34,320 --> 00:06:41,960
So, you can hook a SoundEar with a microphone up to the speaker on the ventilator that auditorily alerts the alarm.

82
00:06:42,120 --> 00:06:46,680
And then when the sound pressure is exceeded, when that alarm goes off, the SoundEar can then trip.

83
00:06:46,680 --> 00: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.

84
00:06:57,680 --> 00:07:01,880
And now, I'm going to pass it over to Sam to go into the architecture.

85
00:07:01,940 --> 00:07:02,720
Thanks, Dave.

86
00:07:03,620 --> 00: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.

87
00:07:11,580 --> 00:07:15,640
And then also, later on, some of the future goals.

88
00:07:15,640 --> 00:07:20,100
So, this right here, this is the user interface for the clinician.

89
00:07:20,280 --> 00:07:23,460
This is the whole goal of the entire project right here.

90
00:07:23,780 --> 00:07:27,100
So, this is what the nurse is going to see at the nursing station.

91
00:07:27,100 --> 00:07:30,160
We've got one little box here for each ventilator.

92
00:07:30,160 --> 00:07:35,540
So, we've got, in this case, 48 ventilators monitored from our single dashboard.

93
00:07:35,540 --> 00:07:42,320
So, this is every ventilator on the entire floor of the hospital monitored from one central dashboard.

94
00:07:42,560 --> 00:07:47,480
So, we've got three states of a ventilator right here that we can display.

95
00:07:47,960 --> 00:07:50,460
The normal state, the happy state, is green.

96
00:07:50,460 --> 00:07:53,560
That means we're able to ping the ventilator.

97
00:07:53,560 --> 00:07:56,940
We're getting a good status report back and there's no alarm.

98
00:07:56,940 --> 00:07:58,200
All is good.

99
00:07:58,560 --> 00:08:03,080
The second state is this gray strikethrough box right here.

100
00:08:03,480 --> 00:08:07,660
That means we're not able to even connect with the ventilator.

101
00:08:07,660 --> 00:08:10,040
So, a technician needs to go check on the ventilator.

102
00:08:10,040 --> 00:08:12,380
So, there's a fault in the system somewhere.

103
00:08:12,900 --> 00:08:16,160
The third state is this red box here.

104
00:08:16,160 --> 00:08:18,840
And that will actually flash, you'll see in the live demo.

105
00:08:18,840 --> 00:08:23,960
And that means an alarm is currently being triggered on the ventilator.

106
00:08:23,960 --> 00:08:26,220
So, the nurse needs to go check on it.

107
00:08:26,220 --> 00: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.

108
00:08:33,980 --> 00:08:35,740
I need to go check on those.

109
00:08:39,960 --> 00:08:42,440
Okay, so how do we go about doing this?

110
00:08:43,700 --> 00:08:47,780
Typical deployment process for software like this is two to three years.

111
00:08:47,780 --> 00:08:49,200
We had two to three weeks.

112
00:08:49,200 --> 00:08:50,860
COVID-19 emergency.

113
00:08:51,340 --> 00:08:53,920
So, how do we go about pulling this off?

114
00:08:54,260 --> 00:08:59,560
Basically, we had to pull all the rapid prototyping software development strategies.

115
00:08:59,560 --> 00:09:01,100
We had to move fast and break things.

116
00:09:01,100 --> 00:09:04,580
We rely heavily on the open source community and the maker communities.

117
00:09:04,880 --> 00:09:11,880
Distributed development, we had software developers all over the country pushing to our GitHub repo.

118
00:09:11,880 --> 00:09:17,560
We had to hack and fork existing products to get something out in just a few weeks.

119
00:09:17,560 --> 00: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.

120
00:09:31,020 --> 00:09:33,540
We had to rely on remote lab testing.

121
00:09:34,120 --> 00:09:37,360
And as much as we could, you know, source locally.

122
00:09:37,360 --> 00:09:40,740
Component sourcing was a key thing.

123
00:09:40,740 --> 00:09:48,200
We had to design our system around the components that we could actually source that were in stock and locally available.

124
00:09:48,520 --> 00:09:54,420
We might have wanted to use a PLC or a custom circuit board, but we didn't have time.

125
00:09:54,420 --> 00: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.

126
00:10:03,780 --> 00:10:08,880
So, basically, we had to move heaven and earth to ship something in a very short amount of time.

127
00:10:08,880 --> 00:10:14,420
Like Dave said, the initial code base was hacked from MakerGear software.

128
00:10:14,420 --> 00:10:16,820
So, MakerGear manufactures 3D printers.

129
00:10:17,000 --> 00:10:19,980
Been doing so for about 10 years out of Cleveland, Ohio.

130
00:10:19,980 --> 00:10:26,400
And it just so happened that MakerGear had some software for remotely monitoring 3D printers.

131
00:10:26,420 --> 00:10:32,460
And as it turns out, a 3D printer is an awful lot like a do-it-yourself ventilator.

132
00:10:32,460 --> 00:10:39,680
A 3D printer has an Arduino and a Raspberry Pi, and a ventilator has an Arduino and a Raspberry Pi.

133
00:10:39,680 --> 00:10:50,400
So, we were able to adapt and import the software to quickly meet the needs of the pandemic.

134
00:10:50,400 --> 00:10:53,080
So, this is the overall architecture here.

135
00:10:53,080 --> 00:10:55,500
So, you'll see the dashboard is what we saw before.

136
00:10:55,500 --> 00:10:59,000
The dashboard is the kind of central brains, if you will.

137
00:10:59,440 --> 00:11:02,180
All information flows towards the dashboard.

138
00:11:02,660 --> 00:11:05,980
So, this is the clinician interface here.

139
00:11:06,600 --> 00:11:12,100
So, the dashboard is going to get its status data in real time from the ventilators.

140
00:11:12,100 --> 00:11:14,540
You'll see three ventilators displayed down here.

141
00:11:14,540 --> 00:11:17,400
Each ventilator is in a different configuration.

142
00:11:18,220 --> 00:11:20,080
And you'll see the cloud up here.

143
00:11:20,080 --> 00:11:25,080
So, the cloud is there only to serve up the application to the browser.

144
00:11:25,080 --> 00:11:27,940
And the cloud doesn't store patient data.

145
00:11:27,940 --> 00:11:32,740
The cloud simply stores configuration data for the app.

146
00:11:32,740 --> 00:11:33,980
A very limited amount of data.

147
00:11:33,980 --> 00:11:35,940
We don't send patient data to the cloud.

148
00:11:36,760 --> 00:11:41,720
So, how does the dashboard get its information from each of the ventilators?

149
00:11:41,900 --> 00: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.

150
00:11:48,940 --> 00:11:53,240
And we wanted to make a universal system to pull data from every ventilator.

151
00:11:53,240 --> 00:11:56,120
Some ventilators are controlled by an Arduino.

152
00:11:56,260 --> 00:11:59,920
One of the MIT designs was controlled by an Arduino.

153
00:12:00,760 --> 00:12:03,900
Some ventilators were controlled by a Raspberry Pi.

154
00:12:03,900 --> 00:12:06,380
I think the JamBest design used that.

155
00:12:06,620 --> 00:12:08,780
And then some ventilators are a little different.

156
00:12:08,920 --> 00:12:16,300
So, we wanted to have a sound ear, a separate appliance to listen to the sound the ventilator is making.

157
00:12:16,300 --> 00:12:18,240
And then trigger it a lot based on that.

158
00:12:18,240 --> 00: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.

159
00:12:28,640 --> 00:12:33,160
So, the Raspberry Pi could serve as a kind of universal network interface.

160
00:12:33,740 --> 00:12:37,020
And on the Raspberry Pi, we have a library.

161
00:12:37,820 --> 00:12:44,560
And so, we can write modules for this library to basically ingest data from any system.

162
00:12:44,560 --> 00: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.

163
00:12:52,420 --> 00: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.

164
00:13:04,440 --> 00:13:06,360
So, this is the overall architecture.

165
00:13:07,780 --> 00:13:14,380
And the specific instance that we tested in the lab was this particular architecture here.

166
00:13:15,320 --> 00:13:18,820
So, the ventilator is obviously going to be in the patient's room.

167
00:13:19,240 --> 00:13:28,940
And then also in the patient's room is the SoundEar device, which listens for an audio alarm from the ventilator.

168
00:13:28,940 --> 00:13:31,960
So, the ventilator is going to emit a beep, and you'll hear this in the demo.

169
00:13:31,960 --> 00:13:33,340
It's going to emit a beep.

170
00:13:33,340 --> 00:13:36,720
The SoundEar is going to detect that audio beep, that sound pressure.

171
00:13:36,840 --> 00: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.

172
00:13:43,020 --> 00:13:49,260
And then the Raspberry Pi is going to then send the alarm to the dashboard that we saw earlier.

173
00:13:51,100 --> 00: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.

174
00:14:10,900 --> 00:14:12,060
And of course, you've got the cloud here.

175
00:14:12,060 --> 00:14:14,740
And again, we're not storing patient data on the cloud.

176
00:14:14,740 --> 00: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.

177
00:14:26,020 --> 00:14:33,520
And again, this is what the nurse is going to see at his or her station right here at the dashboard.

178
00:14:35,280 --> 00:14:38,700
Software stack, we're getting a little bit into the weeds here.

179
00:14:38,700 --> 00:14:42,320
We tried to use as much open-source software as we could here.

180
00:14:42,320 --> 00:14:47,020
Ruby on Rails, reliable, secure, open-source, very quick to deploy.

181
00:14:48,220 --> 00:14:55,040
Raspberry Pis and Arduinos, again, open-source, off-the-shelf, quick to deploy.

182
00:14:56,540 --> 00: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.

183
00:15:05,500 --> 00:15:09,660
GPLv3 is a very permissive license.

184
00:15:09,980 --> 00:15:12,920
You can use it for commercial and or non-commercial.

185
00:15:13,300 --> 00:15:19,560
We wanted hospitals to be able to use this very quickly, and you can see our GitHub link here below.

186
00:15:19,560 --> 00:15:21,480
Everything we have is up on GitHub.

187
00:15:23,240 --> 00:15:24,860
We did a lot of testing.

188
00:15:24,860 --> 00:15:30,380
At-home testing, workbench testing, we did lab testing.

189
00:15:30,540 --> 00: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.

190
00:15:36,940 --> 00:15:39,320
And it actually worked pretty well.

191
00:15:39,420 --> 00:15:44,680
We got a very solid proof-of-concept alpha.

192
00:15:44,980 --> 00:15:49,400
We didn't quite make it through the beta phase, but we got a pretty good alpha prototype.

193
00:15:50,360 --> 00: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.

194
00:16:00,200 --> 00: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.

195
00:16:13,160 --> 00:16:16,880
We just wanted to give you a flavor of what that is right here.

196
00:16:17,080 --> 00: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.

197
00:16:30,280 --> 00:16:37,240
Basically, for the hazard analysis, we had to brainstorm every possible way that this product might fail.

198
00:16:37,240 --> 00:16:45,940
It would either fail to communicate an alarm to the central station or fail in some other way.

199
00:16:46,800 --> 00:16:54,160
Every method we predicted that it might fail, we had to put a contingency plan in place for.

200
00:16:54,820 --> 00:16:56,120
Very detailed, again.

201
00:16:56,120 --> 00: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.

202
00:17:06,760 --> 00:17:12,320
It's a very rigorous process to prepare for FDA approval and hospital approval.

203
00:17:12,320 --> 00:17:14,320
Just a little taste of that right here.

204
00:17:15,940 --> 00:17:18,500
Again, this is the detailed software architecture.

205
00:17:18,780 --> 00:17:20,300
If you want to take a look at that.

206
00:17:20,400 --> 00:17:25,100
All these documents are up on our GitHub wiki, so you can check those out there.

207
00:17:27,240 --> 00: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.

208
00:17:39,560 --> 00:17:47,680
The staff at MITRE did a very nice job and lent their support, so we're very grateful to them.

209
00:17:47,680 --> 00:17:53,100
They used an automated code service called VeriCode and also a manual code review.

210
00:17:53,100 --> 00:17:56,280
Still ongoing, but they were a big help with that.

211
00:17:56,280 --> 00:18:00,660
Just to give you a taste of the automated code review.

212
00:18:00,660 --> 00:18:06,860
This was a code review on, I think, a Ruby on Rails portion of the application.

213
00:18:07,080 --> 00:18:16,280
Basically, you see here, we don't have any severe alerts, but we had a couple of medium alerts.

214
00:18:17,560 --> 00:18:27,660
We had some automated testing code that spit out automated test data, so we need to remove that before deployment.

215
00:18:27,760 --> 00:18:29,620
One little minor thing here.

216
00:18:29,620 --> 00:18:31,080
A few things to fix.

217
00:18:31,260 --> 00:18:33,080
Manual code review.

218
00:18:33,380 --> 00:18:34,500
Again, just a few things.

219
00:18:34,500 --> 00:18:35,640
Nothing critical.

220
00:18:35,640 --> 00:18:37,020
A few things to fix.

221
00:18:37,020 --> 00:18:44,500
We just want to give a little insight into how we went about testing and validating our code.

222
00:18:44,500 --> 00:18:46,520
We learned a lot in this project.

223
00:18:46,520 --> 00: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.

224
00:18:57,700 --> 00:19:02,040
A lot of us were software developers, so these are some of the lessons we learned.

225
00:19:02,040 --> 00: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.

226
00:19:17,280 --> 00:19:20,000
So that was really inspiring.

227
00:19:20,000 --> 00:19:24,500
The biggest hurdles we found were not necessarily the technology.

228
00:19:24,500 --> 00: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.

229
00:19:33,000 --> 00:19:39,620
The validation and approval were much more rigorous and time-involved than we anticipated.

230
00:19:40,160 --> 00:19:45,500
All that being said, FDA approval is daunting, but it's not impossible.

231
00:19:45,500 --> 00:19:48,840
And there are experts out there that are willing to help, and that's what we found.

232
00:19:48,940 --> 00:19:54,700
A lot of really good people with a lot of deep FDA experience out there that are willing to help.

233
00:19:54,960 --> 00:19:57,740
So it's not undoable.

234
00:20:00,000 --> 00:20:07,120
We found it's very important to be aware of HIPAA and personal identifiable information.

235
00:20:07,120 --> 00:20:11,500
So that's one reason we chose not to send patient data to the cloud.

236
00:20:12,580 --> 00:20:16,020
It's very important to be cognizant of HIPAA.

237
00:20:16,020 --> 00: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.

238
00:20:33,400 --> 00: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.

239
00:20:44,680 --> 00:20:48,880
And ultimately, we learned we didn't have a ventilator shortage in the U.S., which is great news.

240
00:20:48,880 --> 00:20:51,480
So ultimately, our software was not needed.

241
00:20:51,480 --> 00: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.

242
00:21:03,640 --> 00:21:06,600
to go around for people who needed them.

243
00:21:08,240 --> 00:21:10,060
So FDA approval.

244
00:21:10,740 --> 00:21:17,940
We just wanted to give you a little flavor of kind of the difficulties we found in the FDA approval process.

245
00:21:18,200 --> 00: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.

246
00:21:24,300 --> 00:21:27,480
Seek expert advice for your own project.

247
00:21:27,480 --> 00:21:31,200
But it's just a high-level overview of some of the things I learned.

248
00:21:31,700 --> 00: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.

249
00:21:44,040 --> 00: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.

250
00:21:53,760 --> 00:22:04,520
During the emergency, for example, the COVID emergency, the FDA allows a couple types of new approvals.

251
00:22:04,520 --> 00:22:08,500
One is what's called EAU, Emergency Use Authorization.

252
00:22:08,960 --> 00:22:11,260
Typically, it can be fast-tracked in two to three months.

253
00:22:11,260 --> 00:22:17,600
It's much quicker, but EAU is only valid for the duration of the emergency.

254
00:22:17,600 --> 00: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.

255
00:22:28,120 --> 00:22:31,260
And then Compassionate Use is potentially even quicker.

256
00:22:32,360 --> 00: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.

257
00:22:44,300 --> 00: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.

258
00:22:51,860 --> 00:22:57,200
There was even a little bit of discussion as to how to classify our software system.

259
00:22:57,200 --> 00:22:58,940
Is this a medical device?

260
00:22:59,000 --> 00:23:02,440
Is it a modification to an existing medical device?

261
00:23:02,440 --> 00:23:04,000
Or is it not a medical device?

262
00:23:04,000 --> 00:23:09,340
Is it a baby monitor or a pager or like a cell phone type device?

263
00:23:09,340 --> 00:23:12,480
So we did have some ongoing debate about that.

264
00:23:13,960 --> 00:23:16,200
So current status of the project.

265
00:23:16,460 --> 00:23:19,860
We've drafted up our validation documents for approval.

266
00:23:20,400 --> 00:23:22,940
We have a working demo proof of concept.

267
00:23:22,940 --> 00:23:23,860
I called it Alpha.

268
00:23:23,860 --> 00:23:24,340
It works.

269
00:23:24,340 --> 00:23:25,040
We tested it in the lab.

270
00:23:25,040 --> 00:23:26,300
We had a code review.

271
00:23:26,500 --> 00:23:30,080
We do not currently have a customer for the project.

272
00:23:30,080 --> 00:23:32,120
Our project is currently parked.

273
00:23:32,120 --> 00:23:39,780
So if you have a potential use for the software, do let us know.

274
00:23:39,780 --> 00:23:44,340
We would love to see our software be used for a good purpose.

275
00:23:44,720 --> 00:23:46,160
Future plans.

276
00:23:47,040 --> 00: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.

277
00:23:58,880 --> 00:24:09,200
And potential AI machine learning to detect different types of audio alarms from different types of medical devices.

278
00:24:09,880 --> 00:24:14,280
We're going to search continually for new customers.

279
00:24:15,040 --> 00:24:19,740
Potential customers may be hospitals with limited resources.

280
00:24:19,880 --> 00:24:24,160
Smaller hospitals in remote areas or developing countries.

281
00:24:25,140 --> 00:24:34,720
And then potentially healthcare organizations with needs to monitor other devices, like pulse oximeters or things like that.

282
00:24:34,720 --> 00:24:41,940
And we're continuing our search for a corporate sponsor, an entity to own the maintenance, installation, support, and liability.

283
00:24:41,940 --> 00:24:46,680
So we're just a group of distributed open source software developers.

284
00:24:46,820 --> 00:24:49,960
We don't have an organization behind us.

285
00:24:50,520 --> 00:24:56,840
And then potentially a future FDA application, again, if we find a customer for this.

286
00:24:58,080 --> 00:25:03,780
So Dave's going to talk a little bit about the power and the possibilities.

287
00:25:03,920 --> 00: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.

288
00:25:12,440 --> 00:25:19,360
You have rapid prototype ventilator monitoring systems that we've discussed, such as bringing in device and patient data.

289
00:25:19,360 --> 00:25:26,460
You have commercial ventilators that are not traditionally integrated with central monitoring systems that you can monitor through sound.

290
00:25:26,460 --> 00:25:29,020
So you can get ventilator alarms from commercial ventilators.

291
00:25:29,020 --> 00:25:35,280
And now with the sound monitoring, you can monitor any medical device alarm that is based in audio.

292
00:25:35,280 --> 00: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.

293
00:25:47,800 --> 00:25:49,660
This could be huge.

294
00:25:49,660 --> 00:25:56,360
So this project has great potential to have a massive impact in the healthcare ecosystem.

295
00:25:56,360 --> 00:25:59,680
Now for the fun part, we've got a live hardware demo.

296
00:25:59,680 --> 00:26:04,040
So we're going to show you the system in operation.

297
00:26:04,080 --> 00:26:12,300
So Dave in Massachusetts has what would be in the patient room.

298
00:26:12,300 --> 00:26:18,920
On this picture is what's on the bench here in Massachusetts.

299
00:26:19,100 --> 00: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.

300
00:26:24,320 --> 00:26:34,020
So you have the speaker in the background next to the cyber lizard who has a microphone next to the speaker.

301
00:26:34,060 --> 00:26:37,800
That microphone is plugged into the sound ear.

302
00:26:37,800 --> 00:26:42,620
The sound ear is then going to calculate the sound pressure.

303
00:26:42,780 --> 00:26:45,340
And it has what's called a sound buster port.

304
00:26:45,340 --> 00:26:51,180
That sound buster port changes voltage if the audio alarm pressure is tripped.

305
00:26:51,240 --> 00:26:55,900
So then the sound buster port comes out of the sound ear into this Raspberry Pi.

306
00:26:56,020 --> 00: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.

307
00:27:03,860 --> 00:27:11,260
Out over the open internet through the encrypted zero tier tunnel over to Sam where he's running the dashboard.

308
00:27:12,340 --> 00: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.

309
00:27:22,540 --> 00:27:24,360
So Dave, you've got the ventilator system.

310
00:27:24,360 --> 00:27:26,800
You've got the patient side system in Massachusetts.

311
00:27:26,800 --> 00:27:28,080
I'm in Ohio.

312
00:27:28,080 --> 00:27:30,620
I've got the clinician dashboard.

313
00:27:30,620 --> 00: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.

314
00:27:41,900 --> 00:27:45,700
Again, all this is communicating over the zero tier secured network.

315
00:27:45,800 --> 00:27:48,180
We're across the country.

316
00:27:48,180 --> 00:27:52,460
We might as well be across the floor in the same hospital.

317
00:27:52,560 --> 00:27:57,200
But I'm getting a good signal back here from Dave's ventilator.

318
00:27:57,200 --> 00:28:03,820
So Dave, if you want to go ahead and trigger your alarm there, we should see an alarm indicated here.

319
00:28:05,860 --> 00:28:06,960
There we go.

320
00:28:07,740 --> 00:28:13,360
The flashing red means the nurse at their dashboard needs to go in and check the patient room.

321
00:28:13,880 --> 00:28:17,180
And as soon as we shut it off, the alarm should go off as well.

322
00:28:21,490 --> 00:28:24,370
Okay, so that's our demo.

323
00:28:24,370 --> 00:28:27,450
So like you see, it's a basic working system.

324
00:28:27,450 --> 00: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.

325
00:28:38,110 --> 00:28:44,030
So we have libraries that can easily incorporate any number of devices.

326
00:28:44,030 --> 00: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.

327
00:28:51,490 --> 00:28:54,690
Very, very adaptable system.

328
00:28:55,250 --> 00:28:58,270
So just some acknowledgments for all of our developers.

329
00:28:58,270 --> 00:29:04,050
I was really honored to be a part of a team of so many people much smarter than myself.

330
00:29:04,390 --> 00:29:08,350
Really fun and really great to work with this team.

331
00:29:08,350 --> 00:29:13,850
David and I led the project, but we have a bunch of other open source contributors here.

332
00:29:13,850 --> 00:29:22,130
Everybody volunteered their time and effort, sacrificed their nights and weekends to really just, you know, contribute to the COVID cause.

333
00:29:23,810 --> 00:29:29,890
Working to express my appreciation for everyone's time and effort here.

334
00:29:29,890 --> 00:29:34,950
Really inspired to see so many people come together on such a short time frame.

335
00:29:34,950 --> 00:29:36,230
Thanks to everybody.

336
00:29:36,230 --> 00:29:37,790
Organizations here.

337
00:29:37,790 --> 00:29:45,330
I just want to thank all the organizations, GHS and FDA for their infrastructure and their funding.

338
00:29:45,330 --> 00: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.

339
00:29:57,350 --> 00:30:03,250
Massachusetts General Hospital and their affiliates for everything they've done and expertise they've provided.

340
00:30:03,250 --> 00:30:09,990
MITRE for its code review and consulting and just expertise and late night phone calls.

341
00:30:10,230 --> 00:30:14,270
Protocol Labs for special thanks for contributing some funding.

342
00:30:14,790 --> 00:30:15,730
Sound Ear.

343
00:30:15,970 --> 00: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.

344
00:30:27,810 --> 00:30:33,230
Not only did they give us technical support, engineering consultation, they open sourced a portion of their code for us.

345
00:30:33,250 --> 00:30:34,450
You'll see that on GitHub.

346
00:30:34,450 --> 00:30:41,750
So I cannot have... I cannot imagine a better response from a manufacturer in a time of crisis.

347
00:30:41,750 --> 00:30:48,450
They were incredibly forthcoming and I cannot thank them enough for helping us to integrate their device into our system.

348
00:30:48,670 --> 00:30:53,250
And last but not least, VeriCode for their automated security review.

349
00:30:53,250 --> 00:31:00,790
So if you would like to become a contributor or customer or sponsor, you know, please reach out to us.

350
00:31:00,790 --> 00:31:03,790
You can find me or Dave on LinkedIn.

351
00:31:04,270 --> 00: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.

352
00:31:11,450 --> 00:31:17,490
It was really inspiring to see so many people involved in this and in such a selfless way.

353
00:31:17,490 --> 00:31:21,870
It really gives me hope for the future that we can really nip this thing in the bud.

354
00:31:22,050 --> 00:31:23,250
So thanks to everyone.