Physical Activity Implementation Guide
1.0.0 - STU Release 1 United States of America flag

This page is part of the U.S. Physical Activity IG (v1.0.0: STU 1.0) based on FHIR R4. This is the current published version. For a full list of available versions, see the Directory of published versions

Welcome to the Physical Activity IG

Official URL: http://hl7.org/fhir/us/physical-activity/ImplementationGuide/hl7.fhir.us.physical-activity Version: 1.0.0
IG Standards status: Trial-use Maturity Level: 2 Computable Name: PhysicalActivity
Page standards status: Informative

Contents:

Banner showing a series of images of people engaged in various forms of physical activity

Welcome to the first release of our specification! This guide is the result of hundreds of hours of work by a wide variety of people who are passionate about enabling and supporting patients in improving their levels of physical activity. We are happy to receive feedback from the broader community about everything written here, but particularly about any concerns with respect to implementability or how we can make it easier to get these features into production systems. If you're interested in joining us, check out our project page, or come join the discussion on http://chat.fhir.org.

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 and infectious disease treatment and prevention. It provides 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 races/ethnicities. (For more information and research citations highlighting the importance of physical activity and intervening to improve it, see the background page of this IG.)

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 physical 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 capture and share the primary, evidence-based measure of a patient's level of physical activity;
  • How to create and share care plans and goals related to improving a patient's level of physical activity;
  • How to order interventions that can assist a patient in improving their levels of physical activity;
  • How to capture and share information that supports that primary measure - for patient, clinical, insurance or other use;
  • How to engage with the patient and their caregivers to provide support and/or gather information as a patient works towards their physical activity goals; and
  • What are the reporting mechanisms to close the referral loop on an interim basis or when referrals are complete?

The IG also provides additional guidance to support all of the above, including registries, consent, status monitoring, etc.

The following diagram shows the participants and functions covered by this IG and how they fit into the overall cycle of care:

Diagram showing a circular cycle around icons representing Care Managers, Patients and Service Providers. The bullets in the circle are: Assessment: Is patient getting sufficient physical activity?; Plans & Goals: What steps need to be taken? How? Targets? By when?; Prescription & Referral: Wh can help and how?; Monitoring: Exercise logs, heart rate, steps, etc.; Engagement: Videos, reading, satisfaction surveys, etc.; Reporting: What was done? Any issues? What should happen next?

Figure 1: Improving Physical Activity - Healthcare Cycle

The focus of this guide is on sharing data related to "what the patient is currently doing/planning to do" from a physical activity perspective as well as how to support the patient in improving and maintaining activity levels. It does not deal with exchanging information about the various factors that may be impact a patient's ability to be physically active. There are several other FHIR implementation guides that deal with the exchange of health conditions, social determinants, functional status, and other considerations that may influence physical activity levels. Refer to the Relationships with Other Work section below for references.

The stakeholders who created this guide were primarily U.S.-based and in some places the IG 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 five primary sections that define expectations for conformant systems:

  1. Conformance Expectations sets general expectations around conformance to the IG.
  2. Physical Activity Measures defines profiles for the standardized capture of a patient's physical activity level. In addition, it defines 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.
  3. Physical Activity Interventions 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.
  4. 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.
  5. Privacy and Security describes expectations and considerations specific to this IG related to data protection and access management.

In addition, there are several 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 have 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. As such, it helps support the business case for implementing this IG.
  • Scenarios describes examples of real-world scenarios where this IG would come into play and how the interactions between the software systems supported by this IG would impact patients, clinicians and others using those systems.
  • Design Considerations lists a variety of architectural and other considerations that have gone into the creation of this implementation guide and explains why the functionality it provides has been implemented as it has. It also lists a few areas where implementers have been left some flexibility and provides guidance about how to best decide amongst alternatives based on implementation context.
  • Artifacts - This provides a summary 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 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.

Relationships with Other 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:

