The Invasion of the Apps: Managing Mobile Devices in ......development of hundreds of thousands of software products distributed over the Internet. This has occurred rapidly – particularly

RMS NRMS NEWSLETTEREWSLETTER AALL LL RR IGHTS IGHTS RRESERVED ESERVED ©© 20201212 PPAGE AGE 1

This publication is not intended to be and should not be used as a substitute for

specific legal or risk management advice. Readers should obtain specific legal or risk management advice in addressing issues discussed in this newsletter.

NNEWSLETTEREWSLETTER Volume Eight - Number Four April 2012

The Invasion of the Apps: Managing Mobile Devices in Healthcare

by Joshua I. Rozovsky, MS

Healthcare organizations are rapidly finding themselves thrust into the world of mobile devices – smartphones and tablet computers. Healthcare may have been one of the earliest adopters of mobile technologies, from one and two-way pagers, to PDAs and the early generation of smartphones. The primary purposes included text-based email on the go, address books, calendars, and very limited web browsing. Smartphones now provide many of the same advanced capabilities as laptop or desktop computers, from email and web browsing, to document management and creation, and video and audio recording and playback. The latest generation of phones and tablets also include features more “at home” in a mobile device – integrated GPS and other location detection systems, accelerometers to determine the physical orientation of the device, touchscreens as a primary user interface. They often include Bluetooth wireless connectivity, one or more cameras, and “always-on” seamless connectivity with cellular networks - including voice and SMS (text) services. The devices are incredibly popular and they are changing the way people read, watch movies, learn, and communicate. In healthcare, providers and patients are bringing these devices into facilities “expecting” them to be supported. Electronic medical records systems and telemetry applications are rolling out support for

POWERED BY ONEBEACON PROFESSIONAL INSURANCE




mobile devices. All of this is putting pressure on facilities to provide mobile device support, for providers and for the public. Healthcare organizations may not be ready to develop and enforce policies and procedures for this “invasion” of different types of mobile devices using different operating systems, apps, network types, levels of security, and ownership. The world of mobile device market is expanding rapidly – and it is a world that hardly existed only a few short years ago. From an IT risk management point of view, mobile devices – smartphones and tablets derived from the smartphone revolution – are computers. They are just as capable in terms of functionality and potential for misuse “traditional” desktop or laptop computers, with two exceptions. They have comparably limited processing capability, and they have to limit their power consumption due to their small battery capacities. What Are Mobile Apps? The increasing capabilities of smartphones and tablets has spawned the development of hundreds of thousands of software products distributed over the Internet. This has occurred rapidly – particularly since the release of Apple’s iPhone in 2007, and Google’s free Android operating system a year later. Some of these software products are built as webpages whose layout is optimized for use on the smaller screen of a smartphone or tablet. Such webpages contain larger buttons for navigation, making them easier for users with a touchscreen. HTML5, the newest version of the primary language of webpages, allows for battery-efficient display of multimedia content such as videos. Users obtain installable apps through special portals, such as the Apple iTunes Store, the Google Android Marketplace, or through repositories maintained by their carriers. Apps are almost exclusively distributed via the Internet through these portals, instead of via CD or other physical media. The definition of the term “app” is likely to change – but today it generally refers to two types of software: • Interactive websites that carry out a function, sometimes referred to as

“software as a service” or “web apps.” They are accessed using a web browser on a desktop, laptop, tablet, or smartphone.





• Software designed specially for mobile devices – often a particular device or device family, such as Blackberry, Nokia, iPhone, iPad, etc. These are “freestanding” programs that the user can launch on their device without having to visit a website using the browser.

