Consumer Mobile Health Application Functional Framework, Release 2
2.0.1 - CI build International flag

Consumer Mobile Health Application Functional Framework, Release 2, published by HL7 International / Mobile Health. This guide is not an authorized publication; it is the continuous build for version 2.0.1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/cmhaff-ig/ and changes regularly. See the Directory of published versions

Requirements: PDS.2 Product Risk Assessment and Mitigation (Header)

Page standards status: Informative
Statement N:

This category deals with process steps for risk assessment and mitigation for those who are developing a new app, or an upgrade to an app, prior to its being deployed to Consumers.

 Description I:

Degrees of risk should be assessed and mitigated according to the intended use of the app. In general, risk management should manage security, privacy, safety, and other types of risks such as potential app failure scenarios, events that could lead to undesirable outcomes, probability and severity of risk, and mitigations or resolutions. One size does not fit all. For example, if apps handle sensitive personal information or give health interpretation or advice, higher degrees of risk are involved than for apps that do not collect personal information or do not interpret or advise. If some information identified during this step should be disclosed to consumers, that is stated in the “Informing Consumers/Users” section

 Criteria N:
PDS.2#01 SHALL

The App SHALL conform to a product risk assessment and mitigation plan as outlined by the developer. This plan should explicitly determine what risk must be addressed through software coding, hardware adaptions, policy, and what residual risk will be accepted by the entity responsible for the app. The developer will need to maintain, review, and update organizational Risk Register to include risks associated with mobile application.
PDS.2#02 SHALL

In development of the App, the developer SHALL follow secure coding and practices using an established risk assessment framework.
PDS.2#03 conditional SHALL

IF personally Identifiable Information is collected THEN in development the App SHALL be guided by risk assessment findings in terms of their potential effect on adequately securing an individual's personally identifiable information (PII) including any protected health information (PHI), and also information used to access an EHR/PHR (e.g., logon credentials).
PDS.2#04 conditional SHALL

IF the App transmits data to an EHR THEN the App SHALL document failure rates, measurement error rates, software bugs, and hardware risks of all types.
PDS.2#05 SHOULD

Prior to product launch, the App SHOULD be approved in accordance with User Acceptance Testing (UAT) by testers who are not part of the formal development team.
PDS.2#06 SHOULD

The App SHOULD be monitored and include documentation of conflicts or compatibility issues of the app with other apps, device features (e.g., camera), or connected devices.
PDS.2#07 conditional SHOULD

IF the App relies on external supporting infrastructure, (e.g., cloud-based servers) to operate, THEN the App SHOULD document measures to ensure the availability of that infrastructure.
PDS.2#08 MAY

The App MAY provide documentation to show that the app publisher has adequate resources to continue to develop, maintain, and support the product (e.g., human resources, finances, IP rights, facilities, equipment, tools).

Notes:

While mobile computing environments may introduce some specific threats not present in non-mobilecomputing, the principles of risk management are the same across environments, so some standards and regulations are cited, even though they are not mobile-centric. Documents (listed alphabetically below) were sources of some cMHAFF criteria for risk assessment. Other useful references on risk assessment are listed in the Appendix. While some are realm-specific, they have much material that is applicable beyond their countries. Realms are listed in parentheses, if not explicit in the title.

Implementation Guidance

While later sections in this standard include specific security and privacy controls to be applied to consumer mobile health apps, all products addressing health issues, regardless of their type, must be subjected to an overall risk analysis. This risk analysis may uncover the need for additional security controls over-and-above the conformance statements included in this document. As such, a risk analysis provides an additional layer of considerations such that conformance statements are not misused as a simple checklist in which it is assumed all security risks have been addressed if an app is in compliance with the conformance statements in this standard. For an app/product, the risk analysis should be conducted for the target environment(s) where the app will actually be used by consumers. Because of the diversity of consumers, such a risk analysis is wider ranging and more challenging than a risk analysis for the development organization’s own environment.