mopdf.com

app in any way, the choice of which mobile app type to use has drastic effects on timelines, budgets, enrollments, and outcomes. The following descriptions of each mobile app type include keyareas to consider when choosing to use a mobile app in a project.Native apps are typically written using a platform’s “native” programming language, i.e., Swiftfor Apple iOS and Kotlin for Google Android. For native apps, Apple and Google grant the abilityto access all device features and capabilities through their proprietary frameworks, developmenttools, and application program interface (API), written specifically for their respective languages.These benefits are effectively to entice loyalty from developers. Although similar in nature, Swiftand Kotlin are not interchangeable, nor is any of their code currently reusable in other environments (e.g., on a server); therefore, for a mobile app to have an iOS and an Android version, itmust be completely written twice. Many businesses choose to target users on a single platform tostart, adding support for other platforms after gaining some traction. Such a strategy may not beappropriate for research because it would create an additional inclusion/exclusion criterion andpotentially bias the data. For instance, iOS users have an average salary of 53,251 and spend anaverage of about five hours on their mobile devices, while Android users have an average salaryof 37,040 and only spend an average of about four hours on their devices (Slickdeals). Nonetheless, a common denominator for both platforms is the dominance of each platform’s proprietaryapp store. Having written an app using a particular platform’s native programming language, thedeveloper must then submit it into the platform-specific app store for distribution, pending review.This review is an evaluation of the app’s functionality and user experience, and as such it is oneof the most important parts of a native app. Because native apps are written in specific programming languages, using proprietary tools, frameworks, and APIs, the respective app store isessentially the only means by which a native app can exist. Failure to meet the app store requirements can lead to a native app being removed from the app store. The ongoing review process ofevery app consists of multiple review periods. These review periods take time and must beaccounted for in project timelines. A review period typically starts upon submission, regardless ofwhether it is an initial submission or an app update. However, Google and Apple regularly performadditional reviews of each app listing, to ensure that these apps continue to meet their requirements. While the duration of the review period may vary, each review period effectively ends witha pass or a fail. It is not uncommon for an updated app submission to fail multiple times even if ithad passed previously.Research studies incorporating a mobile app can often take advantage of specific research andhealth-focused features a platform may offer, such as Apple’s Healthkit; these features are constantly evolving, and thus a detailed discussion of them is beyond the scope of this chapter.However, there are some additional considerations that must be kept in mind that are relevantacross platforms. Researchers must continue to attend to the maintenance of their mobile app, itsuser experience, and its status on the respective app stores to avoid interruptions in their availability/accessibility. Maintenance of a native app includes publishing updates that account for andhttps://repository.upenn.edu/ace/vol1/iss3/194

