Category: COVID-19 Ventilator

Version ? – moving from Arduino to ESP32.

Previous version, as described in a previous post here, underwent many changes. Primarily it suffered from the slow processing time of the Arduino Mega it was based on. The challenge was – how to control the stepper motor while also reading pressure sensors and computing the tidal volume and breathing pressure, all at almost the same time. This was kind of solved by upgrading to ESP32 microcontroller.

However this didnt solve it. Finally, the stepper motor was chucked for a DC motor. This worked great.

This piece is my personal perspective on the COVID19 triggered ventilator-related work among the engineering/scientific community of Pune. I was associated with the College of Engineering, Pune (CoEP) team as a volunteer with the aim of developing low-cost ventilators in collaboration with B.J.Medical College & Sassoon Hospital, Pune.

We started working on ventilators shortly after the national lockdown was declared on the 21st of March 2020. I joined the team as a volunteer having no previous connection with CoEP institution. Our initial ideas about what ventilators were, were shaped by what we saw on websites like YouTube where various designs were posted by many people, hardly of Indian origin (yes, we suck at documentation and we doubly suck at sharing information!). Sadly only a few were actually verified, and this some problem with opensource/openhardware sharing, but that’s another story. To us, an amateur medical devices team glued by a solidarity to make something for the disaster at the door, each idea seemed rational. Some seemed more beautiful and ambitious, others less glamorous. Seasoned design engineers are always better at filtering out fantasy from workable ideas, but it takes many years of hands-on experience to get the ‘seasoned’ tag. We didn’t have that.

Prototype to product – a reflection

It’s pertinent here to reflect on how we think as engineers. It seems we think using only what we know – our vocabulary (not only linguistic, but experiential) determined by our experience and understanding of the past. For example, an economist may only be able to handle any decisions limited by her/his experience and learnings and language. Similarly a tool-room machinist will approach a problem from her/his comfort-zone of past familiarity. We were no different when it came to choosing which designs to begin with. Given our repertoire of tools we in the group had experience with – 3D printers and LASER cutters, lathe, milling, stepper motors, servos etc – we appreciated or rejected ideas. I mean we had a significant comfort-zone bias driving our decisions rather than rational studies and evaluations of what is needed.

However, very few of us had actually made projects which resulted into real products in our pre-COVID day-jobs (academicians, research assistants, managers-made-from-former-engineers and prototype developers we were). This is an important distinction on which it is justified to pause and clarify. What distinguishes a product from a project? When a project begins, the plan is like this:

1. Understand the physics and math to a practical level. This stage also involves collaborative discussions, YouTube videos cringe viewing, forum discussions and knocking on the doorsteps of ‘experts’ for their blessings and if possible, some insight.
2. Identify a couple of experiments that we need to do in order to establish our hold on the concept, to prove to ourselves that our ideas are not pure fantasy.
3. Then we begin with the planned experiments.
4. Often the case is – most of our ideas are fantasy and fail. But by this time we are in deep shit, too much invested in money, time and pride. So this leads to more than the initially planned number of experiments. Rationally planned experiments give way to juggad, hack-jobs, significant head scratching (+ adding more of white to an already grey zone) and a whole unintended learning curve resulting in enlightened maker(s) who rightfully doubt their engineering credentials. One learns truely the hard-way (my repeated experience).
5. Somewhere in-between our original concept moves to a functional prototype. This is where things look wonderful and joy is written everywhere.

Most projects, especially academic ones stop here. A lot of school/college projects stop here. Many potential innovators stop here. Most people can only care to think to this point. Functionality is proved, everyone involved is happy what else is needed? Pride and confidence is restored and all that. And so arrives the most tempting time to give up, the most tempting time to jump on to the next concept-to-functional-prototype challenge, where the stakes are too low. I used to be locked in this eternal cycle for many many years before i learnt to look beyond. Now, what’s in there beyond? This part is the real struggle, the real un-glamorous donkey work, but a necessary path to the real stuff. It’s the making of a product. Here’s what a product must be:

