Page tree
Skip to end of metadata
Go to start of metadata


Committee Approval Date: Dec 20, 2019

Publishing Lead:  Keith W. Boone

Contributing or Reviewing Work Groups:

Mobile Health

EHR

FHIR Development Project Insight ID: 1599

Scope of coverage:

This guide is focused on _functional_ requirements. As such, it specifically leaves
out non-functional requirements addressing system performance and behavior. The
HL7 Consumer 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.
  • FHIR Profiles specifically intended for the purpose of exchange. The profiles in this guide are intended to be used as aid to automate the computation of assessments against the requirements of this guide. Existing profiles, such as the FHIR Use Core and the Observation Vital Signs Profile should be used for these purposes.

Content location:

https://github.com/HL7/fhir-project-mhealth

https://hl7.github.io/fhir-project-mhealth/ (we are substantively complete)

Proposed IG realm and code:

hl7.fhir.uv.mhealth-framework

Maintenance Plan:

This IG will be maintained by the Mobile Health Workgroup

Short Description:

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. This implementation guide documents 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.

Long Description:

Scope of Work
The guide provides an assessment framework and functional requirements
for consumer medical devices and applications that support the exchange of
observations and other data in support of consumer health monitoring. It focuses
on functional requirements of devices, apps, and infrastructure regarding
the observations and device related communicating data about:

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

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

Items that are not in scope in this guide 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 - These non-functional requirements are often weighted differently from the functional needs based on an organizations infrastructure, available resources, and timelines.
  • FHIR Profiles for Exchange: The informative profiles in this guide are intended to be used as aid to automate the computation of
    assessments against the requirements of this guide. Existing profiles, such as the FHIR Use Core and the Observation Vital Signs Profile should be used for exchange purposes.

Involved parties:

  • Reliant Medical Group
  • US Office of the National Coordinator for Health IT (AllOfUs Health IT standards research sponsor) 
  • US National Institutes of Health, All of Us Research Project
  • Open mHealth
  • Audacious Inquiry

Expected implementations:

  • Reliant Medical Group
  • Mobile Health Workgroup Assessments of Devices, Apps and IGs

Content sources:

Existing FHIR Implementation Guides  (e.g., US Core, Observation Vital Signs, AMA FHIR IG, Continua IG, CIMI), IEEE/Open mHealth 

Example Scenarios:

The first section below describes how the assessment framework in this guide enables the assessment of devices, apps, infrastructure and accompanying specifications. The section that follows describes the various use cases supported by the functional requirements in this guide.

Assessment Framework Use Cases

The use cases below describe how the framework described in this IG enables assessment and selection of devices, apps, and infrastructure to support exchange of data in mobile health solutions.

Performing an Assessment of a Device, App or Infrastructure

Provider and developer organizations developing Mobile Health solutions need to assess existing devices, apps and/or infrastructure (including existing EHR or PHR systems) in order to successfully deploy these solutions.

Preconditions

  • The organization has identified multiple devices, apps or infrastructure systems as the systems under test (SUT) to assess.
  • The organization identifies specific criteria from this guide which it considers to be important to the success of the project.

Steps

  • For easy identified SUT, it is assessed against SHALL and SHOULD requirements of this guide.
  • Assessments are reported to the organization.
  • The organization selects a specific system based on the criteria in this guide.

Postcondition

  • The device, app, or infrastructure system that most closely meets the organization’s requirements has been identified.
Assessing at Different Levels and Categories

Extending from the use case above, different organizations will have different requirements that are important to them. To support this, the guide enables providers to base their assessments on their specific needs.

Specific categories include both Simple and Enhanced Data Collection capabilities, the ability to include additional manual inputs from the user, specific kinds of measurements to be collected (e.g., weight, blood pressure, physical activity, et cetera)

Preconditions

  • The provider organization can select specific functional areas (categories) that are important to them.

Steps

  • The assessments to be performed are selected from functional categories in this guide.

Performing an Assessment of an IG or other Specification

Systems to be assessed may already claim and be verified as conforming to a specific implementation guide and/or other specification. That specification may ensure some or all of the providers selected requirements, requiring that the provider only assess certain gaps. In this case, an assessment of a specification can be performed to enable a provider to identify the gaps that need to be assessed.

Preconditions

  • A specification or Implementation Guide exists for which a selected device has been verified to be conformant.

Steps

  • The specification is assessed against the requirements of this guide.
  • The minimum and maximum level of conformance supported by that specification is reported.

Postcondition

  • The organization can determine whether or not a system conforming to that specification can meet their requirements.
  • The organization can determine the gap between what is minimally supported by the specification, and what may need additional work.

Reporting of Assessment Results

Organizations are able to “score” results from multiple categories to enable an aggregate score to be computed and used for evaluation and selection.

Precondition

  • An organization can select two or more categories to assess a system against.

Steps

  • The system is assessed against those categories.
  • The results from those assessments are aggregated into a singular score.

Postconditions

  • The singular score is produced against which further evaluation and selection can be performed.

Use Cases Functional Requirements in this Guide

The high level use cases below demonstrate the kinds of exchange that the functional requirements of implementation guide support. These use cases provide functional requirements the guide supports, and so are not described in further detail.

Capturing Routine Weight Measurement

A Health Care Provider wishes to capture routine weight measurement data to monitor patients with CHF. This guide will enable providers to assess devices, apps and infrastructure to determine those that will meet there needs for developing a program to support monitoring and communications of weight data to their EHR system.

Glucose Monitoring (w/ manual Insulin Dose reporting)

Patients with Diabetes taking insulin routinely journal information about their blood sugar levels and insulin dose. Healthcare providers periodically may review these journals. A Healthcare provider wishing to capture this data automatically can assess devices regarding capabilities to support this data capture, and can also determine the degree to which it supports the providers insulin dosing recommendations based on blood sugar dose.

This implementation guide will enable providers to assess additional manual data capture enabled by the device or app, and to understand how the these may be configured to support the providers treatment recommendations.

Communicating Vital Signs, including Blood Pressure

Blood pressure measurements can be captured for a number of different purposes. The AMA has recommendations for self-measured blood pressure that require collection of additional data (e.g., patient position, recency and type of physical activity, location where the measurement was taken, type and manufacturer of device, etc.). This implementation guide

Recording Physical Activity

Monitoring of Physical activity including sleep is an important component for monitoring treatment for certain conditions. This is a developing area, and so will be limited to just basic data requirements for these observations.

IG Relationships:

  • US Core
  • Observation Vital Signs
  • AMA FHIR IG
  • Continua IG
  • CIMI Models


Timelines:

Balloting in May and September Cycle and Publish by December 31, 2020


FMG Notes