This section is about the compliance of apps to applicable regulations for the domains (realms, locales, environments) in which they are intended to be used. CMHAFF is designed as a framework that can be further constrained (profiled) for these domains and does not require conformance to any specific locale’s regulations.

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.

This category is about providing information about the product to consumers and also other parties (e.g., governments, consumer or provider organizations) who have interest in potential purchase, use, endorsement, or recommendation of apps. The experience of installing an app begins at an app store and completes on a user device. See also the Conditions and Agreements section of this specification for guidance regarding Conditions and Agreements that usually appear as part of the app store experience. cMHAFF does not specify exactly how or where product information is conveyed, e.g., app store, web site, online help.

This category is about the system protecting against unauthorized access (e.g., by persons other than the consumer).

This category is about personal data collection and use, including access to device features, being understood and explicitly authorized (consented to) by the users of the app.

This category is about consumer verification of all devices to which they wish to pair or sync data.

This category is about providing assurance that the consumer’s stored data is secure, regardless of whether it is stored on the consumer’s devices or elsewhere (e.g., in cloud-based servers for an app). It also provides assurance that consumer data is secure when it is moved between the consumer’s device(s) and other locations.

This category is about providing assurance that consumer data is secure when it is moved between the consumer’s device(s) and other locations. This category is about the attribution of sources of data (provenance) and assurance of data authenticity.

This category applies only if an app exchanges data with other devices, health apps, and/or HIT systems. If so, there are applicable standards for data format, vocabulary, and transport, to increase interoperability and ease of connection.

This category applies only if an app exchanges data with other devices, health apps, and/or HIT systems. If so, there are applicable standards for data format, vocabulary, and transport, to increase interoperability and ease of connection.

This category is about auditing, which is a mechanism for user and system accountability. Important events, such as logins and access to particular functions and data, are recorded and can be used to detect instances of non-compliant behavior and to facilitate detection of improper creation, access, modification, and deletion of personal health information. Any information technology including consumer health apps should follow best practices in managing an audit trail. The audit trail should maintain a record of users who have accessed what data, from where, and when. Audit logs should also record any attempts to access the system from an unauthorized terminal; expired usernames or passwords that try to access the system, unusual numbers of authentication attempts, and violations of an organizations security policy.

This category is about what is done with consumers’ data if they close their account (terminate use of the app).

Prior to marketing a mobile app, the developer has a responsibility to ensure it meets Realm-specific rules and regulations. Although cMHAFF does not have guidelines for all aspects of the software product life cycle, cMHAFF still recommends that the product development life cycle, for new apps and for upgrades to apps, ensure that requirements for functionality, reliability, performance, scalability, safety, compatibility, portability, and maintainability have been addressed, as well as any requirements that relate to aspects that include these items previously described above:

• Product Information for consumers (e.g., App Store descriptions, product disclosures)
• Security
• Privacy
• Permission to use device features
• Data Access
• Data Sharing
• Terms of Use, Conditions
• Product Development, including risk management, user-centered design, compliance with applicable regulations, functions (product description), reliability, performance, scalability, safety, compatibility, and portability. The security and privacy of information used by the app needs to be considered throughout the development phases of the app. Functionality must support the intended use of the app for the target users and stakeholders. Thorough and iterative risk assessment and requirement analysis, testing, evidence collection, documentation, and configuration management ensures quality to satisfy the needs of the application’s various stakeholders 8 . Assessing the usability of the app helps ensure the app’s viability and adoption; testing must be population- relevant and demonstrate reasonable product usability (accessibility) by people with visual, auditory and motor disabilities within the intended target audience. Establishing a system of customer support enables product defects and usability issues to be surfaced in a systematic way and helps problems related to use of the app to be effectively resolved and the developer to continually deliver the intended use of the app.

Apps are frequently marketed and downloaded through platform-specific “app stores.” Before an app can be housed within an app store, it must meet requirements set by the app store host. The app store is one primary source of product information for consumers to decide whether they want to install the app. In some realms, apps may also be obtained through an app registry.

This section addresses functionalities and considerations to be addressed while the user is operating the app.

Health apps may be used indefinitely or for a finite period of time and will consequently require the ability to terminate services with the app.Disuse may happen when a health condition improves, a new health habit is established, when motivation to use the app wanes, or when the user determines a different app better meets their needs. Procedures for how data continues to be retained and used after account closure must be clear and understandable and give the app user options for relocation of their data to a new data repository.

This section of cMHAFF deals with nonfunctional, and usually nontechnical, aspects of mobile health apps. While not traditionally in scope for HIT standards oriented at large or small enterprise organizations, it is a very important and distinctive characteristic of apps targeted at consumers.Since one goal of cMHAFF is consumer protection, including their privacy and security, guidance in the area of “Conditions and Agreements” (CnA) is offered. CnA is not a formal or legal term, but an umbrella under which can be grouped various expressions of conditions that consumers to which are asked to agree before they start using a mobile health app. These may be called “Terms and Conditions,” “Terms of Use,” “Terms of Service,” “End User License Agreement (EULA),” and similar concepts. Typically, CnA are displayed and consumers are asked to click buttons to agree to terms, when they interact with “App Stores” (a generic term including wherever a consumer downloads a mobile health app). In addition to what the consumer agrees to, CnA may also commit the app supplier to certain behaviors or restrictions. While cMHAFF does not prescribe what these CnA must include, it provides guidance as to items that are important to disclose. In that respect, there is some precedent in the ONC 2015 Edition Certification, which contains disclosure and transparency requirements for EHR developers, e.g., about pricing and services that are not included in the base software.

This StructureDefinition represents the base EHR-S FM Function type

This StructureDefinition represents the base EHR-S FM Header type

This StructureDefinition represents the base EHR-S FM Section type

This StructureDefinition represents the base EHR-S FunctionalModel type

Requirements Statement Actors

Requirements or Statement Criteria Change Indicator

Requirements Statement Criteria is dependent

Requirements Statement Example

Requirement Change Indicators

Requirement Change Indicator