incorporate updates and changes to all review guidelines and underlying tools, frameworks, andAPIs. Maintenance of the user experience is not as straightforward. Over the past decade, Applehas continued to enforce stricter guidelines while shortening the average review period to about24 hours (Apple Inc, “App Review - App Store - Apple Developer”; Saying Goodbye to AppReview Times – Dave Verwer’s Blog). The Google Play Store has gradually enforced stricter guidelines while extending the expected review period up to seven days in most cases (Toombs; Publishan App - Play Console Help). These changes are symptomatic of the oversaturation of the mobileapp market. From the first 500 apps launched in 2008, the number of apps available on the AppleApp Store grew to over 2.2 million in 2017, and the Google Play Store peaked at 3.6 million inMarch 2018. Both figures have since declined to 1.96 and 2.46 million, respectively (“Topic:Mobile App Usage”; Liao; Ariel). Google and Apple intentionally seek to curate their app stores,updating their guidelines and requirements regularly. Section 4.2 of Apple’s app developmentguidelines lists the minimum functionality of all apps, including those for research, on the AppleApp Store:Your app should include features, content, and UI [user interface] that elevate it beyond arepackaged website. If your app is not particularly useful, unique, or “app-like,” it doesn’tbelong on the App Store. If your App doesn’t provide some sort of lasting entertainmentvalue, it may not be accepted. Apps that are simply a song or movie should be submittedto the iTunes Store. Apps that are simply a book or game guide should be submitted to theApple Books Store Apps created from a commercialized template or app generationservice will be rejected unless they are submitted directly by the provider of the app’s content. These services should not submit apps on behalf of their clients and should offer toolsthat let their clients create customized, innovative apps that provide unique customerexperiences. (Apple Inc, App Store Review Guidelines - Apple Developer)In short, a mobile app must have a unique, compelling reason to specifically be a native app andnot a web app. An example of such a compelling reason could be the ability to leverage Bluetoothor Near Field Communication to integrate a user’s mobile device with some novel external sensor.Nonetheless, an app’s reason will be reevaluated by Apple and Google as they continue to refinethe requirements of a native app to be listed on their respective app stores. Unfortunately, theirreasoning of which apps have unique, compelling reasons and which do not will remain subject totheir discretion. Furthermore, this requirement disproportionately affects leaner operations such assmall businesses, community organizations, and pilot research projects that do not have the meansor funds to invest months of development into creating and maintaining a high-quality app with aunique and compelling feature set. For example, there already exists an abundance of mHealthrelated native apps that simply administer a survey and/or present medically related informationfor educational and research purposes. Often, these apps are generated by some service or usingsome template. For instance, in November 2018 the Food and Drug Administration developed andreleased template code for creating these simple apps for Android and iOS (“New Real 5

Evidence Digital Tool from FDA, MyStudies App”). The code is provided as is and does not guarantee passing the app store review. All of these apps must still offer a unique, compellinginnovation beyond data presentation and collection to be considered fit for distribution on an appstore. Essentially, an “app could be rejected just because the app store reviewer feels like there arealready enough apps in [that] category” (Love, “How Is Apple Encouraging Progressive WebApps?”). This tightening of criteria for native apps is an acknowledgment of the significant investment required to make a native app and an encouragement for developers to consider web apps formost simple use cases (Apple Inc, App Updates for HTML5 Apps - News - Apple Developer;Firtman, “Google Play Store Now Open for Progressive Web Apps”).Web apps are the result of recent innovations in internet browsers that allow web pages to be highlyinteractive and responsive. Currently, the progressive web app (PWA) is the most common standard for web apps. At its most basic level, any website can become a PWA by adding an appmanifest and including a service worker. An app manifest is a single, “simple JSON [JavaScriptObject Notation] file that tells the browser about your web application and how it should behavewhen ‘installed’ on the user’s mobile device or desktop” (“The Web App Manifest Web Fundamentals Google Developers”). A service worker provides the mobile device with many of thenecessary tools and information to essentially “run” a specific website more like a native app.While compliance with the progressive web app specifications varies across devices, a single progressive web app can currently operate on mobile devices (iOS and Android) and desktopcomputers (Firtman, “iPhone 11, iPadOS and iOS 13 for PWAs and Web Development”). Installation of a progressive web app is done directly from the website, without an app store or an appstore review process. At this time, certain abilities are still experimental and/or not implementedfor all devices, such as access to Bluetooth and push notifications on iOS. Their functionality offline is currently more limited than that of native apps. However, support is steadily growing, andGoogle now allows progressive web apps on the Google Play Store as Trusted Web Activities(Love, “Apple Safari Ships Service Worker & Progressive Web App Support”; Firtman, “GooglePlay Store Now Open for Progressive Web Apps”). A listing on the Google Play Store is particularly helpful because users expect all mobile apps to come from an app store due to the currentminimal market recognition of progressive web apps.Hybrid apps can be described as native app shells for web apps. They are an attempt to bridge thedivide between native apps and web apps. At its most rudimentary implementation, a native appshell opens a browser window that displays the web app from either a website or from a JavaScriptcode that was bundled with the native app code. While hybrid apps generally have more access tothe underlying mobile device than web apps, they are most commonly used as a means to distributea web app via an app store since users have been trained to expect apps from app stores. There aremultiple frameworks and services that will simultaneously generate the native app shell for bothiOS and Android. Both versions would access the same web app. More advanced frameworks,such as React Native, create a bridge from the original JavaScript code to the native user 3/196