While some are now using the term “app” to refer to all software applications, including those run on a desktop or laptop computer, “mobile app” refers to software designed to be run on portable devices having less power and storage capacity. Mobile Device Use in Healthcare. Apps designed for healthcare consumers include webpages and downloadable products that may provide directions to an emergency department, tools to help individuals complete self-screening for depression and other illnesses, rate physicians and facilities, store and file insurance information, look up or get reminder users about medications or interactions, learn new diets or exercises, or learn about conditions, procedures; or more. Healthcare professionals are using web apps and installable mobile apps to access and update patient information, securely converse with colleagues and patients, remotely access and review imagery and telemetry, check drug and clinical references, and provide interactive education and consent processes. Unlike a desktop or laptop computer, smartphones and tablets are easily carried and seem fast. Such devices are almost always “on” and the apps launch almost instantly. Moreover, the interaction is simple and intuitive, using a finger instead of a keyboard and mouse. The Internet is accessible on many of these devices all the time with no need to “dial in” or think about connecting – it is “just there.” The device knows where it is – and can provide directions and maps, and easily allow telephone dialing. Mobile devices are more convenient than other types of computers. Security on many mobile devices can be better in some ways than with desktop or laptops – a missing or stolen device may be remotely tracked or disabled. Using a process sometimes called “sandboxing” steps can be taken to protect the information in other apps or on the device from being stolen or damaged if one app is malicious. Furthermore, many apps store little to no information on the device – all of it is pulled securely from remote servers – potentially limiting the damage due to a stolen or lost device.





The danger for healthcare is that mobile devices nonetheless are computers – and have many of the same vulnerabilities as non-mobile systems – including the ability to provide a distraction at inopportune times. Further, mobile devices are not always perceived, or controlled the same way as other integral components of the healthcare organization’s information infrastructure. While sandboxing, and remote disabling may be performed, how does an organization know such controls have been implemented? Which devices are being used to connect to healthcare organization systems, or untrusted third-party systems? It may be harder to track users on mobile devices than it is with users on desktops and laptops that have “thick” browsers with more robust authentication protocols. Observations on the Mobile Device and App Challenge. Mobile devices and mobile apps present unique challenges for healthcare organizations. In particular there is concern about proper use of these tools in the business and clinical settings and protecting patient and organizational information in the event of device damage, loss or theft. Some healthcare organizations are in the process of commissioning their own custom-designed apps for use by their own personnel, or for use by the public such as patients and members of the community. Custom-built apps may include marketing material, health information, driving directions, appointment and medication reminders, or other features. While custom apps may be helpful, there are many questions that must be considered during planning, including whether the app is “native” or built as a mobile-optimized web app, or using a “framework.” See the Special Application supplement attached to this issue for more information. Other questions to ask during the planning phase include the following:

1. Who is authorized to use mobile devices in the organization? An employee may bring a personally-owned smartphone or tablet into the organization, and seek to access the organization’s network, or want access to PHI via the device. What about a subcontractor bringing their devices into the network? How will users attempting access via such an “unauthorized device” be detected? Can patients use their smartphones to audio or photographically record staff? How will this be detected and enforced?





2. Who is authorized to use certain apps, and on what devices? Should all employees be allowed access to a particular patient-records app? ] What if an app cannot be guaranteed to work properly, or securely on certain devices? How will its use on those devices be controlled? Should certain capabilities or functions be restricted to use on campus, or only from wired workstations instead of a mobile app?

3. When can the device or app be used? A smartphone or tablet in the operating room is both a potential fomite - a surface that can transport a pathogen - and a distraction. How will it be sterilized or banned? How will inappropriate or prohibited uses be handled? Can the device be used off campus or taken home? What controls should be considered with regards to texting and driving with an organization-owned or authorized device? Should the device or apps contain code to disable its use if moving faster than a certain speed? What about a patient using the “driving directions” function in a healthcare-organization app trying to get to the hospital while having a heart attack, rather than calling 911?

4. For what purposes is it allowed? Can employees use the device for personal communications or for communication with other providers’ patients? Can credentialed providers install their own apps to allow access to their practice’s EMR system, separate from that of the healthcare organization? How will prohibited uses, such as violations of PHI, be prevented and access attempts logged? Can users install third-party apps such as games or research tools? An acceptable app – an unencrypted “regular” email program – is no more appropriate for the sending of PHI than unencrypted email sent from a desktop or laptop computer. How will users be educated on what data can be sent using what apps?

