PAC: Privacy & Security for Mobile Devices

Back to Policy Committee

Introduction

Privacy and Security Mobile Device Good Practices Project Launched ONC’s Office of the Chief Privacy Officer (OCPO), in working with the HHS Office for Civil Rights (OCR), recently launched a Privacy & Security Mobile Device project. The project goal is to develop an effective and practical way to bring awareness and understanding to those in the clinical sector to help them better secure and protect health information while using mobile devices (e.g., laptops, tablets, and smartphones). Building on the existing HHS HIPAA Security Rule - Remote Use Guidance <http://www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule/remoteuse.pdf> , the project is designed to identify privacy and security good practices for mobile devices. Identified good practices and use cases will be communicated in plain, practical, and easy to understand language for health care providers, professionals, and other entities. HHS will be looking for your input. Stay tuned for a public roundtable this Spring. For information about other HHS mHealth activities, please visit the mHealth Initiative website: http://www.hhs.gov/open/initiatives/mhealth/index.html <http://www.hhs.gov/open/initiatives/mhealth/index.html>.

Plan

• Hans/John to create e-mail request to EHR, CIC, Healthcare Devices, CBCC, Security WG, SOA, and Doug Fridsma to get insight into this area.
• Depending on what feedback we receive, narrow or widen feedback from workgroups.

Discussion

• John Moehrke
  • I would request that you include:
    • Security WG – Basic security and privacy
    • CBCC WG – Privacy – Consent Directive CDA template
    • SOA WG -- Services Oriented view used by many mobile devices; also include Access Control and Audit Control services
    • EHR FM WG – Functional Model that includes Security and Privacy functional capabilities
  • My overall my answer is, that mobile devices are not different than any other. Mobile Devices are just more likely to get lost or stolen (for pawn). It is this increased likelihood (of known risks) that needs to be considered. Thus good application design keeps sensitive information off of the device. Since this is a USA domain, it is quite easy to point at NIST who have excellent guidelines on this topic:
    • NIST Guidelines on Cell Phone and PDA Security SP800-124.pdf
    • NIST Guide to Storage Encryption Technologies for End User Devices SP800-111.pdf
    • NIST Recommended Security Controls for Federal Information Systems and Organizations SP800-53-rev3-db
  • The policy, methods, and technology used to protect a mobile device is common place in IT security circles. There is little that HL7 should add except where there is deep specifics to Healthcare and specifically HL7 artifacts.
  • In the HL7 space, we do encourage a Risk Assessment/Management approach to reasonable applying security technology according to risk Impact and Likelyhood. This is the core of our Security Risk Assessment Cookbook, that which is being included in the fabric of HL7 standards development. Beyond this we do have tools in the HL7 family that are not specific to Mobile devices but are just as applicable: EHR Functional Model that includes security and privacy functionality – with efforts to align with ISO-1441 security functional models; Services for Access Control, and Audit Controls; Role-Based Access Control Permissions Catalog; ConfidentialityCode vocabulary; and Composite Consent Directive (CDA).

Discussion

Submitted by John Ritter on behalf of members of the EHR and PHR Work Groups, including: Mark Brueckl, Gora Datta, Gary Dickinson, Doug Dormer, Lenel James, Joe Ketcherside, Kosta Makrodimitris, Theresa McGillvray-Dodd, Jan Oldenburg, and Josh Reicher. (Comments do not necessarily reflect the views of the contributer’s respective organizations.)

• Other Users of Mobile Devices:

In addition to providers and other health care professionals, various levels of care may also be provided by other people – such as family members, neighbors, midwives, hospice services, assisted living services, retirement community services, complementary medicine/therapy services, or meals-on-wheels services. These stakeholders may create and send information to health care professionals, receive and update information from health care professionals, route information to other members of the circle of care, or all of the above. These stakeholders may employ mobile devices to exchange such information.

• Trustworthiness of Mobile Device information sources:

Providers and other health care professionals need to be able to verify and trust the source of information that is rendered on a mobile device.

Possibility of Consumer alteration of professionally-sourced data: Providers and other health care professionals need to be able to determine whether a consumer has altered professionally-sourced data that is rendered on a mobile device.

• Possibility of Other alterations of professionally-sourced data:

Providers and other health care professionals need to be able to determine whether other, non-consumer alterations have been made to professionally-sourced data that is rendered on a mobile device. For example, a computer application may summarize or blend certain information together before sending it to a mobile device; that computer application may have introduced anomalies into the resulting information. Also, data may be rendered differently in one geographic location versus another. For example, a date may be rendered MMDDYYYY in one area, but DDMMYYYY in another.

• Possibility of insufficient/unexpected Governance or Management of professionally-sourced data:

Providers and other health care professionals need to be able to determine whether information quality and/or integrity have suffered due to data governance or data management issues. For example, a professional may establish a rule that delivers an alert to the provider when certain abnormal health conditions appear in a patient, but the mobile device application that governs or manages that alert may behave in an unexpected manner (for example, blocking the alert-message or translating the alert into a device-vibration-request (unaware that the vibration mode has been switched off)).