(UI) components of the mobile device, essentially rendering to the screen like a native app insteadof like a web page. These advanced frameworks tend to require much more overhead, leading toapps that are much larger in size and take longer to load than a basic native app (Peal, “ReactNative at Airbnb: The Technology”). Moreover, for some use cases, such as supporting complexgestures, the amount of additional bridging code necessary to facilitate communication betweenthe React Native code and the native code can lead to essentially supporting three platforms (ReactNative, React Native to iOS bridging code, and React Native to Android bridging code) instead ofthe single hybrid platform (Peal, “Sunsetting React Native”). The growing complexity of the bridging code led to Airbnb moving from React Native to writing purely native apps in 2018. This isnot to say React Native has no valid use cases. Both Instagram and Facebook use React Native,for example. Often, the average user does not notice the difference between a hybrid app and anative app. At the time of this writing, there are many hybrid apps on both the Apple App Storeand Google Play Store. Nevertheless, hybrid apps must still pass the app store review to be listed.Passing may become increasingly more difficult because Apple wants to remove all hybrid appsthat solely open a browser window to a web app, which they refer to as HTML5 apps, from theApple App Store by March 3, 2020 (Apple Inc, App Updates for HTML5 Apps - News - AppleDeveloper). The remainder of this section will address mobile apps in general and is applicable tonative, web, and hybrid apps.Opportunities for Data Integration with Biometric SensorsResearch studies using or developing biometric sensors benefit greatly from an integration with amobile app. Bluetooth Low Energy (BLE) and Near Field Communication (NFC) are two wirelesstechnologies, readily available in most mobile devices, that help biometric sensors overcome theirlimited computational bandwidth, storage space, and battery life. Using these technologies, a biometric sensor can quickly be “paired” with a mobile device. With an associated mobile app, datafrom the sensor can be streamed to the mobile device, which can store, process, and/or relay thedata to a server for additional storage and processing. This process reduces the amount of localstorage and computational bandwidth needed by a sensor. While a mobile app introduces an additional step in data retrieval from a sensor, the low energy consumption by BLE and NFC incomparison to Wi-Fi and cellular networks is often well worth the investment.Institutional ConsiderationsEvery mobile app should come with a user agreement that includes data use and privacy policies,especially those that handle sensitive information. The specifications within that user agreementcan vary by institution. Each institution will have established software development best practices,in particular for Health Insurance Portability and Accountability Act (HIPAA) compliance. Thesebest practices should be a part of the development process for a mobile app before any /197

