Authentication & Integration Approaches for mHealth Apps from a Usability View

Mobile health (mHealth) apps are increasingly adopted in healthcare domains, such as diabetes management, physical activity monitoring, and HIV treatment. However, mHealth app development is restricted due to healthcare privacy regulations, which require apps to handle collected data securely. The advent of online platforms, such as REDCap, alleviates this problem by providing privacy-compliant databases, so that mHealth apps developed for research groups can securely handle stored inactive data (data-at-rest) with fewer privacy concerns. Unfortunately, the authentication architectures of many online platforms do not meet the needs of mHealth apps and provide insufficient integration support. Assumptions made in other types of mobile apps about how users operate, such as a user’s ability to type or remember a password, therefore may not be valid in the mHealth domain. To address these problems this paper evaluates how authentication approaches impact the usability of mHealth apps. In particular, we present metrics to evaluate usability and show how the Proxy User Adapter pattern can integrate usability-enhanced authentication approaches to legacy secure database providers. We also propose a QR-Code authentication approach that applies the Proxy User Adapter pattern to help mHealth apps overcome common impediments, improve processing efficiency, and reduce potential mistakes caused by patients and providers alike.


Introduction
Emerging trends & challenges. The advent of mobile devices has spurred development and adoption of mobile health (mHealth) apps to support healthcare research and clinical practice. mHealth apps have been widely adopted in chronic condition monitoring, remote patient monitoring, and disease treatment [1], testing, and data collection [2]. Prior research [3] has shown that combining mHealth apps with other interventions helps improve overall quality of care.
Security and privacy are key challenges that must be addressed when developing and deploying mobile technologies. In particular, sensitive patient data must be protected in mHealth apps, which may store users' eating habits [4], daily activities [5] or sleeping patterns [6]. This sensitive, private data may be collected by mobile devices (such as Android advertising networks [7] and passive collection mechanisms [8]) (such as connection between advertising identifiers and device-level identification). However, it can also intercepted and sold on the black market [9,10] since collected data can be linked with users' Google identities. Protecting the privacy of sensitive data requires rigorous authentication and security mechanisms, such as data-at-rest and data-in-transit encryption.
One element affecting mHealth app data-in-transit security is Cyber-Physical identity (CPI) linkage, which connects a patient's digital identity in a medical record system (e.g., master patient identifier) to a physical mobile device. This linkage is vital to collect patient data accurately and securely. For example, a mismatched identity may cause incorrect information sent from a mobile device to enter the wrong patient record and impact treatment decisions, such as prescribing an incorrect dosage of opioids to the wrong patient.
The CPI linkage process is akin to checking arm bands in a hospital to ensure that the correct person is linked to a medical record. In the case of CPI linkage, however, patient records are linked to mobile device(s) that report health information related to that patient. The linkage process typically involves connecting a given credential with a patient's identity. For example, providers may either generate a long-term username/password recorded by a patient or provide a one-time security code on a billing statement.
To ensure security and identify validation, many authentication methods have complex workflows, which require users to follow a list of steps, such as providing email, phone number, and other identifiers. For mHealth apps, however, ensuring effective usability is essential since users are often (1) patients with health problems, who may be limited by mental or physical conditions or (2) nurses and providers, who have limited time and who already follow complex processes. Prior research shows that usability directly impacts the frequency of use and adoption of mHealth apps [11].
Privacy regulations also require data-at-rest be stored securely and meet certain requirements. For example, collected patient data must be stored in a Health Insurance Portability and Accountability Act (HIPAA)compliant environment, which incurs higher cost and effort when developing mHealth apps, especially apps designed for small groups of healthcare providers. Online platforms (often created by healthcare research institutes) are one means for overcoming privacy challenges in data collection by providing secure data storage. For instance, Vanderbilt University created RED-Cap [12] in 2004 to support small groups of researchers collecting data in a HIPPA-comliant manner.

Key contributions.
This paper extends our prior work [13] on evaluating mHealth authentication techniques and examines an architectural pattern for adapting different mHealth authentication schemes to existing patient and research data information systems. In addition, this paper analyzes how various authentication and CPI establishment architectures impact the usability of mHealth apps for patients and providers.
For example, we explore a method for evaluating mHealth authentication method usability in the context of patient and provider burdens. In particular, we evaluate two popular approaches-username/password and SMS based authentication-in the context of sev-eral key process aspects. Based on the results of this evaluation, we propose a third method-QR-Code token transfer and authentication-designed to overcome limitations with conventional approaches.
Paper organization. The remainder of this paper is organized as follows: Section 2 presents a case study, the PainCheck app, which is used throughout the paper to motivate the need for QR-Code token transfer and authentication; Section 3 summarizes different usability and process barriers that impede the adoption of mHealth apps and proposes evaluation methods to assess them; Section 4 describes the design of our of QR-Code authentication architecture; Section 5 analyzes usability challenges in legacy authentication approaches and describes how our proposed authentication method uses QR codes and authentication tokens to address those challenges; Section 6 compares and contrasts our research with related work on mHealth security; and Section 7 presents concluding remarks and outlines future work.

