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

Appendices & Reference Documentation

CMHAFF Pilots

Three pilots were conducted in relation to the CMHAFF STU:

• Children’s Hospital of Philadelphia
• Health App Analyzer– HRSA HITEQ
• CEN/ISO Health & Wellness Apps

Pilot Documentation: https://confluence.hl7.org/display/MH/cMHAFF+Pilot+Implementations

Reference Documents

Document	Relevance to CMHAFF
ONC API Task Force Final Report	General, Authentication, Authorization
ONC Model Privacy Notice (updated December, 2016)	Authorization for Data Collection and Use
Open Web Application Security Project (OWASP) Top 10 Mobile Security Risks	Risk Assessment and Mitigation, Authentication, Authorization, Security for Data at Rest, Security for Data in Transit
U.S. Department of Health and Human Services, Usability Guidelines, U.S. Dept. of Health and Human Services. The Research-Based Web Design & Usability Guidelines, Enlarged/Expanded edition. Washington: U.S. Government Printing Office, 2006.	Usability
US Department of Health and Human Services (HHS) Summary of the HIPAA PrivacyRule which includes a definition of PHI (also known as “individually identifiable health information”) for the US realm.	Launch App and Establish User Account
U.S. Federal Trade Commission, Children’s Online Privacy Protection Rule (COPPA) for the US realm. National Institute of Standards and Technology, Electronic Authentication Guideline, NIST 800-63-2.	Launch App and Establish User Account
U.S. Food and Drug Administration. Applying Human Factors and Usability Engineering to Medical Devices. February, 2016.	Usability
U.S. Food and Drug Administration: Device Software Functions Including Mobile Medical Applications. FDA Policy for Device Software Functions and Mobile Medical Applications, updated 9/26/2019	Regulatory Considerations
U.S. Food and Drug Administration (FDA) – FDASIA Health IT Report.	Risk Assessment andMitigation
U.S. Food and Drug Administration: Cybersecurity	Risk Assessment and Mitigation
U.S. Food and Drug Administration (FDA) Digital Health Innovation Action Plan Indicates where FDA will and will not focus its regulations of mobile health apps.	Regulatory Considerations
W3C User Agent Accessibility Guidelines (UAAG) Overview W3C Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile	Usability
W3C Mobile Usability	Usability

Label

It is possible that cMHAFF can assist both consumers (purchasers, users) of MH apps, as well as assessment organizations, through a “Label” that summarizes the major facts about the product. Well known examples (shown below) include Nutrition Facts labels and OTC Drug Facts labels required by governmental agencies. For cMHAFF, each “topic” (the sections of conformance criteria) would be represented by an entry, for example a table. We envision an easy-to-understand combination of graphical symbols and colors (red = bad/fail, yellow = middle/partial, green = good/present, gray = not applicable). The label’s information would be provided by a combination of self-attestation (by the app provider) verified by a third party (e.g., assessment or certification body), and possibly supplemented bythird party testing (e.g., technical requirements for interoperability, security, etc.).

To be understandable, the Label should present cMHAFF categories in consumer-friendly language, notthe developer-centric terms used for the cMHAFF categories.

!! Label IMAGE !!

Proposed cMHAFF Information Label for an App

The “Ind” column is an indicator (score) for the category, summarized by a color and a graphical symbol (green/up arrow = pass, red/down arrow=fail, yellow/side arrow=middle/partial). For “not applicable, cells are shaded gray and … is proposed as a graphical symbol.

SIMPLIFIED cMHAFF LABEL (LUMPING OF CATEGORIES)

App Name:		Publisher:
Category	Ind	Other Contents (examples)
1. Product Information	■	Missing information on authors of app and evidence for app claims
2. Starting an Account	■
3. Security and Trust	■
4. Exchanging or Sharing Data	...	App does not share data
5. Ongoing Support and Updates	■
6. Notifications and Alerts	■
7. Ending Use of the App	■	Does not ask user about keeping or deleting data.
8. Product Development Process	■	"Follows all applicable laws recommended by FTC Mobile Health Tool"

Other icons, as alternatives to up/down arrows, include !! IMAGE !! or !! IMAGE !! The goal is to be internationally recognizable unlike letters, the meaning of which may be locale-specific. Notes on Categories and Potential Assessment Methods The category name is listed first (followed by the corresponding cMHAFF section names in parentheses). Then there is a consumer-friendly explanation of what that section includes, and finally a recommended means of assessment. Principles of assessment:

• Green = all SHALL and SHALL [IF] statements met (where the [IF] conditions apply), plus some “subset of SHOULD criteria” (to be determined: may be some specific set of criteria, or some percentage).
• Yellow = Not all of the “subset of SHOULD criteria” were met. (This is the fuzziest area. It is “clean” if all SHOULD criteria are required for green, but that may be too tough)
• Red = one or more SHALL or applicable SHALL [IF] statements were not met

Notes on how measured (self-attestation, test, inspection, etc.).