ment even begins. Generally, these will include recommendations and requirements for data transmission and data storage, assessments of security policies, delineation of maintenance and auditingresponsibilities, and definition of acceptable use of internal and external resources. Therecommendations and requirements for data transmission and data storage will generally mirrorindustry best practices for data encryption “at-rest” and “in-flight” and for multi-factor authentication. The assessments of security policies will cover how data breaches will be caught, mitigated,and reported. The delineation of maintenance and auditing responsibilities covers who will takeresponsibility of providing updates and bug fixes to the mobile app and its infrastructure (e.g.,back-end servers) and who will track and review audit logs for suspicious activity, both maliciousand bug related. Finally, the definition of acceptable use of internal and external resourcesestablishes the kind of tools, services, and resources that a mobile app can use to mitigate a databreach and/or liability. For example, some institutions do not consider the use of Amazon WebServices servers as complying with HIPAA because of / resulting in the lack of a business associateagreement in place between the institution and Amazon (Office for Civil Rights (OCR)). Thisdetail would be disastrous for a researcher to discover if their mobile app had already been builton Amazon Web Services. In this case, the researcher may need to substantially modify their datacollection to limit it to de-identified data only, which will likely require discussion with the institution and the affiliated institutional review board (IRB).Most academic healthcare institutions are also using an electronic medical record (EMR). Integration of an app with the EMR can substantially leverage the large body of data in the EMR and itsease of access for clinicians and patients. However, most EMRs are tightly controlled and accesscan be challenging and time-consuming. Several initiatives exist to enhance interoperability withthe EMR and other health IT systems, such as the Fast Healthcare Interoperability Resource(FHIR) specifications developed by the Health Level Seven International non-profit organization(SMART on FHIR).While digital health solutions often focus on the patient, it is also important to keep in mind theperspective of the healthcare provider when developing an effective software solution for deployment. Traditionally, healthcare providers have been reluctant to embrace digital health solutionsfor a variety of reasons (Figure 2); these must be addressed as part of the development cycle foran academic entrepreneur to successfully engage with this key stakeholder (see chapters on “Conducting Insightful Market Research” and “Human-Centered Design: Understanding Customers’Needs Through Discovery and vol1/iss3/198

Figure 2. Factors Driving Low Levels of New Technology Implementation by HealthcareProviders and Institutions.Intellectual PropertyDigital health innovations often take a different approach to intellectual property (IP) as comparedto drugs or devices. Software may be copyrighted, but there are often multiple approaches to performing a task, thus limiting the utility of a copyright to influence potential competitors fromdeciding to enter the space. In some cases, design patents can be used, but a competitor can easilyfind alternatives to those as well. In many cases, the startup team’s deep knowledge of the clinicalarea and their ability to rapidly execute remain key ways to mitigate the lack of formal IP protections in digital health.FDA Regulatory OversightThe FDA has provided guidance regarding when digital health, such as mobile apps, may requireFDA certification: “if a software function is intended for use in performing a medical devicefunction (i.e. for diagnosis of disease or other conditions, or the cure, mitigation, treatment, orprevention of disease) it is a medical device, regardless of the platform on which it is run” (Policyfor Device Software Functions and Mobile Medical Applications—Guidance for Industry andFood and Drug Administration Staff). FDA oversight is also required when medical claims aremade in marketing material. The FDA has enforcement discretion, which means that, in somecases, the FDA may decide that review is not required. Broad categories of apps that may requireFDA review are shown in Figure 3.https://repository.upenn.edu/ace/vol1/iss3/199

Figure 3. Mobile Apps That May Require FDA Review.Traditional FDA certification pathways commonly used for mobile apps or digital health solutionsrequire each product to be independently certified, such as through the 510(k) premarket notification pathway. In addition to the FDA template code for simple apps mentioned earlier, the FDAhas introduced a new model (Pre-Cert) where the software company’s development process iscertified and will allow the company to create software devices without each new one undergoingits own FDA clearance/approval process. As described by FDA Commissioner Dr. Scott Gottlieb,it is intended for “certain novel types of low- to moderate-risk devices to obtain marketing authorization” (“FDA Looks to De Novo Pathway Model as It Unveils Updates to Pre-Cert Program”).For Pre-Cert, a software development company must undergo an excellence appraisal by the FDAfirst. This process includes evaluating quality system regulations (QRS) to demonstrate designcontrol and validation. Dr. Gottlieb further clarified that the FDA “evaluat[es] the quality andexcellence of the software developer for Pre-Cert. By collecting this information early, the Excellence Appraisal could be leveraged to streamline a developer’s De Novo submission, reducingcontent the developer would need to submit to the agency under the De Novo pathway since theinformation would already have been demonstrated and documented during the ExcellenceAppraisal” (“FDA Looks to De Novo Pathway Model as It Unveils Updates to Pre-Cert Program”).Once a software development company has completed Pre-Cert, acceptable studies for SaMD approval are typically randomized trials. For example, Pear’s reset-O software was approved 10

on the results of a single unblinded randomized trial of 170 participants, which also rigorouslymonitored safety (adverse events) as well as efficacy (“FDA Clears First Prescription Digital Therapeutic for Opioid Use Disorder”). Additional guidance can be found in the “SoftwarePrecertification Program: Regulatory Framework for Conducting the Pilot Program within CurrentAuthorities” document available at loping a mobile app is similar to building a house. The cost will vary mainly by the level ofcustomization, but any number of other factors might further shift the cost. If the desired featureset is simple enough, perhaps a cookie-cutter solution through an app generator might be best.However, as the feature set grows and becomes more original, the cost, timeline, and complexitywill grow exponentially. This is because each feature will have to integrate to some degree withevery other feature. Furthermore, features do not necessarily have to be additional components tothe mobile app, but may also be on the back-end database or elsewhere; choices on the implementation of the back-end will affect more than just the cost, and thus merit additional discussion.The back-end is the central database that stores all user data. There are multiple approaches forimplementing a back-end, and not every approach fits all situations. To start, a back-end must havea location; either it is physically hosted in house/on premise or in the cloud. An on-premise backend requires purchasing equipment, having a location to store and safeguard that equipment, andsupporting the ongoing maintenance of the equipment. The physical proximity of the back-end tousers will have a noticeable effect on data loading times. Meanwhile, cloud solutions have a varietyof flavors, including Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and serverless. Infrastructure as a Service is the most comparable to in-house because it is effectively thecontracting of a third party to host and manage all of the equipment that would be required for anin-house solution. A financial cost comparison of an in-house back-end versus one hosted with anInfrastr

2. Software that is integral to the functioning of a physical medical device: Software in a Medical Device (SiMD). 3. Software used in the manufacture or continued maintenance of a physical medical device. This chapter will be focusing on the first category, Software as a Medical Device. While Software as a Medical Device covers a broad range .