Physical Activity Implementation Guide
0.1.0 - CI-build United States of America flag

Physical Activity Implementation Guide, published by HL7 International - Patient Care WG. This is not an authorized publication; it is the continuous build for version 0.1.0). This version is based on the current content of and changes regularly. See the Directory of published versions

Physical Activity Home

Official URL: Version: 0.1.0
Draft as of 2022-05-29 Computable Name: PhysicalActivity

This specification is a straw-man draft. It is intended to form a starting point for discussion, but has not undergone any form of review, nor been endorsed by the community of providers and implementers it is intended to serve. Expect to find things that are unclear, missing, or outright wrong. A list of known open issues and outstanding to-dos can be found here. If a concern you have about the specification isn't already on that list of issues, please raise it on the project discussion stream on

Scope and purpose

Being physically active is one of the most important lifestyle behaviors people can engage in to maintain physical and mental health and well-being. Regular physical activity is both health-promoting and important for chronic disease and infectious disease treatment and prevention with numerous benefits that contribute to a disability-free lifespan. Currently in the US, one in four adults are physically inactive with increasing prevalence across some geographies and in certain race/ethnicities. (For more information and research citations highlighting the importance of physical activity and intervening to improve it, see this page.)

This implementation guide standardizes interoperability expectations for systems involved in measuring, reporting, and intervening to improve patient physical activity levels. It defines interface expectations that are relevant for patient-facing applications, patient activity measurement devices, clinical electronic health records, payers, quality measurement systems, and applications used by health and fitness professionals, personal trainers, and community-based fitness centers. By improving standardization and interoperability around measuring physical activity levels and data sharing needed to help patients improve their physical activity levels, we can make a significant impact on overall patient health at both the individual and the population level.

This version of the specification defines standards for the following:

  • How to consistently share the primary, evidence-based measure of a patient's level of physical activity?
  • How to capture and share information that supports that primary measure - for patient, clinical, insurance or other use?
  • How to create and share care plans and goals related to improving a patient's level of physical activity? and
  • How to order interventions that can a assist a patient in improving their levels of physical activity?
  • Additional data and exchange flows needed to support all of the above, including registries, consent, status monitoring, satisfaction evaluation, etc.

This guide was created primarily by U.S. stakeholders and in some places requires the use of code systems that are U.S.-centric. However, the general architecture of the solutions defined here and most of the interoperability expectations are likely to be relevant irrespective of country. Implementers in non-U.S. jurisdictions are welcome to leverage this content. If there is sufficient interest, a future version of this implementation guide might be developed that is international in scope.

Specification overview

This implementation guide is organized into three primary sections:

  1. Physical Activity Measures defines a profiles for the standardized capture of a patient's physical activity level. It also defines an optional FHIR Questionnaire that can be used by questionnaire-based systems to capture that measure. In addition, it defines additional profiles to capture supplemental observations assertions around physical activity levels, such as daily physical activity log entries, heart rate measurements, and step counts. The specification also covers how to link these supporting records to the primary physical activity measure.
  2. Physical Activity Interventsions defines profiles supporting the ordering of interventions intended to increase patient physical activity and/or to support maintenance of existing but at risk levels of physical activity. This includes profiles covering plans and goals related to physical activity as well as orders to physical activity professionals.
  3. Physical Activity Workflow defines the specific workflow and interoperability capabilities expected for systems that support this implementation guide. It describes each of the different types of electronic systems that might participate in sharing information around physical activity as well as what types of data exchanges those systems are expected to support. Some requirements will be mandatory, others will be optional.

