Close

2.4 Exemplary Use Cases

As noted in the Introduction, consumer mobile heath apps take many forms, and as such, conformance statements in section 3 of this standard must allow for variation based on multiple factors, including data sensitivity, the nature of conditions addressed by the app (e.g., wellness, chronic illness), and whether/how app data connect to other data sources.

In this section, three archetypal use cases are introduced. While most consumer mobile health apps will not precisely fit any of these models, the models are meant to demonstrate a continuum of issues which may be applied to any app. Use Case A covers the least sensitive example of a health app that collects user information, while Use Case B builds off of Case A with the inclusion of an external system through which personal data is synchronized with the device. Use Case C is the most sophisticated and generates the most requirements. Its description includes examples of the risk factors that should be considered by developers and users.

Section 3 (Conformance Criteria) includes discussion of considerations as to how subsets of conformance criteria can be addressed in different manners, referencing the use cases in this section as a way to provide directional, rather than pinpoint, guidance.

HL7 CMHAFF Standard Overview and Use Cases

2. Overview
CMHAFF Workgroup

2. Overview

Goals, Scope, Conformance Design Principles

2 Overview

  2.1 Goals

The primary goals of cMHAFF are to provide a standard against which a mobile app’s foundational characteristics -- including but not limited to security, privacy, data access, data export, and transparency/disclosure of conditions -- can be assessed. The framework is based on the lifecycle of an app, as experienced by an individual consumer, from first deciding to download an app, to determining what happens with consumer data after the app has been deleted from a smartphone. It is important to note that the Framework does not speak directly to the specific health or clinical functionality of an app but can be extended to do so through the use of profiles (with constraints and/or extensions) developed on top of cMHAFF.

The decision to create a standard focused on a smaller set of criteria was made so that the standard is both developer-friendly and easy to update on a frequent basis. CMHAFF challenges market assumptions concerning safe and acceptable use of personal information and may in some circumstances increase coding complexity and decrease the efficiency of data transmission. As such, there is no expectation that most consumer health apps will choose to follow this standard. Yet, for apps which conform, cMHAFF can potentially provide a path to assessments that can span a range including self-attestation, testing, endorsement (see link provided below), and/or certification (voluntary or regulatory). CMHAFF is independent of the method of assessment, but aims to be suitable for use for types of assessments up to and including certification. Certified apps can promote their conformance, and as a consequence, consumers who use the apps, and providers who recommend them, can be more confident of an app’s rigor in enforcing basic security, its respect for the privacy of individuals, and the usefulness of data for improving and maintaining a better state of health.

 

  2.2 Scope

     2.2.1 In Scope

CMHAFF focuses specifically on consumer mobile apps that run on devices such as smartphones, tablets, and wearables. It is focused on the general capabilities, that can be thought of as “horizontal” features that are applicable to most or all apps, rather than to the specific health, clinical, or medical functionality of an app.

There is a broad range of apps that cMHAFF intends to cover, from simple self-contained standalone apps that a consumer can use for personal benefit, which do not exchange or store data outside the mobile device; to apps that share or store data externally (e.g., in the app provider’s cloud) but do not interact directly with provider systems; to systems that share and store data externally and interact with provider EHRs or organizations (in the USA, covered entities or business associates governed by HIPAA and/or FDA).

The intent is to lay a foundation, on top of which realm-specific and domain-specific “profiles” can be layered, that addresses an app’s:

  • 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.

     2.2.2 Out of Scope

  • “Professional” apps that may run on consumer devices, but are intended for healthcare workers, e.g., clinical decision support aids, which are not consumer-focused.
  • Clinical or health app functionality (e.g., diabetes monitoring, exercise calculations). The Mobile Health workgroup does not have the subject matter expertise to define those types of criteria.
  • General “device” security requirements, e.g., password or biometric locking of a phone. CMHAFF is an application functional framework intended for app developers, not a framework for the devices or platforms on which the apps run. As such, cMHAFF is not directed to Apple, Google, Samsung, or other device manufacturers and in general, seeks to remain agnostic in terms of platform. However, risk management should identify dependencies or assumptions about the common platforms that an app may rely on.
  • General “infrastructure” requirements for consumers or healthcare organizations, such as the protection of networks via virus or malware protection, firewalls, etc., physical environmental security, since app developers have no control over such networks or environments. However, risk management should identify dependencies or assumptions about the supporting infrastructure that an app may rely on and should identify threats and mitigate risks.
  • Human resource policies and procedures of developers, healthcare organizations, or consumers, such as security awareness education, except inasmuch as they directly affect product development.

 

  2.3 Conformance Design Principles

Conformance Criteria in sections 3.x follow a lifecycle model in relation to a consumer’s use of a mobile health application, from first finding an app in an App Store to disuse and de-installation.

CMHAFF Sections and Mobile App Life Cycle

HL7 CMHAFF Sections and Mobile App Lifecycle

Print
9259 Rate this article:
No rating
0Upvote 0Downvote

Leave a comment

This form collects your name, email, IP address and content so that we can keep track of the comments placed on the website. For more info check our Privacy Policy and Terms Of Use where you will get more info on where, how and why we store your data.
Add comment
Terms Of UsePrivacy StatementCopyright 2024 by HL7 International
Back To Top