A comparative study on HIPAA technical safeguards assessment of android mHealth applications

Abstract

Protecting personal health records is becoming increasingly important as more people use Mobile Health applications (mHealth apps) to improve their health outcomes. These mHealth apps enable consumers to monitor their health-related problems, store, manage, and share health records, medical conditions, treatment, and medication. With the increase of mHealth apps accessibility and usability, it is crucial to create, receive, maintain or transmit protected health information (PHI) on behalf of a covered entity or another business associate. The Health Insurance Portability and Accountability Act (HIPAA) provides guidelines to the app developers so that the apps must be compliant with required and addressable Technical Safeguards. However, most mobile app developers, including mHealth apps are not aware of HIPAA security and privacy regulations. Therefore, a research opportunity has emerged to develop an analytical framework to assist the developer to maintain a secure and HIPAA-compliant source code and raise awareness among consumers about the privacy and security of sensitive and personal health information. We proposed an Android source code analysis framework that evaluates twelve HIPAA Technical Safeguards to check whether a mHealth application is HIPAA compliant or not. The implemented meta-analysis and data-flow analysis algorithms efficiently identify the risk and safety features of mHealth apps that violate HIPAA regulations. Furthermore, we addressed API level checking for secure data communication mandated by recent CMS guidelines between third-party mobile health apps and EHR systems. Experimentally, a web-based tool has been developed for evaluating the efficacy of analysis techniques and algorithms. We have investigated 200 top popular Medical and Health & Fitness category Android apps collected from Google Play Store. We identified from the comparative analysis of the HIPAA rules assessment results that authorization to access sensitive resources, data encryption–decryption, and data transmission security is the most vulnerable features of the investigated apps. We provided recommendations to app developers about the most common mistake made at the time of app development and how to avoid these mistakes to implement secure and HIPAA-compliant apps. The proposed framework enables us to develop an IDE plugin for mHealth app developers and a web-based interface for mHealth app consumers.

1. Introduction

In today’s medical environments, smartphones are becoming increasingly prevalent. According to a survey done in the United States (US) (Krebs, Duncan, et al., 2015), almost 58% of those polled have downloaded a mHealth application and more than 50% of physicians in the US motivate their patients to use smartphone-based medical applications as per (Perna, 2018; Survey, 2019). Moreover, this percentage has increased during medical emergencies (e.g., due to COVID-19 lockdowns Baumgart, 2020; Neubeck, Hansen, Jaarsma, Klompstra, & Gallagher, 2020). Medical smartphone applications are even being used more frequently by healthcare practitioners (Moorhead et al., 2013). These mHealth apps are offered by healthcare providers and used by patients for various reasons such as paying bills, scheduling appointments, sending messages to providers, accessing lab results, and viewing prescriptions and medical records. With patients’ increasing desire for data accessibility and app data sharing, it is critical to ensure that patients transmit their Protected Health Information (PHI) to apps. Hence, the security and privacy of patient health information is an ongoing concern for the mHealth community (Grispos, Flynn, Glisson, & Choo, 2021). In 1996, the Health Insurance Portability and Accountability Act (HIPAA) became law in the United States (Act, 1996). According to the Health Insurance Portability and Accountability Act (HIPAA) regulation, business associates who create or offer a mHealth app on behalf of a covered entity must apply administrative, technological, and physical safeguards to preserve electronically protected health information (EPHI) (Government, 2007a, 2007b, 2016).

According to a survey (Contributor, 2018), 84% of FDA-approved medical health applications had security threats that might expose sensitive data or corrupt the device. Moreover, healthcare data hacks have threatened the patient’s health due to changes in a patient’s medical history (Allan, 2008; Oliynyk, 2016; Smith et al., 2010). A mHealth app must ensure: (1) secure data transmission among the external sensor, third-party API, the provider’s server, the cloud environment, and mobile app; (2) protect data at the time of processing it on the phone and the cloud environment; (3) transparency in data collection, store, and transfer protocols; to meet the security and privacy requirements (HealthIT, 2015). Researchers estimate there are over 300,000 mHealth apps in existence, and some of them are related to a HIPAA covered entity or their business associates. About 25% of healthcare providers suffer from data breaches violating HIPAA policies and they are caused by using mobile devices that come with mHealth apps. This results in lawsuits, and loss of confidence among health providers and patients. According to a research article published in the New England Journal of Medicine (Mandl & Perakslis, 2021), the Office of Civil Rights (OCR) at the Department of Health and Human Services (HHS) announced that it will not impose penalties for using HIPAA-noncompliant private communications technologies during the public health emergency. This announcement significantly raise the use of technology infrastructure recently during the COVID-19 pandemic. As a result, COVID-19 has directly increased unsecured mHealth applications in the market, which needs to be HIPAA Technical Safeguards assessment before further use.