In addition, there are a number of supporting pages that to help support the implementation process:

  • Table of Contents - A complete listing of all the pages in this implementation guide (helpful if you're not sure how to navigate to a page or want to ensure you've read every page there is).
  • Understanding FHIR - This page is aimed at implementers who might be new to using FHIR. It identifies the key pieces of the FHIR specification an implementer should read and be familiar with before reading through the technical artifacts and instructions found in this implementation guide. It also defines key documentation conventions used in this IG. Finally, it defines the rules for asserting conformance with this implementation guide.
  • Importance of Physical Activity - This page summarizes some of the research and policy considerations that underpin the need for improving the standardization of physical activity measures and the benefits of intervening to help patients improve their levels of physical activity.
  • Artifacts - This provides a summary of all of the technical artifacts defined in this implementation guide. It also provides a list of the artifacts defined elsewhere that are leveraged as part of this implementation guide.
  • Downloads - This provides a handy set of zip files that can be downloaded for local use, including this implementation guide and all of its artifacts.
  • Credits - This provides a list of some of the key stakeholders involved in the development of this implementation guide.

All the main pages in this implementation guide can be navigated to using the main menu at the top of the page. Links to dependencies and useful external and support pages are also available from the menu. Near the top of each page, there's also a grey bar containing a breadcrumb navigator that allows you to easily navigate to parent pages or back to the root table of contents.

Building on Existing Work

This implementation guide builds on other specifications, helping ensure a consistent approach to data sharing that should ease adoption. The specific guides used, and the portions relevant from each of them are as follows:

  • Gravity SDOH - While focused on social determinants of health such as appropriate housing, food availability, interpersonal violence, there is a significant overlap between the SDOH implementation guide and the exchange needs relevant to physical activity. In both the SDOH and physical activity spaces:

    • The relevant measures are typically gathered by asking questions of patients or their care-giver.
    • There is not yet national consistency in how the measures are captured (or even in the need to capture the measures at all).
    • Interventions to address any identified issues will often involve non-traditional service providers (e.g. food pantries and home repair services for SDOH; personal trainers and fitness centers for physical activity). These non-traditional service providers often do not have sophisticated EHRs or other interoperability capabilities.
    • Improving the patient situation means agreeing on and sharing information about care plans and goals between primary care providers, patients, care givers, and the non-traditional service providers.
    • There is a need to 'close the loop' on interventions to determine whether the requested intervention was performed, whether the patient is satisfied, and whether the outcome met the original objectives.
    • There may be a need to seek payment for interventions that don't fall into the traditional realm of 'healthcare services'.

    For all these reasons, the physical activity implementation guide builds on the standards defined by the Gravity SDOH implementation guide. Where SDOH artifacts are overly restrictive but still relevant, this guide will define aligned but parallel profiles and will try to continue alignment in future releases.

  • US Core defines profiles that express the data elements defined in U.S. Core Data for Interopreability (USCDI) (which is mandated for implementation by EHR systems falling under the 21st Centure Cures Act) as well as other data elements the major U.S. EHR vendors have agreed to implement. As such, this implementation guide is a foundation for interoperability with EHR systems in the U.S. All profiles defined in this IG either derive from or align with US Core profiles whenever possible.
  • Structured Data Capture (SDC) defines standards for creating, populating, extracting data from and otherwise manipulating Questionnaires and QuestionnaireResponses. This implementation guide allows optional use of Questionnaires when gathering information from patients and care givers about physical activity levels. It also uses questionnaires as part of the evaluation process. Leveraging SDC ensures that questionnaires created with this guide will be able to be rendered and, where appropriate, automatically have some of their answers pre-populated into and/or extracted from using off-the-shelf tooling that already supports the SDC implementation guide.
  • Subscriptions Backport defines standards for automatically detecting that data has changed on a system and providing notifications to interested systems. The Gravity SDOH implementation guide uses this to allow systems to monitor for updates between EHR systems and service delivery systems. This implementation guide allows the same approach.

Intellectual Property Considerations

While this implementation guide and the underlying FHIR are licensed as public domain, this guide includes examples making use of terminologies such as LOINC, SNOMED CT and CPT codes that have more restrictive licensing requirements. Implementers should make themselves familiar with licensing and any other constraints of terminologies, questionnaires, and other components used as part of their implementation process. In some cases, licensing requirements may limit the systems that data captured using certain questionnaires may be shared with.