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

Physical Activity Implementation Guide, published by HL7 International / Patient Care. This guide is not an authorized publication; it is the continuous build for version 1.0.1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of and changes regularly. See the Directory of published versions

Privacy and Security Considerations

Page standards status: Trial-use

While exercise-related information is typically less sensitive than most healthcare information, it is still considered to be protected healthcare information. As such, the data sharing enabled by this IG requires authentication, authorization, and secure transport.

Implementers of this IG are expected to adhere to the same security and privacy rules as are defined in the Gravity IG. Gravity allows several alternative authentication mechanisms, however in the near-term, implementers of this IG are strongly encouraged to use the SMART App Launch mechanism for user-mediated interactions (e.g. interactions from a Patient Engagement system or Light Service Provider) and SMART Backend Services for system-to-system interactions that do not necessarily involve human intervention (e.g. between a Care Manager and a Full Service Provider).

Serious Asian lady in pink boxing gloves in studio


Many of the exercise professionals and exercise organizations that will be Service Providers in this IG fall outside the bounds of "Covered Entities" from a HIPAA perspective. As such, consent will typically be required for referrals, plans, goals, observations, etc. to be shared from clinical systems. In addition, consent will often be needed if patient information is to be shared with a patient's caregivers. It is the responsibility of each organization and provider to ensure that consent is gathered when necessary and that disclosures are conducted in compliance with the consents on file.

This specification does not set expectations for sharing consent information because, at present, it does not envision the use of intermediaries and that would be the primary reason why other systems would need to have an awareness of what consent(s) had been granted. For implementers who do make use of intermediaries, conveying consent as described by the Gravity SDOH IG should be workable.

Shared or Delegated Access

In implementations where caregivers are involved in accessing and/or reporting patient information via Patient Engagement systems, those systems SHOULD be designed to allow each caregiver to authenticate independently and track what information is accessed, created, or updated by which individual. Unless both Care Managers and Service Providers maintain a shared or synchronized authorization server that tracks patient delegated access, such users will need to be configured independently for each system they have access to.

Access Management

This specification relies on RESTful searches to allow retrieval of data from other systems. When a Service Provider searches for observations, goals, plans, etc. on a Care Manager, it is unlikely that they will (or should) have access to all data available. It is the responsibility of all systems acting as a data source to ensure that the data consumer only has access to the patient records and the data from within those records that is appropriate for the type of care they are offering. In some cases, that may include information beyond what is defined in this IG. For example, it may be appropriate (with patient consent) to disclose to an exercise professional that a patient is taking an ACE inhibitor, is diabetic, etc. It is up to organizational policy, in conjunction with regulation and patient preferences, to determine what data should be made available. As discussed in the Design section, Categories may prove to be a helpful mechanism to assist in filtering, but they are not the only option, and may not be sufficient for all filtering that needs to be performed.