1. Introduction
Acknowledgements, Background, Intended Audience, and Instructions
1.1 Acknowledgements
The consumer Mobile Health Application Functional Framework (cMHAFF) team acknowledges the members of the HL7 Mobile Health Workgroup, who developed this Standard for Trial Use. In addition, acknowledgements are due to the HL7 EHR Workgroup and the HL7 Security Workgroup, and the Community Based Health Services (CBHS) workgroups, which also provided valuable guidance. Many other mobile health initiatives in the European Union and USA influenced cMHAFF as well, as referenced throughout this specification.
1.2 Background
As of 2015, there are thousands of consumer health applications (apps), which run on smartphones, watches, tablets, and other mobile devices, available for download from platform-specific application stores such as the Apple App Store (iOS) and Google Play (Android). Consumer acceptance and use of these apps is primarily based on recommendations—either personal recommendations through individual contacts or social media or app store ratings. While this information is important in understanding the relevance of an app to one’s life and the design and usability of an app, it is insufficient in communicating how an app secures and protects the personal information of its users. This poses a problem both for consumers and clinicians, who may be considering or prescribing use of an app to help track and improve health behaviors and conditions.
There is a great diversity in consumer health apps. Some are meant to be used for oneself, some help manage care for others, and some work best when an individual uses an app along with consultation from a health professional. Within section 2.4, three exemplary use cases of increasing complexity are introduced and serve to guide development of cMHAFF.
1.3 Intended Audience
- CMHAFF is primarily directed at developers and vendors of mobile health apps for consumers, to assist them in building and marketing apps that educate consumers and protect their privacy, security, data access, etc.
- CMHAFF is also directed at organizations (such as test labs, certification bodies, professional societies, or organizations that provide app reviews and ratings) that will assess or endorse mobile apps for conformance to essential criteria.
- CMHAFF can also be informative as a checklist (or “gold standard”) for prospective purchasers of mobile apps (e.g., consumers, or providers on behalf of consumers).
The beneficiaries of cMHAFF will primarily be consumers, due to improvements in apps and in a consumer’s increased understanding and trust. Other beneficiaries may include those who receive information from consumer health apps, such as providers, caregivers, and researchers. Some provider organizations, such as the American Medical Association, have published principles (see link below) to ensure accurate, effective, safe and secure mHealth apps.
1.4 How to Use this Guide
The questions in this section help the intended audience (particularly mobile app developers and vendors) determine which conformance subsections of cMHAFF should be read. Each subsection of 3.x contains one or more conformance statements. Based on the characteristics of the app being developed, some of those subsections may be applicable and some may not. To assist developers in understanding which subsections of cMHAFF are relevant to their app, the following table is presented. The left column is a yes/no question, and the right column represents decisions whether or not to apply sections of cMHAFF, depending on the answer to that question.
|
QUESTIONS
|
DECISIONS BASED ON ANSWERS
|
|
As a mobile app developer, what sections apply to me no matter how simple the app?
|
3.2.x (Product Development), 3.4.9 (Product Upgrades), 3.3.x (Download and Install App)
|
|
Does the app handle patient-identifiable information?
|
YES – then cMHAFF sections 3.4.1 (authentication), 3.4.2 (authorization), 3.4.10 (audit), 3.5.1 (app and data removal), and 3.5.2 (permitted uses post closure) apply
NO – then those sections from cMHAFF do not apply
|
|
Does the app store or transmit data outside the mobile device, e.g., the cloud or another HIT system?
|
YES – then cMHAFF 3.4.4 (security for data at rest), 3.4.5 (security in transit), 3.4.6 (data authenticity and provenance) and 3.4.7 (data exchange and interoperability) apply
|
|
Does the app connect to sensors or other types of devices that gather measurements of the patient’s condition?
|
YES – then cMHAFF 3.4.3 (pairing), 3.4.5 and 3.4.6 also apply
|
|
Does the app send alerts or notifications to the user?
|
YES – then cMHAFF 3.4.8 (notifications and alerts) applies
|
The intent of the Mobile Health Work Group is to use feedback from reviewers of the standard to improve the quality and relevance of the Framework so that it can become a normative Standard for Trial Use (STU) in 2019.
Section 3 forms the core of the Framework. Each section addresses product information and technical concerns based on a given stage of the app lifecycle, through conformance criteria, supported by references to related regulations and standards. Implementation guidance is also included.