2.4.4 Risk Factors
For apps, especially those like Use Case C, there are several potential threats and vulnerabilities which should be assessed and mitigated, where necessary, by mHealth developers (see 3.2.2 Product Risk Assessment and Mitigation). While cMHAFF does not attempt to “do” the risk assessment for any particular mobile app, the following are examples of specific risk scenarios that may be applicable and point to cMHAFF criteria (-> potential mitigations are listed in parentheses). Some of these potential risks are motivators for the conformance criteria in cMHAFF. Where risks have both high likelihood and high impact, SHALL criteria are indicated.
|
RISK FACTOR
|
CONFORMANCE SECTION
|
|
Consumer loses their device. Confidential information is handled by the app, and there is risk of information disclosure (-> encryption of data, automatic timeout/logoff)
|
Section 3.5.1
|
|
The device can be lost or damaged, impeding the consumer’s use of the app, thereby impacting their care, even if privacy is protected. (-> information about backup of data, ability to restore to new device)
|
Section 3.3.1
|
|
The consumer, for convenience, may turn on “automatic login” (saved credentials, “remember me”), so the app may be accessed without re-authentication. (-> don’t offer such a feature if app handles PHI)
|
Section 3.4.1
|
|
The app is used and left open, where others could see it while the device is unlocked (-> automatic timeout/logoff)
|
Section 3.4.1
|
|
Measurements are not captured accurately or not transmitted accurately, and consumer takes action based on inaccurate measurements (-> quality management, disclosure of evidence)
|
Section 3.2.2
|
|
A data collection device paired with the mobile phone may in fact be for a different person (mis-association of data) (-> Pairing User Accounts)
|
Section 3.4.1
|
|
A third-party cloud-based platform may have inadequate security measures of which the consumer is unaware. (-> disclosure of infrastructure security measures)
Transmission between mobile app and cloud-based platform may have inadequate or unknown transmission security (-> encryption of data in transit)
|
Section 3.4.4
|
|
The consumer exchanges or discontinues their use of the mobile device without removing all data from the device or other locations to which the device transmitted data. (-> App and Data Removal, Permitted Uses of Data Post Account Closure)
|
Section 3.5.1
|
|
The healthcare provider to which the app communicates data has little or no control over the device characteristics, environment, or usage patterns, unlike enterprise IT where only approved/provisioned devices are used. (-> out of scope, not a developer issue, but should be documented in product risk assessment)
|
Section 3.2.2
|
2.4.5 Summary of Major Differences in Use Case Scenarios
|
|
Simple |
Device Integrated |
EHR Integrated
|
|
Medical Device App Categorization
|
Wellness |
Wellness or Medical |
Medical
|
|
Data Device Categorization
|
None |
Unregulated or Regulated Device |
Regulated Device
|
|
PHI Data Storage
|
Smartphone |
Smartphone/PHR |
Cloud/EHR
|
|
Data transmission by App
|
None |
Device-App-PHR |
Device-App-Cloud-EHR
|
|
Importance of Data Integrity
|
Low |
Mid |
High
|
|
(USA) HIPAA covered?
|
No |
No, but Yes, if white-labeled |
Yes
|
2.5 Environmental Scan
The documents mentioned below are not standards, but explain the state of the mobile health industry in the USA and Europe, and assist developers to understand which legislation is applicable to their apps.