Date of Award
Master of Science (MS)
Dr. Kuang-Ching Wang
Dr. Jerome McClendon
Dr. Melissa Smith
The COVID-19 pandemic strained our healthcare resources and exacerbated the existing issues of primary care shortages and burnout rates for healthcare professionals. Due in part to these factors, telehealth has seen more wide-spread use during this time. However, current asynchronous telehealth applications require stable Internet to function fully. Since many medically underserved populations in the United States lack Internet access in their homes, an application that offers patient monitoring and assessment could extend their access to medical resources. This work proposes such a digital healthcare application for iOS devices and evaluates it based on the system requirements of availability, data security and privacy, and scalability.
The functionality of the application is achieved by using two interacting backends to complete the task of interviewing patients for monitoring and assessment purposes. The Interview Backend is composed of four modules that control the interview process and utilize a rule-set as well as previous patient responses to determine how to progress through an assessment interview. The UI Backend functions as the display for the interview and communicates with the Interview Backend to collect the patient response to a question and present new questions to be answered.
The application's availability is ensured using Kubernetes and the local storage techniques of Apple's iOS sandbox environment. Kubernetes provides built-in functionality for the replica pods and load balancing to ensure stable pods are maintained and available for patients when needed in addition to balancing incoming requests between the available pods to provide similar workloads to each. These pods maintain the web pages for a provider dashboard and process requests from instances of the application. The iOS sandbox environment offers a method for storing patient data locally on a device's Documents Directory while protecting it from unauthorized access from other applications or malicious parties without file-share permissions.
To provide for data security and privacy requirements, federal HIPAA regulations relevant to this application are met through patient authentication, role-based provider access to data, and data separation between patients' electronic Protected Health Information (e-PHI) and Personally Identifiable Information (PII). Patient authentication was implemented to help prevent unauthorized accounts from being created without a provider's permission and to associate patient accounts to their devices, adding an extra layer of security to address potential breaches. Providers are granted the ability to enroll patients in the application by a system administrator, creating roll-based access separating the ability to grant provider permissions from the ability to interact with patient data. This helps prevent data misuse and improper disclosure by requiring healthcare providers to be enrolled in the app by a system administrator similar to the patient authorization process.
Further, patient data separation is implemented between the application's Cloud database and the provider's database to protect the privacy of patient data. All data stored on the application database are de-identified e-PHI and associated with a generated patient ID, thus preventing malicious parties from re-identifying a patient with data collected from the proposed app without also breaching the provider's database containing PII or otherwise already collecting sensitive data on the patient. By encrypting the data while on the application database and in transit, data are further secured as decryption would be required before re-identification can be attempted.
To ensure that the scalability of the application's network to real-world population sizes, three of the largest underserved populations of Oconee County, South Carolina, were used as a basis for three sets of network tests using two of the most common request types from the application. These tests used two of the most common request types for the application, the login and last interview retrieval requests, and included a stress test and two load tests, one of which was a simulated 24-hour test. More specifically, they included 1,000 to 5,000 concurrent requests for the stress test, 1,000 to 5,000 total requests in smaller batches of up to 500 for the first load test, and 10,000 requests normally distributed over a 24 minute period representing 24-hours for the the second load test, or simulation test. For these tests, the average response time, longest response time, and error rate were recorded for the two types of requests, and the response times were compared against the three-second timeout threshold for requests set by the application.
The results of these studies showed that the application is able to process both request types with similar response times while producing no errors. The stress tests exhibited a linear trend that increased as the number of concurrent users increased for the average response times and a less linear trend that also increased for the longest response times. The longest response time was under 2 seconds for these tests, which is below the three-second threshold for a timeout.
The first load tests displayed more erratic trends for both the longest and average response times than the stress tests, with response times increasing overall as the batch size of concurrent requests increased. The reason for this variability in response times is attributed to the sustained batch sizes increasing CPU usage on the Kubernetes cluster more than the stress tests. With a peak longest response time of over 2.5 seconds, this set of load tests neared the three-second threshold and surpassed the longest response times found for the stress tests' data.
The second load tests exhibited trends resembling a normal distribution as expected due to the data being distributed normally over the simulated hours. The request types exhibited similar response times for both the average and longest response times, with the times increasing toward the center of the distributed data. The longest response time for these data was less than 0.7 seconds, much shorter than the peak values for the other two sets of tests and well below the three-second threshold.
Based on the data collected, the request types seemed to have a limited effect on the response type for the population sizes tested. It was also demonstrated that the application can process requests for population sizes similar to those of Oconee County's underserved populations; however the network would likely need more resources to support larger populations due to the risk of timeouts occurring.
In addition to the limitation of the population capacity of the network, this study also was unable to conduct network tests on interview insertions to the database due to the expense, and being constrained to iOS devices. Future research will be conducted to address these limitations, including developing future iterations of this application in React Native to allow for development in iOS and Android simultaneously. In addition, future studies will also explore implementing an authentication server to enhance security, performing tests on SQL query times, and adding additional backend monitoring and assessment features to the provider dashboard.
The digital healthcare application proposed here builds on existing telehealth options by focusing on populations that are currently underserved. The results from this study indicate that the proposed application ensures availability in areas with limited Internet access while at the same time maintaining the level of security and privacy required by HIPAA, and exhibiting scalability to population sizes similar to those explored in this study. By extending our robust telehealth and digital healthcare options, we can better prepare for future situations like the COVID-19 pandemic as well as further improve the effectiveness of our current healthcare system.
Shumin, Brandon, "A Digital Healthcare Application for Patient Monitoring and Assessment" (2022). All Theses. 3856.