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: APU.7 Data Exchange and Interoperability (Header)

Page standards status: Informative
Statement N:

This category applies only if an app exchanges data with other devices, health apps, and/or HIT systems. If so, there are applicable standards for data format, vocabulary, and transport, to increase interoperability and ease of connection.

 Criteria N:
APU.7#93 SHALL

[App exchanges discrete clinical data] Use standard terminologies (e.g., SNOMED CT, LOINC…).
APU.7#94 SHALL

[App exchanges discrete clinical data] Use standard format/content, e.g., HL7 FHIR, SMART on FHIR, HL7 Consolidated CDA, Detailed Clinical Models (HL7 CIMI), etc.
APU.7#95 SHOULD

[App exchanges discrete clinical data with devices] Use standard format/content, e.g., IEEE 11073.
APU.7#96 SHOULD

[App exchanges unstructured data] Use standard or commonly accepted formats, e.g., HL7 CDA, PDF.
APU.7#97 SHOULD

[App collects personal health information] allow data to be imported or exported from the app.[1]

Notes:

Implementation Guidance

In the realm of alerts and notifications, the following table proposed suggested standardized (generic)terms in the left column, with mappings to the leading two platforms in the middle columns, and comments in the right column. The platform-specific definitions have been derived from web sources,with preference given to information from the creators of the platforms (Apple, Google). Note: the mapping cannot be made an exact 1:1. In some cases, the platform-specific term may be more precise(e.g., subtypes) than the generic term, but we do not require a generic equivalent for every platform- specific term. In other cases, there may be substantial similarity of concepts across platforms, but not identical behavior, and certainly not identical appearance. Despite the proposed granularity of these terms, that does not mean that there need to be separatecMHAFF conformance requirements for each type, but at least the opportunity is there if the need arises. In particular, there may be different conformance requirements for “alerts” vs other types ofnotifications.

!! Convert table !!

Hierarchy

  • Message (overarching term)
    • Content Message (e.g., HL7 v2, C-CDA payload, FHIR resource) – out of the scope for this set of definitions.
    • Notification (overarching term)
      • Alert (requires user action, whereas all other types of notifications do not require it,though they may allow it)
      • Persistent notification
      • Temporary notification
      • Emergency Notification (government, outside app control)