Consumer Mobile Health Application Functional Framework, Release 2
2.0.1 - CI build International flag

Consumer Mobile Health Application Functional Framework, Release 2, published by HL7 International / Mobile Health. This guide is not an authorized publication; it is the continuous build for version 2.0.1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/cmhaff-ig/ and changes regularly. See the Directory of published versions

Requirements: PDS.1 Regulatory Considerations (Header)

Page standards status: Informative
Statement N:

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.

Criteria N:
PDS.1#01 SHALL

The app SHALL be analyzed to determine if regulatory approval (following Realm-specific regulatory rules) is needed before the app is used by the general public.

PDS.1#02 conditional SHALL

IF it is determined that realm-specific regulatory rule approval is required THEN the app SHALL not be presented for general public use until regulatory approval is obtained.

PDS.1#03 SHOULD

The App SHOULD have measures to safeguard minors in accordance with applicable regulations.

Notes:

The documents listed below are overviews of the regulatory landscape, rather than specific regulations governing mobile health apps. Specific references are listed either following the conformance tables, or in the Appendix.

Commission Staff Working Document on the existing EU legal framework applicable to lifestyle and wellbeing apps. This broad guidance for the European Union, analogous to the USA FTC document. It is complemented by country-specific guidelines. In the EU, some mHealth apps may fall under the definition of a medical device and therefore may have to comply with the safety and performance requirements of Council Directive 93/42/EEC concerning medical devices.

Implementation Guidance

  • Use Case A: In the US Realm, a walking app which encourages general wellness is not considered a mobile medical app by the FDA. As such the FDA does not intend to regulate this type of app.
  • Use Case B: In the US Realm, a weight management app is not considered a mobile medical application by the FDA as long as it makes no claims to improve/cure a disease. How the app is described is important, and FDA guidance defining wellness vs. apps which aim to improve specific disease conditions should be referenced and reviewed before making a definitive decision as to its FDA classification.
  • Use Case C: There are two distinctions regarding compliance issues for this app. For the data collection devices in this use case, a glucometer would be FDA regulated, while a general activity monitor, would not. Apps which collect and display disease information would not typically be regulated until the information is compiled or transformed and clinical decisions are made on the data. In this case, the app is capable of receiving alerts, but the logic behind the alerts are based on individualized settings through a rules engine which is integrated into an EHR. In this case, the locus of regulation is not clear, and as such counsel should be engaged in forming a definitive case as to what regulatory approvals might be needed.

For the European Union, the figure below summarizes relevant guidance and regulations for Mobile Health. There are three principal EU regulatory areas impacting mHealth apps:

  • Medical devices, applying to higher medical risk apps only, including Regulation (EU) 2017/745 for medical devices in general and Regulation (EU) 2017/746 for in vitro diagnostic devices.
  • Information protection, applying to all apps that store or transmit personal data – currently a group of three directives, that will largely be replaced by the General Data Protection Regulation on 25th May 2018, together with an expected mHealth-specific voluntary code.
  • Consumer protection, including the right to fair treatment, products which meet acceptable standards, and right of redress if something goes wrong.

Shades of blue indicate directives and regulations. Red indicates voluntary codes/guidelines. Yellow indicates possible other actions with uncertain timing.

!! IMAGE !!