5. What apps or functions are users granted? What capabilities does a particular user need? Do all users in the organization need access to the device camera or GPS? Do all users get to see all patient records accessible from a particular app, or are more granular limits imposed? Should users be allowed to install or remove apps from the device, or change system settings? How can users be banned?

6. What differences are acceptable between mobile apps built for different platforms, web apps, and desktop software? How will users be educated on the different appearance and workflows for software built for different devices? Will users be able to change their passwords on the “full” web version, but not on the apps for mobile devices? What feature differences will be acceptable? How will ADA requirements be handled? How will the organization meet the different user interface requirements of the app marketplace or store administrators?





7. How will access to the app, its data, and connected systems be controlled? When will users be required to enter a passcode? To unlock the device, the app, or both? Will users be allowed to use the same passcodes, and how often must they be changed? If data is pulled from or sent to remote servers, how will users and mobile devices authenticate themselves to those servers? How will records on the servers be compartmentalized? How will the organization defend against attacks or breaches appearing to originate from mobile devices? How will the organization stop a breach due to a lost, stolen, or infected mobile device? How will the organization handle a smartphone or tablet “left behind” in a waiting room, exam room, or restroom that could be used for eavesdropping? What education will be provided to prevent users from carrying an unknown device into a secure environment, or connecting it to a “secure” system?

8. What devices and operating systems will be allowed? How will access to legacy versions of the app, or the mobile device operating system be maintained? Will the organization allow the use of “old” versions of operating systems and apps? Will the organization support the use of Android, iOS (Apple), Blackberry, Nokia, or other mobile operating systems? How will limits be enforced? Will the organization allow the use of an imaging app on devices with a lower-resolution screen? How will this control be enforced?

9. What data is stored, and where? Where is sensitive information accessed from the device stored? Is it stored on the device – temporarily or permanently? Is it encrypted? What methods and protocols are used for the encryption? Is the data always stored remotely and only sent to the device when needed? How is the data protected when it is being sent? Where are the servers that store this data remotely? How are passwords and encryption keys protected on the device? How long is data retained on the device and in the remote servers? What metadata is collected? What data could be unintentionally collected, such as GPS location data embedded inside photos? What privacy protections and policies must be developed for unintentional collection of PHI and other sensitive data?

10. Who is responsible if it doesn’t work? In the event of a device or software malfunction, who is responsible for data backup and restoration, device repair or replacement? How will devices that contain PHI be handled with regards to repair or replacement by third parties? If an app is removed from distribution in an app store or marketplace, what is the plan for restoring it? If the app harms a user’s personally-owned device, what is the the organization’s responsibility? What happens if an app is





incompatible with a device following an operating system or device hardware upgrade?

11. How are devices and apps kept up to date? If an app or device operating system must be updated, such as to protect against a vulnerability, how will the organization ensure all the distributed app copies and devices have been patched? How will the organization ensure that the update does not cause unintended consequences, such as loss of access, data corruption, or unacceptable server loads?

12. How will the organization prevent phishing, malware, and piracy? How ill the organization prevent user downloads of a malware-containing apps? What about use of the device web browser to visit sites containing malware, or purporting to be the legitimate web app site for the organization? How will users be educated that “vetting” by an app store or marketplace does not guarantee safety? How will the healthcare organization protect against “fake” mobile websites purporting to be the legitimate one? How will the organization detect devices that have been “jailbroken” – had their security disabled? Will the organization allow such devices? What about devices that are stolen, or contain pirated software or data? How will the organization resolve complaints of “false positive” alarms regarding “compromised” devices?

13. How will the organization test security? How will the organization test to ensure that apps transmitting data back and forth from remote servers are using encryption? How will security be tested quickly when changes to the device operating system, app version, or dependencies occur? Will the organization test devices and apps to determine what information is retained after physical loss or theft? How will remote servers be tested?

