Cov.Less

Inspiration

One of the biggest problems brought by the COVID-19 pandemic is the limited number of ventilators available in hospitals, coupled with the fact that 22% of people that get in the hospital need to be put on mechanical respirators to survive. Doctors, deciding the moment their patients are put on respirators based on the severity of their cases, need to be able to evaluate them in the most efficient way.

We are a Romanian team based in Cluj and in the past 2 years we have developed a wearable sensory bracelet (www.mytully.com) helping children with special conditions (ADHD and autism) manage their emotions and stress level. Our device, already at functional prototype and large scale testing phase, monitors a set of physiological indicators, including heart rate, pulse-oximetry and temperature. Hearing about this hackathon galvanized our desire to contribute and help. We reached out to doctors and nurses in our city and tried to find the best way to apply our skills and knowledge to battle the epidemic. Discussing Tully led quickly to the realization that we can help by offering the hospitals a way of monitoring the state of ICU patients and promptly alerting the medical staff when their condition is deteriorating and mechanical respirator is needed. While some of hospitals have the necessary monitoring equipment, most of the times the availability is not sufficient for the high number of patients, and even when existing, there are no portable solutions and the patients can be monitored only while in their beds. There are therefore lots of cases in which they have to rely on direct observation by doctors and nurses. This ties up one of their most crucial resources, the medical personnel time and introduces an element of subjectivity in the decision. Patients can be put on respirators too early, blocking the equipment, or too late, with dire consequences for their survivability.

We realized that we can modify our platform to provide this, by adapting the sensors range and adding live communication possibilities – our device, being destined for children to use during school was purposely designed with data connectivity only by cable, while charging. We had the first discussions with the doctors and nurses earlier during the week and we already had an initial action plan on Friday, at the start of the Hackathon.

What it does

Our device will be worn by COVID patients during their observation and hospital phase. It continuously tracks the wearer heart rate, temperature and level of oxygen in the blood and communicates them to a tablet or PC used by the doctors and nurses to monitor their patients. The data is collected on dashboard for all patients in the hospital and each one entry is color coded (green, yellow or red) based on their status. This way the doctor will have an overall image of all patients’ condition of and can take immediate action when needed. The alarm levels can be adjusted depending on the hospital/patients specific conditions (available resources, number of cases, etc.) We added a WIFI module for wireless communication and portability to our initial device. Also, for continuous operation the it does not rely on an internal battery, but on an external power bank as the ones used for smartphone recharging. The MVP created during this week-end includes all the necessary sensors (HR, SpO2, temperature and accelerometer) and we developed the first version of the dashboard. The device is easily sanitizable, by immersion in medical alcohol before being fitted to another patient. To keep the use of materials that need to be disinfected to the minimum and for maximum flexibility on using it, the device is composed only from the sensory case, without any strap or bracelet, and will be fixed, preferably on the interior of the wrist, with medical tape. Based on discussions with mentors during the hackathon we decided to also add an ECG sensor, modifying the existing GSR (Galvanic Skin Response) sensor into a two electrodes electrocardiography sensor during the following week. While this is not directly crucial for the immediate evaluation of the patients’ state, the doctors consider the data, especially as it can be consolidated with pulse, temperature and SpO2, potentially extremely valuable for a better understanding of the virus effects. There are several use cases for our device, based on slightly different versions:

The first use is the one described, for ICU patients monitoring. We estimate that we will complete the introduction of the ECG sensor, the final version of the case and dashboard and the device certification in the following 2-3 weeks. We will start testing the MVP this week and we’ll be able to test the final version by May 15th, and, if everything works out, have the first integrated systems delivered to hospitals starting with June. The business model for this version is B2B, the hospitals being the direct buyers of the monitoring platforms. The size of the problem is significant: as of April 24th there were over 620k active cases of coronavirus in Europe alone. Hospitalization rate varied wildly between countries and periods, between 4% and more than 20% from confirmed cases. Assuming a 15% hospitalization rate and a total number of patients in Europe plateaued at 600k in the next months, there still will be about 90k people in need of monitoring and even by providing monitoring systems to only 25% of the hospitals we are looking at over 20,000 units. The ease of re-use and the 1-2 weeks period in which most of the patients need to be monitored in hospitals means that these 20k units will help hundreds of thousands of people in the following months/year. The Bill of Materials for the electronics and PCB of one device, ordered from within Europe, is 75 EUR and the case, cables and power-bank and assembly will raise the total cost of production to 150 EUR, allowing us a price point of 200 EUR/device or 2,000 – 2,500 EUR / 10 devices platform which will include also the monitoring tablet and maintenance. This raises the total estimated potential of the European market to 4m – 5m EUR.
The second use case is on monitoring the recovered cases, after being dismissed from the hospitals. There are several slight changes needed – adding an internal battery and a more traditional, user friendly fitting option (as a bracelet), potentially eliminating the need for the ECG sensor, which might not be suitable for the in-home environment and expanding the data platform to allow remote data collection and integration with the hospital generated data. This use case will allow the observation of patients during recovery phase, or even in convalescence for less severe cases if their treatment happens at home. It will also generate hugely valuable data on the infection evolution, touching even immunity and re-infection possibility. Because data integration between hospital and patient is a crucial component, even though the patients will wear the devices at home the beneficiary and owner will still be the hospital, and GDPR also pretty much demands this in order for the doctors to have access to data. As a result the business model is still going to be B2B, hospitals acquiring the devices for the recovering patients. The cost and price points are similar to the first use-case version, but at this moment the potential volume is still unclear. We estimate that at least several hospitals will be interested in collecting this data, and they will each acquire probably 50+ devices, but for a better approximation further exploratory discussions are needed.
The third use case builds up on the data collected through the other two versions to create an early-stage warning device, in time for the next COVID wave in the fall or next spring. We are already collaborating with RIST, The Romanian Institute for Science and Technology, a research institute with 35 scientists specializing in Machine Learning and AI, in integrating ML algorithms in our product for emotion recognition. We checked with them and sufficient physiological data from confirmed COVID cases, even anonymized, will let us develop an algorithm that could interpret the heart rate and respiration patterns, together with temperature and level of blood oxygenation, and provide an early alert to potentially infected individuals, especially if evaluated in the same time with a “contact tracking” tool like the one being developed now by Apple and Google. This could prove tremendously helpful, potentially reducing both the virality and mortality of a future infection wave, as the infected people will get earlier medical treatment and will also reduce their social contact days before their condition becomes so severe to warren a hospital admission.