Since early 2016, there have been an average of 4000 daily ransomware attacks and a 300% increase over the 1000 daily ransomware attacks reported in 2015 as per a recent US Government inter-agency assessment. Justice (2015). Healthcare institutions that provide EHR systems, EMR systems, billing systems, practice management systems, computerized physician order entry systems, and the thousands of IoT devices, etc., are an appealing target for cyberattackers as they possess so much information of high monetarily valuable. Furthermore, during the pandemic, cyberattacks on health-care networks have escalated, putting patient care and private data at risk, and potentially violating HIPPA’s Privacy and Security Rules. For instance, a ransomware attack on Dusseldorf University Hospital in 2020 results in patient transfer and one death (O’Neill, 2020). Another recent ransomware attack, Ryuk ransomware attack, on Universal Healthcare Services in September 2020 resulted in EHR disruptions at all 400 sites for around three weeks, costing $67M in lost revenue and recovery (Davis, 2021). Several health care institutions, including Brookside ENT and Hearing Center of Creek in Michigan, Wood Ranch Medical in Simi Valley in California, DCH Health Systems in Alabama, Rouen University Hospital-Charles Nicolle in northern France, Cancer Center of Hawaii, and Hackensack Meridian Health in New Jersey, were attacked with ransomware in 2019 and forced to suspend regular services (Carson, 2019; Davis, 2019; Eddy, 2019; Hepp, 2019).

The HIPAA Security Rule requires covered entities and business associates to security incident procedures and response and reporting processes including detecting and conducting analysis of ransomware, eradicate the instances of ransomware and mitigate or remediate vulnerabilities, data backups and recovery plan, contingency plan, etc. that can assist an entity in responding to and recovering from a ransomware attack as per (HSS.gov, 2016) Fact Sheet. Malicious assaults, such as malware and ransomware, represent serious cybersecurity risks and can result in catastrophic damage to computer systems, data centers, web, and mobile applications in a variety of industries and businesses (Maigida et al., 2019; Sharma, Kumar, & Rama Krishna, 2021). Traditional anti-ransomware solutions are unable to combat newly developed sophisticated attacks (Cooper, Shahriar, & Haddad, 2014). As a result, cutting-edge methodologies such as conventional and neural network-based architectures can be used to create cutting-edge ransomware solutions (Alzahrani & Alghazzawi, 2019; Faruk et al., 2021; Kambar, Esmaeilzadeh, Kim, & Taghva, 2022; Rani, Dhavale, Singh, & Mehra, 2022; Waghmare & Chitmogrekar, 2022).

Earlier research has focused on the security of mobile devices, but has not checking further how apps store or transfer data securely or testing before being used by remote health care providers or users. Most mHealth app developers are not aware of HIPAA security and privacy regulations. This creates the opportunity to develop algorithms and techniques for static and dynamic code analysis aimed at mHealth app developers so their developed products are free from issues as per HIPAA security and privacy guidelines (Sivilli, 2019). Currently, there is a lack of an analysis framework to check mHealth apps’ security and privacy risks by following the applicable HIPAA technical security and privacy guidelines.

We propose an HIPAA Technical Safeguard assessment framework ‘HIPAAChecker’ by designing and implementing a number of analysis algorithms and techniques that focus on static and dynamic analyzing of mHealth source code for Android applications. Moreover, a comparative study has been conducted on the investigated 200 samples of Medical and Health & Fitness category mHealth apps collected from the Google Play store. We have used the qualitative evaluation methods to analyze the result of the HIPAA report generated from the investigated apps and identified the vulnerabilities on the apps. The results show that our framework is highly effective to address potential future data breaches through mHealth apps, while provide in depth too support for developer community. Our core contributions to design, develop, and evaluate the HIPAAChecker are as follows:

1. We propose HIPAA rules based meta-analysis and data-flow analysis algorithms for privacy and security assessment of Android apps.

2. We comparatively evaluate the analysis algorithms and techniques using top popular mHealth application collected from Google Play Store.

3. We provide recommendations to the app developers and consumers based on the findings to reduce the privacy and security risks of mHealth applications.

This paper is organized as follows. We have presented selected literature reviews on the existing framework, tools, and methodologies of security and privacy analysis of Android apps in 2. Section 3 briefly describes the approach and proposed framework of the HIPAAChecker with experimental design. In Section 4, we present the investigation results and comparative analysis of the results to evaluate the efficacy of the framework. Section 5 shows the discussion of the findings with recommendations to mHealth app developers and consumers. Finally, Section 6 concludes the paper with a future research direction and market potential of the framework.

2. Background