1. It should be functional.
2. It should be functional for many years to come.
3. It should be functional without the need of its makers’ constant presence nearby, as it was in pre-product stages.
4. It should be functional for many kinds of users – even non-expert ones who may manipulate the product beyond its anticipated functional envelope. Meaning it should be really really user-tolerant! (My best example of this is the Hero Honda Splendor bike. Just the most abuse friendly thing i have seen)
5. It must be of a good design. This is an artistic as well as functional aspect of a product that humans will use. Often the most neglected end of many Indian products. (What is a good design? – i love this designer’s philosophy) .
6. It should be easy to make, so that manufacturing steps and costs are low and comprehendable to production machinists. This is called design for manufacturing.
7. Overall its cost must be acceptable to the end user.
8. If it ever reaches this stage, if this product fails in the field, like all real machines do (good ones less than bad ones), there should be a machine doctor to fix it and give the relationship between the product and its user a just lifetime.
9. And of course, each product must evolve because there are always feedbacks and failures where the product doesn’t work as intended. Meaning, the above cycle(s) are repeated to transform from a mere prototype to a mature product.

Why all this tangent and how is this relevant to this post? This is only to put in perspective our developments on the ventilator project. Ventilators used in the hospitals are products. Lives depend on them. They must work, day in day out, in all conditions. They are used by doctors all over the world, as diverse as they can be. Nothing must fail within a set time, else lives could be lost. As an engineer, its the first time i am worried to such an extent about my work, so much so that i wish the situation doesn’t arise where any of these amateurish ventilators would be needed. Because we don’t have the robustness and the development man-years that form the foundations of a well-designed mature product. I have heard that usually ventilators undergo severe testing of over 4-5 years before they are approved. From my experience so far as a product developer, reaching functionality takes 5-6 prototypes, and making a product takes many many more. All i am pointing to is this – developing a medical grade product is amazingly complex and a lot of hard work. Being humble is of utmost necessity if we are to do anything serious.

Challenges faced

So whats a ventilator? Ventilators do 1 key job – push in air into the patient’s lungs as if pumping a balloon and let the patient exhale automatically (deflation of a balloon). Why? because some diseases like the COVID19 affect the breathing efficacy of the patient’s lungs, its ability to absorb oxygen into the blood severely decreased resulting in tiredness out of excessive breathing to compensate for lack of O2. This tired lung needs a support system, so a ventilator.

The complication is, that like a balloon our lungs have a safety limit. And a very very sensitive one. Different people, depending on physical body conditions and age have different volumes that can be pumped in. There’s also the peak pressure that must always be respected while doing the pumping, else we’ll damage the lungs significantly! And all the while maintaining the timing of the pumping, else the pumping may be in conflict with the patient’s natural cycle and speed of inhalation/exhalation! Add the complexities of pumping in a restrained manner rather than an explosive manner. The machine should also give the doctors options to set these variables as per the patient. So one has to design 3 parts: A) the action making air pumping part B) The sensing and monitoring part that measures the action taken as well as patient’s response and C) the interface between machine and the doctor.

There are many ways to do the mechanics of the above – using compressors (like the ones you use to fill car tyres with air), using blowers, or using AMBU bags (Bag-Valve-Mask). Most ventilators function on pressureized air and O2 lines, and that’s what serious high-end machine designs are based on, like the design IISER Pune chose to follow. But we chose the humble Ambu bag way, despite that it is the least liked option by doctors and governments because it has its limitations. However, its cheap, easy to make and does not depend on pressurized gas lines only available in modern hospitals. Hence, given the crisis and lack of proper ventilators in many areas of the country and worldwide, this option (first suggested by a student team of the MIT, USA in 2010) became one of the most popular approaches among the amateur ventilator makers all over the world. We were no different.

