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.4.10 Audit
Nathan E Botts
/ Categories: 3.4.10 Audit

3.4.10 Audit

Auditing methods for consumer health apps

Overview

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.[1]

Related Regulations and Standards

Implementation Guidance

Every consumer mobile health app needs an audit strategy, which includes what data will be generated for audit, who will be able to access audit records, the location where audit data is stored, the length of time audit information will be stored, and any ability to delete audit data. Audit for security events is highly dependent on the nature of the app itself; audit requirements will differ significantly based on app sponsorship (e.g., sponsor is a HIPAA entity or a commercial non-covered entity), the need for user authentication, and if data generated through an app is accessible by consumers, clinicians, or both.


[1] NIST Security Architecture Design Process for Health Information Exchanges (HIEs): https://www.nist.gov/healthcare/security/health-information-exchange-hie-security-architecture

 

Print
10476 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