Regarding the business aspect of this project, we have the advantage of a very strong team, including, besides the outstanding strong technical talent and abilities, evident from the progress done over the weekend, people specialized in strategy, finance and business development. My career started in finance, working in sales in financial institutions for 10 years and developing national and regional sales channels for two different companies. Getting my MBA at UC Berkeley “infected” me with the entrepreneurship virus and after a detour through consulting and investments I first returned to creating partnerships and business development opportunities for a large SaaS company before starting, with my partners, our own company almost 3 years ago. Adina, my co-founder, brings a more academic approach to the business, as she has a PhD in Economics and Master degrees in Business and in Psychology, and she teaches Investments and Behavioral Economy at Babes Bolyai University, Faculty of Economics. Our second advantage in developing this product as a business is that it tracks very well with our existing product, Tully, which we have been working on for the past 2 years. We have done extensive work in preparing the business plan and the launch, scheduled for this fall. Tully will be launched on a B2C model, direct to consumers and we will add a B2B component, selling it directly to hospitals. The business model for this product will be similar, just in a reverse order, starting from a B2B focus for the first version and adding a B2C distribution for the third use case, once sufficient data is collected.

How we built it

We started from our existing product, Tully, a wearable bracelet for children with ADHD, and modified it to focus on continuous oxygen level monitoring. The embedded development has been done in C and the dashboard was created using Phython and Flask The main hardware specifications of our product are:

The 3 main sensors are optical heart rate, pulseoximeter and temperature
The heart rate and the SpO2 sensors use photoplethysmography on mixed wave lengths (infra-red, red and green) and integrate algorithms for movement effect cancellation based on an accelerometer MEMS sensor
The MVP includes partly the electronics and input elements for a electrocardiography sensor, but it needs to be completed to become functional
The data is processed on board of the unit’s microcontroller and sent to the receiving device dashboard via a WIFI module

Challenges we ran into

Making the devices as disinfectant friendly as possible; we manage to create an architecture that allows a simple process as just taking it from a patient, throwing away the medical tape and dropping the entire device for a minute into a medical alcohol tray. After that it only takes 5 more minutes for the device to dry before it can be placed on a different patient
Creating the case – making the cases in the same time sturdy enough, easy to manufacture by 3D printing or resin injection and not in the last place have them looking good
Modifying the GSR into an ECG sensor, we're still working at this
Testing, benchmarking and calibration are needed and still to be effected

Accomplishments that we're proud of

We are quite proud of the fact that we managed to modify our existing product and update the entire programming, not to mention adding the dashboard, all within 48 hours.

What we learned

With all the discussions, reading and experimenting done these days we got more and more convinced that our solution can help a lot of people, and by actually doing during the hackathon we learned that we are able to deliver it.

What's next for CovLess

Our immediate focus is on moving from MVP to a fully functional unit and complete the electrocardiogram sensor development. Following that we will build several complete units and start testing them and fine-tuning the programming and dashboard, while simultaneously going through the fast-track medical device certification. We will also focus on refining the business plan and securing resources and support in building the units and contacting interested hospitals for the first deliveries and contracting the suppliers for electronic parts and PCB component boards. Not in the last place we will need to move from 3D printing the cases to having them done through plastic injection, much more efficient and faster but not suitable for prototype level.

The next step will be to finalize the version for recovered patients home-monitoring. We will start by talking with a sufficiently large number of stakeholders, doctors, hospital managers and researchers, once we start to see the results from the first use-case, the in hospital monitoring. This way we will be able to correctly evaluate the real interest for this version. We will go through creating a complete plan for this phase and develop the communication and data integration layers needed by the product.

The third step, developing an early stage warning device is the most promising one. Even though putting our devices in hospitals will decrease the work load of nurses and doctors, letting them take faster decisions putting the patients on ventilators and will help thousands of people, we feel that the biggest win will come from leveraging the data into a system that could decrease the effects and transmission speed of the next infectious wave, one that could be applied to not only coronavirus, but also to other viral infections. It will require a lot of work but we’re confident that we will be able to reach the result, and the Cov.Less solution is just the first step towards it.