Along with the technical challenge of getting all of the above working (which we are still struggling with) we had other challenges. Due to the lockdown, getting parts hitherto taken for granted, became a huge bottleneck. Importing electronic components from abroad was out of the way. Lack of city to city courier services eliminated the remaining options. Pune has a few shops – our last bet. So we were left to jugaad off the electronics too (See my post on it).

We’v been working on the ventilators for the past 2-3 months. We have made some 3-4 prototypes, all ambu based. Currently we are able to do all the 3 things – drive the device, sense essential parameters and interface them to the operator. All things work and functional but we are far from a fully functional prototype. The kind doctor at B.J.Medical College will have the final say and from time to time gives valuable feedback on our work.

Criticism

Given the background, i would like to list some criticisms of us as a community that came about on solidarity and clear intention to solve or mitigate COVID19 related problems.

1. Community
   1. Multiple teams in Pune and India are working on ventilators. However there seems to a secretive air about them. No one discloses the design and the parts within. No one says how rigorously they have tested their designs. No one says where they have failed and the bottlenecks in their design, so that others can learn and do better. No one documents. And certainly no one puts documents on the web for everyone’s access and reaction. This includes me and my group. This is the worst thing we could do as a community, and bypasses all the original reason we got into making this.
   2. When we went to buy parts, parts related to ventilators were bought en-masses by whoever reached the shops first in the initial days. Our team members also harbored this instinct to horde – so that we could have enough suppose we hit upon the jackpot of a successful design. And probably in the process also starve other teams of crucial parts, to get an edge. Why this selfish behavior?
   3. When contacted, repeatedly, people working in other teams didn’t respond back. I can name the team here – the IISER guys! These are tax-payer funded people, we in the CoEP are also tax-payer funded and we don’t talk to each other? Why so much arrogance?
   4. There was no discussion within the development community as to the design and challenges or progress status. There was a Slack group named Open Breath Tech where some discussion was taking place initially. But after IISER Pune’s initial interest and involvement died down, this group kind of became silent. I posted my needs, design of electronic ideas, and services (free and voluntary) on it, but no response. Others offered too.
   5. When some people came to know that we were working on ventilators, many people contacted as wanting to join in the efforts.
      1. Job seekers, freshers straight out of college sending in their CVs.
      2. Idea people – people who thought they had great ideas and could help. One even went so far as to wanting to sign some NDA and stuff even at these times of crisis!
      3. Factory owners who offered to help for production or R&D.
   6. One of the most important problem in getting help from the above interested people was lack of permissions. Even in our group, we volunteers got permission from the B.J.Medical college, but not from the district collector. Yet we somehow got past trusting police officials. Point is, shouldn’t the DM and administration actively help in such efforts by the city engineers?
   7. As developers, we didn’t know what was needed. Luckily in collaboration with B.J.Medical docs, we kept on getting some cues. But why one design over the other, cost of different designs, design specs, etc. were all flying in the air. There was no coordinated effort. We were often relying on info from YouTube about cases and practices in the US and Europe while being totally blank about requirements in our own locality.
   8. Whenever a group made a prototype, they created a huge noise about their ‘success’ (we are also guilty here, see ToI article “Expert team creates prototype of low-cost mechanical ventilator in Pune“). Media and social media gave much coverage. Technical limitations and challenges were swept under the carpet by the makers as well as the ill-informed ignorant non-homework doing media. All this made this social crisis into a personal competition – men fighting for their ego cup. And here is the relevance of the section above on prototype vs product. It’s relatively super easy to make a functional prototype, but extremely hard to keep at it and make something really useful. After making a proto and making huge fuss about it, the teams have not really updated if they have made other protos. No one knows.
