We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Biohacking Village - Open Remote Ventilator Monitoring Project

00:00
subtitles
off
playback rate
1
subtitles
off
English (auto-generated)
playback rate
0.25
0.5
0.75
1
1.25
1.5
1.75
2
quality
576p
1
 Cite
 Share
 Download Purchase
No logo availableDEF CON
 Cervantes, Sam Guffrey, David A.

Formal Metadata

Title
Biohacking Village - Open Remote Ventilator Monitoring Project
Title of Series
Number of Parts
374
Author
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
2020 has been the year of COVID-19. The healthcare sector has been on the frontlines of battling this pandemic. There was significant projected demand for rapidly-manufactured ventilators during the early stages of the COVID-19 pandemic in the United States. Massachusetts was hard hit during the early stages of this pandemic, and the state’s largest healthcare delivery organization brought together the open source community to develop new technologies and processes for rapidly developing resources needed to treat predicted growth of infections. The open source community came together to develop rapid prototype ventilators that could be potentially mass produced in quick succession. Many of these devices did not have built-in monitoring capabilities, so there was an anticipated need for staff to adequately track alarms in a centralized manner for these devices. The Open Ventilator Monitoring Project addressed this need by rapidly creating a system that allows hospitals to monitor alarms and patient data from ventilators, integrating the status of multiple devices into a single display, similar to a central nursing station. During the design process of this project, an additional need was brought to the team’s attention. Due to infection control procedures that require closing doors to patient rooms, clinical staff were unable to hear alarms from ventilators that were not already integrated into a traditional central monitoring system. The team then pivoted to develop a solution to modify the hardware and software system to include the ability to auditorily monitor and alert based on the sound pressure of these ventilator alarms. To date, the team has delivered a Minimum Viable Product (MVP), which has undergone limited lab testing in the Massachusetts General Hospital’s Medical Device Interoperability and Cybersecurity Program Lab (MGH MD PnP). The project has longer term goals of safety/integration, and ultimately, deployment within settings such as field hospitals. It is expected that this project's capabilities may be useful to many hospitals, extending beyond the constantly-changing emergency of COVID-19's spread. While the software has been designed to monitor ventilators, the project's architecture - utilizing APIs and plugins - is extensible to other network environments and other device types. Ultimately, hospitals in the U.S. have not experienced a shortage of traditional ventilators, and so our software was not needed during the Covid-19 crisis. However, we present a framework for rapidly developing software in crisis situations along with a set of lessons learned for those who follow in future crises.
00:00
Open setComputer programMassRemote procedure callMassComputer programSoftwareInformation securityCybersexOpen sourceOffice suiteDescriptive statisticsDigital rights managementOpen set
00:46
NumberMassComputer animation
01:16
Pivot elementLocal GroupOpen sourceMulti-agent systemMassSelf-organizationThermodynamischer ProzessBit ratePrototypeSoftware testingMassInternet service providerThermodynamischer ProzessBit rateSoftware developerOrder (biology)
01:56
Local GroupPivot elementOpen sourceSystem callCompass (drafting)Computer hardwarePrototypeComponent-based software engineeringSoftware testingAuthorizationProduct (business)Coma BerenicesOpen sourceRapid PrototypingSoftware developerMassPresentation of a groupSoftwareGroup actionGame controllerRemote procedure callComputer hardwareComputerComputer animation
02:23
Form (programming)Curve fittingSoftwareLocal GroupPrototypeOpen setComputer networkOpen sourceHelixVisual systemCausalityInterrupt <Informatik>SoftwareInterrupt <Informatik>Rapid PrototypingParallel portRepresentation (politics)Staff (military)Workstation <Musikinstrument>Centralizer and normalizerOpen sourceState of matterPhysical systemExecution unitCausalityRemote procedure callVisualization (computer graphics)Group actionValidity (statistics)CodeComputer animation
04:22
SoftwareHacker (term)Open sourceRemote procedure callPhysical systemCodeComputer hardwareSoftwareOrder (biology)Centralizer and normalizerRapid PrototypingComputer animation
05:10
Local GroupPivot elementPrototypeDisintegrationControl flowClosed setHough transformDependent and independent variablesProduct (business)Commercial Orbital Transportation ServicesCAN busDiscrete element methodSingle-precision floating-point formatPhysical systemBijectionArithmetic meanGame controllerINTEGRALProduct (business)Rapid PrototypingCentralizer and normalizerMultiplication signDependent and independent variablesStaff (military)Hooking
06:58
User interfaceWindowOpen sourceSystem callSoftware testingOpen setComponent-based software engineeringSicElectronic data processingArc (geometry)Computer architectureElectronic visual displayConfiguration spaceSoftwareInternational Date LineFunction (mathematics)Computer hardwareStack (abstract data type)Point cloudComputer networkControl flowMachine codeWeb browserComputing platformInterface (computing)Hazard (2005 film)Mathematical analysisDiagramComputer architectureProcess (computing)Cartesian coordinate systemOpen sourceConfiguration spaceInformationMobile appPhysical systemPoint cloudData storage deviceComponent-based software engineeringComputer hardwareCodeEvent horizonDifferent (Kate Ryan album)SoftwareBitRight angleOrder (biology)Centralizer and normalizerLimit (category theory)Information securityNumberModule (mathematics)Universe (mathematics)Software testingRemote procedure callPhase transitionAlpha (investment)Point (geometry)Function (mathematics)Link (knot theory)Type theoryLibrary (computing)PiValidity (statistics)Interface (computing)User interfaceBEEPInstance (computer science)Serial portState of matterSharewareLevel (video gaming)Beat (acoustics)Connected spaceCuboidTraffic reportingGoodness of fitWorkstation <Musikinstrument>PrototypeEntire functionCASE <Informatik>Multiplication signSoftware developerRapid PrototypingSoftware repositoryStrategy gameLetterpress printingProduct (business)Real-time operating systemPacket Loss ConcealmentWeb browserSolid geometryProof theoryOpen setLocal ringDigital electronicsAnalogySource codeComputer animation
16:03
SoftwareMathematical analysisHazard (2005 film)Computer architectureMachine codeOpen setAutomationProcess (computing)AuthorizationMIDIComputer architectureSoftware developerArithmetic progressionFrame problemMultiplication signConfidence intervalCodeProcess (computing)FrequencyProduct (business)AutomationSoftware testingType theoryBitPhysical systemExpert systemProof theorySoftwareValidity (statistics)AuthorizationVirtual machineFlow separationSelf-organizationAdditionAlpha (investment)Staff (military)Vector potentialDifferent (Kate Ryan album)Contingency tableField (computer science)SharewareCausalityOpen sourceInformation securityWikiRemote procedure callRight angleComputer hardwareCartesian coordinate systemGoodness of fitPoint cloudWorkstation <Musikinstrument>Centralizer and normalizerPulse (signal processing)Software maintenanceOnline helpService (economics)AreaHazard (2005 film)MereologyMathematical analysisGroup actionLimit (category theory)InformationIdentifiabilityIdentity managementPower (physics)CognitionSoftware architectureNormal (geometry)Level (video gaming)Set (mathematics)
25:04
Power (physics)Ring (mathematics)INTEGRALPhysical systemCentralizer and normalizerWebsiteRapid PrototypingRemote procedure callPower (physics)MereologyComputer animation
25:56
Computer hardwareSharewareSharewareOperator (mathematics)Computer hardwarePhysical systemInternetworkingCybersexRow (database)VideoconferencingMathematicsConditional-access moduleComputer animation
27:23
Computer hardwareSharewareDataflowPhysical systemAnalogyNumberMultitier architectureCuboidSharewareLibrary (computing)Goodness of fitSoftwareDigitizingComputer hardwarePoint (geometry)Function (mathematics)Computer animation
28:53
Self-organizationOnline helpMultiplication signInformation technology consultingComputer hardwareNumberSystem callPhysical systemSoftware developerDependent and independent variablesOpen sourceCausalityInterface (computing)CodeWordMereologyAutomationCommunications protocolInformation security
Transcript: English(auto-generated)
00:00
Welcome everybody to the open ventilator remote monitoring project. This was a project that we did, 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
So by way of introduction, my name is Sam Cervantes. I'm the chief technology officer at Maker Gear 3D Printers based out of Cleveland, Ohio and also leading the project with me is Dave Guthrie. He's the medical device cybersecurity program manager at Mass General Brigham Health Care. So we're gonna give you a little description
00:40
of our project, what we did and how we went about it. So over to you, Dave. Okay, so this has been the year of COVID. We've all been impacted by this global pandemic and early on in this pandemic, there was fears of massive shortages of ventilators. For example, Governor Cuomo of New York predicted
01:02
there would be 26,000 people who could die from ventilator shortages. In Italy, they stopped intubating patients over the age of 60 and the New England Journal of Medicine predicted a need of anywhere from 160,000 to over a million. So there's a global pandemic. Early on in this, Massachusetts hit pretty hard by this
01:22
as far as the United States is concerned. Mass General Brigham is the largest healthcare provider in Massachusetts and has a significant need for ventilators. 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
01:42
this predicted growth in rate of infections. And you need to do this in a massively condensed timeline. So typical medical device development takes two to three years. This needed to be done in two to three weeks, crazy. So Mass General Brigham reaches out to the open source community
02:01
to develop rapid prototype ventilators. Open source community responds. This is an example of just some of the resources that the open source community has provided and Sam is gonna go into this in more detail later in this presentation. So now you have the open source community at the ready. Working groups are starting to form to develop hardware systems, control software
02:21
and remote monitoring software. All of these are being done in parallel under this condensed timeline. So what's the initial need and scope of this project? So you have this predicted ventilator shortage. You have a need for these rapid prototype ventilators that the community is now building. However, most of these ventilators
02:40
lack built-in monitoring and clinical representatives need to have central monitoring express this need to have central monitoring similar to central nursing station networks. So in a hospital, you typically would have like a GE network or a Philips network or a neon code-in network or some other monitoring network where you have bedside physiological monitors going out
03:01
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. And you have ventilator systems that can then plug into these bedside monitors to jump onto this network and then you can monitor these ventilator systems as well. Well, you can't do that with these rapid prototype ventilators.
03:21
So you have these open source teams actively developing these ventilators and now you need to have remote monitoring and central monitoring of these systems. That's where this team comes into play and it initiated in April 2nd of 2020. So what's the clinical request and the need for this remote monitoring software? So you have this rapid prototype ventilator groups.
03:42
They're not integrated into central monitoring traditionally with hospitals. So you need a method of monitoring of all your ventilators on a given floor or a given unit. You have to have a central dashboard with visual learning that's easily interpretable. You have to be able to ingest device data from all these ventilators. So not just your patient device data
04:01
but also device status data and alarm states and alarm data from ventilators if available. And again, you have to do this in this wicked condensed timeline of two to three weeks and you shouldn't cause patient harm or interruption in patient care because if you do that you're defeating the purpose of helping clinical staff and instead you're getting in the way
04:21
and potentially causing patient harm. So this is where Sam's company, MakerGear comes into play. They have a 3D printing company and they have software that has the ability to integrate with physical hardware as well as providing a centralized dashboard. So this was the initial code base that was hacked and adapted by the remote monitoring team
04:42
to develop this ventilator monitoring system. So now what happens is we're actively developing all of these rapid prototype ventilators and the remote monitoring team is working on integrating with these ventilator teams in order to build a central monitoring system. However, simultaneously,
05:01
hospitals are procuring ventilators left and right. You're trying to build up your ventilator inventory from traditional commercial vendors. And what happens is there was not a need to then deploy these rapid prototype ventilators because you're shoring up your inventory of already off the shelf commercial ventilators.
05:21
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. And so the amount of time to design these integrations was extremely costly, resource intensive and you just can't do that in emergency response situations. You have new commercial ventilators
05:40
that can't integrate into your central monitoring system. On top of that, you have infection control restrictions because this is a global pandemic. So you have closed doors for infection control reasons. You have ventilators inside of these rooms that can't be centrally monitored and now you have alarms going off with these ventilators. Now clinical staff are having trouble hearing alarms
06:01
through these closed doors. So this is where our team now pivots and we are requested to create a method for monitoring these commercial ventilators and essential means that don't typically integrate with the other traditional central monitoring systems. So what's our plan of attack? So MGH Biomed, for example, researched off the shelf sound monitoring solutions.
06:20
They vected in on one product, the SoundEar. So the SoundEar can deploy a one-to-one system per patient room, per ventilator. It's a self-contained consumer off the shelf system that can monitor sound pressure. So you can hook a SoundEar with a microphone up to the speaker on the ventilator that auditorily alerts the alarm.
06:42
And then when the sound pressure is exceeded when that alarm goes off, the SoundEar can then trip. 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. And now I'm gonna pass it over to Sam
07:00
to go into the architecture. Thanks, Dave. So I'm gonna talk a little bit about the technical aspects of the project and how we went about pulling this off. And then also later on, some of the kind of the future goals. So this right here, this is the user interface for the clinician.
07:20
This is the whole goal of the entire project right here. So this is what the nurse is gonna see at the nursing station. We've got one little box here for each ventilator. So we've got, in this case, 48 ventilators monitored from our single dashboard. So this is every ventilator on the entire floor of the hospital monitored from one central dashboard.
07:43
So we've got three states of a ventilator right here that we can display. The normal state, the happy state is green. That means we're able to pin the ventilator. We're getting a good status report back and there's no alarm, all is good. The second state is this gray strikethrough box right here.
08:03
That means we're not able to even connect with the ventilator. So a technician needs to go check on the ventilator. So there's a fault in the system somewhere. The third state is this red box here and that'll actually flash, you'll see in the live demo. And that means an alarm is currently being triggered
08:23
on the ventilator. So the nurse needs to go check on it. 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, I need to go check on them.
08:40
Okay, so how did we go about doing this? Typical deployment process for software like this is two to three years. We had two to three weeks, COVID-19 emergency. So how do we go about pulling this off? Basically, we had to pull all the rapid prototyping software development strategies. We had to move fast and break things,
09:01
rely heavily on the open source community and the maker communities, distributed development. We had distributed software developers all over the country pushing to our GitHub repo when we had to hack and fork existing products to get something out in just a few weeks. We use things like 3D printing and quick turn PCBs
09:21
off the shelf hardware to get something that we could barely quickly snap together, bolt together and ship a solution to our customers in just a very short amount of time. We had to rely on remote lab testing and as much as we could, you know, source locally. Component sourcing was a key thing here.
09:41
We had to design our system around the components that we could actually source that were in stock and locally available. We might've wanted to use a PLC or a custom circuit board, but we didn't have time. So we had to use things like off the shelf, raspberry pies and Arduinos that we could get in quantities of thousands that were actually in stock.
10:04
So basically we had to move heaven and earth to ship something in a very short amount of time. Like Dave said, the initial code base was hacked from the MakerGear software. So MakerGear manufactures 3D printers, been doing so for about 10 years out of Cleveland, Ohio. And it just so happened that MakerGear had some software
10:23
for remotely monitoring 3D printers. And as it turns out, a 3D printer is an awful lot like a do it yourself ventilator. 3D printer has a Arduino and a raspberry pie and a ventilator has an Arduino and a raspberry pie. So we were able to adapt and import the software
10:43
to quickly meet the needs of the pandemic. So this is the overall architecture here. So you'll see the dashboard is what we saw before. The dashboard is the kind of central brains, if you will. All information flows towards the dashboard.
11:03
So this is the clinician interface here. So the dashboard is gonna get its status data in real time from the ventilators. You'll see three ventilators displayed down here. Each ventilator is in a different configuration and you'll see the cloud up here.
11:20
So the cloud is there only to serve up the application to the browser and the cloud doesn't store patient data. The cloud simply stores configuration data for the app. Very limited amount of data. We don't send patient data to the cloud. So how does the dashboard get its information
11:40
from each of the ventilators? 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 and we wanted to make a universal system to pull data from every ventilator. Some ventilators are controlled by an Arduino. One of the MIT designs was controlled by an Arduino.
12:01
Some ventilators were controlled by a Raspberry Pi. I think the JamVet design used that. And then some ventilators are a little different. So we wanted to have a sound ear, a separate appliance to listen to the sound the ventilator is making and then trigger alarm based on that. In order to interface with all these different types of ventilators,
12:22
we decided to put a Raspberry Pi in between each ventilator and the dashboard. So the Raspberry Pi could serve as a kind of universal network interface. And on the Raspberry Pi, we have a library. And so we can write modules for this library
12:40
to basically ingest data from any system. So the system we set up, the dashboard we set up can basically take data from pretty much any device with any output capability, if it's a serial out, if it's a spy or a UART out or whatever, analog out, we can take that data from a ventilator
13:02
and relay it to our dashboard here. So this is the overall architecture and the specific instance that we tested in the lab is this particular architecture here. So the ventilator is obviously going to be in the patient's room. And then also in the patient's room
13:22
is the sound ear device, which listens for an audio alarm from the ventilator. The ventilator is going to emit a beep and you'll hear this in the demo. It's going to emit a beep. The sound ear is going to detect that audio beep, that sound pressure. If the sound pressure is above a certain level, it's going to send a signal to the Raspberry Pi,
13:42
the network adapter. And then the Raspberry Pi is going to then send the alarm to the dashboard that we saw earlier. The nice, we should note here that we use the zero tier software-defined network, which provides a very secure network in the hospital
14:03
and even outside of the hospital if we need to, to provide connectivity between the Raspberry Pi and the interface here. And of course, you've got the cloud here. And again, we're not storing patient data on the cloud. The cloud is just there to serve up static assets, the application, if you will, to the dashboard
14:22
and also very limited configuration information. And again, this is what the nurse is going to see at his or her station right here that the dashboard. Software stack, we're getting a little bit into the weeds here. We try to use as much open source software
14:42
as we could here. Ruby on Rails, reliable, secure, open source, very quick to deploy. Raspberry Pis and Arduinos, again, open source, off the shelf, quick to deploy. And then everything we did is open source under a GPLv3 license.
15:02
You can pretty much use it for whatever purpose you'd like. GPLv3 is a very permissive license. You can use it for commercial and or non-commercial. We wanted hospitals to be able to use this very quickly and you can see our GitHub link there below. Everything we have is up on GitHub.
15:23
Did a lot of testing, at-home testing, workbench testing. We did lab testing. 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 and it actually worked pretty well. It worked very well and we got a very solid
15:42
proof of concept alpha. We didn't quite make it through the beta phase, but we got a pretty good alpha prototype. So one of the lessons we learned was the validation and the regulatory process was actually very involved, as you might imagine, from medical products.
16:00
So 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. We just wanted to give you a flavor of what that is right here. So the main three documents are the requirements
16:22
which have to be formatted in a certain way, the architecture, which again needs to be formatted a certain way, and then the hazard analysis, which is pretty involved. Basically for the hazard analysis, we had to brainstorm every possible way that this product might fail. You either fail to communicate an alarm to the central station or fail in some other way.
16:46
So in every method we predicted that it might fail, we had to put a contingency plan in place for it. Very detailed, again, just wanted to give you a brief overview of what this,
17:00
for those of you who haven't done a medical product before, just a brief overview of what that involves. It's a very rigorous process to prepare for FDA approval and hospital approval. Just a little taste of that right here. And again, this is the detailed software architecture. You want to take a look at that.
17:20
All these documents are up on our GitHub Wiki, so you can check those out there. Another important thing here to do was 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:40
The staff at MITRE did a very nice job and lent their support, so we're very grateful to them. They used an automated code service called Veracode and also a manual code review. Still ongoing, but they were a big help with that. Just to give you a taste of the automated code review,
18:01
this was a code review on, I think, a Ruby on Rails portion of the application. Basically, you see here, we don't have any severe alerts, but we had a couple of medium alerts. This was generated for some, we had some automated testing code
18:20
that spit out automated test data. So we need to remove that before deployment. So one little minor thing here. So a few things to fix. Manual code review. Again, just a few things, nothing critical, a few things to fix. So we just want to let, just kind of give a little insight
18:40
to how we went about testing and validating our code. We learned a lot in this project. 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. But a lot of us were software developers. So these are some of the lessons we learned.
19:03
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, and to really come together and work for this good cause. So that was really inspiring.
19:20
The biggest hurdles we found were not necessarily the technology. As technologists, we found it, I don't want to say it was easy, but the technology was the easiest part in a lot of ways. The validation and approval were much more rigorous and time-involved than we anticipated.
19:40
All that being said, FDA approval is daunting, but it's not impossible. And there are experts out there that are willing to help. And that's what we found. A lot of really good people with a lot of deep FDA experience out there that are willing to help. So it's not undoable.
20:00
We found it's very important to be aware of HIPAA and personal identifiable information. So that's one reason we chose not to send patient data to the cloud. It's very important to be covering a set of HIPAA. Another important lesson we learned was that hospitals are reluctant to use open source software
20:23
without the strong backing of an organization to own the technical support and the liability aspect of it. So in the future, we're looking for potentially a sponsor for the project
20:40
to kind of own that deployment in technical support aspect. And ultimately we learned we didn't have a ventilator shortage in the US, which was great news. So ultimately our software was not needed. We're very happy that we could be there and kind of rise to the nation's call as an insurance policy. But ultimately there were plenty of ventilators
21:01
for what the experts tell us in the US to go around for people needing them. So FDA approval. We just wanted to give you a little flavor of kind of the difficulties we found in the FDA approval process. Big disclaimer, I'm not a lawyer or a medical expert,
21:21
so please don't take us as medical advice or legal advice. Seek expert advice for your own project. But it's just the high level overview of some of the things I learned. In a normal timeframe, non-COVID, non-emergency timeframe, say last year, a typical approval process for a system like ours
21:43
would be about two to three years. It's a lengthy submission process. Once you get that approval process, you can use your product for a long period of time. During the emergency, for example, the COVID emergency, a couple, the FDA allows a couple of types
22:02
of new approvals. One is what's called an EAU, emergency use authorization. Typically it can be fast-tracked in two to three months. It's much quicker. But EAU is only valid for the duration of the emergency. So if we were to get EAU for our software system,
22:25
we would not be able to use it after the COVID emergency. And then compassionate use is potentially even quicker. 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 the approval, but potentially quicker.
22:43
So again, not a legal expert, not a medical expert, but these are just some of the things that we learned in the process. There was even a little bit of discussion as to how to classify our software system. Is this a medical device? Is it a modification to an existing medical device
23:02
or is it not a medical device? Is it a baby monitor or a pager or like a cell phone type device? So we did have some ongoing debate about that. So current status of the project, we've drafted up our validation documents for approval.
23:21
We have a working demo, proof of concept, I call it an alpha. It works, we test it in lab, we had a code review. We do not currently have a customer for the project. Our project is currently parked. So if you have a potential use for the software, do let us know and we would love to see our software
23:41
be used for a good purpose. Future plans. One thing we discussed is additional audio alerting at the central nursing station that may require in addition to the visual learning that we already have that may require a separate hardware appliance and potential AI machine learning
24:02
to detect different types of audio alarms from different types of medical devices. We're gonna search continually for new customers. Potential customers may be hospitals with limited resources, smaller hospitals in remote areas
24:22
or developing countries and then potentially healthcare organizations with needs to monitor other devices like pulse oximeters or things like that. And we're continuing our search for a corporate sponsor, an entity to own the maintenance, installation, support and liability.
24:42
So we're just a group of distributed open source software developers. We don't have an organization behind us. And then potentially a future FDA application. Again, if we find a customer for this. So Dave's gonna talk a little bit about the power
25:02
and the possibilities. Yeah, so when you think about this system, the real power is in the possibilities of all the integrations that this system can provide. You have rapid prototype ventilator monitoring systems that we've discussed, such as bringing in device and patient data. You have commercial ventilators
25:21
that are not traditionally integrated with central monitoring systems that you can monitor through sound. So you can get ventilator alarms from commercial ventilators. And now with the sound monitoring, you can monitor any medical device alarm that is based in audio. So you think about all the infusion pumps or other devices that you have all throughout your hospital or remote care sites
25:44
that potentially do not have integrations into your central monitoring system. This could be huge. So this project has great potential to have a massive impact in the healthcare ecosystem. Now for the fun part, we got a live hardware demo. So we're gonna show you the system in operation.
26:05
So Dave in Massachusetts has what would be in the patient room. What you see on this picture is what's on the bench here in Massachusetts. So the way you're gonna see in the video
26:21
is gonna be from that camera that you see in the forefront of the picture. So you have the speaker in the background next to the cyber lizard who has a microphone next to the speaker. That microphone is plugged into the sound ear. The sound ear is then going to
26:41
calculate the sound pressure and it has what's called a soundbuster port. That soundbuster port changes voltage if the audio alarm pressure is tripped. So then the soundbuster port comes out of the sound ear into this Raspberry Pi and then the Raspberry Pi itself will then go out through the network cable
27:02
over to a switch that's on my bench here, out over the open internet through the encrypted zero tier tunnel over to Sam where he's running the dashboard. 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:23
So Dave, you've got the ventilator system, you've got the patient side system in Massachusetts. I'm in Ohio. I've got the clinician dashboard. 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:42
Again, all this is communicating over the zero tier secured network. We're across the country. We might as well be across the floor in the same hospital. But I'm getting a good signal back here from Dave's ventilator. And Dave, if you want to go ahead and trigger your alarm there,
28:01
we should see an alarm indicated here. There we go. So flashing red means the nurse at their dashboard needs to go in and check the patient room. And as soon as we shut it off, the alarm should go off as well.
28:22
Okay, so that's our demo. So like you see, it's a basic working system. 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. So we have libraries
28:41
that could easily incorporate any number of devices. Pretty much any device that's got some kind of hardware, digital or analog output, we can tie this into our system. Very, very adaptable system. So just some acknowledgements for all of our developers. I was really honored to be a part of a team
29:01
of so many people, much smarter than myself. Really fun and really great to work with this team. Dave and I led the project, but we have a bunch of other open source contributors here. Everybody volunteered their time and effort, sacrificed their nights and weekends to really just contribute to the COVID cause.
29:22
So words can express my appreciation for everyone's time and effort here. We're really inspired to see so many people coming together on such a short time. So thanks to everybody. Organizations here, just wanted to thank all the organizations,
29:40
GHS and FDA for their infrastructure and their funding. MakerGear for contributing development time from a number of engineers and also open sourcing the code base and contributing hardware resources. Massachusetts General Hospital and their affiliates
30:00
for everything they've done and expertise they've provided. MITRE for its code review and consulting and just expertise and late night phone calls. Protocol Labs for special thanks for contributing some funding. SoundEar, so we contacted SoundEar to the manufacturers of our sound interface device.
30:23
And we asked them for help on a very short timeframe and they were incredibly supportive. Not only did they give us technical support, engineering consultation, they open source the portion of their code for us. And you'll see that on GitHub. So I cannot imagine a better response from a manufacturer in a time of crisis.
30:42
They were incredibly forthcoming and I cannot thank them enough for helping us to integrate their device in our system. And then last but not least, Veracode for their automated security review. So if you would like to become a contributor or a customer or a sponsor, please reach out to us.
31:01
You can find me or Dave on LinkedIn. And I just wanna give an extra shout out to everybody who worked on this project and an extra thanks to everyone who was really inspired to see so many people involved in this and in such a selfless way. So it really gives me hope for the future and that we can lean into this thing in the bud.
31:22
So thanks everyone.