This section of the specification talks about the different types of systems and the specific workflows covered by this implementation guide.

NOTE: Additional systems and/or workflows may be introduced in the future. E.g. anonymized reporting, quality metric assessment, etc.

Actors

There are three specific types of systems that cooperate to help manage and improve patient physical activity levels. They are:

• Care Managers are electronic health record or similar systems used by physicians, social workers, or others who have general responsibility for care of the patient. These are the systems that will typically perform initial data capture, whose users may identify an issue with physical activity level, and will coordinate any interventions to improve physical activity levels.
• Patient Engagement Apps are systems that will be used by patients and/or their caregivers to capture data to share with clinicians and physical activity specialists. They will also allow patients and their representatives to see and potentially update goals and plans of care related to physical activity. (Caregivers might include relatives, neighbors, friends, or anyone else acting in support of the patient based on their personal relationship.)
• Service Providers are systems used by physical activity professionals, such as personal trainers, community fitness centers, etc. who can provide services to patients to enhance and maintain their levels of physical activity. In this IG, there are two types of Service Provider systems - Full Service Providers which have their own FHIR server endpoint and Light Service Providers, which do not.

In some cases, a Service Provider may delegate responsibility for interventions, in which case they will themselves also behave as a Care Manager.

NOTE: Not all scenarios will necessarily involve all three types of systems. For example:

• Some patients will not have access to (or interest in using) a monitoring app and communication will solely be between the Care Manager and Service Provider systems.
• Some patients may not be interested in (or require) a referral to external exercise professionals and all interactions will take place solely between the Care Manager and Patient Engagement Apps.
• Some patients will self-refer for care and will not have a general practitioner or other clinician who is interested and/or capable of receiving data and interactions will be limited to communications between Patient Engagement Apps and Service Providers.
• In some cases, Care Managers will act alone and not interact with other systems, though exposing their records over FHIR interfaces will still enable care transitions and other data sharing.

Payers as an actor

In addition to the three actor types above, payer systems are also relevant in this space, as they may provide coverage for services offered by Service Providers and may need measures reported by any of the other two system types. However, interaction with payers is outside the scope of this implementation guide. Implementers interested in also supporting interoperability with payer systems related to physical activity are encouraged to examine the various Da Vinci implementation guides, in particular:

• Coverage Requirements Discovery (CRD), Documentation, Templates, and Rules (DTR), and Prior Authorization Support (PAS) which, together, support capturing and sharing any data needed to support post-acute order submission, prior authorization, and claims submission processes.
• Clinical Documentation Exchange (CDex) which allows payers to solicit information from clinical information systems.

While this IG doesn't define interactions with payer systems, the data standardization of physical activity measures and related referrals will improve interoperability for payer processes. In some cases, the RESTful interfaces defined in this guide that support sharing data with clinicians, patients, and service providers may be extended (with permission and oversight of appropriate access) to allow direct query by payer systems.

Workflows

This implementation guide covers two main workflows: Care planning and Referral management. Both are heavily informed by the workflows described in the Gravity SDOH IG. However, these flows and their associated artifacts have been adapted to reflect the needs of the physical activity space.

NOTE: These workflows will frequently refer to the 'patient' being involved in the process - as a source of data, as a participant in care planning, as a participant in interventions, etc. In almost all circumstances, this should be read as "the patient and/or their care giver(s)". Information might be gathered from parents, guardians, or any other trusted person who has responsibility for the patient's care and/or are otherwise supporting the patient in meeting their healthcare objectives. This can even include caregivers being the focus of interventions, for example receiving training so they can better assist the patient in the execution of their exercise plan. Please also review the guidance from the Design Considerations page, particularly the sections on Electronic Sharing with Patients, Patient Data Management and Patient Caregivers.

Physical Activity Care Planning

Care planning around physical activity follows a 'loop' pattern similar to all clinical care planning:

1. The patient is assessed to determine if there is an issue to be addressed.
2. If an issue is found, the care provider works with the patient to determine a goal or set of goals to improve the current state and a plan to meet them.
3. The care provider and patient then work together to come up with a plan to meet those goals, possibly involving external interventions.
4. From time to time, the care provider and patient touch base to evaluate progress and, as necessary, adjust the plan and goals.

This may continue until the issue is deemed 'resolved' or until the patient determines they no longer wish to address the issue. Alternatively, it may continue indefinitely, even when a target state has been reached, just to monitor and ensure ongoing success.