2. Criticism of the government’s role/actions:
   1. The government added to the noise, by converting it into hackathons and competitions. It could have instead helped in making good specification plans and studies of ventilator requirements in cities, villages, etc. It could have coordinated various groups.
   2. When there is competition of the artificial kind like now in between ventilator makers, there is even less sharing, even less growth and farther we are from developing good machines in the shortest of times. Why do this?
   3. India is a diverse country, and so it can be assumed our ventilator needs could be as diverse across – language, training, cost, service, accessibility barriers. Before jumping into making, some of us should have just studied the landscape of ventilators specific to our country to better inform the developers. There could be different categories of ventilators specified so that we could pick and choose according to our strengths which ones to work on. Who could do this survey?
   4. No forum was available that could make a healthy and regular collaboration between doctors and health staff on one hand and engineers/scientists on the other. We were and are all blind and whimsical as to our designs and choices.
   5. Its obvious – ventilators are glamorous. On the other hand – facemasks – they are not glamorous but easy to make and visible. If visibility could be a driving factor, it does not matter if its difficult or easy to make, they will be made it seems. However, there are many things that are of high impact and absolutely necessary but without the public-frenzy inviting glamour. I guess many people just went for the most glamorous of the projects while other things were not looked into until lately:
      1. Automated spirit/soap dispenser unit for public areas like hospitals, public washrooms, travel depots, etc.
      2. Proper quarantine facilities, how they should be designed keeping in mind long term stay?
      3. Disinfection units for healthcare workers, to avoid the significant jump in hospital wastes.
      4. Breathable PPEs for hot non-AC Indian climate.
      5. Communication design – this was a big big mess!
3. Criticism of my own group: I have deep respect for my colleagues with whom i was lucky to work and learn, especially the team head Prof. Sandip Anansane who kept it all together and drove to this point through tough times. These are good dedicated men (sadly no women). They have been very open and passionate about this project. Yet, the critical self observes:
   1. Our initial focus was to make a device that will be low cost, easy to manufacture and use materials locally available in large quantities. However, we dropped this most important focus point. The current design is bulky, costly and requires some serious machining facilities.
   2. Our group lacks much expertise. This also implies that progress is extremely slow and dangerous. In the most deepest of engineering challenges, its lonely as there is no scope of discussion or debate. Often there is only 1 person who does bulk of the engineering and calls the shots.
   3. Many times this 1 person dominance leads to whimsical designs, which distracts from the goal. There are not many checks and balances.
   4. Being an engineering college, it misses tools and facilities commonly used in the industry. Tools had to be discovered in one drawer or the other, from one department or the other. Sheet metal bending for cabinet and enclosure making, a fundamental need of any engineering work was not available on the campus. Modern LASER/Plasma metal cutting tools were missing.
   5. Tool dexterity is severely poor in this top engineering school. Example – if one knows machining, he does not know electronics and vice-versa.
   6. And all this despite CoEP being the top engineering institute in Pune and one of the top in Maharashtra with crores of machinery, funding and talent pool available at its disposal. Why is it that we were the only team working in such a large college? Where are the others?
4. Self-criticism:
   1. My colleagues will complain that i have not been a good team player, often going on with my ideas and concepts and imposing others to follow.
   2. I am guilty of shifting between too many designs and ideas, too quickly without completing previous ones. This may have scared and worried my teammates immensely. And i didn’t quite give convincing reasons why i did so.
   3. If i was leading an aspect of the project, i didn’t really break it up and ask for other’s help and contribution to it so that everyone can be involved and the task can be done faster. This may be kind of an insult to my teammates.
   4. ?…. I am sure there are many more. Probably my teammates can add here.

This concludes my rant.

Many people including myself are or were involved in making low-cost ventilators in reaction to the panic need expressed by the leaders during the COVID19 crisis. Most of us began working on the MIT E-Vent model (discussed in 2010 paper here) that uses a bag-valve mask (BVM) normally available with all emergency care professionals, in all countries, as a fundamental piece to begin building the ventilator on. There are many advantages to this approach such as availability, low cost, non interference with medical grade materials issues, and others. Many people made these devices, focusing on the mechanical part and there may be many reviews out there.