This Implementation Guide (IG) is derived from US Core version 3.1.1 which is the version currently referenced in U.S. regulation. However, certain resources, such as RelatedPerson, were not profiled as part of this US Core release. Consequently, the profiles for these resources have been designed to mirror the requirements of future US Core versions. Newer versions of US Core introduce additional features, some of which may be relevant to the physical activity space. Implementers are free to adopt extensions and other functionality from newer versions of US Core where that can be done in a way that doesn't break interoperability with systems that strictly adhere to 3.1.1.

In addition to those implementation guides, there are several other HL7 specifications that may be of interest to implementers of this IG. The guides below are listed for information purposes only. None of their content is needed in order to conform with this Physical Activity guide.

  • Coverage Requirements Discovery (CRD), Documentation, Templates, and Rules (DTR), and Prior Authorization Support (PAS) - these three IGs (collectively known as the Da Vinci Burden Reduction IGs) provide support for prior authorization and other documentation capture. They may assist in determining whether a patient is or can be covered for physical activity-related interventions.
  • Clinical Documentation Exchange (CDex) - Allows payers to retrieve or solicit records from an EHR related to patients covered under their plans. May be used to allow payers retrieving physical activity-related information for quality measures or in support of contractual or other payment schemes.
  • Data Exchange for Quality Measures (DEQM) - Allows sharing patient data with payers to support quality measures and capitated care. Physical activity measures may be reported to payers for patients covered under such measures.
  • SMART App Launch - allows launching third party applications in the context of another system, including allowing the application to control access to patient information. Rather than developing Questionnaire form filler capabilities within their own system, Care Providers and Service Provider systems may opt to use a 3rd party SMART App to handle form rendering, data capture, form population and data extraction.
  • PACIO Functional Status - defines standards for sharing information about a patient's physical capabilities, which may influence what types of physical activity interventions are appropriate.
  • Quality Measure Implementation Guide - defines standards for sharing clinical quality measures electronically, allowing defining and sharing measures related to patient physical activity and appropriate clinical interventions related to physical activity.
  • Personal Health Device (PHD) IG - defines standards for sharing information from personal healthcare devices (heart rate monitors, step trackers, etc.) using FHIR - either directly or via intermediaries. While not all relevant devices will support this standard, a consistent way of handling data from those that do should be useful.
  • National Healthcare Directory Exchange - a U.S. Office of the National Coordinator-sponsored IG supporting the exchange of directory information for a wide range of service providers and organizations. Once in place, this directory will significantly reduce the efforts to find and connect with Care Provider and Service Provider systems.
  • Occupational Data for Health (ODH) - a guide that focuses on gathering information about a patient's occupation - which may provide context when evaluating their level of physical activity from their occupation, as well as influence what guidance is appropriate for introducing additional physical activity.
  • IHE FHIR Audit Event Query and Feed to ATNA - for systems wishing to maintain robust audit records of changes and access to patient records (always a good idea), this IG defines standards for using FHIR to do so. (Note that this standard is only really relevant if there's a need for electronic sharing of audit records.)
  • Bulk Data Access - defines standards for sharing large volumes of FHIR data at one time. This may be relevant if sharing large volumes of patient exercise, heart rate, and/or other information between systems.
  • Patient Contributed Data - defines guidance for incorporation of patient and caregiver-collected information into clinical records (which this IG supports and advocates for).
  • BSeR: Bidirectional Services_eReferral - also deals with referrals and Gravity and Physical Activity are likely to both be formal constraints on BSeR once it has more explicit support for RESTful referral management.

An extensive list of FHIR implementation guides published by HL7 and other related organizations can be found here.

Intellectual Property Considerations

This implementation guide and the underlying FHIR specification are licensed as public domain under the FHIR license. The license page also describes rules for the use of the FHIR name and logo.

This guide includes profiles and examples making use of terminologies such as LOINC and SNOMED CT codes that have more restrictive licensing requirements. Implementers should make themselves familiar with licensing and any other constraints of the 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 artifacts may be shared with.

This publication includes IP covered under the following statements.