Health care organizations provide high-quality health care for their patients and strive for continuous improvement by incorporating cutting-edge technologies and innovations, such as mobile health (mHealth). The term mHealth has been adapted to identify the use of mobile phones and other wireless technologies to assist with medical/health care. By downloading special applications onto mobile phones/devices, users can manage their own health maintenance concerns/goals or, in the case of clinicians, they can use them for the enhancement of the services provided for patient monitoring, treatment, medical research, etc. As with any other IT or medical device, there are always security, privacy, and system function issues that need to be addressed or mitigated in order to minimize patient safety and privacy risks. For example, an IT attack against the mobile device can have serious patient safety issues or pose negative impacts to the network. Hence, it is important to develop a comprehensive mHealth program based on guidelines from industry experts and government organizations, including the FDA and the National Institute of Standards and Technology (NIST).

Here, we will highlight recommendations from the aforementioned as a start-up tool that can assist biomedical/clinical engineers in helping their health care organization develop their own comprehensive mHealth risk-reduction program.

Best Practices

Michael Lustig, CEO of Movero Inc,1 Atlanta, states in his January 19, 2012 article, “The Potentially Harmful Side Effects of Mismanaged Mobile Health,”2 that mHealth can be viewed as a means to improving patient care and lowering costs, or as the potential for compromised security and patient privacy. He proceeds to express that it is feasible to find the balance between ensuring the security of mobile devices while simultaneously meeting the needs of clinicians. He provides the following best practices to assist organizations in meeting HIPAA requirements and to prevent unauthorized access to sensitive data:

1) Identify all mobile devices and maintain inventory management utilizing mobile device management (MDM) software, ensuring that no unauthorized devices obtain connection to the network and that all devices can be fully tracked.




2) Add on-device password and over-the-air data encryption to enforce authentication when the device is cycled-on and ensure that data exchange is fully protected.

3) Enable remote device kill and data deletion, allowing administrators to clear all data and settings on lost or stolen devices.

4) Separate personal and health care organization information, enabling IT to secure, control, and erase enterprise data and applications without adversely impacting personal photos, music, apps, or e-mail.

5) Provide updated and automatic antivirus, firewall protection, and remote delivery of security patch updates.

6) Establish either a “bring your own device” (BYOD) or health care industry-owned device policy for consistency across the organization. Include guidelines and education regarding potential missteps, keeping mobile devices in compliance, and limiting introduction of malware through spam and unauthorized apps.

7) Allow IT to control exactly what data users can access with their mobile devices, including back-office systems, formalized user groups, and blocked access to devices that do not have a MDM installed.

It is important to note that some of the applications available as mHealth may convert the mobile devices into medical devices, which require meticulous IT security and proper functioning in order to minimize the risks to patient safety. As per the FDA Draft Guidance—Mobile Medical Applications, from July 21, 2011,3 software applications (apps) for mobile platforms, such as smartphones, tablet computers, and personal digital assistants, are being developed and deployed for various purposes. The document focuses on those that are intended to assist users to manage their own health and wellness and those that health care providers use as tools to deliver patient care. These mobile medical applications (mMApps), like any other medical device, can pose potential risks to the public health, which has led the FDA to consider guidelines and oversight to minimize the risks.

FDA Definitions

The FDA’s draft guidance defines a small subset of mMApps that impact or may impact the performance or functionality of currently regulated medical devices. This subset includes mMApps that:

  • Are used as an accessory to a medical device already regulated by the FDA. For example, an application that allows a health care professional to make a specific diagnosis by viewing a medical image from a picture archiving and communication system (PACS) on a smartphone or a mobile tablet.
  • Transform a mobile communications device into a regulated medical device by using attachments, sensors, or other devices. For example, an application that turns a smartphone into an ECG machine to detect abnormal heart rhythms or determine if a patient is experiencing a heart attack.3

As described in this guidance, the FDA plans to apply its regulatory oversight only to certain types of mobile apps. It reads as follows: “This narrowly-tailored approach focuses on a subset of mobile apps that either have traditionally been considered medical devices or affect the performance or functionality of a currently regulated medical device. The FDA believes that this subset of mobile apps poses the same or similar potential risk to the public health as currently regulated devices if they fail to function as intended. Using mobile or other innovative platforms along with a mobile medical app to perform medical device functions does not necessarily change the intended use or the risk to patients if the device fails to operate properly.