• Interoperability standardization within health information exchange environments:

Health data may be stored and exchanged across a variety of systems (e.g., patient system, provider, or other source (such as a HIE). Standards-based information exchange (even to the data-element level) is crucial to the successful interchange and utility of data in such an environment.

• Various types of Mobile Devices:

Mobile devices can be categorized according to the range of their capabilities. For example, a “Dumb Mobile Device” would store electronic Protected Health Information on a remote system, not on the device. A “Smart Mobile Device” could collect information that is manually entered by the user; perhaps collect information from nearby electronic devices; perhaps store some of that information on the handheld device; perhaps amalgamate or integrate (e.g., summarize) sets of information; perhaps transmit some data to an external system; perhaps integrate with an external application(s).

• Functionality (or capability) –nuances of various information exchange systems:

The healthcare professional might not be aware of the dynamic adjustments that have been made regarding the “pipeline” or “data-channel” that is used to render information on a mobile device. For example, one medical device may have a finer-grained display than another display, causing the same image to be displayed differently on each mobile device.

• Labeling of mobile devices (and corresponding software) as “regulated” by the FDA:

Healthcare professionals need to be aware of the presence (or absence) of an “FDA-regulated” label on mobile devices. For example, one electronic bathroom scale may be FDA-regulated (for recording the weight of a patient who is under the care of a cardiac surgeon); another bathroom scale may not be regulated (for recording daily weight).

• Amount or Type of Data:

The “amount of data” or the “type of data” could be a factor that prevents providers and other health care delivery professionals from using mobile devices. For example, the information that arrives on a provider’s mobile device might need to be summarized, filtered, staged, translated (for example, into an alert message), or merged with other data before being sent to the mobile device. Sometimes the source-information is sparse; sometimes it is so very plentiful that it is best summarized (or graphed, for example). Since it may be important for the user of the mobile device to be aware of any transformations that were applied to information being rendered on a mobile device, the system should provide the ability to display information that describes any transformations that were made to the data. Consequently, the system should offer a pointer to the “pre-transformation” data.

• Configuration of the parameters that control mobile device information delivery and/or display:

Providers may desire the ability to configure the amount, type, granularity, timing, level-of-urgency, frequency, mode, etc., of data that is shipped to their mobile device.

• Use of Mobile Devices for Clinical Decision Support:

Any mobile device application that is intended to run on a mobile device platform and that is also used to provide Clinical Decision Support services, may be subject to FDA regulations (due to potential patient-safety –related issues).

• Location of Data-At-Rest:

It may be better to store Protected Health Information on a secure portion of a vendor’s system than on a mobile device (whereby the mobile device could render the data via an “on-demand” service). The consumer should be informed that consenting to store such data on the vendor’s system may pose certain risks. Additionally, the consumer should also be informed that consenting to extract data from a secure system and passed through an “app-for-that” service (for display on a mobile device), might increase the risks to that data’s security and privacy.

Certain Protected Health Information might be collected from time to time on a consumer’s mobile device and stored for specified duration before being routed to a secure site. For example, the consumer’s mobile device might collect blood pressure readings once an hour in the patient’s home after cardiac surgery, but only transmit those readings to a secure site at midnight. Note: The data could be at risk on the mobile device until it is sent to the secure site and should likely be purged from the mobile device after being transmitted.

• Management of lost, stolen, or misplaced mobile devices:

When a mobile device is lost, stolen, or misplaced, it would be good if the owner could quickly transmit a “SUSPEND” order to the service provider. Thus, if the device is not recovered by the proper user in a timely fashion, then any data on the device would be automatically sent to an external storage area (perhaps for a small price) and then purged from the device. If the device is recovered by the proper user in a timely fashion, then the SUSPEND order could be lifted by the user (with no prejudicial impact).

• Mobile Device functionality and/or data covered under HIPAA regulations – Or not?

A covered entity often uses an EHR system that employs a set of chain-of-trust functionality regarding electronic Protected Health Information (as specified by HIPAA (Health Insurance Portability and Accountability Act of 1996) regulations) that a mobile device may not employ. Note that the higher the level of chain-of-trust governance, the higher the level of trustworthiness by downstream users. A non-covered entity, such as a patient, may not always prefer to utilize privacy and security measures that are specified by the HIPAA regulations. For example, an 80-year old person who uses a smart phone will likely not employ two-factor authentication if that device is used five times a day in the home to help manage daily medication usage. Thus, there is a need to balance the accessibility of data (“usability”) versus security and privacy of data.

• Consents, Authorizations, and other Governance issues:

Mobile devices ought to be able to locate, interrogate, and respect consents, authorizations, and other governance expectations (with respect to sensitive data or certain functionality). Examples of governance expectations include mobile device –controlled information exchange, synchronization, management, and/or reconciliation among Personal Health Record (PHR) systems, Electronic Health Record (EHR) systems, or other systems. Consider also, that it very well might be that the consumer may desire to declare a consent, authorization, or governance preference differently in one context (namely, PHR, EHR, or other system) than in another context.

• Location Awareness Services:

Mobile device users may benefit from Location Awareness Services that identify and respond to changes in geographic and/or jurisdictional boundaries. For example, when visiting a new city the user may need to locate the nearest dialysis machine or methadone clinic. However, consider that even the request for such information may disclose certain health conditions regarding the user.

• Use of multiple mobile devices:

Which issues should be considered when multiple mobile devices are used by a given user? For example, which issues arise when a physician uses a mobile tablet computer while caring for a certain patient while in the hospital, but then switches to a personal smart phone after leaving the hospital?

• Usage heuristics:

A mobile device could possess functionality that recognizes that the current user is using the mobile device in a manner that is uncharacteristic of the designated owner (possibly revealing theft, fraud, or abuse). For example, a medical device should not be used to request pregnancy services for a male patient, or to request insurance coverage for medicines not prescribed for the owner. (This functionality is similar to that used by credit card services.)

• Difference between “patient-entered” and “patient-sourced” data:

Is there a difference between “patient-entered” and “patient-sourced” data? If so, what impact might these two types of data have on the users of such data (specifically, on providers who view such information on mobile devices)? For example, what does “patient-entered” data mean when the number “165” appears as the patient’s weight for last Tuesday? Did the data come from a reading made by the patient while standing on a bathroom scale – or was it an estimate made by looking in the mirror? Was the scale recently calibrated? Was the scale’s spring cold (yielding a high number)? Was the patient lying (or being overly optimistic about the number), that is, the scale displayed 185 but the patient refused to believe the number? Was the patient wearing heavy boots and a coat? Did the patient transpose the numbers during data-entry, i.e., from “156”? Was the battery low, yielding an inaccurate reading?

Or did the number come from a smart-bathroom-scale-device that electronically transmits the identity of the machine, the date/time, and the patient’s weight to a mobile device (that sends a packet of data to the patient’s computer, whereby the patient eventually forwards that packet to a PHR system). Perhaps the receiver is a smart-phone that contains an “App-For-That” that collects the electronic packet and automatically routes it to the patient’s PHR system.

So the questions are: Who (or what) entered the data? And who (or what) is the source? And, could that data be “bad” for some reason (e.g., misleading, incorrect, or imprecise)?

Furthermore, if a patient’s mobile device receives a lab report from a lab via a “Direct-To-Consumer” lab service – and the patient forwards that document into his PHR, is that data professionally-sourced or is it patient-sourced?

Therefore, though it is important for the professional to know the source of a piece of data being displayed on a mobile device, it may be very difficult to determine the actual source.

• Relationships between PHR, EHR, and Mobile Devices:

Medical Devices collect health information about an individual which may be exported to a Personal Health Record (PHR) system, Electronic Health Record (EHR) system, or another system. Depending on the purpose and capabilities of a given mobile device, the device may be able to share its data with these systems in various formats, ranging from raw (unformatted) data, to coded / mapped values, to fully summarized and formatted reports. Furthermore, the systems may need to collect the data from the mobile device in multiple formats. For example, a patient who has diabetes may use a PHR system to see a summary report from a blood pressure device that states, “Your blood pressure is very high today. Contact your physician immediately.” while an EHR system may require raw blood pressure data values from the past two weeks for the patient’s cardiologist. The same mobile device may generate glucose values that are of interest to the patient’s nutritionist. These values may be combined with values from other mobile devices to create synthesized reports that are richer in content and value than those reports resulting from devices whose information cannot be synthesized. This level of power requires that the PHR system interact with mobile devices in sophisticated ways, including: the ability to configure the mobile device data input according to granularity, type, format, frequency, etc. of data collected; the ability to code or map data; the ability to summarize, filter, or merge data; the ability to route data to pre-designated role-types; the ability to tailor the data according to role-types; the ability to transform the data into alerts or notifications. As the PHR system’s ability to manage mobile device data increases, so does the value of the mobile device data – and of the PHR system itself. Mobile device –related gains made by the PHR system can, and should, be shared with EHR (and other) systems.

• Responses to rules-engine requests:

A mobile device ought to be able to respond to a rules-engine -based request from a Personal Health Record (PHR) system, Electronic Health Record (EHR) system, or other system – so that those systems can tailor their interactions with the mobile device. More specifically, the mobile device ought to be able to negotiate with other systems so that it can integrate its capabilities (or lack of capabilities) with those of other systems. For example, if the patient’s weight has increased more than two percent during the previous week, then the EHR system could recommend that the PHR system request blood pressure reports once an hour from a mobile device, rather than once a day. The mobile device should be able to declare its ability to comply with the updated data-collection expectation.

• Security and privacy obligations vary between providers and consumers:

Consumers must rely upon the providers’ adherence to standards and regulations to insure that proper levels of security and privacy are maintained (with respect to protected health information held by providers). In the case of PHI held by consumers (such as in a Personal Health Record system or on a mobile device), the same security and privacy rules may not apply. Instead the consumer should be able to manage access to the mobile device – and applications on that device that constitutes a compensating control. The objective is to enable the consumer to specify a level of security and privacy that balances ease-of-access to critical information versus protection of private information.