14. How will users be assisted who have lost their devices, or credentials such as passwords? How will the organization manage and assist users who forgot their username or password for accessing the device? For accessing the app on the device? For connecting to a web app or remote server? How will fraudulent attempts to obtain user’s credentials be detected and stopped?

15. How will the mobile device and app connect to the Internet and other networks? Should users of mobile devices or apps be allowed to connect over unsecured WiFi “hotspots?” Will users be allowed to use unsecured WiFi? How will the organization manage internal users racking up cellular data charges due to roaming, or exceeding data plan allowances? What about complaints about excess data usage for third party users, or members of the public who have downloaded an organization-developed app?





Risk Management Strategies for Mobile Devices and App Management. With the rise of social media, mobile devices, cloud computing and the drive towards adoption of electronic medical records systems, risk managers can recognize potential legal and practical challenges – and help develop solutions that may not be apparent to those with a purely legal or technical background. The following strategies should be part of the discussions over what controls – contractual, educational, procedural, and technical should be used to manage the challenges described earlier.

1. Protect the Healthcare Organization’s “Perimeter.” Consider segregating mobile devices on their own network segments, and discuss with software and network specialists the deployment of internal firewalls, egress filters, and intrusion detection systems. Strongly enforce the principle of least privilege for users and devices.

2. Consider Centrally Managing Mobile Devices and Apps. Implement device management to give IT personnel the ability to manage many devices remotely - rather than on a one-by-one basis. Device profiles may be used to authenticate devices, and remotely track and disable those lost or stolen. A challenge that remains is managing multiple types of devices (Blackberries, iOS devices, Android, etc). Healthcare organizations may consider limiting the types of devices that will be given access, and then only after the owner submits the device to the organization’s security and management profiles. Alternatively, healthcare organizations may consider issuing a common set of devices.

3. Know Where The Data “Is” and How it is Sent and Received.

Develop a process that allows the healthcare organization to recognize at all times where information is physically and logically stored, who has access to it, and how it is protected. This includes considering what occurs when the information is in transit – such as from a mobile device to the organizational “cloud,” or from the server room to a bank vault on a backup tape. What sort of encryption is employed? What data is stored on every user’s smartphone? How sensitive is it? Classifying and tracking information can be important in determining the scope of a suspected breach, writing privacy policies and contracts, defending against claims of unlawful collection of protected information, or defending violations of data protection laws. Data inventories may also be used during tests to ensure that information is being collected, stored, and protected appropriately.





The inventory should include data that may be obtained by apps inadvertently.

4. Exercise Caution in Adopting Overzealous Controls.

Avoid overzealous controls that can lead to unanticipated outcomes, such as preventing use above certain speeds or during particular hours. Emergency situations may arise during which a user does need to gain access – but is blocked. A device may fail in such a way as to trigger security controls, blocking access at a critical time. Overzealous controls may also lead to user frustration and “work arounds.” Long passwords that must be changed frequently are an example of a “good control” that can lead to frustration and the “work-around” of writing the passwords down – compromising security.

5. Educate End-Users and Other Stakeholders on Handling Unusual

Device and App Behaviors, or Requests from Third Parties. Educate users on acceptable uses for the mobile devices connected to the healthcare organization’s network, and how to report unusual app and device behaviors. Users should be educated that mobile devices are not “safe” from malware and fraudsters. Likewise, attempts by those purporting to just “borrow the phone” or “check the system” need to be explained as very real security threats.

6. Educate End-Users and Other Stakeholders on the Limitations of App Store or Marketplace Listings. Educate users that only those apps audited by the healthcare organization or their designees are endorsed, or allowed for use in the case of providers. Simply being listed in commercial repositories does not guarantee that the third-party app maintains appropriate data security, or that the information obtained from the app is accurate.

7. Maintain an Awareness of Industry Trends and User Behaviors. Recognize that the “mobile app industry” did not exist in its current form only a few years ago. Apps have spawned new startup companies after going “viral” overnight. The ways in which users – including patients and providers – use existing apps and devices, and the features added to new products are always changing. This requires risk managers, legal counsel, and information security personnel to remain abreast of the latest trends and take steps to defend the organization through timely policy updates, procedural changes, user education, and technical controls.





