During the COVID-19 pandemic, the urge to deliver efficient drugs for curing diseases has been put into relief even more.
Some of you may question the delivery of the vaccines in such a “short” time (around one year), but we may ponder this speed by the ability of researchers to conduct research all together. Indeed, thousands of researchers have worked on a medicine for COVID-19, resulting in a vaccine after only one year of research, which normally takes two to five years.
The question now is: Could it pave the way for the clinical research as the whole? Could we find new treatments every year with way fewer resources than during the COVID time? Although it seems idealistic, the medical community is now open to make radical changes in order to reach it.
In this article, we will talk about how we could use smartphones to help accelerate medical research, and how a few lines of code could impact the industry.
Let's focus first on what takes time during the medical research process.
Before selling a new drug, all pharmaceutical companies have to perform clinical studies to validate its efficiency. This process usually takes two years but can take up to ten years as a lot of data has to be gathered in order to validate or invalidate the initial claim of the drug.
A patient who is enrolled in a clinical study usually goes to a hospital every 3 months to perform activities. He could go more often, but going to a hospital is time-consuming for the patient, and he cannot go every day at the hospital, for logistical reasons. Moreover, after a few months/years, some of them also lack motivation and do not finish their study.
This results in data that are slow to be collected for scientific research.
In the way of aggregating faster an acceptable scope of data, the pharmaceutical companies start to think about the technologies to help them.
What if they could use a device owned by every people on earth for aggregating data at home every day? What if they could use phones?
Nowadays, the tech industry can develop mobile applications that are GDPR compliant, and certified as safe by the health system, we call them Software as Medical Devices (SaMD).
A medical device is any device intended to be used for medical purposes.
Over the years, the phone companies included a set of hardware sets in phones that can be used to follow the user's gestures and reactions.
From a medical point of view, these features are interesting to track.
By using these sensors for medical purposes, professionals can have access to the way you truly are: the way you are walking, the way you are moving, the emotions you have after doing an effort. And if you add connected objects to your phone, they can also track the way our heart is reacting.
The advantages of using a phone are consequential:
To summarise, phones are good candidates to be used in clinical studies. But then, what prevent them to be used massively nowadays?
Yet, if clinical studies can control their material, they cannot control the type of phone that a patient will use.
The main concern for people creating medical device applications is how to be sure that all people using the app will have the same experience, whatever material they use.
Indeed, when doing a clinical study, all parameters should be the same for all patients to conclude that the tested medicine is the source of the patient’s health improvement. Otherwise, the study claim could be invalidated by the scientific community.
Let’s say you are designing a new experiment for curing Parkinson's, and you want to test the ability to pinch because the first symptoms of Parkinson's are a decrease in the dexterity of your fingers. For that, you want the patient to pinch circular objects and see how he manages to do this gesture. You can imagine that pinching a balloon that is ten centimeters diameter compared to a one centimeter diameter is not the same gesture.
As the gesture is not the same, you don’t test the same neurological part in your brain. That is why you will use the same-sized balloons for all patients.
Now we want to reproduce this experiment on a phone and have the same balloon size on all phones. The problem that software engineers have is that displaying balloons with the same size on all devices is not so easy.
One of the most important differences between phones is the screen resolution and this can be a very tricky topic when it comes to medical softwares.
Here is below two different screen resolutions for the same size of phones.
And here is the main screen data on the main phones companies. You will see that all resolutions are different.
From a technological point of view, the developers have to take into account the screen resolution as a main parameter of their work.
Let’s imagine a SaMD built with react-native where we would want to draw a Circle on a phone and let the patient pinch the circle to see if he can do the gesture.
The app has one constraint: The circle has to be 25mm diameter, on all phones.
Believe it or not, react-native does not offer the possibility to do it because dimensions properties in react native are unitless, as explained in their documentation here:
There is no universal mapping from points to physical units of measurement. This means that a component with fixed dimensions might not have the same physical size, across different devices and screen sizes. However, this difference is unnoticeable for most use case.
🐞🐞🐞🐞🐞 This code cannot be done in react-native 🐞🐞🐞🐞🐞
For clinical studies, unnoticeable is not acceptable.
You may try to use the metrics provided by react-native, but you will always face a dimension error as all companies phones are classified by metrics that are approximated (to be able to group them and compare them).
For instance, Huawei Mate 20 is listed as having a pixel density of 4 but is precisely 3.7, which will result in a size error if you are using these metrics in your computation.
The only way to be precise is to adapt our code and go directly into Native development, which provides the exact values of the phone.
The function "useConvertSizeInMmToExactDip" calls a function that will call native code to do the conversion to device independent pixel (DP or DIP), real pixels based on the pixel density of the screen.
Here, we are using a hook to have this call asynchronous.
Then we define the called function in Android/iOs native code and use these functions with bridges.
With this method, we can see that it is possible to get the size we want in react-native, on all phones. But that increases the development time and expertise to make it work.
We are just at the beginning of the developments of first phone-based medical devices. We have seen that, if it may complicate the app developments, using phones may have several advantages for reducing the cost of clinical studies and aggregating information every day instead of every three months.
One other interesting piece of information to share is that when a patient goes every three months to a hospital, recent studies have shown that he has a cognitive bias where he will try to perform as best as he can the activity, which he would not do if he was doing it at home every day. (included in his daily routine)
That means that using phones may actually improve not only the data quantity but also the data quality, more representative of RWE (real-world evidence).
Everything remains to be done on that part, and i’m sure we are at the dawn of new discoveries, where collaboration between software engineers and clinicians will be the key.