“For the subset of mobile medical apps that are subject to regulatory oversight, manufacturers must meet the requirements associated with the applicable device classification. If the mobile medical app, on its own, falls within a medical device classification, its manufacturer is subject to the requirements associated with that classification. A mobile medical app, like other devices, may be classified as Class I (general controls), Class II (special controls in addition to general controls), or Class III (premarket approval).”

Table A (below right) shows mHealth applications that may fall under the FDA’s oversight, while Table B (below right) shows those that do not. Table C (below right) provides the FDA categories and examples of mMApps and the classifications into which they fall.

NIST Guidelines

In addition to the FDA’s guidelines and Michael Lustig’s best practices, the NIST also offers guidelines on MDM with the introduction of a comprehensive initiative, “Guidelines for Managing and Securing Mobile Devices in The Enterprise (Draft),” aimed at supporting the multiple security objectives required to protect the confidentiality, integrity, and availability of the associated data. The first draft version4 provides guidelines to assist organizations in centrally managing and securing the mobile devices against the various threats. It provides recommendations for the selection, implementation, and usage of centralized management technologies.

Besides the MDM recommendations, the NIST document also includes the security concerns associated with the use of mobile devices and the means to securing both organization-provided and personally owned—BYOD—mobile devices.

NIST recommends the use of threat modeling—defined as involving the identification of resources and their associated vulnerabilities, security controls, and quantifying the likelihood and impacts of successful attacks—to assist an organization in identifying security requirements needed for compliance.

Below is an abbreviated version of the NIST document that lists the major security concerns of mobile devices and mitigation strategies:

  • Lack of Physical Security Controls

a) The mitigation strategy for this is layered. One layer involves protecting sensitive data—either encrypting the mobile device’s storage so that sensitive data cannot be recovered from it by unauthorized parties, or not storing sensitive data on mobile devices. Even if a mobile device is always in the possession of its owner, there are other physical security risks, such as an attacker looking over a teleworker’s shoulder at a coffee shop and viewing sensitive data, such as a password, on the mobile device’s screen.

b) A second mitigation layer involves requiring authentication before gaining access to the mobile device or the organization’s resources accessible through the device. More robust forms of authentication, such as domain authentication, can be used instead of/or in addition to the built-in device authentication capabilities.

  • The Use of Untrusted Mobile Devices, such as BYOD

a) Consider all mobile devices as untrusted unless locked down by the organization.

b) Consider prohibiting BYOD.

c) Fully secure all mobile devices before issuing and implement continuous monitoring.

d) Run the organization’s software in a secure, isolated sandbox on the phone.

e) Use device integrity scanning applications.

  • The Use of Untrusted Networks

a) Plan security under the assumption that all networks between mobile devices and the organization cannot be trusted.

b) Reduce risks with strong encryption technologies and mutual authentication mechanisms.

  • The Use of Applications Created by Unknown Parties

a) Assume all downloadable apps should not be trusted.

b) Reduce risks by prohibiting download of apps.

c) Reduce risks by implementing a secure sandbox that isolates the organization’s data and applications from all other data and applications on the mobile device for all browser-based access related to the organization.

d) Reduce risks by leaving the mobile device’s built-in browser for other uses.

  • The Interaction with Other Systems

a) Reduce risks by using technologies/policies that restrict the synching of organization’s mobile device with BYOD.

b) Reduce risks by using technologies/policies that restrict the synching of BYOD with organization-owned computers.

c) Reduce risks by preventing the use of remote backup services by blocking use of those services (eg, not allowing the domain services to be contacted) or by configuring the mobile devices not to use such services.

  • The Use of Untrusted Content

a) Reduce risks by providing personnel training.

b) Reduce risks by restricting peripheral use on mobile devices, such as disabling camera use in order to prevent QR codes from being processed.

  • The Use of Location Services

a) Mobile devices with GPS capabilities typically run what are known as location services. Reduce risks by disabling location services/GPS.

b) Reduce risks by prohibiting the use of location services for particular applications such as social networking or photo applications.

c) In addition to location services and GPS, it is increasingly common for Web sites and applications to determine a person’s location based on their Internet connection, so the primary mitigation for this is to opt out of location services whenever possible.

Evaluating Security Services