Motivating Example
For decades, pain monitoring has played a critical role in healthcare [14,15]. Evidence extracted from published data [14] shows that concise postoperative pain measurement positively influences the pain management strategy. Researchers and clinicians attach great importance to subjective pain severity measurement [15], which helps determine appropriate dosage of pain medications.
This paper uses the PainCheck mHealth app as a case study to motivate our authentication and integration approaches. This app was developed at Vanderbilt University to help patients report their pain levels following thoracic surgery in both acute and postacute settings. Figure 1 shows several screenshots of our PainCheck app.
Immediately following surgery, nurses, patients, and care-givers use PainCheck to report subjective pain levels for patients suffering from post-operative pain. Patients and care-givers can report pain scores in the hospital and after leaving for a configurable period of time. With these timely pain reports, such as pain level and activity level, PainCheck can visualize patients' pain status, which helps providers quickly refine patients' pain management strategy. Unlike regular userreported apps, patient data collected via PainCheck strictly follows healthcare privacy regulations.
For example, the Unite States (US) requires healthcare data be stored in an HIPAA-compliant manner. We chose Research Electronic Data Capture (RED-Cap) [12] as the data management system to store data and design data collection instruments administered via mHealth apps. REDCap is a web app developed by Vanderbilt University that provides research teams with a reusable system to collect and manage clinical data and meet HIPAA and Institutional Review Board (IRB) standards for patient privacy.
REDCap is widely adopted in research communities and used in over 100 countries for over 612,000 projects, such as the Texas twin project [16], librarian-mediated literature searches [17], and biomedical research [18]. Integrating our PainCheck app with REDCap allowed us to leverage existing institutional knowledge on the use and operation of the system, as well as overcome challenges in deploying a resilient system that stores HIPAA-protected data securely.
Adherence to HIPAA privacy rules is required for US health research to protect data confidentiality [19]. However, researchers have observed that the HIPAA rules can negatively impact research progress in terms of cost and delays [20] and create compliance challenges in mHealth research for both providers and developers [21]. REDCap is designed to meet privacy requirements, which is an efficient resource for mHealth research to handle secure data storage without incurring the drawbacks of app-specific privacy considerations.

3.
Usability Challenges in CPI-linkages of mHealth Apps to help researchers understand how mHealth authentication methods impact patients and providers, this section examines several types of usability challenges incurred by different authentication approaches. This section also describes evaluation metrics we developed to measure how mHealth cyber-physical linkage and authentication approaches impact usability.

Memory Impediments
A "memory impediment" is a requirement for a patient to remember a specific set of information, such as a username/password or a process that must be followed. Remembering a long string of account/password characters can be hard for patients who are already in pain. Moreover, even healthy individuals rarely change their passwords and tend to use the same passwords among various services due to the effort needed to learn and remember new passwords.
A survey conducted by Telesign [22] revealed that 21% and 47% of people use 5-year old and 10-year old passwords, respectively. Moreover, 70% of customers are concerned with their account security, but 73% of accounts still use the same password. This practice is highly vulnerable to attack since hackers need only obtain access to one password to attack other accounts of the same owner. Password problems make up 20-30% of all IT service desk volume [23], so requiring nurses or providers to manage credential transfer to patients can introduce a substantial usage barrier.
According to a survey conducted by HDI (339 service centers) [23], roughly 3 out of every 10 IT tickets received by support centers are related to password resets. To ensure security, 52% of organizations require users to change their password every 3 months, and 28% of them require higher frequency of password reset. Sixty-eight percent of organizations require customers to keep 2-5 passwords, while only 13% need customers to remember just one password. For patients and providers, however, requiring changes in passwords can add a substantial burden. It is therefore beneficial to consider security approaches that maintain security without requiring patients and providers to continually learn new or complex credentials.
We define the following metrics to measure the memory and recall burden placed on a patient relative to the security of the underlying authentication credential.