I am associated with such a team of engineers at the College of Engineering, Pune, under Prof. Sandeep Anasane of Production Department. In 2 weeks time when i began working with Swapnil, Abhijeet, Kaustubh and Dr. Anasane, we made about 3-4 different designs. Two have lasted the test of time of which i am free to present my model that uses a commonly available Maruti Swift wiper motor, a hall sensor+magnet combination to convert it into a servo, a motor driver and some Arduino Nano to complete it all. Here’s a video.

• 

• 

• 

The other one is developed by the team as a whole where the sharing policy is not very clear so i must refrain from sharing.

However, what struck me as we progressed over making these prototypes is that the electronics part is hugely underestimated. In the 2 weeks time i learnt a significant amount of things about ventilation and its pitfalls such as ventilator induced trauma. The latter part is the common side effect of such devices that assist in such difficult times. I have now realized that all this is not simple. Along with advanced ventilators it is mandatory to have specialists and experienced doctors around to manage that device. In wrong or untrained hands it can kill.

Point being, the idea that amateurs like ourselves could come up with impactful solutions to the ventilator end of the COVID19 problem spectrum seems to me a pure fantasy.

Yet, although i have given up on this end, here is a hack that i discovered that could be still used by optimistic ventilator designers elsewhere.

Electronics for basic flow measurement and respiratory pressure

Often many designs are focusing on the mechanical pressurized air delivery with intermittent strokes that are adjustable as per the attending nurse/doc’s understanding of the situation. What is missing are 2 key realtime feedback mechanisms that in my naive opinion are an absolute must:

• Air flow measurement to figure out volume of air delivered/breath as well as the rate at which air is pumped.
• Respiratory pressure measurement that indicates how the patient is experiencing the ventilation.

Both these need pressure sensors. When we began this aspect of the work at CoEP, we could not find the right sensors. In the regular city shops, other city teams working on ventilators had exhausted all the options. We had a few in stock to begin with. There was even not much clarity within the team as to what is the ideal sensor required?

What pressures are we talking about?

• Respiratory pressure measurement: 0-60 cmH2O = 0-5.88 kPa.
• Volume flow orifice pressure range – 0-0.3 kPa

What we instead got were these sensors with some key properties in the following table.

The greens indicate good match, the reds don’t. What i found was that only MPX2010DP was the closest that we could get, atleast on the respiratory range. It was also a ratiometric sensor (so we needn’t worry about excitation voltage fluctuations) as well as temperature compensated! The latter is always good, so MPX10DP is dropped. In fact the MPX2010DP datasheet does mention its use in respiratory diagnostics! All this we discovered (thanks to Swapnil who called the shops to check what they had) after we were stuck with a few samples of MPX2010DP at Rajiv Electronics, the local electronics store. Each MPX2010DP costed about 1200 Rs.

Respiratory pressure measurement could be easy with a differential sensors and as simple as connecting the positive port of MPX2010DP directly to the inhale/exhaling mouth piece on the patient’s mouth, the other end to atmosphere. However we need another piece of critical equipment to measure volume flow rate – an orifice flow sensor. Thanks to Kaustubh’s ingenuinity and research this part was readily available and used in commercial ventilators such as made by GE – the SpiroQuant H flow sensor by Envitech, a Honeywell company.

The way this thing works is there is a thin flexible flap in the middle of this piece that restricts the flow by opening or closing as per flow. This restriction causes a pressure difference between the two ends of the device and this pressure difference can be converted into flow rate through the formula mentioned in SpiroQuant H’s datasheet (link above). Simple!

So whats the problem? All is plain and simple!

As you may have noticed is that the output of these pressure sensors is in milli volts (mV). Also these pressure sensors have a full range of 10 kPa whereas our requirements are on 6kPa for breathing pressure and a whopping 0.3 kPa for the flow measurement! So what we need is an amplifier. Kaustubh worked with the common 3 Op-Amp design but unfortunately could not make it working to satisfactory ends. Another commonly available the excellent ADS1115 was used, but again its gain (max 16x) and resolution (16bits) was not sufficient.