Breaking these steps up into more detail:

Issue identification

Some models might refer to this as 'diagnosis', but that word can be somewhat charged with connotations around 'who' is permitted to make such decisions. In the context of this implementation guide, no specific rules are established around who 'authorized' to determine that a patient's level of physical activity is problematic. However, some insurance plans or programs may introduce such expectations to authorize payment for interventions.

U.S. Health and Human Services provides the following minimum recommendations for physical activity for Americans:

Age group	Target activity level
6-17 years	60 minutes/day moderate-vigorous activity
Adults	150-300 minutes/week moderate or 75-150 minutes/week of vigorous activity

However, the determination of when intervention is appropriate is left up to care providers and patients to determine. Comorbidities such as diabetes, hypertension, obesity, cardiac risk factors, etc. may all come into play, either indicating that higher target levels or sometimes lower target levels are appropriate. Payers may set rules for what criteria need to be met for interventions to be covered under specific plans.

One key part of the preceding paragraph is that care providers and patients together make a determination as to whether a problem exists and requires intervention. The cycle of setting goals, planning steps to achieve those goals and monitoring progress can only occur if the patient is on-board. Absent that, a clinician can only note their concern in the chart, counsel the patient, and follow up on subsequent visits to see if readiness may have changed.

Typically the identification of an issue will begin with the capture of an exercise vital sign using the days/week, min/day, min/week, and strength days/week profiles. This information might be recorded directly by the patient or by the care provider based on information solicited from the patient or one of the patient's caregivers.

If the care provider believes the patient's exercise level is problematic for their long-term health, they might choose to record a Condition in the record indicating their concern and to act as a focal point for subsequent plans, goals, and interventions.