In this section, we describe the related work and approaches used to detect the security and privacy vulnerabilities of mHealth applications and how the existing work related to the HIPAA technical safeguards. In Android platform, the situation of mHealth security vulnerability is as extremely serious as it collects, processes, stores, and transfers sensitive user information and personal health records. The HIPAA security regulation, effective in April 2005, enforces administrative, physical, and technical safeguards to ensure the confidentiality, integrity, and availability of electronic health information that is stored or transmitted electronically (Pieper, 2004; Zubaydi, Saleh, Aloul, & Sagahyroon, 2015).

Securing mHealth apps to protect the data of patients and healthcare professionals is important. A recent study in this direction (Morera, de la Torre Díez, Garcia-Zapirain, López-Coronado, & Arambarri, 2016) suggested classifying security risks for mobile health apps into various levels such as high (apps for monitoring, diagnosis, treatment, and care), medium (calculator, localizer, and alarm), and low (informative and educational apps). American Health Information Management Association (AHIMA) suggested guidance (Butler, 2018) to address mobile health data breaches, such as reviewing privacy settings of both the apps and mobile devices, checking signs of certification, using password and encryption, and not sharing confidential and personal health information through texts. However, most vulnerabilities should be addressed and fixed in the mobile health app to reduce security and privacy risks. Such efforts require support to analyze the source code of mhealth applications and test them before approving to use the following security and privacy requirements of HIPAA.

Data security and privacy are major concerns for personal health records according to Kharrazi, Chisholm, VanNasdale, and Thompson (2012). The lack of standardization and security issues involved with mHealth apps are a huge barrier to their widespread use. According to a comparison study (Adhikari, Richards, & Scott, 2014) of the top 20 mHealth apps collected from the Apple store and Google marketplace, 65% of apps required users to enter personal information such as name, address, email, and DOB, but only two apps required user authentication prior to login. 50% of applications stored data in the cloud, posing a serious danger to users’ data privacy and security breaches. Moreover, more than 65% of apps shared consumers’ data with a third party or advertisers without user consent, which violates the privacy regulation. Consumers were only informed about data privacy and security precautions in a small percentage of apps (20%).

Shahriar, Talukder, Chi, Rahman, Ahamed, Shalan et al. (2019) designed a data protection Labware to enforce secure android mobile application development and learning management. As a consequence, this research group has developed an Android Studio plugin tool named DroidPatrol that can perform data flow analysis to detect various security bugs leading to privacy and data leaks based on OWASP guidelines (Riad et al., 2021; Shahriar et al., 2021; Talukder et al., 2019). Moreover, Shahriar, Riad, Talukder, Zhang, and Li (2019) presented a static security analysis approach with open source FindSecurityBugs (find sec bugs, 2019) plugin for Android Studio IDE. They demonstrated that integration of the plugin enables developers to secure mobile applications and mitigate security risks during implementation time.

Based on extensive literature and Internet searches conducted as of December 2020 (Eclipse, 2022; guardsquare, 2022; jetbrains, 2022; Li et al., 2017; Shahriar & Zulkernine, 2012; TrustKit, 2022; UMD, 2020), there is a lack of tools and framework that checks mHealth app security based on HIPAA security requirements of EPHI. Some complementary code analysis tools help developers to maintain and clean up the code through the analysis such as Eclipse IDE (Eclipse, 2022), IntelliJ IDE (jetbrains, 2022), and FindBugs (UMD, 2020). These tools are aimed at detecting potential bugs such as inconsistencies, assisting in the improvement of code structure, conforming source code to guidelines, and providing quick solutions. The data security risk checking based on HIPAA technical security requirements is not their major task. A survey (Li et al., 2017) lists an exhaustive set of Android app analysis tools; however, none of these tools focus on mHealth app security and privacy analysis based on HIPAA technical security and privacy requirements. DexGuard (guardsquare, 2022) and TrustKit (TrustKit, 2022) are recent examples of mobile security analysis tools which was not focused on HIPAA violation. A comparison of the features of existing security tools and frameworks with proposed framework is shown in Table 1. The major difference between all available tools and our framework is that we use static and dynamic analysis techniques for checking source code for identifying the patterns of security and privacy risk, possibly violating HIPAA rules. Secondly, we have developed analysis algorithms to increase the accuracy of detection, which could be piloted after large scale case study and evaluation of the overall performance of the framework.

Table 1.

Comparison of the proposed framework’s features with other market available products.