Enter the hack! From my experience in designing ADC boards for the SmallDAC opensource controllers, i knew that these pressure sensors are similar to load cells that use a Wheatstone bridge as their basic sensing element, with resistors flexing or contracting and the difference between the 2 bridge arms basically forming the output voltage linear with the pressure or weight. A common loadcell amplifier is the HX711, amply used by hobbyists anytime a loadcell comes into the equation. It has an inbuilt whopping 128x gain and a 24-bit resolution – perfect for our job. Its unconventional and i could not find any case where a pressure sensor was interfaced with this 100 INR ‘toy’ module. So despite revolt from team members claiming that it wont work i went ahead, while others may have been cursing me that i am distracting from the team’s focus areas and spending time in fancy exploits. I was glad it paid off, else i could have been thrown out!

The circuit is a bit to be noted. These MPX2010DP require a 10V supply to be excited. So i had to create a separate 10V supply (left of the above image) using a 230V-12V PCB mounted SMPS that i could get from Rajiv Electronics (~350 Rs). Then i used a LM317 (i know dropout is 3V, but thats at peak current draw!) to reduce to a clean 10V supply.

The way these bridge sensors work is that their output is centered around half of the supply voltages = 5V. Now HX711 is a 5V device, so the trick i used here is to not connect the 10V supply ground with HX711’s ground and instead only connect the differential output of MPX2010DP to the modules A+ and A- ports. Thus the module is experiencing directly the difference without the 5V bias of the 10V exited pressure sensor. Maybe there are other ways of solving this bias problem, but i must learn more about these kinds of issues.

The output of the module was connected to a regular digital pin of an Arduino Mega board that also handled the motor works and overall controls. This pressure sensing rig was so sensible that even a touch on an ambu bag was recorded as a nice clean peak while the overall noise was pretty low. I must admit that i had to use a lot of capacitors and tricks to get the noise low, but it worked. I used 2 HX711 modules to interface the volumetric measurements (left sensor) and the respiratory measurements.

Hack update

Well, here’s what can be done to make the above better!

Only a single HX711 is used because it has 2 differential ports A and B. A, which as the max possible gain of 128 (equivalent to a span of +/-20mV) can be used to measure the 0.3 kPa max pressure swings of the orifice flow meter as before. However, port B has a gain of only 32x (equivalent to a span of +/- 80mV) which can be used to access the 60cmH2O or 6kPa range required for measuring respiratory pressure. The 24 bits can be enough to distinguish both these measurements to sufficient accuracy.

The other hack has been to use the same 10V supply to also power the HX711. Now we know the HX711 is a 5V device and that the pressure sensors are outputting their differential signals centered around 5V. So what the above circuit does is biases the ground of HX711 w.r.t. the 10V power supply ground using a Rb resistor. The same 10V supply can now be down moded to bring about 5V supply, referenced wrt HX711 ground. Now this part is a bit confusing to me so the values may change or maybe my scheme is wrong? Need to check/think…

The code side could be any that uses the standard HX711 library. Try the simpler ones that do not hide the inner workings, these are much easier to modify!

Happy hacking 🙂

I am volunteering with a team of medical instrument designers at the College of Engineering, Pune (CoEP) to help attempt to address some of the technological requirements of the current COVID-19 crisis. This team, headed by Dr. Sandeep Anasane is in deep collaboration with doctors at B.J. Medical College/ Sasoon Hospital, Pune. I have been extremely lucky to get access to this team and be made comfortable to work with. Because of this, i can work at will at the college and roam about in the city which the city is in lockdown, all thanks to some official permissions the team members have got.

I have come across many others like myself, who wish to contribute technologically in any way, but are at a loss as to how. The problems they are facing:

• Lack of mobility due to nationwide restrictions to movement.
• Lack of know-how as to where is the specific need that needs to be helped.

As of the former part, here’s a probably way that can work:

