start	end	text
0	5020	Welcome, everybody, to the Open Ventilator Remote Monitoring Project.
5020	11120	This was a project that we did. The open source community came together to create software to remotely monitor
13780	19840	do-it-yourself, rapidly manufactured ventilators during the COVID-19 pandemic.
20040	24060	So, by way of introduction, my name is Sam Cervantes.
24060	28900	I'm the Chief Technology Officer at MakerGear 3D printers based out of Cleveland, Ohio.
28900	33140	And also leading the project with me is Dave Guthrie.
33140	38240	He's the Medical Device Cybersecurity Program Manager at Mass General Brigham Healthcare.
38240	43920	So, we're going to give you a little description of our project, what we did, and how we went about it.
43920	45660	So, over to you, Dave.
46060	50600	Okay, so this has been the year of COVID.
50600	53440	We've all been impacted by this global pandemic.
53440	58560	And early on in this pandemic, there were fears of massive shortages of ventilators.
58560	65740	For example, Governor Cuomo of New York predicted there would be 26,000 people who could die from ventilator shortages.
65740	69520	In Italy, they stopped intubating patients over the age of 60.
69520	76460	And the New England Journal of Medicine predicted a need of anywhere from 160,000 to over a million.
77040	79160	So, there's a global pandemic.
79300	84240	Early on in this, Massachusetts has hit pretty hard by this as far as the United States is concerned.
84240	91500	Mass General Brigham is the largest healthcare provider in Massachusetts and has a significant need for ventilators.
91840	104860	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.
104860	108380	And you need to do this in a massively condensed timeline.
108380	111500	So, typical medical device development takes two to three years.
111500	115020	This needed to be done in two to three weeks. Crazy!
115940	123620	So, Mass General Brigham reaches out to the open-source community to develop rapid prototype ventilators.
123620	125600	Open-source community responds.
125760	129920	This is an example of just some of the resources that the open-source community has provided.
129920	133600	And Sam is going to go into this in more detail later in this presentation.
134160	137460	So, now you have the open-source community at the ready.
137460	143340	Working groups are starting to form to develop hardware systems, control software, and remote monitoring software.
143340	147660	All of these are being done in parallel under this condensed timeline.
148180	151920	So, what's the initial need and scope of this project?
151920	154760	So, you have this predicted ventilator shortage.
154760	158740	You have a need for these rapid prototype ventilators that the community is now building.
158740	162320	However, most of these ventilators lack built-in monitoring.
162320	170520	And clinical representatives need to have central monitoring and express this need to have central monitoring similar to central nursing station networks.
170520	177140	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
177140	181580	where you have bedside physiological monitors going out.
181580	190100	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.
190100	195240	And you have ventilator systems that can then plug into these bedside monitors to jump onto this network.
195240	198480	And then you can monitor these ventilator systems as well.
198480	201020	Well, you can't do that with these rapid prototype ventilators.
201020	205440	So, you have these open source teams actively developing these ventilators.
205440	209640	And now you need to have remote monitoring and central monitoring of these systems.
209640	211760	That's where this team comes into play.
211760	215120	And it initiated in April 2nd of 2020.
215260	219420	So, what's the clinical request and the need for this remote monitoring software?
219420	222340	So, you have this rapid prototype ventilator groups.
222420	226040	They're not integrated into central monitoring traditionally with hospitals.
226040	230380	So, you need a method of monitoring of all your ventilators on a given floor or a given unit.
230380	234140	You have to have a central dashboard with visual learning that's easily interpretable.
234140	238280	You have to be able to ingest device data from all these ventilators.
238280	247160	So, not just your patient device data, but also device status data and alarm states and alarm data from ventilators if available.
247160	252040	And again, you have to do this in this wicked condensed timeline of two to three weeks.
252040	255600	And you shouldn't cause patient harm or interruption in patient care.
255600	259100	Because if you do that, you're defeating the purpose of helping clinical staff.
259100	263220	And instead, you're getting in the way and potentially causing patient harm.
263220	266600	So, this is where Sam's company, MakerGear, comes into play.
266600	268840	They have a 3D printing company.
268840	275980	And they have software that has the ability to integrate with physical hardware as well as providing a centralized dashboard.
275980	285100	So, this was the initial code base that was hacked and adapted by the remote monitoring team to develop this ventilator monitoring system.
285120	291480	So, now what happens is we're actively developing all of these rapid prototype ventilators.
291480	298540	And the remote monitoring team is working on integrating with these ventilator teams in order to build a central monitoring system.
298540	305620	However, simultaneously, hospitals are procuring ventilators left and right.
305620	309760	You're trying to build up your ventilator inventory from traditional commercial vendors.
309840	316580	And what happens is there was not a need to then deploy these rapid prototype ventilators.
316580	321120	Because you're sharing up your inventory of already off-the-shelf commercial ventilators.
321220	328860	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.
328860	335260	And so, the amount of time to design these integrations was extremely costly, resource-intensive.
335260	337960	And you just can't do that in an emergency response situation.
337960	342360	So, you have new commercial ventilators that can't integrate into your central monitoring system.
342360	347540	On top of that, you have infection control restrictions because this is a global pandemic.
347540	351140	So, you have closed doors for infection control reasons.
351140	355240	You have ventilators inside of these rooms that can't be centrally monitored.
355240	357960	And now you have alarms going off with these ventilators.
357960	362300	Now clinical staff are having trouble hearing alarms through these closed doors.
362300	369260	So, this is where our team now pivots and we are requested to create a method for monitoring these commercial ventilators
369260	374300	in a central means that don't typically integrate with the other traditional central monitoring systems.
374300	376280	So, what's our plan of attack?
376300	380320	So, MGH Biomed, for example, researched off-the-shelf sound monitoring solutions.
380320	383700	They vectored in on one product, the SoundEar.
383700	389800	So, the SoundEar can deploy a one-to-one system per patient room per ventilator.
389800	394320	It's a self-contained consumer off-the-shelf system that can monitor sound pressure.
394320	401960	So, you can hook a SoundEar with a microphone up to the speaker on the ventilator that auditorily alerts the alarm.
402120	406680	And then when the sound pressure is exceeded, when that alarm goes off, the SoundEar can then trip.
406680	413940	So, we were then requested to integrate with this SoundEar and provide a central means for monitoring the SoundEar
413940	417680	and be able to create a central dashboard for when it trips.
417680	421880	And now, I'm going to pass it over to Sam to go into the architecture.
421940	427700	Thanks, Dave. So, I'm going to talk a little bit about the technical aspects of the project
427700	431360	and how we went about pulling this off.
431580	435640	And then also, later on, some of the future goals.
435640	440100	So, this right here, this is the user interface for the clinician.
440280	443460	This is the whole goal of the entire project right here.
443780	447100	So, this is what the nurse is going to see at the nursing station.
447100	450160	We've got one little box here for each ventilator.
450160	455540	So, we've got, in this case, 48 ventilators monitored from our single dashboard.
455540	462320	So, this is every ventilator on the entire floor of the hospital monitored from one central dashboard.
462560	467480	So, we've got three states of a ventilator right here that we can display.
467960	470460	The normal state, the happy state, is green.
470460	473560	That means we're able to ping the ventilator.
473560	478200	We're getting a good status report back and there's no alarm. All is good.
478560	483080	The second state is this gray strikethrough box right here.
483480	487660	That means we're not able to even connect with the ventilator.
487660	490040	So, a technician needs to go check on the ventilator.
490040	492380	So, there's a fault in the system somewhere.
492900	496160	The third state is this red box here.
496160	498840	And that will actually flash, you'll see in the live demo.
498840	503960	And that means an alarm is currently being triggered on the ventilator.
503960	506220	So, the nurse needs to go check on it.
506220	513980	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.
513980	515740	I need to go check on those.
519960	522440	Okay, so how do we go about doing this?
523700	527780	Typical deployment process for software like this is two to three years.
527780	529200	We had two to three weeks.
529200	530860	COVID-19 emergency.
531340	533920	So, how do we go about pulling this off?
534260	539560	Basically, we had to pull all the rapid prototyping software development strategies.
539560	541100	We had to move fast and break things.
541100	544580	We rely heavily on the open source community and the maker communities.
544880	551880	Distributed development, we had software developers all over the country pushing to our GitHub repo.
551880	557560	We had to hack and fork existing products to get something out in just a few weeks.
557560	570620	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.
571020	573540	We had to rely on remote lab testing.
574120	577360	And as much as we could, you know, source locally.
577360	580740	Component sourcing was a key thing.
580740	588200	We had to design our system around the components that we could actually source that were in stock and locally available.
588520	594420	We might have wanted to use a PLC or a custom circuit board, but we didn't have time.
594420	602560	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.
603780	608880	So, basically, we had to move heaven and earth to ship something in a very short amount of time.
608880	614420	Like Dave said, the initial code base was hacked from MakerGear software.
614420	619980	So, MakerGear manufactures 3D printers. Been doing so for about 10 years out of Cleveland, Ohio.
619980	626400	And it just so happened that MakerGear had some software for remotely monitoring 3D printers.
626420	632460	And as it turns out, a 3D printer is an awful lot like a do-it-yourself ventilator.
632460	639680	A 3D printer has an Arduino and a Raspberry Pi, and a ventilator has an Arduino and a Raspberry Pi.
639680	650400	So, we were able to adapt and import the software to quickly meet the needs of the pandemic.
650400	655500	So, this is the overall architecture here. So, you'll see the dashboard is what we saw before.
655500	662180	The dashboard is the kind of central brains, if you will. All information flows towards the dashboard.
662660	672100	So, this is the clinician interface here. So, the dashboard is going to get its status data in real time from the ventilators.
672100	677400	You'll see three ventilators displayed down here. Each ventilator is in a different configuration.
678220	685080	And you'll see the cloud up here. So, the cloud is there only to serve up the application to the browser.
685080	692740	And the cloud doesn't store patient data. The cloud simply stores configuration data for the app.
692740	695940	A very limited amount of data. We don't send patient data to the cloud.
696760	701720	So, how does the dashboard get its information from each of the ventilators?
701900	708940	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.
708940	713240	And we wanted to make a universal system to pull data from every ventilator.
713240	719920	Some ventilators are controlled by an Arduino. One of the MIT designs was controlled by an Arduino.
720760	726380	Some ventilators were controlled by a Raspberry Pi. I think the JamBest design used that.
726620	736300	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.
736300	738240	And then trigger it a lot based on that.
738240	747940	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.
748640	753160	So, the Raspberry Pi could serve as a kind of universal network interface.
753740	757020	And on the Raspberry Pi, we have a library.
757820	764560	And so, we can write modules for this library to basically ingest data from any system.
764560	772420	So, the system we set up, the dashboard we set up, can basically take data from pretty much any device with any output capability.
772420	784400	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.
784440	786360	So, this is the overall architecture.
787780	794380	And the specific instance that we tested in the lab was this particular architecture here.
795320	798820	So, the ventilator is obviously going to be in the patient's room.
799240	808940	And then also in the patient's room is the SoundEar device, which listens for an audio alarm from the ventilator.
808940	811960	So, the ventilator is going to emit a beep, and you'll hear this in the demo.
811960	813340	It's going to emit a beep.
813340	816720	The SoundEar is going to detect that audio beep, that sound pressure.
816840	822780	If the sound pressure is above a certain level, it's going to send a signal to the Raspberry Pi, the network adapter.
823020	829260	And then the Raspberry Pi is going to then send the alarm to the dashboard that we saw earlier.
831100	843080	We should note here that we used the zero-tier software-defined network, which provides a very secure network in the hospital,
843080	850900	and even outside of the hospital if we need to, to provide connectivity between the Raspberry Pi and the interface here.
850900	854740	And of course, you've got the cloud here. And again, we're not storing patient data on the cloud.
854740	864540	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.
866020	873520	And again, this is what the nurse is going to see at his or her station right here at the dashboard.
875280	878700	Software stack, we're getting a little bit into the weeds here.
878700	887020	We tried to use as much open-source software as we could here. Ruby on Rails, reliable, secure, open-source, very quick to deploy.
888220	895040	Raspberry Pis and Arduinos, again, open-source, off-the-shelf, quick to deploy.
896540	905500	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.
905500	912920	GPLv3 is a very permissive license. You can use it for commercial and or non-commercial.
913300	921480	We wanted hospitals to be able to use this very quickly, and you can see our GitHub link here below. Everything we have is up on GitHub.
923240	936520	We 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.
936940	949400	And it actually worked pretty well. We got a very solid proof-of-concept alpha. We didn't quite make it through the beta phase, but we got a pretty good alpha prototype.
950360	959740	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.
960200	973160	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.
973160	990280	We just wanted to give you a flavor of what that is right here. 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.
990280	1005940	Basically, for the hazard analysis, we had to brainstorm every possible way that this product might fail. It would either fail to communicate an alarm to the central station or fail in some other way.
1006800	1026760	Every method we predicted that it might fail, we had to put a contingency plan in place for. Very detailed, again. 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.
1026760	1034320	It's a very rigorous process to prepare for FDA approval and hospital approval. Just a little taste of that right here.
1035940	1045100	Again, this is the detailed software architecture. If you want to take a look at that. All these documents are up on our GitHub wiki, so you can check those out there.
1047240	1059560	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.
1059560	1076280	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 VeriCode and also a manual code review. Still ongoing, but they were a big help with that.
1076280	1080660	Just to give you a taste of the automated code review.
1080660	1096280	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.
1097560	1109620	We had some automated testing code that spit out automated test data, so we need to remove that before deployment. One little minor thing here.
1109620	1124500	A few things to fix. Manual code review. Again, just a few things. Nothing critical. A few things to fix. We just want to give a little insight into how we went about testing and validating our code.
1124500	1137600	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.
1137700	1142040	A lot of us were software developers, so these are some of the lessons we learned.
1142040	1157280	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.
1157280	1179620	So that was really inspiring. The biggest hurdles we found were not necessarily the technology. As technologists, 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.
1180160	1197740	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.
1200000	1216020	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 cognizant of HIPAA.
1216020	1233400	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.
1233400	1251480	So in the future, we're looking for potentially a sponsor for the project to own that deployment and technical support aspect. And ultimately, we learned we didn't have a ventilator shortage in the U.S., which is great news. So ultimately, our software was not needed.
1251480	1266600	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. to go around for people who needed them.
1268240	1287480	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, so please don't take us as medical advice or legal advice. Seek expert advice for your own project.
1287480	1313760	But it's just a 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 would be about two to three years. It's a lengthy submission process, and once you get that approval process, you can use your product for a long period of time.
1313760	1337600	During the emergency, for example, the COVID emergency, the FDA allows a couple types of new approvals. One is what's called 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.
1337600	1362380	So if we were to get EAU for our software system, 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 approval, but potentially quicker.
1364300	1389340	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? Or is it not a medical device? Is it a baby monitor or a pager or like a cell phone type device?
1389340	1392480	So we did have some ongoing debate about that.
1393960	1412120	So current status of the project. We've drafted up our validation documents for approval. We have a working demo proof of concept. I called it Alpha. It works. We tested it in the lab. We had a code review. We do not currently have a customer for the project. Our project is currently parked.
1412120	1424340	So if you have a potential use for the software, do let us know. We would love to see our software be used for a good purpose.
1424720	1437880	Future plans. 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.
1438880	1449200	And potential AI machine learning to detect different types of audio alarms from different types of medical devices.
1449880	1454280	We're going to search continually for new customers.
1455040	1459740	Potential customers may be hospitals with limited resources.
1459880	1464160	Smaller hospitals in remote areas or developing countries.
1465140	1474720	And then potentially healthcare organizations with needs to monitor other devices, like pulse oximeters or things like that.
1474720	1486680	And we're continuing our search for a corporate sponsor, an entity to own the maintenance, installation, support, and liability. So we're just a group of distributed open source software developers.
1486820	1489960	We don't have an organization behind us.
1490520	1496840	And then potentially a future FDA application, again, if we find a customer for this.
1498080	1503780	So Dave's going to talk a little bit about the power and the possibilities.
1503920	1512440	Yeah, so when you think about this system, the real power is in the possibilities of all the integrations that this system can provide.
1512440	1519360	You have rapid prototype ventilator monitoring systems that we've discussed, such as bringing in device and patient data.
1519360	1526460	You have commercial ventilators that are not traditionally integrated with central monitoring systems that you can monitor through sound.
1526460	1529020	So you can get ventilator alarms from commercial ventilators.
1529020	1535280	And now with the sound monitoring, you can monitor any medical device alarm that is based in audio.
1535280	1547800	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.
1547800	1549660	This could be huge.
1549660	1556360	So this project has great potential to have a massive impact in the healthcare ecosystem.
1556360	1559680	Now for the fun part, we've got a live hardware demo.
1559680	1564040	So we're going to show you the system in operation.
1564080	1572300	So Dave in Massachusetts has what would be in the patient room.
1572300	1578920	On this picture is what's on the bench here in Massachusetts.
1579100	1584320	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.
1584320	1594020	So you have the speaker in the background next to the cyber lizard who has a microphone next to the speaker.
1594060	1597800	That microphone is plugged into the sound ear.
1597800	1602620	The sound ear is then going to calculate the sound pressure.
1602780	1605340	And it has what's called a sound buster port.
1605340	1611180	That sound buster port changes voltage if the audio alarm pressure is tripped.
1611240	1615900	So then the sound buster port comes out of the sound ear into this Raspberry Pi.
1616020	1623860	And then the Raspberry Pi itself will then go out through the network cable over to a switch that's on my bench here.
1623860	1631260	Out over the open internet through the encrypted zero tier tunnel over to Sam where he's running the dashboard.
1632340	1642540	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.
1642540	1646800	So Dave, you've got the ventilator system. You've got the patient side system in Massachusetts.
1646800	1650620	I'm in Ohio. I've got the clinician dashboard.
1650620	1661900	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.
1661900	1665700	Again, all this is communicating over the zero tier secured network.
1665800	1672460	We're across the country. We might as well be across the floor in the same hospital.
1672560	1677200	But I'm getting a good signal back here from Dave's ventilator.
1677200	1683820	So Dave, if you want to go ahead and trigger your alarm there, we should see an alarm indicated here.
1685860	1686960	There we go.
1687740	1693360	The flashing red means the nurse at their dashboard needs to go in and check the patient room.
1693880	1697180	And as soon as we shut it off, the alarm should go off as well.
1701490	1704370	Okay, so that's our demo.
1704370	1718110	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.
1718110	1724030	So we have libraries that can easily incorporate any number of devices.
1724030	1731490	Pretty much any device that's got some kind of hardware, digital or analog output, we can tie this into our system.
1731490	1734690	Very, very adaptable system.
1735250	1744050	So just some acknowledgments for all of our developers. I was really honored to be a part of a team of so many people much smarter than myself.
1744390	1748350	Really fun and really great to work with this team.
1748350	1762130	David 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, you know, contribute to the COVID cause.
1763810	1774950	Working to express my appreciation for everyone's time and effort here. Really inspired to see so many people come together on such a short time frame.
1774950	1785330	Thanks to everybody. Organizations here. I just want to thank all the organizations, GHS and FDA for their infrastructure and their funding.
1785330	1797230	Maker Gear for contributing development time from a number of engineers and also open sourcing the code base and contributing hardware resources.
1797350	1803250	Massachusetts General Hospital and their affiliates for everything they've done and expertise they've provided.
1803250	1814270	MITRE for its code review and consulting and just expertise and late night phone calls. Protocol Labs for special thanks for contributing some funding.
1814790	1827550	Sound Ear. 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.
1827810	1833230	Not only did they give us technical support, engineering consultation, they open sourced a portion of their code for us.
1833250	1841750	You'll see that on GitHub. So I cannot have... I cannot imagine a better response from a manufacturer in a time of crisis.
1841750	1848450	They were incredibly forthcoming and I cannot thank them enough for helping us to integrate their device into our system.
1848670	1853250	And last but not least, VeriCode for their automated security review.
1853250	1863790	So if you would like to become a contributor or customer or sponsor, you know, please reach out to us. You can find me or Dave on LinkedIn.
1864270	1877490	And I just want to give an extra shout out to everybody who worked on this project and an extra thanks to everyone. It was really inspiring to see so many people involved in this and in such a selfless way.
1877490	1883250	It really gives me hope for the future that we can really nip this thing in the bud. So thanks to everyone.