Tools and Framework	Code check	Vulnerability evaluation	HIPAA evaluation	Design for mobile	Design for mHealth	Static Analysis	Dynamic Analysis	Malware Analysis	Web-tool end-user	IDE plugin
ThreatAlert (stackArmor, 2021)	Yes	Yes	Yes	Yes	No	Yes	Yes	Yes	No	No
Gitlab security tools (Gitlab, 2019)	Yes	Yes	Yes	No	No	Yes	No	No	No	No
FindSecurityBugs (find sec bugs, 2019)	Yes	Yes	No	Yes	No	Yes	No	No	No	No
Acunetix (Invicti, 2022)	Yes	Yes	No	Yes	No	Yes	No	No	No	No
Kiuwan (Kiuwam, 2022)	Yes	Yes	No	Yes	No	Yes	No	No	No	No
Raxis (Raxis, 2022)	Yes	Yes	No	Yes	No	Yes	No	Yes	No	No
PVS-Studio (PVS studio, 2022)	Yes	Yes	No	Yes	No	Yes	No	No	No	Yes
Gamma (Gamma, 2022)	Yes	Yes	No	Yes	No	Yes	No	No	No	No
DeepScan (deepscan, 2022)	Yes	Yes	No	Yes	No	Yes	No	No	No	Yes
DexGuard (guardsquare, 2022)	Yes	Yes	No	Yes	No	Yes	No	No	No	No
TrustKit (TrustKit, 2022)	Yes	Yes	No	Yes	No	Yes	No	No	No	No
Lint (Android, 2016)	Yes	Yes	No	Yes	No	Yes	No	No	No	No
Proposed (HIPAAChecker, 2022)	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes

3. Approach and proposed framework

HIPAA security requirements are divided into three types: Administrative, Physical, and Technical. Policies and procedures designed to govern the selection, development, implementation, and maintenance of security measures are referred to as administrative safeguards. Physical safeguards refer methods, policies, and procedures that are designed to safeguard equipment from natural and environmental hazards and unauthorized access. Finally, technical safeguards refer to the technology and policy-related measures that protect and control access to electronically protected health information (EPHI) (Farhadi, Haddad, & Shahriar, 2019; Ouellette, 2012; Snell, 2015; Staff, 2022).

Our source code analysis algorithms focus on issues related to twelve HIPAA Technical Safeguards as shown in Table 2. If technical safeguards in mHealth apps are complied, it will be possible to meet other types of administrative and operational safeguards (e.g., offering tools and applications to review and monitor administrative security features) and prevent adverse incidents (e.g., not complying with physical safeguards). For example, if a cell phone with a mHealth app is lost or stolen, stealing PHI data that has already been encrypted would be extremely difficult.

Table 2.

HIPAA Technical Safeguards.

Rule Reference	Rule Name	Technical Safeguards
164.312(a)(1)	authorization	Providing access controls to allow EPHI access only to persons or programs that have been granted access rights
164.312(a)(2)(i)	unique_id	Assigning unique id for identifying and tracking patient’s identity
164.312(a)(2)(ii)	phi_emergency	Establishing procedures for obtaining necessary EPHI during emergency
164.312(a)(2)(iii)	user_inactivity	Implementing procedures to terminate a session after a predetermined time of inactivity
164.312(a)(2)(iv)	encryption_decryption	Implementing encryption and decryption of EPHI
164.312(b)	audit_control	Implementing audit controls to record and examine activity that contain or use EPHI
164.312(c)(1)	data_integrity	Maintain EPHI data integrity to prevent improper alteration or destruction
164.312(c)(2)	unauthorized	Mechanisms to corroborate that EPHI has not been altered or destroyed in an unauthorized manner
164.312(d)	user_authentication	Implement authentication procedures to verify that a person or entity seeking access to EPHI is the one claimed
164.312(e)(1)	guard_against_com_network	Implement technical security measures to guard against unauthorized access to EPHI that is being transmitted over communications network
164.312(e)(2)(i)	transmition_secuirity	Implement measures to ensure that transmitted EPHI is not improperly modified without detection until disposed of
164.312(e)(2)(ii)	phi_encryption	Encrypt EPHI whenever appropriate

The proposed analysis framework has focused on Android mhealth apps that designed and developed for accepting patient data as input, which may be further stored in the device, or transmitted to other parties following HIPAA technical security requirements. While some analysis tools exist (e.g., findsecuritybugs find sec bugs, 2019), they are concerned with app implementation language such as Java-specific security checking. The purpose of the framework is to develop the automatic analysis of application source code and identify patterns of security and privacy present in mhealth apps. Fig. 1 shows the overall architecture.

Fig. 1.

Proposed framework architecture.

The tool allow mHealth developers to identify vulnerabilities that can affect HIPAA technical security and privacy requirements and fix them before sharing apps in the marketplace through Android Studio. It also allow users to check the data leakage through APK file URLs. Android applications are usually developed in Java language, compiled into dex format files, and run in Android virtual machine instances (Tang, Li, Wang, Gu, & Xu, 2020). Using JADX (JADX, 2018), we have decoded AndroidManifest.xml and other resources from resources.arsc and de-compiled the dex file into java classes. The Framework Virtual Machine contains the metadata for analysis algorithms. The call graph generator map different elements to the corresponding Java objects based on the metadata to complete the analysis, and detect the HIPAA violation.

