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: PIM.2 Launch App and Establish User Account (Header)

Page standards status: Informative
Statement N:
Criteria N:
PIM.2#54 SHALL

A user can review the app’s Terms of Use before personal data about the user is collected and used.
PIM.2#55 SHALL

[The app creates user accounts] User acceptance of the app’s Terms of Use is logged before a user account is authorized (See section 3.4.10 for information about audit log record creation).
PIM.2#56 SHALL

[User is allowed to use pre-existing account credentials from an Identity Provider (IDP) to access the app] Before a user chooses to use pre-existing account credentials to access the app: (a) The user is informed about what attribute information will be used by the app associated with the pre-existing credentials; (b) The user is informed about what data is communicated back to the IDP at the time of account creation and at each subsequent user authentication.
PIM.2#57 SHOULD

For purposes of establishing an account, the minimum necessary amount of a user’s personally identifiable information (PII) is collected, e.g., the information is necessary to authenticate the user, provide customer support, or affect the app logic.

Notes:

Implementation Guidance

  • Use Case A: Knowing who the user is, in an absolute sense, is not needed as data is not being sent to any external data set. Primarily, account controls are in place to ensure the same person is using the app each time. For this walking app, possession of a smartphone may be sufficient to allow someone to use it without any additional need for authentication or need to set up a unique user ID and password to access the app.
  • Use Case B: Knowing the user’s absolute identity is not needed but minimal account controls (e.g., user ID and password) should be established as the app will allow information to be sent to an existing data set, and these data sets will need some ability to be linked, in part showing evidence an individual has control over both the app data and a right to access the existing data set.
  • Use Case C: requires more rigorous identity proofing as data will be both sent to an EHR and interactions initiated by a physician result in information being pushed to the app. Identity proofing can occur within the app itself, or in the use of pre-existing identity credentials (e.g., patient portal credentials for the entity controlling the EHR) to establish identity.