Evgeny Zorin, Software Engineer at Auriga Inc.07.08.19
The explosion of new technologies and expansion in the number of different wearable devices and their affordability provide perfect opportunities for capturing data about human health and vital activity that medical researchers could dream about some 10–20 years ago. Experts estimate the market capacity for software that allows data collection on end user devices will be $15–20 billion by 2023. Already, wearable devices themselves are becoming integral to health insurance and treatment plans. Of course, not all applications on the market are equally useful, user-friendly, reliable, or secure. In this article, we will describe what issues software developers have to face, how to sort out priorities, and what should be avoided when creating an application for monitoring a patient’s vital sign parameters through the example of the creation of a cross-platform application for people suffering from chronic diseases such as Parkinson's disease. The application collects various data from mobile phone sensors and wearable devices (e.g., accelerometer, gyroscope, microphone, Apple Watch ECG sensor) and sends it to the server for further analysis and processing in a machine learning system for the purpose of adequate diagnosis and proper treatment of the disease.
Architecture
Any mobile application with a focus on personal usage starts with a login screen. For the described application, we chose authorization implemented based on the Amazon Cognito service. Given its relative simplicity of use and solution intuitiveness, Amazon Cognito allows designers to easily add user registration and authentication to mobile and web applications. The convenient external management of the web user authorization method enables them to quickly, efficiently, and securely integrate the authorization mechanism into an application on the server side.
Server-side service integration, even into an existing application, is performed quite quickly and easily. However, we noticed unusual service behavior in some networks (especially those with firewalls and content filtering). Constant switching from mobile internet to Wi-Fi sometimes results in token expiration and requires re-authorization.
For clients with different types of chronic diseases, each function of the application is configurable and can be enabled/disabled depending on the particular task. What is more, it is possible to configure ECG data sensors, physical activity sensors (HealthKit), and weather monitoring. The application functionality can be configured for different clients through plist configuration files (xml-like structure) for a specific client’s application.
The challenge of cross-platform mobile applications is of vital importance, and numerous publications are devoted to it. There are several approaches to this issue; however, we decided to address one that is not the most popular but partially solves the task with a common code base. The solution was dictated by the need for end-to-end integration of server data structures written in Java with client code for iOS/Android. In the described solution, Android code is hooked up as native, and iOS is converted by the utility. In comparison with other possible methods, this method addresses the maximum number of emerging concerns while developing cross-platform solutions.
Business logic is the most important and, at the same time, a relatively easily converted part of an application. It is separated into a different module written in Java, and for the iOS platform, it is best to use the j2obc conversion utility. This also allows writing a single code base for both the server and client application.
The most logical decision for application logic integration is to connect libraries generated after conversion by way of artificial pods compiled on a CI server. Therefore, all network requests as well as data processing and notification generation are performed at the logical level of the application (LL or Logic Layer), and platform-specific functions are carried out in different classes, written in the form of a client with a required outer envelope.
Along with this, the problem with a common code base for the application on a watch and a smartphone remains. Due to restrictions in the system API of watchOS, not all of the libraries can be easily ported to a watch. To get past this roadblock, we decided to create a message-passing mechanism from a smartphone to a watch. This partially addressed the problem, but the issue with synchronous data transmission was not yet fully resolved. Wireless devices have a higher probability of data transfer errors compared to wired devices.
User Interface (UI)
The UI application enables patients to provide information on exercises they perform during the day and drug administration and complete the questionnaire (to collect nonmetric clinical data), which is implemented by means of a list of items with assigned duration.
Screens for exercises, the questionnaire, and drugs are made up into pages with activity history. Exercises might be run either according to the schedule or manually. Exercises might have different durations. After performing exercises, the questionnaire is automatically launched to obtain patient feedback. Exercise or questionnaire reminders are given by local notifications.
Data Exchange
Receiving data from an accelerometer 24/7 taking into consideration potential issues with communication between a watch and a smartphone turned out to be quite a challenging task. For data capture activation, we used the workout mechanism. This method is normally used for fitness exercise registration, and it successfully runs in the background.
The user’s permission is required for reading any type of data from smartphone or watch sensors. The application start-up on a watch is performed only after a user logs in and accepts all the necessary permission requests on a smartphone. Otherwise, the application crashes on the watch, which stems from Apple security policies that require a restart after any updates of user permissions on a smartphone. Exercises cannot be launched, for example, without data access to fitness monitoring. The user is reminded of it by a notification and banners in the application.
When designing an application for a smart watch, developers need to keep in mind that the maximum utilization of a watch CPU by the application itself shall not exceed a certain limit of time (it is different for every watch model). That is why it is necessary to embed interrupts in advance to avoid system errors and the application unloading from the memory. To prevent processor overload, a several-second sleep process may be planned as a workaround; otherwise, the user will face an application restart by the system.
During the development process, we also came across a rather interesting fact: in watchOS, there is a special API for receiving data from a gyroscope. Nevertheless, the data can only be obtained from a numeric array for an accelerometer.
For the purpose of ensuring uninterrupted data flow in critical cases of connectivity breaks between a smartphone and a watch, we had to organize data redirecting upon restoration of connection. In addition, receiving data from a watch accelerometer is followed by different challenges: phone blocks, charging phone, and low battery level. To combat each of these problems, we implemented a mechanism allowing data flow from a database to be filtered (only those areas containing data from the sensors).
We would advise developers of the following: to organize data retrieval from a database, it is necessary to optimize the size of files sent from a watch to a smartphone (we recommend not exceeding 1000 records and precisely defining the record gap; otherwise, you will face application memory overload due to its overflow). Data transmission from a watch does not always work stably due to communication issues, which is why sent files are archived to reduce their size, and this makes data transfer more stable.
In the process of working on the project, we also ran into an issue when reading different types of data. For example, HealthKit data (heart rate and physical activity of a patient) cannot be read in the main application thread, because several days’ worth of data, depending on the interval, may block the main thread for a long time and lead to the application unloading from the memory. Before reading, it is necessary to verify that the screen is unblocked; otherwise, in accordance with Apple security policy, the data will be blocked.
HealthKit data accuracy is also highly questionable, and it does not allow a patient’s condition to be diagnosed with medical precision. However, this data provides an overall picture of physical activity and general habits, which serves as an additional parameter for the optimal choice of treatment options and medication dosage.
New functionality of the Application
In the Apple Watch 4, new promising functions for Parkinson's disease diagnostics, which will require new features for data collection from a wearable device and new projects for software development and its reliability support, have already been implemented.
ResearchKit is intended to be used in a new version of the application. This is a promising platform for open source application development, which allows researchers to register participants and carry out investigations.
Conclusion
New technologies and devices radically change the approach and perspectives of clinical investigations and the evaluation of obtained results and therefore essentially enhance the quality of medical preparations. A growing number of pharmaceutical companies realize that using machine learning technologies will bring them to a new level of drug development and early disease detection. For healthcare delivery workers, this is a quantum leap to truly personalized medicine in which a medication regimen and its action are formed individually for every patient. Methods of data processing are improving, and the volume of processed data is increasing, and if a critical data size is reached, it will undoubtedly lead to a breakthrough in the medical field, allowing researchers to find remedies for diseases currently considered incurable.
Evgeny Zorin is a software engineer at Auriga Inc.
Architecture
Any mobile application with a focus on personal usage starts with a login screen. For the described application, we chose authorization implemented based on the Amazon Cognito service. Given its relative simplicity of use and solution intuitiveness, Amazon Cognito allows designers to easily add user registration and authentication to mobile and web applications. The convenient external management of the web user authorization method enables them to quickly, efficiently, and securely integrate the authorization mechanism into an application on the server side.
Server-side service integration, even into an existing application, is performed quite quickly and easily. However, we noticed unusual service behavior in some networks (especially those with firewalls and content filtering). Constant switching from mobile internet to Wi-Fi sometimes results in token expiration and requires re-authorization.
For clients with different types of chronic diseases, each function of the application is configurable and can be enabled/disabled depending on the particular task. What is more, it is possible to configure ECG data sensors, physical activity sensors (HealthKit), and weather monitoring. The application functionality can be configured for different clients through plist configuration files (xml-like structure) for a specific client’s application.
The challenge of cross-platform mobile applications is of vital importance, and numerous publications are devoted to it. There are several approaches to this issue; however, we decided to address one that is not the most popular but partially solves the task with a common code base. The solution was dictated by the need for end-to-end integration of server data structures written in Java with client code for iOS/Android. In the described solution, Android code is hooked up as native, and iOS is converted by the utility. In comparison with other possible methods, this method addresses the maximum number of emerging concerns while developing cross-platform solutions.
Business logic is the most important and, at the same time, a relatively easily converted part of an application. It is separated into a different module written in Java, and for the iOS platform, it is best to use the j2obc conversion utility. This also allows writing a single code base for both the server and client application.
The most logical decision for application logic integration is to connect libraries generated after conversion by way of artificial pods compiled on a CI server. Therefore, all network requests as well as data processing and notification generation are performed at the logical level of the application (LL or Logic Layer), and platform-specific functions are carried out in different classes, written in the form of a client with a required outer envelope.
Along with this, the problem with a common code base for the application on a watch and a smartphone remains. Due to restrictions in the system API of watchOS, not all of the libraries can be easily ported to a watch. To get past this roadblock, we decided to create a message-passing mechanism from a smartphone to a watch. This partially addressed the problem, but the issue with synchronous data transmission was not yet fully resolved. Wireless devices have a higher probability of data transfer errors compared to wired devices.
User Interface (UI)
The UI application enables patients to provide information on exercises they perform during the day and drug administration and complete the questionnaire (to collect nonmetric clinical data), which is implemented by means of a list of items with assigned duration.
Screens for exercises, the questionnaire, and drugs are made up into pages with activity history. Exercises might be run either according to the schedule or manually. Exercises might have different durations. After performing exercises, the questionnaire is automatically launched to obtain patient feedback. Exercise or questionnaire reminders are given by local notifications.
Data Exchange
Receiving data from an accelerometer 24/7 taking into consideration potential issues with communication between a watch and a smartphone turned out to be quite a challenging task. For data capture activation, we used the workout mechanism. This method is normally used for fitness exercise registration, and it successfully runs in the background.
The user’s permission is required for reading any type of data from smartphone or watch sensors. The application start-up on a watch is performed only after a user logs in and accepts all the necessary permission requests on a smartphone. Otherwise, the application crashes on the watch, which stems from Apple security policies that require a restart after any updates of user permissions on a smartphone. Exercises cannot be launched, for example, without data access to fitness monitoring. The user is reminded of it by a notification and banners in the application.
When designing an application for a smart watch, developers need to keep in mind that the maximum utilization of a watch CPU by the application itself shall not exceed a certain limit of time (it is different for every watch model). That is why it is necessary to embed interrupts in advance to avoid system errors and the application unloading from the memory. To prevent processor overload, a several-second sleep process may be planned as a workaround; otherwise, the user will face an application restart by the system.
During the development process, we also came across a rather interesting fact: in watchOS, there is a special API for receiving data from a gyroscope. Nevertheless, the data can only be obtained from a numeric array for an accelerometer.
For the purpose of ensuring uninterrupted data flow in critical cases of connectivity breaks between a smartphone and a watch, we had to organize data redirecting upon restoration of connection. In addition, receiving data from a watch accelerometer is followed by different challenges: phone blocks, charging phone, and low battery level. To combat each of these problems, we implemented a mechanism allowing data flow from a database to be filtered (only those areas containing data from the sensors).
We would advise developers of the following: to organize data retrieval from a database, it is necessary to optimize the size of files sent from a watch to a smartphone (we recommend not exceeding 1000 records and precisely defining the record gap; otherwise, you will face application memory overload due to its overflow). Data transmission from a watch does not always work stably due to communication issues, which is why sent files are archived to reduce their size, and this makes data transfer more stable.
In the process of working on the project, we also ran into an issue when reading different types of data. For example, HealthKit data (heart rate and physical activity of a patient) cannot be read in the main application thread, because several days’ worth of data, depending on the interval, may block the main thread for a long time and lead to the application unloading from the memory. Before reading, it is necessary to verify that the screen is unblocked; otherwise, in accordance with Apple security policy, the data will be blocked.
HealthKit data accuracy is also highly questionable, and it does not allow a patient’s condition to be diagnosed with medical precision. However, this data provides an overall picture of physical activity and general habits, which serves as an additional parameter for the optimal choice of treatment options and medication dosage.
New functionality of the Application
In the Apple Watch 4, new promising functions for Parkinson's disease diagnostics, which will require new features for data collection from a wearable device and new projects for software development and its reliability support, have already been implemented.
ResearchKit is intended to be used in a new version of the application. This is a promising platform for open source application development, which allows researchers to register participants and carry out investigations.
Conclusion
New technologies and devices radically change the approach and perspectives of clinical investigations and the evaluation of obtained results and therefore essentially enhance the quality of medical preparations. A growing number of pharmaceutical companies realize that using machine learning technologies will bring them to a new level of drug development and early disease detection. For healthcare delivery workers, this is a quantum leap to truly personalized medicine in which a medication regimen and its action are formed individually for every patient. Methods of data processing are improving, and the volume of processed data is increasing, and if a critical data size is reached, it will undoubtedly lead to a breakthrough in the medical field, allowing researchers to find remedies for diseases currently considered incurable.
Evgeny Zorin is a software engineer at Auriga Inc.