3.1. Metadata analysis

To extract metadata information from Android applications, metadata analysis uses de-compiling technologies in our framework architecture. The underlying meta-analysis mechanism to analyze mHealth Android apps’ source code based on HIPAA technical security and privacy requirements follow the steps of Algorithm 1. We have directly analyzed whether HIPAA rules violation or compliance functions, algorithms, or methods are called or not in the source code through string regular matching. The metadata-based static analysis enables the detection of possible locations of data flow and inspects with real input next through dynamic analysis in an emulator.

Algorithm 1 Meta Analysis

$$\begin{array}{cc}\hfill & \mathbf{procedure}\text{METAANALYSIS}(\text{apk})⊳\text{Take APK as an input}\hfill \\ \hfill & \mathbf{Step}1:\text{Take APK file as an input from the user through upload}.\hfill \\ \hfill & \mathbf{Step}2:\text{Store the uploaded apk into the server disc and make a respective database record}.\hfill \\ \hfill & \mathbf{Step}3:\text{Extract the apk in the first level to obtain compiled}∕\text{encrypted source code}.\hfill \\ \hfill & \mathbf{Step}4:\text{Decompile}∕\text{Decrypt the compiled source code in the second level extraction to readable source code}.\hfill \\ \hfill & \mathbf{Step}5:\text{Recursively traverse all the second level extracted source code to match HIPAA rules}.\hfill \\ \hfill & \mathbf{Step}6:\text{Take the match result corresponding to a source code file of that apk and store it}.\hfill \\ \hfill & \mathbf{Step}7:\text{Analyze the match result and group them according to HIPAA rules}.\hfill \\ \hfill & \mathbf{Step}8:\text{Build a HIPAA compliance report from analyzed results}.\hfill \\ \hfill & \mathbf{Step}9:\text{Display the report and allow users to see specific HIPAA related security flaws}.\hfill \end{array}$$

3.2. Data flow analysis

The call graph has been generated by analyzing source code from the dissemble APK with Apktool (Apktool, 2022), which is an open-source Apache licence APK decompiler library. The call graph provides a list of paths between health data sources and sinks. A data source is an input coming from users (e.g., name, SSN, Rx number) and a sink is the destination of data for storage or processing or transmission to third parties (e.g., SMS message, email, database). The source data may include PHI data such as patient name, SSN, and Rx. However, sources and sinks to be expressed in terms of Android classes. For example, the diagram in Fig. 2 shows an example of Source as database Cursor object, and the sink as SmsManager (SmsManager), with the API sendTextMessage that can trigger a potential data security breach and HIPAA violation if data obtained from a database query not encrypted before sending to SMS channel.

Fig. 2.

Example of Source as Database Cursor object and SINK SmsManager.

3.3. HIPAA rules

We use formal language to describe the corresponding vulnerability pattern based on HIPAA requirements instead of natural language. The HIPAA technical safeguard patterns are formally described as Eq. (1). The complete list of the pattern-based matching for meta-analysis is described in Table 3.

Table 3.

HIPAA rules based meta-analysis and data-flow analysis techniques.

HIPAA Rule (r)	Detection process (d)	Sub Rule (s)	Vulnerabilities (v)	Example Code Patterns (p)
authorization	meta-analysis	Access Control-1	This Application implements authorization to access sensitive resources.	- AuthorizationException
		Access Control-2	This Application restricts illegal access to sensitive resources.	- IllegalAccessException