In this IG, creation or updating of a Condition is always done internally by a Care Manager. However, external systems (i.e. Service Providers and Patient Engagement systems can search for and retrieve these records.

Planning

The planning step involves coming to agreement with the patient about what their target should be for exercise frequency and duration, possibly with sub-targets along the way, as well as target timeframes for meeting those objectives. Then the two need to agree on what steps will best help the patient to get their exercise levels into the desired duration, frequency, and intensity target range. Historically, this plan would typically have been captured as encounter notes within the care provider's system. However, this guide sets higher expectations.

To ensure appropriate ongoing coordination between care provider, patient, and exercise professionals, both the plan and any associated goals need to be shareable in a standardized manner. The exercise plan is a simple structure that captures the date, patient, author and a textual narrative describing the proposed plan the patient will follow. Systems are free to capture and share additional discrete information if they wish, but only the minimum set of data described in this IG's profile needs to be supported. In some cases, the plan shared may carry more information than just information about exercise. However, the plan SHOULD not contain any information that would be inappropriate for exercise professionals or others involved in the patient's exercise plan to see.

The exercise plan will almost always be accompanied by physical activity goals. These express targets for the patient in a computable manner such that Patient Engagement systems can render a patient's progress against their goals and all participants in the patient's care can have a shared understanding of what goals have been met, what goals are still being worked towards and what is intended for the future.

In this IG, the expectation is that both the exercise plan and its associated goals are stored on either the Care Manager or Service Provider, depending on who is most actively managing the plan of care. (In some cases, both systems might maintain their own records.) At minimum, Service Provider and Patient Engagement systems will be able to query and monitor the plan and goals. In some environments, they may also be able to make changes to plans and goals, such as adjusting status, adding comments or otherwise indicating progress.

Referral Management

As discussed on the interventions page, referrals are the mechanism by which a Care Manager authorizes interventions to be performed by a physical activity professional. The referral record is created and maintained exclusively on the Care Manager system. However, Service Provider and Patient Engagement systems will have query access to the record.

The referral process generally involves the interplay of three different resources, though not all three will necessarily always come into play:

Figure 2: Referral Resources

ServiceRequest:

• The official 'referral'. It represents the 'authorization' for a patient to receive a particular type of care.
• To create a 'referral', the author must have appropriate training/licensure.
• Existence of a referral might be necessary for service to be performed and/or for insurance coverage to exist. However, referrals are not always needed.
• The status of the referral is generally either 'active', 'cancelled' or 'completed'. A referral doesn't track what's happening with execution.
• The referral generally can't be updated by anyone other than the author.
• A referral *might* be targeted to a specific performer. If so, then only that one performer has authorization. To change the performer, a new referral is needed.
• While we might use the term "self-referral" for a patient-initiated service, there is no ServiceRequest in this case - there is no FHIR representation of the patient asking for the service.

Task:

• Asks a specific service provider if they can fulfill a referral.
• Gives the service provider the ability to 'accept' or 'refuse' - and if they accept, to eventually indicate successful completion or failure.
• Could be multiple Tasks for one ServiceRequest - because first few go to service providers who refuse or cancel prior to completion.
• Tasks can be updated by both the referral initiator (Care Provider) - e.g. to cancel, as well as the service provider - e.g. to update status.
• Task is also how the service provider can indicate progress and link to any produced results (interim or final).
• Task is not needed if the referral solicitation process is manual (e.g. the patient shopping around a paper referral trying to find someone who can perform the service)
• Even if the referral itself was directed, Task is necessary to give the ability to accept or refused, convey progress and link to results.

DiagnosticReport:

• For this IG, this is where the 'results' of the referral are represented
• This might be as short as a single paragraph or could be many pages. For the purposes of this IG, it will always be a PDF.
• Technically, there doesn't need to be a ServiceRequest for a DiagnosticReport to be created, but it would be unusual for a service provider to write a report without a referral
• A report is optional. Not all referrals will result in a report.

Initiating referrals

Referrals are typically initiated in one of two ways:

• A clinician or other professional determines that a patient's physical activity level is too low and that intervention by an exercise professional is likely to help improve the patient's activity level.
• A patient is already receiving treatment by an exercise professional and the professional indicates that, with a referral, some portion of the services being provided might be covered by insurance. The patient reaches out to their clinician who, after verifying the patient meets eligibility criteria for referral, may refer for the services currently being rendered or for others.

Most exercise programs and exercise-related services are not 'gated'. I.e. no referral is needed to access the services. In these cases, the primary purpose of a referral is to enable funding to flow from insurance coverage. However, certain specialized programs, such as those related to post-cancer or cardiac rehabilitation might require a referral both to ensure the program is appropriate for the patient and that the patient has sufficiently recovered that beginning an exercise program is appropriate. In these cases, referrals might be sought even if the patient does not have coverage that would support reimbursement.

Managing Referrals in FHIR

The Task is what really drives referral workflow. Typically referrals will not be directed to a particular service provider. Instead, Tasks will be used to solicit providers who are willing to perform a needed intervention (possibly with guidance from the patient around their preferences). Service Providers will use a subscription to monitor for new 'requested' Tasks assigned to them and will update the Tasks to indicate acceptance and eventually update the status to 'completed', possibly with a link to a report showing final outcomes.

However, in addition to this 'happy' path, the Task is also used to document other workflows. These include:

• Changing the Task.status to 'rejected' and populating Task.reason. E.g. the service provider is not accepting new patients.
• After initially 'accepting' the task, changing the Task.status to 'cancelled' and populating Task.reason. E.g. the service provider has become unavailable and is no longer able to satisfy the referral.
• Changing the Task.status to 'on-hold' and populating Task.reason. E.g. the patient has been hospitalized or gone on vacation.
• Changing the Task.status to 'failed' and populating the Task.reason. E.g. the patient has chosen to discontinue the training program, or the Care Manager has decided that the referral is no longer appropriate/necessary.
• Changing the Task.businessStatus to communicate some degree of internal progress. E.g. "completed intake session", "Developed workout plan", "'fading out' supports", etc. (There is no requirement to do this, but it helps ensure everyone is on the same page.)
• Adding Task.note repetitions capturing progress against the Task.

The following diagram shows the expected state transitions expected in this implementation guide. Those with heavier lines must be supported by all systems. Those with lighter lines may occur, but Service Providers are not required to support them for their own workflows.

NOTE: Not shown in this diagram is the 'entered-in-error' status which is an allowed transition from all states.

For additional information about each of the possible states, when they are appropriate, and rules around their use, refer to the table in the notes section of the Task profile.

Subscription Process

Subscription is the mechanism by which the systems other than the system on which a Task is stored become aware of the fact that a Task has been created or updated. The Gravity IG describes the subscription process here.

For the purposes of this guide, there is no requirement for Patient Engagement and Light Service Providers will actually create Subscription instances. Instead, the Care Manager and Full Service Providers SHOULD allow manual establishment of a referral with notifications to the preferred email or SMS (see below) address. The email or SMS message will provide the prompt for the user to launch their system and query for new Tasks.

Based on implementer feedback, this IG defines an additional customChannelType code that can be used to deliver notifications via SMS device rather than email or rest-hook. Such notifications SHALL only include a short human-readable message indicating the subscription id and a short message indicating that updated content is available. Subscription.contentType SHALL be "omit" for both security as well as bandwidth reasons. The SMS message SHALL NOT actually include a subscription notification Bundle. The use of this approach is experimental, and feedback is welcome. The code to use is found here. The endpoint will be populated with the phone number to send the SMS message to, expressed in compliance with rfc3966 - i.e. "tel:" followed by the phone number digits.

While Gravity supports subscriptions to monitor for changes to both Tasks and ServiceRequests, in this IG, only Tasks need to be supported. The expectation is that if a ServiceRequest is cancelled, the Care Manager will cancel the associated Task. If the ServiceRequest is modified, the Care Manager will add a note to the Task. This will minimize the complexity of the subscription process.

Closing the Loop

Once a referral has been issued and accepted, there is a need to communicate progress and status back to the initiating practitioner. There are three main mechanisms for accomplishing this: using Task status, ongoing measurements, and diagnostic reports. Using Task status is further discussed in the Design section.

Using measurements

Even without looking at status, a Care Manager system that opts to receive or access a patient's physical activity measures can keep tabs on whether the patient's physical activity level is changing. Supporting measures capturing activity-specific exercise information can even allow inference in programs (through regular performance of specific activities). This is true even in the absence of a referral - a practitioner who only provides counselling around increasing physical activity can have access to information about activity levels and types and get insight into how well the patient is adhering to the agreed plan. In most cases, this review would happen at the time of the next visit, though a proactive practitioner might opt to monitor how the patient is doing between visits so that they can reach out to provide support/adjustment if needed.

Using diagnostic reports

The PA Intervention Report profile allows the use of the DiagnosticReport resource to convey a summary of the intervention(s) performed by the Service Provider. These would typically be created at the completion of the activities required by the referral, though an instance could also be created at intermediate points. This resource allows conveying much more information than just 'status' and observations. The service provider can convey impressions, recommendations, obstacles, degree of compliance, strategies used, level of success, motivation, etc.

Because the profile is essentially a text blob, there is great flexibility in how much information is provided and how it is organized. At present, this IG doesn't set specific expectations for what must appear in the report. Realistically, the type of information will vary depending on the type of intervention, the length of patient engagement, and any documentation requirements imposed by payers. It is possible that future versions of this IG will allow tracking more discrete information about the interventions performed if implementation experience shows that discrete information is useful and can reasonably be captured as part of provider workflows.

Billing details

Another part of 'closing the loop' is the process of billing for services provided - in those cases where insurance coverage exists. This step is outside the scope of this IG. Coverage could be provided in different ways:

• On a fee-for-service basis for delivering specific interventions.
• On a contractual basis where a service provider is paid for delivering a program and reimbursed based on the number of patients who participate.
• As part of a captitated payments program where physical activity services are included as part of set of types of care covered by a bulk payment for each patient for a specific period.
• Others?

In the U.S., the claims submission process will typically leverage the X12 standard with billing codes dependent on the mechanism by which coverage is provided. While this guide does not define recommended billing codes and payers will determine which codes they accept, implementers and payers may find this set maintained by the Physical Activity Alliance a useful starting point. It is possible that new codes will need to be defined to better support the types of services that are relevant to enhancing patient physical activity.

Capturing Feedback and patient engagement

Another area where this implementation guide borrows from Gravity SDOH is in the use of Questionnaires to solicit feedback from patients (and their caregivers) about satisfaction with a service provider. Patient satisfaction with their providers is a key indicator of their long-term success in improving and sustaining their physical activity levels. Gravity also uses the same Task-based mechanism to prompt patients to contact specific service providers, to review documentation, or to perform other ad-hoc actions.

This IG leverages the same SDOHCC Task for Patient profile because the requirements are the same and there is nothing in the profile that makes it specific to social determinants of health. The providers the patient is asked to contact, the literature they're asked to review, and the types of feedback they're asked to provide may differ. However, the interoperability mechanisms for requesting the actions and capturing and monitoring the responses will be the same.

The workflow is also the same. The Patient Engagement app monitors for Tasks assigned to that patient and retrieves them and displays them to the patient, then updates the Task with the information from the completed task.

Use of this functionality is not required. It is simply available where Care Managers and/or Service Providers feel that soliciting patient feedback is useful and where an electronic mechanism of doing so is more useful than using traditional paper-based approaches.