The NIST draft also covers security services commonly provided for mobile devices, which are relevant for both centrally managed and individually managed mobile devices. Organizations deploying mobile devices should consider the merits of each security service, determine which services are appropriate for their environment, and then design and acquire a solution—or solutions—that provide the necessary services, which could include the following, as specified in the NIST draft:

1) General policy: The centralized technology can enforce enterprise security policies on the mobile device. General policy restrictions of particular interest for mobile device security include the following:

  • Restrict user and application access to hardware, such as the digital camera, GPS, Bluetooth interface, USB interface, and removable storage.
  • Restrict user and application access to the built-in Web browser, e-mail client, application installation services, etc.
  • Manage wireless network interfaces (Wi-Fi, Bluetooth, etc).
  • Automatically monitor, detect, and report when policy violations occur.

2) Data Communication and Storage

  • Strongly encrypt data communications between the mobile device and the organization. This is most often in the form of a virtual private network (VPN), although it can be established through other uses of encryption.
  • Strongly encrypt stored data on both built-in storage and removable media storage. Removable media can also be “bound” to particular devices such that encrypted information can only be decrypted when the removable media is attached to the device, thereby mitigating the risk of offline attacks on the media.
  • Remotely wipe the device (to scrub its stored data) if it is suspected that the device has been lost, stolen, or otherwise fallen into untrusted hands and is at risk of having its data recovered by an untrusted party. A device often can also be configured to wipe itself after a certain number of incorrect authentication attempts.

3) User and Device Authentication

  • Require a password/pass code and/or other authentication (eg, domain authentication) before accessing the organization’s resources. This includes basic parameters for password strength and a limit on the number of retries permitted without negative consequences (eg, locking out the account or wiping the device).
  • If device account lockout is enabled or the device password/pass code is forgotten, an administrator can reset this remotely to restore access to the device.
  • Have the device automatically lock itself after it is idle for a period.
  • Remotely lock the device, if it is suspected that the device has been left in an unlocked state in an unsecured location.

4) Applications

  • Restrict which applications may be installed through whitelisting (preferable) or blacklisting.
  • Install, update, and remove applications.
  • Restrict the use of synchronization services (eg, local device synchronization, remote synchronization services, and Web sites).
  • Digitally sign applications to ensure that only applications from trusted entities are installed on the device and that code has not been modified.
  • Distribute the organization’s applications from a dedicated mobile application store.
  • Limit or prevent access to the enterprise based on the mobile device’s operating system version (including whether the device has been rooted/jailbroken) or its mobile device management software client version (if applicable). Note that this information may be spoofable.

Mobile devices as well as mHealth devices definitely may provide positive benefits for the health care organization. However, the benefits may be directly proportional to the incurred risks unless a comprehensive mobile management plan is implemented. When specifically talking about mHealth applications, biomeds and their facilities must ensure that all security and FDA requirements are met in order to minimize risks to the sensitive data and, most importantly, to their patients’ safety.

This article’s recommendations can help provide health care technology management professionals—both managers and teams—with controls that can be used to enhance the security of mHealth devices so that the services provided to the patients continue to be of the highest quality.


German G. (John) Baron, CBET, BSBME, CSP, has more than 30 years of experience in the biomedical arena, including military medical specialties and clinical experience, and 10 years in the IT security arena. For more information, contact .

References
  1. Movero Inc, Atlanta, a global provider of technology services that helps enterprises effectively manage fixed and mobile communications expenses and other business processes. Available at: www.moveroinc.com. Accessed August 16, 2012
  2. Lustig M. The potentially harmful side effects of mismanaged mobile health. CMS Wire, January 19, 2012. Available at: www.cmswire.com/cms/information-management/the-potentially-harmful-side-effects-of-mismanaged-mobile-health-014168.php?goback=%2Egde_98243_member_135980145. Accessed August 16, 2012.
  3. Draft Guidance for Industry and Food and Drug Administration Staff—Mobile Medical Applications. Available at: www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm263280.htm. Accessed August 16, 2012.
  4. NIST Special Publication 800-124, Revision 1 (Draft). Guidelines for Managing and Securing Mobile Devices in the Enterprise (Draft). Available at: csrc.nist.gov/publications/drafts/800-124r1/draft_sp800-124-rev1.pdf. Accessed August 15, 2012.
Other Helpful Articles: