MHWG Security

Mobile Health: Security Subgroup

Members:

• Paul Petronelli
• Ed Hierman
• John Moehrke
• David Gobuty

Frequently Asked Questions and Answers

mHealth Identification

David Gobuty Contribution February 4, 2013

What is identification in the realm of MHealth Devices? Identification enables the device to present controls and displays tailored to the work the user intends to perform with it. It also links the identification to the record of actions performed using the device.

How does identification differ from authentication? Identification begins to form a link between the device and a specific user (or users), while authentication raises likelihood to an acceptable level that the user (or users) are who they claim to be.

Why require an identification step? Identification can enable presentation of role-specific controls and displays. In this way it can manage access to controls and displays for which an identified user is not privileged to use or see. For example, identification as a general user can preclude changes to the audit record, a privilege that would be available only to an administer user (whose identification would be added to the audit record as the one who made the change).

Is identification necessary for a personal MHealth device? Identification can occur concomitantly with authentication providing the number of users is small (one or two individuals), provided the automated identification controls against change to sensitive audit records. Identification can require specific action to gain privilege to use controls and view displays that should be reserved when the single user wants to acting as an administrator. This can prevent inadvertent changes to device settings or audit records.

Does a MHealth device need an identification step if used by more than one person? Yes, because the audit record must contain the identification of the user responsible for the recorded event.

How is identification used in a MHealth device? Identification enables role-based management of controls, displays and privilege available to a specific user.

Can identification and authentication be performed in a single step? In personal MHealth devices, where the user population is small (one or two individuals), the identification and authentication steps can be performed in a single action, provided there are measures in place to control against manipulation of audit records.

mHealth Authentication

David Gobuty contribution, June 14, 2013

What is authentication in the realm of mHealth Devices? Authentication is a process that can raise likelihood to an acceptable level that a claimed identity is true. “Users” of mHealth devices can be an individual or individuals, or another device with authority to interact with it. Authentication attempts to prove that the identity of a user or a device is in fact the user or device it purports to be.

What is the relationship between authentication and authorization? Authentication is distinct from authorization, where the former attempts to prove validity of a claimed identity, while the latter describes the access privileges to which an authenticated identity can be granted. Authentication ensures that the individual or device is who or what it claims to be, so that accurate access rights can be granted and meaningful audit records can be collected, but of and by itself says nothing about the authorizations themselves.

What are common authentication mechanisms? Authentication can be implemented based in the concept (or factor) of something known. It may also be linked to the factor of something had. A password (something known) can authenticate a claimed identity when it is carefully constructed, stored safely, e.g., memorized, and carefully revealed during logon. A token or cypher (something had) can also be used to authenticate a claimed identity when it is safeguarded when not in use and carefully presented or computed during logon.

What is meant by one factor or two factor authentication? One factor authentication or two factor authentication refers to the number of factors employed to prove a claimed identity. Using only a password or a token to authenticate a claimed identity is an example of a one factor authentication system; using both a password and a token is an example of a two factor authentication mechanism. Logically, authentication can be based on employing one or more factors.

Must authentication always be the 2nd step in granting access? No, identifying and authenticating a user or a device before granting access to an mHealth Device can be performed in a single step if the user or device attempting access can be unequivocally associated with the credential presented. For example, when an mHealth device supports access by a limited realm of users, both identification and authentication can be processed as a single step. Typically, when authorized devices attempt access to an mHealth device and present a computable cypher as their authentication token, a separate identification step is not necessary.

What should happen when either the identification or the authentication process does not successfully conclude? Failure of the identification or authentication process should result in the mHealth Device denying access. The user or device should simply be alerted to the fact the credentials presented were in error. The mHealth Device should not specify which credential was faulty.

General Design Issues

Nadine Contribution

1. Can identification be tied to SIM (Subscriber Identity Module) card of the user mobile device? This would enable the user to access Personal health Records from his/her device.

2. What are the safeguards to protect the patient’s data if the device is stolen?

3. What kinds of authentication/authorization could be used in this scenario to verify that the person accessing the information is actually the intended user?

4. Can biometrics be used? 5. Will the data be encrypted during transit? 6. Will the data be encrypted at rest? 7. How do you prevent replication of PHR data onto unsecure platforms or environments?

Business Associate Agreement

jBrandt Contribution

There are new platforms that are entering the discussion such as Samsung SAFE that provide an environment of security. There are also companies such as Box that claim that their systems are HIPAA compliant. We may want to look into what this really means for the security of PHI

Discussion with Nathan I'm not sure I understand your question Jeff. When you say "organizations" do you mean such as eligible providers?

If so, then if patient data passes through the app developers systems in any way, then according to the recent Omnibus they would need to have a BA in place with them. If it is only that the application is being purchased and installed locally then I would think not. In that case, providers would just need to make sure that the general contract for the purchase confirms that it passes all OCR requirements and would need to.

What Box seems to be implying though is that data stored by them for your organization is HIPAA compliant. This is the quote from their literature: "Box supports HIPAA and HITECH compliance following the Department of Health and Human Services’ publication of the Omnibus Final Rule in January of 2013. Box also signs HIPAA Business Associate Agreements (BAAs) with customers."

On Fri, May 24, 2013 at 11:24 AM, J Brandt <jbrandt@comsi.com> wrote: There are a lot of apps on the market that claim security, however there is not way to confirm. Box with sign a BA with the developers; I assume organizations should have BA with the App developers?? Jeff

John Moehrke, John (GE Healthcare) Contribution

I would like to see something even more fundamental. I presented the following at the HL7 meeting in the Security wg free Wednesday tutorial. It speaks of very basic mobile device security and points at NIST 800 documents for details. This helps set the ground work for the later discussion on specifics of user identity, and application identification...

http://healthcaresecprivacy.blogspot.com/2013/05/security-tutorials-on-mhealth-security.html

Data Storage on Mobile Devices

Ed Heierman’s contribution

These are extracted from information that will be available in a soon to be published CLSI Auto11 Document on the Security of IVD Instruments (I’ve contributed to the development of this document). These were initially identified from the perspective of diagnostic instruments and systems, but really apply for most mHealth applications/devices. These could be broken down into more than one FAQ, and additional details could be provided.

What are some guidelines to follow pertaining to the storage of data on mobile devices?

• mHealth data on a mobile device should not be stored or the storage should be treated as temporary and not reliable. • The confidentiality of data transmitted to the mobile devices should be assessed based on the risk assessment of the specific use cases and involved systems. • The mHealth data should be encrypted on the mobile device. • The validity of mHealth data stored on mobile devices should be limited to current user session. • mHealth data stored on mobile devices should be removed when the user session ends. Examples of when a user session ends include:

• Within 1 hour after end of the working shift of the user of this mobile device • Connection to the network is lost for a period of time • Logging off the device • Logging out of the application

Also, HIMSS has a “mHIMSS Mobile Privacy & Security Toolkit” that contains quite a few references on various topics. The Wiki could point to this resource as a general source of information: http://www.mhimss.org/resource/mhimss-mobile-privacy-security-toolkit Our FAQ’s would provide more specific guidance on topics than I found on the HIMSS web page.

List of useful References

Tutorial http://healthcaresecprivacy.blogspot.com/2013/05/security-tutorials-on-mhealth-security.html

Standards

Industry Agreements

HL7 Organization