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

3.3.2 Launch App and Establish User Account
Nathan E Botts
/ Categories: 3.3.2 Launch App

3.3.2 Launch App and Establish User Account

Assisting the Consumer with Establishing Access

Overview

This category is about the process of a consumer getting started with an app, potentially including establishing an account.

Related Regulations and Standards

See Appendix: Reference Documents

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.
Print
1577 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