Conclusion. The use of mobile devices in healthcare has the potential to enormously improve the ability of providers to access and update records and clinical references quickly and accurately. Providers using these devices can communicate more effectively with each other and patients. Apps designed for healthcare can be used to improve consent communication with patients, empower patients to better track their health, appointments, and medications, and follow-up with providers more effectively. At the same time, app development is an immature field. Many legal and security challenges are coming to light only as developers push more “apps” onto the marketplace. Apps exist in healthcare that contain “educational” material on procedures that may be inaccurate or misleading. App developers too may inadvertently collect information that is unintended – and then fail to secure it properly. Malware and phishing (fraud) targeting mobile devices is also a growing threat. The use of mobile apps in healthcare requires organizations to consider the ways they may be misused – and proactively implement a combination of technical controls, contractual obligations, policies and procedures, and education for all users – including patients and members of the public who may be using healthcare apps as part of their care.

If you would like assistance with policy and procedure development or education on risk management for emerging technical trends, such as

mobile apps, please contact us at (860) 242-1302.

Special Application: Developing In-House Mobile Apps

RMS NRMS NEWSLETTEREWSLETTER AALL LL RR IGHTS IGHTS RRESERVED ESERVED ©© 20201212



Special Application: Developing In-House Mobile Apps.

Why Develop Your Own App? Apps may be developed internally – such as to provide clinical decision assistance based on a proprietary organizational algorithm. Some healthcare organizations are also developing apps for the public – to provide general health education, keep track of vital signs or emergency information, schedule appointments, or obtain live driving directions to the facility. Considerations for Internal or External Distribution? Apps available via the Internet – in Apple’s iTunes Store, the Android Marketplace, or carrier’s markets and stores are distributed externally. They must meet the requirements of the market or store administrators, and the organization does not have control over who downloads and uses the app. If the app connects to an external server controlled by the healthcare organization, limits can be placed on the app functionality – the only thing an unauthorized user may be able to do is view the “login” screen. Internal distribution means that the app is only available within the confines of the organization. However, this should not be considered a reason to reduce good practices for secure design and implementation. The Differences between Apps: Web, Framework-based, and “Native.” Risk managers and IT personnel should recognize the way apps are constructed “behind the scenes” as this can affect the functionality – and the vulnerability of the app to misuse or attack or error. The distribution and functionality varies also depending on the way the app was built. A healthcare organization developing its own app should work with a qualified outside developer to choose the model carefully. Web apps are those viewed in a web browser, whether on a mobile device or on a laptop or desktop, although the appearance may be optimized (see the main body of the article for further information). Web apps can run on many types of systems, and generally pull all of their data from centrally controlled remote servers. They can also information from the device. Web apps are webpages – they will not be listed in the app marketplaces or app stores. Native apps are distributed via an app store or marketplace and are installed onto the mobile device. They may not require any network connection to run – all the data can be kept on the device. Native apps are often more efficient in terms

Special Application: Developing In-House Mobile Apps

RMS NRMS NEWSLETTEREWSLETTER AALL LL RR IGHTS IGHTS RRESERVED ESERVED ©© 20201212



of battery life, and may be able to take advantage of special features on a particular device. Native apps are designed specifically for a type of smartphone or tablet – they cannot be easily reworked to work on a different kind of device. Framework-based apps are written using more “universal” languages. This allows the code to be “re-packaged” for different kinds of devices. As a result, one set of code (and work) can allow a developer to produce a “native app” for multiple devices. The concern is that these apps may not be as efficient as “true” native apps, and may contain security weaknesses that may be less detectable. However, they can be listed in app stores and marketplaces.

The Invasion of the Apps: Managing Mobile Devices in ......development of hundreds of thousands of software products distributed over the Internet. This has occurred rapidly – particularly

Documents