M1
. Total characters remembered relative to credential length. With the traditional username/password approach, users must remember an amount of data proportional to the length of the credential pair (i.e., it is O(N ), where N is length of characters users need to remember). Longer passwords tend to increase security by protecting user account information against attacks, so providers may add a layer of protection that requires users to create a password with a minimum length, which creates extra work for users to remember a longer password.
In contrast, encrypted credentials provided by some authentication methods alleviate users from remembering complicated credentials. These methods map user information with an arbitrarily long token. The length of this token has no affect on how much the user must remember (i.e., it is O(1), where the character users need to remember is not related to token length).
M2. The duration that patients need to remember the data relative to length of treatment. The duration that patients need to remember their credentials is flexible for mHealth apps. Target user groups of mHealth apps vary depending on the functions offered by a certain app. For our PainCheck app, the majority of target users could be chronically ill patients suffering from pain, patients who have undergone a surgery, or those who are recovering from a surgery and are under observation. In these cases, users must only remember their credential data for a certain period of time, e.g., as long as they are active users of the app. Conversely, the frequency and duration of using in-hospital mHealth app could be decided by providers. When the frequency is low and the duration is short, the likelihood of users forgetting their password increases.
We use metrics M1 and M2 to ascertain how much a patient must remember relative to the security of the underlying credential. Some processes require patients to remember the complete security credential. A patient must therefore remember as many characters as there are in the underlying security credential used to authenticate, such as O(N ) characters, where N is the length of the security credential.
As shown in Section 5, other authentication approaches just require the patient to remember a specific password, which only has a one-time use. This password can then be exchanged by the device for an authentication token that can be much more complex than the original password. The authentication credential and the password are therefore decoupled because after the first use the token is used to authenticate and need not be remembered by the patient.
The total characters remembered by the patient in this approach is O(1) since the length of the one-time password is constant and independent of the length of the security token. As with algorithmic complexity analysis, authentication approaches that require patients to remember O(1) characters are typically better than approaches that require O(N ) characters.

Physical Impediments
Physical impediments are operations a patient must perform during the authentication process, including pressing on a mobile device, typing on the device, or shaking the device. According to a survey in 2003 [24], elderly patients age 65 and older constitute one third of hospital stays. Eyesight, senility, and postoperative fatigue are common problems in elderly patients and can impact data entry on mobile devices. Moreover, typos happen more frequently on mobile device virtual keyboards compared to typing on a physical keyboard. Likewise, typing on a small screen is slower for most people, particularly those with age-related motor control issues or surgery-related health issues.
mHealth apps should minimize these physical impediments to facilitate use. We hypothesized that an ideal authentication method should reduce these impediments to improve user experience while maintaining equivalent security. To evaluate this hypothesis, we analyzed total characters typed relative to credential length and total characters typed for credential recovery relative to credential initialization. We therefore propose the following two measures of physical impediments to assess mHealth authentication approaches: Ph1. Total characters typed relative to credential length. For username/password authentication, the amount of characters patients need to type is linearly dependent on the length of credential pairs (i.e., it is O(N ), which is equal to the length they need to remember). If credentials is encrypted by an authentication method, patients only need to input constant characters of (i.e., it is O(1)).
Ph2. Total characters typed for credential recovery relative to credential initialization. When patients lose or forget their credentials, they must update their credentials via a credential recovery mechanism, which may require patients to provide additional identity information (such as a phone number or email address) to retrieve credentials securely.
For example, a password reset link will be sent to the corresponding email address so that patients can create new passwords. In this case, the total characters typed is same as credential initialization (i.e., it is O(N )). For some authentication methods, both credential initialization and credential recovery process require no data input (i.e., it is O(1)).
Similar to the memory impediments, we measure physical impediments in terms of how much typing a patient must perform relative to the length of the underlying security credential. Better authentication approaches for mHealth apps allow the length of the underlying security credential to vary independent of how much data a patient enters.