• Contact a your local good doctor / hospital. 
• Offer your design and engineering services to their ventilator and other on field needs.
• If they agree, team-up with them and pursue permission from the government authorities to travel and begin making stuff.
• Make and test.
• Share with the world with test results (failure is OK, at least the world will know what design does not work).

Now to the second part, what to do? Its hard to know what is actually needed on the field. The medical staff may be too caughtup to sit and talk to anyone about possible future devices that could help a current crisis situation. They wont have time to convert their experiences into articlately worded challenges that could be spread around. So what comes out and is received by amateurs like me are only the more pressing problems – like the ventilators. This is just because everyone is talk about it, from the political leaders to the media to the local doctors on the field. However, i am sure a lot many problems are to be solved which sadly are not coming up to our notice.

Anyways, thanks to my immense luck ( credit to Mr. Vijay Kumar of Texol Eng., my long time mentor and friend) i could get involved with a team already working on the ventilator problem. So here i will just list what i have understood about the current crisis.

The low cost ventilator challenge

• Why is it needed? – Simple answer, not enough high grade ventilators available for the current crisis of COVID-19 which causes respiratory difficulties.
• What’s the role of a ventilator – pump air into the patient in a controlled manner because the patient can’t breath properly on his/her own.
• So what are the basic features a ventilator has:
  • There’s a bag of air that needs to be pushed into the patient. This is a mechanical requirement, like using a motor or piston.
  • The air that needs to be pushed in needs often to be modified by adding pure oxygen.
  • The pumping action must match breathing requirements of the patient, so there are rules and guidelines of pumping.
• When the above requirements are converted into an engineered products, the following features will constitute what makes a real basic ventilator :
  • Should be an add-on to existing Bag Valve Mask system.
  • Should be able to control volume of air / breath.
  • Should be able to control breaths per minute.
  • Should be able to control Inhalation:Exhalation time ratio.
  • Should withstand at minimum 3-4 days of failure free operation.
  • Should pass 8 days of continuous testing on artificial test lungs.
• Additional features could be added :
  • Measure O2% in delivered air.
  • Measure volume flow rate and pressure of delivery.
  • Remotely controllable with wifi.

So thats it, a small note on the requirements of a ventilator. Now the question arises, if one gets all permissions to travel and make ventilators, and has understood the above requirements of the end-device what and how should one begin?

1. One could begin by reverse engineering existing ventilator designs.
2. One could use one’s experience to make an engineering jig that could solve the above challenge list.
3. One could learn new skills and advanced techniques to solve the above problem.
4. One could just design new ways to solving the above challenge list but leave the testing to others.

The above ways are perfectly fine, and in the normal world all these are used extensively. My point here is that its not a normal world now. We are in a crisis. And the crisis is as follows – we the engineers have learnt our tools very well by investing thousands of manhours into learning and using these. These tools have become our vocabulary with which we think. For example a lathe machinist will probably come up with a very different design as compared to a laser cutter tool engineer, just because one uses what one knows. Similarly, as a product designer i am used to order circuits and modules and parts online. I am also used to visiting the market and augmenting up my library of parts/products/etc in my head. I can consult the internet and there is big chance that i can get those parts discussed in far of places right here in Pune, thanks to online e-commerce websites, money transactions, etc. So like every other person, used to using the tools we all probably know, i realized how useless my ways of product development was at the present situation when none of the mobility, access to workshops, online ordering etc is possible.

Long story short, we need to be resourceful. Rather than beign stuck with our past vocabulary we need to shift all gears and levers into a super learning mode. We need to unlearn, so that there is space for new learning to play out. So here are the new design constraints for this ventilator project:

1. Reliable: Make it so sure that there wont be a chance that the design fails a trusting patient to death or added breathing complications.
2. Low cost – so that everyone and anyone can use it.
3. Mass manufacturable – we need 1000s of these now. But we cant depend on conventional supply chains. These must be locally manufacturable without dependency on imported components, etc.
4. Manufacturable with minimal skills – because experienced workforce may not be available to make these in mass numbers. Learning to make one should not be difficult.