Application Data Exchange Assessment Framework and Functional Requirements for Mobile Health
0.1.0 - CI Build

Application Data Exchange Assessment Framework and Functional Requirements for Mobile Health - Local Development build (v0.1.0). See the Directory of published versions

Application Data Exchange Assessment Framework and Functional Requirements for Mobile Health

Mobile apps and devices provide their own APIs and methods for collecting device data that can be communicated to EHR, PHR and research endpoints. Much of this data can (and has been) readily converted to FHIR resources. However, some limits have been encountered which demonstrate that essential data needed to generate, interpret and use the FHIR resources is sometimes missing. The purpose of this implementation guide is document the functional requirements that can be used to assess devices, applications, and FHIR profiles to ensure that the essential data needed for clinical, patient and research uses is present in communications between applications.

Target Audience

The target audience for this document includes executive leaders, senior managers, and development staff interested in integrating mobile health devices into the health care eco-system.

This includes:

  • Members of organizations developing standards or regulation supporting these capabilities including:
    • Public Health Agencies
    • Quality Reporting Agencies
    • Regulators and Law-makers
  • Organizations developing or assessing the functionality of
    • Electronic Health Record (EHR) systems,
    • Personal Health Record (PHR) systems,
    • Patient Engagement solutions,
    • Mobile Health Devices, and
    • Mobile Health Apps or infrastructure.
  • Healthcare Institutions using, purchasing, or connecting to these systems to their EHR systems.
  • Health Information Exchange organizations facilitating such connections.

Scope of Work

The scope of this project is to develop the assessment framework and functional requirements for consumer medical devices and applications required to support the exchange of observations and other data in support of consumer health monitoring. This project will focus on Observation resources related to:

  • vital signs
    • height,
    • weight,
    • blood pressure,
    • O2 saturation,
    • respiration and heart rate,
  • physical activity (including sleep).

Out of Scope

This guide is focused on functional requirements. As such, it specifically leaves out non-functional requirements addressing system performance and behavior. The HL7 Mobile Health Application Functional Framework specification addresses many of these issues.

Out of scope items include:

  • Privacy and Security - Devices and applications are expected to operate in a secure environment, but this specification provides no guidance in assessing the security or privacy of these components.
  • Reliability, Accuracy Precision - Devices and applications are expected to operate reliably and produce results with adequate precision and accuracy, however, this specification does not document how these are assessed.
  • Performance, Scalability, Cost, Quality, et cetera.

Document Conventions

Explains Meaning of key words and other conventions or structures used in the document.

The phrases: SHALL, SHOULD, MAY, SHALL NOT, SHOULD NOT, NEED NOT, when appearing in this document in BOLD UPPERCASE have the following meanings:

SHALL
An absolute requirement for all implementations.
SHALL NOT
An absolute prohibition against inclusion for all implementations.
SHOULD/SHOULD NOT
A best practice or recommendation to be considered by implementers within the context of their particular implementation; there may be valid reasons to ignore an item, but the full implications must be understood and carefully weighed before choosing a different course.

MAY/NEED NOT: This is truly optional language for an implementation; can be included or omitted as the implementer decides with no implications.

This are similar to the Conformance Language used in HL7 FHIR and have the same meanings.

FHIR Resource names and field names will appear in text as Resource. Field names may be preceded by the encompassing resource as in Resource.field or may simply appear on their own as field when the Resource can be understood from context.

Document Organization

Overview
Provides an overview of the challenges this implementation guide is trying to solve and describes the technical environment and approach it uses to address these challenges.
Use Cases
Describes the four key use cases associated with this implementation guide.
Actors
Describes the systems and users that are affected by this implementation guide, and their roles and responsibilities.
Using This Guide
Explains how implementers of solutions conforming to this guide, users of those systems, and assessors of those systems can use this guide to facilitate integration of mobile health devices and applications into their health inforamation technology solutions.
Conformance
Explains how to assert or communicate conformance to this guide.
Functional Requirements
Provides the functional requirements against which a device, system, or implementation specification can be assessed.
Resource Profiles
Provides FHIR Resource profiles against which FHIR Resources can be assessed for conformance.

Click on any of the links above, head on over the table of contents, or if you are looking for a specific artifact including sample resources, check out the Artifact Index.

Downloads

You can also download:

Acknowledgements

HL7 would like to thank the following individuals and organizations for contributing to this effort.

Individuals

Organizations

Glossary

“When I use a word,” Humpty Dumpty said in rather a scornful tone, “it means just what I choose it to mean – neither more nor less.” - Lewis Carrol, Alice in Wonderland

The purpose of this Glossary is to ensure that the words and phrases are properly understood in the context of this guide. It is not an attempt to standardize these terms for general use.

App
Whether used alone, or with the adjective Mobile Health, App is simply a shortened form of Application, but specifically means Mobile Health Application in the context of this document. A Mobile Health Application is one that can be accessed via a mobile devices such as a smart watch, smart phone or tablet. Such an App may also be accessible via the Internet or a personal computer.
Application
In this guide, the term application refers to a collection of computer software which provides some computing functionality to an end user. This functionality can be spread across multiple computing devices or executed within a single computing devices. While all Apps are also applications according to this guide, not all applications may be considered to be Apps.
Assessor
An assessor is one who measures. In the context of this guide, an assessor is an individual or organization who measures how well a device, app, application, system or implementation guide measures up against the criteria specified in this guide.
Mobile Computing Device
Mobile computing devices are designed to be easily carried around (i.e., either worn or carried in an possibly over-sized pocket), can perform general purpose computing on behalf of a user, contain sensors that measure data about a user, and can connect wirelessly to a network (e.g., via WiFi, Cellular, Bluetooth or other technology). The principle form of input for a mobile device is generally a touch screen. These include devices such as a smart watch, smart phone or tablet computer. Laptop computers (even 2-in-1 units) are not considered in this guide to be a mobile computing device. While “mobile” in the general sense, they aren’t the kind of thing that you can fit into an over-sized pocket easily and usually rely on external keyboard input for certain tasks.
Mobile Device
Mobile Devices include sensors that measure data about a user or their environment and can connect to mobile (or other) computing devices. Mobile computing devices are considered to be mobile devices.
Mobile Health
Mobile Health is often used as an adjective to describe devices, applications, data repositories and other systems used with mobile computing devices such as a smart watch, smart phone, or tablet or wireless networks (WiFi, Cellular, Bluetooth or other).
Regulated Health Device
A regulated device is one which is subject to some form of regulatory health authority (e.g., in the US, the Food and Drug Administration (FDA)). Devices may also be subject to other regulation (e.g., if they contain a radio transmitter, they may be regulated by the FCC, they may be regulated by by authorities such as UL or CE), but in the context of this guide, the term specifically addresses devices regulated by health authorities.
Software
Software is a collection computing instructions which tells a computing system how to operate to perform some function. An application is a collection of software components. This guide makes NO distinction between software and firmware (basically read-only or unmodifiable software included in many computing devices). Today’s computing platfoms include software known as a Basic Input Output System (BIOS) that in prior years was not designed to be replaced or altered by the end-user. Most systems today now use some form of non-volatile memory to store this software, which was previously known as “firmware” because it couldn’t be easily changed (it still can’t be easily changed, but that’s another story).
SUT
In conformity assessment, SUT is an acronym that means the System Under Test. In the context of this guide, other specifications or implementation guides may also be tested.
System
A system is a collection of both hardware and software which provided computing capabilities to an end user. It is distinct from “application” in that in includes both the application and the computing components, whereas “application” includes only the software components.