Process Impediments
Process impediments capture the complexity and potential errors inherent to an mHealth authentication architecture. For example, when nurses treat a number of patients each day, a long repetitive account setup process can yield mistakes, such as giving the wrong authentication credentials to a patient, causing them to submit pain data to the wrong patient record. Process barriers can be analyzed by calculating the total process steps for both providers and patients. We measure process impediments in terms of the following steps: P1. Total process steps for provider. To help patients master an app quickly, medical staff can provide detailed instructions, such as helping patients create accounts and bind identities to accounts. However, nurses (who often play the role of an instructor) perform many other tasks during their shift. To reduce the workload of medical staff, therefore, authentication methods should be simplified by minimizing the total process steps required of providers.
P2. Total process steps for patients. When starting to use an mHealth app, patients using mobile devices must be authenticated by following certain steps, such as receiving short messages, typing on device and getting access authorizations. Patients recovering from surgical procedures are usually fatigued, however, which makes it impractical for them to concentrate on complex or long instructions. Thus, mHealth apps should consider reducing as many process steps as possible.
P3. Total error-prone steps. Complexity exists in different steps for both patients and providers, which makes some steps more error-prone than others. For example, mistakes tend to happen in steps related to typing operations. Error-prone steps bring higher barriers for users since more concentration is required of patients and providers to avoid potential mistakes.
P4. Revocation steps at the end of treatment. Revoking each patient's access manually poses a higher requirement from providers (i.e., they must remember every patient's credential status) and is also error-prone (e.g., the wrong patient's access may be revoked). By providing a revocation mechanism during authentication process, patients' access to apps can be auto-revoked at the end of treatment, thereby lightening the process burden for providers.

Other Impediments
Other impediments incur additional demands, such as cost and hardware usage, that are unique to a specific approach. When adopting an authentication method, providers may need to pay for other resources besides basic computing resources, including third-party service fee or hardware fee. For example, the SMS authentication systems require a mobile device have cellular service, as well as a network connection, whereas other approaches do not require cellular service.
For example, a static username/password is vulnerable for services that involve sensitive data, such as financial or banking services. To overcome this problem, smart cards [25] can be used to generate dynamic passwords. Smart cards can create a one-time password (OTP) for bank systems and provide core Public Key Infrastructure (PKI) services [25,26]. However, using extra hardware (such as smart cards) can impede adoption of an authentication method due to implementation costs and the need to carry them in person. We measure other barriers in terms of additional costs for providers and addition requests for patients.

4.
Integrating Alternative Authentication Mechanisms with Legacy Health Systems CPI-linkage and authentication alternatives offer different advantages, such as reduced patient/provider burden. In practice, however, it may not be possible to employ a given approach due to design decisions "hardcoded" into legacy patient data management systems.
For example, many existing systems for capturing medical data are designed with the assumption that trusted medical providers will input the data on behalf of patients. As discussed in Sections 5.1-5.2, however, patient-reported outcomes require direct reporting of data from patients. This difference in design stemming from who is expected to enter data creates an architectural mismatch that must be overcome to realize more effective authentication schemes for mobile devices. To realize the benefits of alternative CPI-linkage and authentication approaches, architectural patterns [27] can be applied to resolve this conflict.
In most existing medical records systems, staff and providers perform the step of CPI-linkage by asking the patient for identifying information, such as their name, date of birth, and phone number, and then looking up the corresponding cyber-identity of the physical person in front of them in the medical records system. After this linkage step is performed, the staff or provider directly enters data about the patient into the system since the patient does not directly enter their data into the medical records system or have an account. For mHealth apps, however, the CPI linkage must be performed to link patient mobile devices to their records and then access must be delegated to the devices so patients can directly enter data about themselves (e.g., patient reported outcomes).
The remainder of this section explores an architectural pattern, called Proxy User Adapter, that can be applied to integrate mHealth apps with QR-codes [28], which are two-dimensional barcodes providing fast readability and compact storage capacity. QR-codes can be used to link patient devices securely with their corresponding records in systems designed for data entry by trusted users. Moreover, this pattern enables direct insertion of data from a patient into the system without changing the existing architecture of these systems from a model based on data entry by trusted users. The Proxy User Adapter pattern enhances the Proxy pattern [29] to provide an authentication proxy in context of legacy hospital systems.

REDCap Integration Case Study
To motivate the challenges of integrating a QR-code authentication scheme into legacy data management systems, we discuss our experience integrating the PainCheck app based on QR-Code authentication with legacy research data management systems for patients at the Vanderbilt University Medical Center (VUMC). We initially considered creating our own stand-alone data management system specifically for mHealth data. However, the complexities of providing high-assurance secure data storage in HIPAA-Complaint environment made starting from scratch impractical. Moreover, training is a major consideration since our goal is to support healthcare providers who have limited time to learn new systems and incorporate them into their research and clinical workflows.
The architecture of the PainCheck app is shown in Figure 2. REDCap is shown in Item A and is respon- Fig. 2: The Structure of a Proxy Server sible for data storage and designing metadata, which defines the basic attributes of a project/questionnaire, such as the number or type of questions. The mHealth app, shown in Item C, is responsible for displaying data collection instruments, such as pain checks, to patients. The proxy user adapter, shown in Item B, is responsible for adapting the mobile device-centric authentication and security model of the mobile app to the trusted user architecture of existing legacy patient data management systems.
Even though healthcare providers can generate a form in REDCap to collect patients' identities, linking identities by filling out a form is not a secure CPIlinkage method, as we discuss in Section 1. Since mistakes can be made when manually entering data for CPI-linkage, these identities may be inaccurate and affect either treatment decisions or the accuracy of collected clinical data. Thus, although REDCap does support form-based entry of patients by data on the web, it is designed primarily for trusted users.
To overcome the issue with trusted users, we introduce a proxy user adapter, which plays the role of connecting patients and providers with the REDCap system, which is a HIPAA-compliant platform shown in Figure 3. REDCap has been widely adopted by de- At VUMC medical records and clinical research data are processed by Epic and REDCap respectively. Clinical data, such as lab results and provider notes, are stored in Epic. Due to legal considerations, storage of patient-reported research data, such as pain and activity levels, are stored separately from Epic in REDCap.
To submit new reports in a REDCap project, trusted users need an API token, which is generated in the REDCap web app and bound to a REDCap account. Project data can be exported and modified by external tools, whose actions are limited by the user account rights associated with the API token. As mentioned Section 3, however, a patient-created account might not match the desired CPI-linkage and authentication model whereby devices are bound to patient records, increasing patient burden (and thus resistance) to use an app. It is hard to implement our QR-Code Authentication schema with these user-centric authentication systems that were not built to integrate mobile devices in their authentication model.
Based on our experiences, we identified the following challenges of integrating QR-code based authentication with these types of systems: • Trusted-user based authorization system.
Since accessing these systems requires tokens generated by authorized accounts in the web browser, patients do not have permission to input data to the system without an account. However, the servers in the QR-code based authentication approach from Section 5.2. need to assign each patient a unique access token for authorization and CPI linkage, which may not be supported.
• Limited ability to customize authentication structure in legacy applications. Researchers often cannot customize the structure of the application authentication architecture, such as RED-Cap's API token authentication or data format. It is therefore necessary to build an integrated design pattern to implement alternative authentication schemes to integrate with legacy applications.

The Proxy User Adapter Pattern
The Proxy User Adapter architectural pattern (shown in Figure 2) consists of middleware that bridges the various CPI-linkage and authentication models of mHealth apps and the underlying trusted-user-focused patient data system, such as REDCap. This pattern employs identity-based tokens to authenticate patients when interacting with mHealth apps. Likewise, the proxy user adapter component holds a credential of one or more trusted users in the target patient data system that it uses to store data on behalf of the mobile devices. By applying this pattern, a facility for adapting the authentication model of the mHealth device to that of the patient data system is enabled by proxy-ing data submissions through one or more trusted user accounts in the patient data storage system.
In our implementation of the PainCheck app on REDCap, the Proxy User Adapter pattern is employed to separate the functionality of secure data storage and patient authentication. This pattern employs an API token, which is authentication key that provides programmatic access to a trusted user's account in RED-Cap, and uses the token to access and operate upon data in REDCap. Each request from a mobile device is proxied through a trusted REDCap user's account that is associated with the API token.
PainCheck's QR-code based authentication (described in Section 5.2. ) is implemented at the proxy user adapter rather than being built into REDCap. This approach enables patients to access mHealth apps on their mobile devices and join research studies by scanning QR-codes with access tokens. The Proxy User Adapter pattern is therefore a conduit for passing requests to REDCap and does not store any patient data that transits through it.
As shown in Figure 2, after creating a data collection instrument (which is a form for collecting patient data) in REDCap's online designer, healthcare providers register their API tokens with the proxy user adapter. This adapter imports the instrument and proxies the submission of data from mobile devices. Authorization interactions between the proxy user adapter and app clients follows the rules covered in Section 5.2.
Trade-offs When Applying the Proxy User Adapter Pattern. The Proxy User Adapter pat-tern decouples mHealth apps from the authentication and CPI-linkage approach of the underlying patient data management system. At the same time, however, this pattern introduces the following security considerations that must be made explicit: • The proxy user adapter requires the intermediate proxy server to hold credentials belonging to a trusted account, which in turn requires credentials be protected properly and only possess the minimum privileges needed to proxy the required requests on behalf of mHealth apps. In particular, where possible, credentials should allow write-only access and no facility to read and extract data.
For patient data systems that support OAuth 2.0, the proxy server can hold an OAuth token that is generated for it and scoped to the appropriate permissions for requests it needs to proxy.
• Since all patient-reported outcomes transit through the proxy user adapter, the proxy server must not store confidential data inadvertently. Developers must ensure that common practices, such as logging of requests, do not accidentally capture and store patient data. Proper application of the proxy server requires a careful security audit to ensure that requests are simply forwarded on to the backing patient data management system.
• Any request buffering or queuinq/retry behavior must be implemented at the mHealth client. Since the proxy server should not capture or store patient data, transient errors due to network issues, patient data management system outages, or other unexpected events must be managed at the mHealth app. While it is tempting to allow the proxy to handle buffering and retry logic on behalf of the mHealth app, this approach introduces security risks in the proxy that are better handled at the client since it should have retry logic to handle connection issues to the proxy server.
Benefits of the Proxy User Adapter Pattern. The Proxy User Adapter pattern provides researchers and clinicians with an efficient way for mHealth apps to adopt the most appropriate authentication mechanism without modifying existing information systems. Legacy systems are usually designed for trusted users to manage medical data and clinical systems that patients are not authorized to access directly. For example, REDCap adopts provider-centric accounts, requiring providers to collect data from patients, rather than offering a patient-centric account. A solution is to add new patient-centric account mechanisms to supply patient-reports apps in REDCap.
In practice, however, integrating existing systems with various mHealth apps by appending a new authentication approach is hard for developers. In partic-ular, developers must fully understand the structure of legacy systems to add new parts carefully without disrupting existing functionality. Moreover, systems developed by third-parties (such as VUMC's use of Epic) may not allow direct modification of the authentication architecture onsite. Adopting the Proxy User Adapter pattern thus provides developers with greater flexibility to customize their authorization server.

Evaluating Authentication Methods
This section describes how we apply QR-Code based authentication to substitute legacy authentication methods (username and password authentication)) according to our discussion in Section 4. Section 5.1 evaluates a common legacy authentication method (username and password authentication), which incurs significant impediments and burden on patients and providers. To overcome potential shortages of legacy authentication systems, Section 5.2 describes how we applied QR-Codes and authentication tokens to improve usability for our PainCheck app developed based on REDCap.

Username/password
Username-password authentication is widely used in legacy healthcare systems. A verification table stores usernames and hashed passwords. Clients are authenticated by providing a username and a password that is checked against the stored table of account credentials. After providing correct information, mHealth apps can then perform operations on the data in that account, such as sending pain information to the server.
When username/password authentication is implemented in the PainCheck app, patients can use any device to input pain data as long as they enter a valid username/password on that device. After verification, the new hashed password will replace the previous one in the table. These credentials will not expire.
With username/password-based systems, credential and identity establishment is relatively independent. The system cannot recognize authorized users if users do not enter their identity/profile manually. To avoid falsified or incorrect identities, additional workflow is required for CPI linkage in this structure. The server needs to pre-validate the identity entered by patients.
Credential transfer to users. Only patients who are actively receiving treatment should submit pain data to the PainCheck app, thereby prev invalid data from arbitrary users. Providers thus need to control account creation and physical identity establishment. To link a new device to a patient's PainCheck account, a provider must create a username/password for the patient and/or coordinate the collection of username/password from the patient to create the account.
Electronic medical record (EMR) systems can also help providers auto-generate a pair of username/temporary password for patients the first time they access an EMR system. Patients need to create their new passwords after entering an application. In either case, a coordination step must occur to collect or distribute a username/password to/from a patient, as shown in steps 1-4 of Figure 4. Table 1 applies the metrics from Section 3. to username/password authentication. The total characters remembered and typed relative to credential length is O(n) since patients must remember their entire username/password to login to a device. The duration that patients need to remember the data is the length of the treatment period, which is also O(N ).
Cyber-physical identify (CPI) linkage of mobile devices. To link a new physical mobile device to a patient's account, the username/password credentials for the patient or for an account that has access to that patient's data must be entered onto that device. Providers must manage this CPI linkage process since patients must be signed up without problems and the linkage must be performed accurately. Table 1 shows the evaluation of metrics P1-3 for this process. Providers must perform a total of four steps: create the credential, link identities, print accounts, and give accounts to the patients. Patients must enter the username/password on their device. Likely errors incurred during the steps include (1) providers incorrectly linking patient accounts to mobile devices (e.g., linking the wrong device and account), (2) providers incorrectly transferring account credentials to patients (e.g., giving the wrong password to the patient), and (3) incorrect usernames/passwords being entered into the device.
Credential entry on physical devices. After obtaining username/password credentials from a provider, patients or caregivers must manually enter the credentials on a mobile device. Initial passwords are normally generated randomly (which may include letters, numbers, or special characters). It will therefore take longer for patients to enter credentials compared to if they choose their own custom passwords.
The overall security of the password is usually much stronger if a random password is generated for the patient since human-produced passwords are prone to dictionary (and other) attacks [30]. Regardless of the approach, the total number of characters that must be typed on the mobile device is proportional to the length of the security credential (i.e., O(N )), as shown in metrics Ph1 in Table 1.

Re-linkage of Devices to Different Patient
Accounts. The shared in-hospital device can be used either by patients or nurses, so switching accounts on

Metrics
Username/password QR+OTP M1 Total characters remembered relative to credential length The duration that patients need to remember the data relative to length of treatment Ph1 Total characters typed relative to credential length Ph2 Total characters typed for credential recovery relative to credential initialization Total process steps for provider 4 1 P2 Total process steps for patient 2 1 P3 Total error-prone steps 4 1 P4 Revocation Steps at the end of treatment 2 0 Binary Metrics O1 Additional costs / Barriers NO NO same device happens regularly. Anyone can access the shared device. Therefore, an administrator account (which can input data for any patient) is not an optimal solution due to the potential invalid data entered by a wrong person. Patients have to re-enter credential pairs every time when they need to switch accounts.
Credential Loss & Recovery . In the event that a patient or caregiver forgets their username/password, a credential recovery process must be followed. For example, a provider may need to reset the patient's credentials using an administrative account or emailing a password reset link to the patient. Regardless of the approach, the patient and/or provider must remember and enter data proportional to the length of the new credential into the system, which requires typing O(N ) characters, as shown in metric Ph2 in Table 1.

Credential Revocation at End of Treatment.
At end of the treatment period, providers can manually delete patients' accounts to revoke their permissions. Nurses need to check the status of patients before they leave hospitals and revoke their credentials in a database, so there are two revocation steps at the end of treatment, as shown in metric P4 in Table 1. If patients come to the same hospital in the future, they will be assigned new accounts.

Integrating Legacy System with QR-Code based Authentication
To overcome the limitations described in Section 3, we designed an alternative authentication approach that combines OTPs with transfer via QR-Codes. With this approach, OTPs are generated for each device, as shown in Figure 5. Rather than sending the OTPs via SMS, however, the OTPs are encoded into a QR-code that can be displayed on a provider-controlled mobile device or printed on a sheet of paper.
A provider takes the QR-code to the patient or caregiver, who can use the camera on their mobile device to scan it and transfer it to the device/app. This approach maintains the advantages of the SMS OTP approach, i.e., automatic transfer of the authentication credential to the app/device. It also eliminates the requirement for a cellular connection and the risk that the OTP is sent to the wrong device accidentally.
Only devices physically near the provider can possibly receive the OTP by scanning the provider's mobile device or printed sheet of paper. Providers should protect patients' QR-Codes carefully, however, to prevent malicious usage from third-parties. For example, cameras with high resolution can scan QR-Codes from distant locations.
Hospitals already have extensive physical security mechanisms in place. Since the transfer of the OTP via QR-code requires the physical presence of potential receivers, the transfer is more secure and aided by existing hospital security procedures. Even if the QRcode is printed on a sheet of paper that is taken outside of the hospital and lost, the OTP cannot be reused after its initial use (e.g., it is a one-time code) and can be time-limited to protect against the loss (e.g., it can become invalid three hours after generation).

Key Processes in QR-Code-based Authentication
Credential Transfer to Patients. To link a device to a patient's account, the provider generates a QRcode with an OTP embedded within it. After scanning the given QR-Code (which can contain up to 7,089 characters for the OTP), the patient's mobile device automatically transfers the OTP to the app. Both the total characters remembered as a function of credential length and the duration that patients will need to remember the data is O(1) since the patient need not remember any credentials at all, as shown in Table 1.
CPI Linkage of Mobile Devices. Table 1 shows the evaluation of metrics P1-3-for this linkage process. Providers must only choose the correct patient to generate the QR code for, as shown in Step 1 of Figure 5. Likewise, patients must only scan the QR-code, as shown in Step 2. The main errors that can occur are selecting the wrong patient to generate a QR-code for or showing the wrong QR-code to the patient.
Credential Entry on Devices. Credential transfer is automated and the total characters typed relative to credential length is O(1), as shown in Metric Ph1.
Credential Loss & Recovery . Credentials are automatically remembered by the mHealth app and credential loss is not possible.

Re-linkage of Devices to Different Patient
Accounts. If QR-based authentication is adopted for an in-hospital device, nurses must switch between accounts by scanning a new QR-code. For patients or caregivers using an in-hospital device, a nurse's help is required to authenticate their account on this device.

Credential Revocation at End of Treatment.
Providers can decide the length of patient credentials in every treatment. No revocation steps are needed at the end of treatment, as shown in metric P4 in Table 1.

Related Work
This section summarizes the differences between our research and related work on mHealth security and usability. Most prior work does not discuss the interplay between mHealth security and patient/provider burden. We explore relevant prior work in each of these areas separately.
We cover related work by presenting (1) an overview of prior work on mHealth authentication approaches, (2) analyzing related metrics for mHealth app usabil-

Authentication in mHealth Apps
In studies of authentication in mHealth, prior work focuses on improving the resistance of an authentication method to attacks from malicious third parties by optimizing authentication protocols and encryption schemes [31,32]. Attacks from the outside, however, are not the only threat that must be handled for mHealth apps. In particular, Kotz et al. have categorized privacy-related threats in mHealth systems [33], which can be posed by not only malicious third parties but also service providers and patients (inside threats). For example, patients themselves could share their credentials with others and expose their private data.
The impact of security on usability [11] is not widely studied by mHealth authentication researchers. Our paper complements existing authentication literature by defining metrics for analyzing burden that authentication processes place on patients and providers and shows how different authentication processes lessen these burden without compromising security. Moreover, our paper provides an architectural pattern (Proxy User Adapter described in Section 4. ) for integrating newer authentication approaches with legacy patient data management systems that lack support for these alternate authentication formats.

Mobile App Usability
Significant prior research addresses ways to improve mobile app usability and overcoming mobile device limitations, such as the small screen sizes and touch-based displays [34,35,36]. To assess mobile app usability, researchers have proposed various evaluation methodologies, such as laboratory experiments and field studies [34,37]. The evaluation methodologies are primar-ily qualitative metrics based on user preference or assessments through A/B testing that assess how differing designs affect a goal metric, such as menu completeness of a mobile wireless information system [37].
A challenge in evaluating mobile app usability is defining standardized objective measurements of usability. To ensure accurate measurement, previous research often combines both objective and subject metrics. For example, the ISO 25062/ISO 9241 and QUIS 7.0 standard questionnaires are used to measure mobile app usability of the Google Maps [38]. An alternative strategy is to analyze usability aspects of mobile apps by modeling approaches [39]. Other researchers have looked at usability issues of username/password authentication on mobile devices by collecting data on users' input time and failure frequency [40].
The evaluation methods presented in Section 3 complement existing usability metrics and provide quantitative measures of cognitive, physical, and process burdens specific to healthcare. These specific burdens are not assessed in a healthcare context in prior work, but are critical to understand and assess the design of mHealth technologies. For example, a design that scores high on usability for patients may place an undue burden on provider workflows and thus be undesirable when analyzed in the overall healthcare context.

Integration Strategies with Legacy Patient Data Management Systems
Hospital information systems are responsible for managing both medical records and research data and are usually built with a focus on input of data from staff or other trusted users, who are typically not patients.
With the rapid development of mobile technologies and demands for data capture outside of the clinical setting, such as increasing number of mHealth apps, it has become a challenge to integrate existing systems with a patient-centric data capture model. Some research has investigated new service architectures and frameworks to integrate edge technology with legacy information systems [41,42].
For example, Li-Fan et al. propose a middleware framework to transit data from legacy information system to a more robust and scalable system in the National Taiwan University Hospital [41] so that heterogeneous information systems can be integrated with existing medical record data. Researchers have also discussed interactive strategies to integrate with healthcare legacy system in different scenarios [43,44,45], such as wireless web-enabled devices, external systems accessing medical records and home health services.
In this paper, the Proxy User Adapter architectural pattern presented in Section 4. complements prior work on integration by providing a standard architectural model to connect legacy medical record systems wiwith alternative authentication and CPIlinkage mechanisms that are better suited for mHealth apps.

Concluding Remarks
This paper discussed usability challenges that arise when integrating new mHealth apps with legacy data storage systems by evaluating a set of mHealth authentication techniques to determine (1) how they impact clinical workflows and (2) what types of impediments they place on patients and providers. We also presented several metrics for quantifying the identified impediments, including the amount of information that patients must remember and the number of steps that are added to a clinical workflow.
The results of our analyses showed that different authentication techniques have steps of roughly the same complexity, though a wide variation exists across authentication approaches in terms of the total number of steps, amount of information that patients must remember, and types of errors. Conversely, the proxy user adapter allows developers to apply new authentication approaches that have higher usability, without modifying legacy system authentication processes.
Based on the research conducted in this paper, we learned the following lessons that are relevant for researchers evaluating how the usability of an mHealth app impacts its frequency of use and adoption: • Username/password authentication approaches are common, but not ideal, for mHealth apps in acute care settings. Barriers in Section 3. explore potential usage problems encountered by patients.
• The QR-code + OTP method described in Section 5 preserves the key usability improvements of conventional authentication techniques, but eliminates the requirement for cellular service and the potential of sending credentials to the wrong person.
Our future work focuses on extending our research to outpatients so that mHealth apps like PainCheck can provide patients with highly-usable authentication methods, even if they do not reside in a hospital setting. We also realize there are other ways to evaluate authentication methods in mHealth apps besides our metrics, which focus largely on usability for patients and providers. We are therefore improving and extending our evaluation methods to provide more adequate and complete metrics. Jules WHITE is an Associate Professor of Computer Science in Vanderbilt University. His research interests include mobile security, mobile augmented reality, cyber-physical systems, deployment and configuration optimization, distributed Systems and cloud Computing Jonathan C. NESBITT has been in the practice of thoracic surgery since 1989. He has broad experience in the management of thoracic diseases including lung cancer, esophageal cancer, minimally invasive surgery, diseases of the mediastinum, airway tumors, airway stents, chest wall tumors and pleural diseases. He has extensive experience in resection of complex thoracic tumors including locally advanced cancers, reoperative surgery and multi-modality therapy. His interests also include minimally invasive approaches in the surgical management of thoracic diseases. His research has focused on the evaluation of multidisciplinary treatment for thoracic malignancies.
Douglas C. SCHMIDT is the Cornelius Vanderbilt Professor of Computer Science, Associate Provost for Research Development and Technologies, Co-Chair of the Data Sciences Institute, and a Senior Researcher at the Institute for Software Integrated Systems, all at Vanderbilt University. Dr. Schmidt's research covers a range of software-related topics, including patterns, optimization techniques, and empirical analyses of frameworks and model-driven engineering tools that facilitate the development of mission-critical middleware for distributed real-time embedded (DRE) systems and mobile cloud computing applications running over wireless/wired networks and embedded system interconnects. He has published 12 books and more than 600 technical papers -many in top conferences and journals. Dr