encryption_decryption	meta-analysis	EN-DE	Base64 encoding and decoding is present	- import java.util.Base64;
		AES	Calling Cipher.getInstance(“AES”) will return AES ECB mode by default. ECB mode is known to be weak as it results in the same ciphertext for identical blocks of plaintext.	- import org.springframework.security.crypto - import java.security.Security; - Cipher\.getInstance\(\s*“\s* AES\/ECB - Cipher\.getInstance“AES”
		MD5-Weak	MD5 is a weak hash known to have hash collisions.	- Cipher\.getinstance\(\"rsa/.+/nopadding - \.getInstance\(.*rc2 \.getInstance\(.*blowfish - \.getInstance\(.*RC2 - \.getInstance\(.*rc4 - \.getInstance\(.*RC4 - \.getInstance\(.*BLOWFISH - Cipher\.getInstance\(.*DES - Cipher\.getInstance\(.*des
		Message Digest-1	Message Digest	- import java.security.MessageDigest; - \.getInstance\(.*MD5 - \.getInstance\(.*md5 - DigestUtils\.md5\(
		SHA-1	SHA-1 is a weak hash known to have hash collisions.	- \.getInstance\(.*SHA-1 - \.getInstance\(.*sha-1 - \.getInstance\(.*SHA1 - \.getInstance\(.*sha1 - DigestUtils\.sha\(
		ECB	The App uses ECB mode in Cryptographic encryption algorithm. ECB mode is known to be weak as it results in the same ciphertext for identical blocks of plaintext.	- Cipher\.getInstance\(\s*"\s*AES\/ECB
		Message Digest-2	This App uses Message Digest (MD) algorithm encryption.	- java\.security\.MessageDigest - MessageDigestSpi - import org.apache.commons.codec.digest.DigestUtils; - import org.apache.commons.codec.digest.HmacAlgorithms; - import org.apache.commons.codec.digest.HmacUtils; - MessageDigest
guard_against_com_network	data-flow	COM-NET	Unauthorized access to PHI that is being transmitted over communications network is restricted.
phi_encryption	meta-analysis	DE-1	This App Uses Base64 or Other Decoding	- android\.util\.Base64 - \.decodeToString - \.decode
		EN-1	This App Uses Base64 or Other Encoding	- android\.util\.Base64 - \.encodeToString - \.encode
		ENCRYPT	This App use Realm Database with encryption.	- io\.realm\.Realm - \.encryptionKey\(
		SQLChiper	This App uses SQL Cipher. SQLCipher provides 256 bit AES encryption to sqlite database files.	- net\.sqlcipher\. - AS encrypted KEY
transmition_secuirity	meta-analysis	EXT-API	This Application uses Authorization header to secure external API calls.	- addRequestProperty\(\"Authorization
		PKIX	This Application uses checking the revocation status of certificates with the PKIX algorithm.	- PKIXRevocationChecker
		TRANS-Data	This Application uses secure connection to transmit data.	- HttpsURLConnection new
unique_id	meta-analysis	PKey	Creating a unique primary key in the database for storing PHI	- PRIMARY KEY
user_authentication	meta-analysis	FireBaseAuth	Checks whether application is using FireBase Authentication	- FirebaseUser - sendFirebasePropertyRegisteredUser - FirebaseUserPropertiesSender - com\.google\.firebase\:firebase-auth - FirebaseAuth
		oAuth	Checks whether application is using android API oauth	- android\.accounts\.AccountManager - AccountManager\.get\( -\.currentUser
user_inactivity	meta-analysis	Inactivity	User Inactivity is detected and handled properly	-public void onUserInteraction\(\) - \.reset\(\) - \.clear\(\) - \.commit\(\)

$$H=(r,d,s,v,p)$$ (1)

Where H represents the HIPAA technical safeguard in mHealth applications, r denotes the rule reference, d refers to the detection process, s refers to subrules of HIPAA Technical Safeguard, v indicates vulnerability information or vulnerability evidence, and p is the patterns of HIPAA compliance.

3.4. Implementation

We have implemented and released the beta version of the framework as a web-based platform for experiments (HIPAAChecker, 2022). The web app of the framework allows users to check HIPAA rules violation through APK file or URL and generate the report. Eight HIPAA rule-specific analysis algorithms have been implemented experimentally (Fig. 3). Two layers of security have been applied to ensure the highest level of security to access the resources of the web services. Layer 1: Password-protected website access where we restrict access to the URL of the website to users who do not have the access username and password, and Layer 2: User account and authentication security using JSON Web Token (JWT) and two-factor authentication (2FA). The platform has been designed in such a way that we can easily integrate the analysis API with a Integrated Development Environment (IDE) (e.g. Android Studio) as a plugin tool.

Fig. 3.

Beta version of the HipaaChecker deployed on AWS.

3.5. mHealth apps collection

We manually collected 200 mHealth apps from the Google Play Store’s Medical and Health & Fitness categories to assess the extent to which current health apps pose a HIPAA violation threat. The selection of the apps is prioritized based on the features and functionalities that are stored, processed, managed, and transferred EPHI. Moreover, the covered entities and business associates of the selected apps are from different demographic locations. We have considered the top-rated downloaded apps (10M+) to low rating apps (100+ downloads) in the selection process. The detailed description of the collected apps (30 apps out of 200 samples) is shown in Table 4.

Table 4.

Description of a snapshot of 30 mHealth applications out of 200 samples collected from Google Marketplace.

APP	File Size (MB)	User Base	Total Download	Category	Features
APP1	53	Italy	10,000,000+	Medical	Electronic Medical Record (EMR), Appointment, Billing
APP2	15	USA	100,000+	Medical	Electronic Medical Record (EMR), Appointment, Billing, Imaging reports, Data sharing.
APP3	3	Global	100+	Medical	Behavioral Health Practice
APP4	48	USA	10,000,000+	Medical	Symptom Checker, Allergy Tracker, Medication Reminders, Drug Interaction Checker, Treatment Decision Support.
APP5	97	India	1,000+	Medical	Patient Management, Health Record, Appointment, Message Billing, Video Conferencing, e-Prescribing, Report
APP6	15	Ghana	500+	Health & Fitness	View your insurance policy, Get access to your claims history, Track all visits to your health provider, Find a Health provider, Receive important notifications on new health policies, Keep information on your dependents.
APP7	42	European Union	5,000,000+	Medical	Smart health results, Personalized health information, Health assessment report, Symptom tracking.
APP8	10	Global	100,000+	Health & Fitness	access your digital membership card, submit or check the status of your medical claim, check your benefits and explore your cover, consult the Health Assistant.
APP9	165	Global	500,000+	Medical	A social media for health, wellness, and lifestyle topics, An accurate AI-based and personalized symptom checker, A booking system
APP10	61	Global	100,000+	Health & Fitness	Submit and view your claims, View and Print ID cards for the entire family, Find health care providers and facilities, Pharmacy Access
APP11	98	Global	1,000,000+	Medical	Order medicines online, Book lab tests from home, Consult doctors online, Access reliable information about medicines and diseases, Health monitoring, Reminders for medicines
APP12	141	Global	10,000+	Medical	Electronic Medical Record (EMR), ePrescriptions, Appointment and SMS/email reminders, E-Billing, Expense Management, Reports and Analysis, SMS/Email Campaign.
APP13	97	Global	100,000+	Health & Fitness	Appointment, Consultation, ePrescription, Drug services.
APP14	16	Global	100+	Medical	Electronic Health Records (EHR)
APP15	26	Global	100,000+	Medical	Diagnostic Decision Support
APP16	57	Bangladesh	500,000+	Medical	Appointment, Video consultation, ePrescription, Diagnostic tests, Medicine, Health records, Billing.
APP17	9	Global	100,000+	Medical	Clinic information system, Doctor Patient Medical Record, Healthcare management mobile application, Patient Medical Records to track Patient history. Electronic Health Records.
APP18	12	Global	100,000+	Medical	Store, manage, and share medical history
APP19	73	Global	500,000+	Medical	Clinical Decision Support
APP20	50	Pakistan	50,000+	Health & Fitness	Electronic medical Records (EMR), Appointment, Consultancy, Booking, Prescription, Medicine, Billing.
APP21	29	Canada	100,000+	Medical	Electronic Health Records (EHR), Medicine, Immunizations, Personal health devices, Health journals, Data sharing.
APP22	26	Global	1,000,000+	Health & Fitness	Appointment, Telemedicine.
APP23	47	Global	10,000+	Medical	Appointment, Video consultation, Prescription.
APP24	16	Global	100,000+	Medical	Point-of-care, Diagnosis and medicine management.
APP25	13	Global	100,000+	Medical	Telemedicine, Appointments, Video consultations, Medical report, Prescription, Billing.
APP26	95	China	1,000,000+	Medical	Electronic Health Records (EHR), Appointments, Allergies, Medications, Vaccines.
APP27	67	India		Medical	Appointment, Video consultations, Book lab test, Order medicine, Report.
APP28	104	Bangladesh	10,000+	Health & Fitness	Electronic medical Records (EMR), Appointment.
APP29	100	Singapore	100,000+	Medical	Video consultations, Doctor and nurse home visits, Lab tests, vaccinations, virtual hospital, Medicine, Emergency services.
APP30	267	Global	100,000+	Medical	Clinical Decision Support

4. Results

We considered top-rated apps as of May 2022 to evaluate the efficacy of the proposed algorithms and techniques of meta-analysis and data flow analysis. We have comparatively analyzed the generated result of a 200 apps by our analysis algorithms, also identifying the extent to which each HIPAA Technical Safeguard was evident.

The HIPAA analysis report data has been extracted from the system database and performed exploratory data analysis on this data using Jupyter Notebook. A total of 8693 lines of codes from the investigated apps have been detected that are relevant to HIPAA regulation. Among the detected code segments, app developers mostly focused on Encryption and Decryption (39.7%), Access Control (30.5%), and EPHI Encryption (23.7%) as shown in Fig. 4(a). Fig. 4(b) indicates that most of the apps used weak ECB mode and Message Digest (MD5) algorithm to encrypt–decrypt the data and less concerned to implement authorization mechanism to access sensitive resources. Moreover, the medical category apps implement security measures to ensure the privacy and security of consumers’ information rather than the Health & Fitness category apps as per Fig. 4(c). The percentage of apps that applied AES, Encoding–Decoding, Realm Database Encryption, PKIX Algorithm, and FireBase Authentication are relatively less than 20% as per Fig. 4(d).

Fig. 4.

Source code analysis results.

Fig. 4(e) is shown a summary of the comparative analysis of the 30 mHealth apps. The results illustrate that not all mHealth apps are free of issues. Out of the 30 apps, only nine (30%) implement authorization to access sensitive resources which is a required HIPAA Technical Safeguard. Even though some popular apps such as “APP4” (10M+), “APP11” (1M+), and “APP22” (1M+) have higher HIPAA compliance scores (14+ out of 17) these apps also have a considerably higher score of HIPAA technical rules violation such as they had used weak MD5 hash function for encryption and decryption. Other highest downloaded apps such as “APP1” (10M+), “APP7” (5M+), and “APP26” (1M+) that store, manage, process, and share Electronic Health Records (EHR) have satisfied the HIPAA required rules such as Access Control, Encryption and Decryption, Data Transmission Security, etc. However, among them, only “APP26” uses checking the revocation status of certificates with the PKIX algorithm before transmitting data to the third-party via external API and only “APP1” addresses the Automatic Logoff.

5. Discussion and future trends

This study aimed to investigate the data security and privacy features of top popular free and paid health apps as per the HIPAA guidelines using our HIPAAChecker framework. According to our findings, the main risks posed by the investigated mHealth apps are insufficient security policies to protect consumers’ sensitive data, information shared with third-party or external APIs, and a lack of authorization prior to accessing sensitive resources. We recommend that apps developer should more focus on secure external API integration and use strong encryption and decryption protocol such as Advanced Encryption Standard (AES), Rivest–Shamir–Adleman (RSA), etc. A set of recommendations to consumers and app developers is provided in Table 5.

Table 5.

Recommendations to mHealth app consumers and developers.

Consumers	App Developers
1. Research the app before downloading it	1. EPHI should always be stored encrypted using strong encryption algorithms e.g. ASE so attackers cannot retrieve data.
2. Use third party tools to check the HIPAA compliance of the apps before entering you sensitive and personal health information	2. Try to avoid common encryption algorithms such as MD5, SHA-1, ECB. In our study 86.67% apps use MD5 and 73.33% apps use SHA-1.
3. Examine the user reviews and the app’s privacy policy, either in the app store or online.	3. Use authorization for accessing sensitive data and authorization header for external API calls. In our study 70% apps use authorization header.
4. Give review and feedback on products that will help the developers and researchers to restructure the app appropriately.	4. Use Realm Database with encryption or SQLCipher to sqlite database files.

The global mHealth apps market size was valued at USD 38.2 billion in 2021 (mHealth Apps Market Size & Share Report, 2022–2030, 2021) and is expected to reach USD 236.0 billion by 2026 (Grand View Research Report, 2022). It is projected to expand at a compound annual growth rate (CAGR) of 44.7% during the forecast period. Mobile Market shares show android occupies a large percentage of the users, roughly around 87%, and the rest 12.5% by iOS. According to the U.S. Department of Health and Human Services (hss.gov, 2016), an app developer needs to comply with the HIPAA Rules. Thus, the automated tools to assess the HIPAA requirements of mHealth apps are one of the most market demands. The framework we have developed can offer the following services in the future to the app developers and consumers: (a) offering awareness regarding potential health data security breaches among mHealth consumers through the web-based interface, (b) developing a plugin-based tool that can be integrated with the Integrated Development Environment, particularly Android Studio, so that apps can easily be checked for security and privacy issues affecting HIPAA technical and security requirements, (c) increased awareness of developing HIPAA security and privacy compliant mHealth apps for Android (the largest market share in the USA) and extending the framework for iOS applications, particularly Swift source code analysis.

6. Conclusion

In this paper, we demonstrate that the top popular mHealth apps available in the marketplace are not free of privacy and security issues as per the guideline of HIPAA Technical Safeguards. The proposed HIPAAChecker framework analyzes mHealth apps using metadata and data flow analysis technique where potential sources (e.g., data input) and destinations (where data is used to generate output) are identified by analyzing a source code and warnings are generated if data sources reach to unintended data sinks, indicating violating HIPAA technical security and privacy requirements.

Apps developers must focus on the major vulnerable areas, which are HIPAA rules 164.312(a)(1): Access Control, 164.312(a)(2) (iv): Encryption and Decryption, and 164.312(e)(2)(i): Data Transmission Security. We recommend mHealth apps developers how to avoid the mistake and use appropriate algorithms to protect the data leakage. Moreover, awareness among apps consumer needs to be risen to share the EPHI only if the apps are compliant with HIPAA regulations by self-verifying.

Data availability

The data that has been used is confidential.