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 https://github.com/HL7/physical-activity/ and changes regularly. See the Directory of published versions

Resource Profile: PA Task for Referral Management

Official URL: http://hl7.org/fhir/us/physical-activity/StructureDefinition/pa-task-for-referral-management Version: 1.0.1
Standards status: Trial-use Maturity Level: 2 Computable Name: PATaskForReferralManagement

Represents a request for fulfillment of a physical activity-related referral or order and supports management of the same.

Used as part of the workflow documented here. This is distinct from the Patient Task profile which is used to make requests of patients rather than providers.

Usage:

  • This Resource Profile is not used by any profiles in this Implementation Guide

Formal Views of Profile Content

Description of Profiles, Differentials, Snapshots and how the different presentations work.

This structure is derived from Task

NameFlagsCard.TypeDescription & Constraintsdoco
.. Task C0..*TaskA task to be performed
pa-taskrm-1: Task.statusReason is required if Task.status is 'rejected', 'on-hold', 'cancelled', or 'failed' and is not permitted otherwise.
... implicitRules 0..0
... modifierExtension 0..0
... status SC1..1codedraft | requested | received | accepted | +
Binding: PA Task Fulfillment Status (required)
.... text S0..1stringPlain text representation of the concept
... businessStatus 0..1CodeableConceptE.g. "Specimen collected", "IV prepped"
.... text S1..1stringPlain text representation of the concept
... intent 1..1codeorder
Required Pattern: order
... priority S0..1coderoutine | urgent | asap | stat
... code 0..1CodeableConceptTask Type
Required Pattern: At least the following
.... coding1..*CodingCode defined by a terminology system
Fixed Value: (complex)
..... system1..1uriIdentity of the terminology system
Fixed Value: http://hl7.org/fhir/CodeSystem/task-code
..... code1..1codeSymbol in syntax defined by the system
Fixed Value: fulfill
... focus S1..1ReferenceRest(PA Service Request)What task is acting on
... for S1..1ReferenceRest(US Core Patient Profile)Beneficiary of the Task
... authoredOn S1..1dateTimeTask Creation Date
... requester S1..1ReferenceRest(US Core Practitioner Profile S | US Core PractitionerRole Profile S | US Core Organization Profile S)Who is asking for task to be done
... owner S1..1ReferenceRest(US Core Practitioner Profile S | US Core PractitionerRole Profile S | US Core Organization Profile S)Responsible individual
... reasonCode
.... text S1..1stringPlain text representation of the concept
... note S0..*AnnotationComments made about the task
.... author[x] S1..1ReferenceRest(US Core Practitioner Profile S | US Core Organization Profile S)Individual responsible for the annotation
.... time S1..1dateTimeWhen the annotation was made
.... text S1..1markdownThe annotation - text content (as markdown)
... Slices for output 0..*BackboneElementInformation produced as part of task
Slice: Unordered, Open by pattern:type, type:value
.... output:All Slices Content/Rules for all slices
..... modifierExtension 0..0
.... output:PerformedActivityType S0..*BackboneElementInformation produced as part of task
..... type 1..1CodeableConceptLabel for output
Required Pattern: At least the following
...... coding1..*CodingCode defined by a terminology system
Fixed Value: (complex)
....... system1..1uriIdentity of the terminology system
Fixed Value: http://hl7.org/fhir/us/sdoh-clinicalcare/CodeSystem/SDOHCC-CodeSystemTemporaryCodes
....... code1..1codeSymbol in syntax defined by the system
Fixed Value: resulting-activity
..... value[x] S1..1CodeableConcept SResult of output
...... text S1..1stringPlain text representation of the concept
.... output:PerformedActivityReference S0..*BackboneElementInformation produced as part of task
..... type 1..1CodeableConceptLabel for output
Required Pattern: At least the following
...... coding1..*CodingCode defined by a terminology system
Fixed Value: (complex)
....... system1..1uriIdentity of the terminology system
Fixed Value: http://hl7.org/fhir/us/sdoh-clinicalcare/CodeSystem/SDOHCC-CodeSystemTemporaryCodes
....... code1..1codeSymbol in syntax defined by the system
Fixed Value: resulting-activity
..... value[x] S1..1ReferenceRest S(PA Intervention Report S | Resource)Result of output

doco Documentation for this format

Terminology Bindings (Differential)

PathConformanceValueSetURI
Task.statusrequiredPATaskFulfillmentStatus
http://hl7.org/fhir/us/physical-activity/ValueSet/pa-task-status
from this IG

Constraints

IdGradePath(s)DetailsRequirements
pa-taskrm-1errorTaskTask.statusReason is required if Task.status is 'rejected', 'on-hold', 'cancelled', or 'failed' and is not permitted otherwise.
: statusReason.exists() = (status='rejected' or status='on-hold' or status='cancelled' or status='failed')

 

Other representations of profile: CSV, Excel, Schematron

Notes:

Task status

This profile supports a number of Task.status codes. The referral fufillment task status diagram on the Workflow page describes the relationships between the states. The table below provides additional detail on each state, as well as rules around its use.

Status Initiator Task Reason? Meaning Rules
draft Care Manager No This will rarely, if ever, appear. It would be relevant if a provider system has begun the work of deciding who to route a referral to, but has not yet actually clicked 'send' to make the request. Service Providers SHALL either filter out or ignore Tasks in this state.
requested Care Manager No Indicates that fulfillment is being requested and no response has yet been provided. This SHALL be the initial status of the Task when it is first released for consideration. Once the Task has left this status, it SHOULD NOT return to this status, though in cases of an erroneous transition, a quick return to this status might be appropriate.
accepted Service Provider No Indicates that the Service Provider has agreed to perform the actions described in the referral ServiceRequest.
rejected Service Provider Yes Indicates that the Service Provider does NOT agree to perform the actions described in the referral ServiceRequest. It is possible that, based on the reason for the refusal, the underlying ServiceRequest might be revised (or a new one created) and a new Task seeking fulfillment could be created for the same target Service Provider. This is a final state. When in this state, a Task.statusReason SHALL be provided explaining the refusal.
cancelled Care Manager Yes Indicates the request for fulfillment has been terminated. This occurs when the authorization for the action has been revoked. This should happen only in exceptional circumstances, for example if the patient's clinical status changes in a way that would make the ordered therapy inappropriate. A cancelled Task means the Service Provider should cease their interventions as soon as possible, though this may not be instantaneous. A Care Manager should always make sure the patient is aware when an existing referral is being cancelled. Cancelled is a terminal state. If there is subsequently a decision to seek continuation of an existing ServiceRequest after the Task has been cancelled, a new Task will be needed - which would then be accepted or rejected as usual.
in-progress Service Provider No Used to distinguish that the requested work has actually begun. E.g. The patient has started attending classes, the patient has come to their first consultation, etc. Not all systems will track this information.
on-hold Service Provider Yes Indicates that work on the service(s) requested by the referral has been temporarily paused. For example, the patient has gone on vacation, the patient has suffered an injury that requires a break from activity, etc. Communicating this is generally only relevant when the pause will significantly impact when the service might have been expected to complete and/or will result in a noticable change to the ongoing observations being communicated to the Care Manager to allow them to monitor progress. 'on-hold' is a temporary state. If the Service Provider determines after putting the Task on-hold that it will not resume, then the Task SHALL be transitioned to 'failed'.
failed Service Provider Yes Indicates that the action(s) requested by the referral were attempted but could not be successfully completed. For example, the patient stopped attending a program, the exercise professional determined their services were not a good match for the patient's needs, etc. Failed is a terminal state. In order to solicit further action (from the same Service Provider or someone else, a new Task is needed, which will go through the Accept/Reject proecess the same as any other.
completed Service Provider No Indicates that the Service Provider believes they have completed all of the requested actions asked for as part of the ServiceRequest. No further action is expected to be taken as part of the referral, though the Service Provider and the patient might still have further interaction through their own volition. It is up to the Care Manager to decide whether to update the ServiceRequest to 'completed'. However, if further action is desired, a new Task will need to be initiated.
entered-in-error Care Manager No Indicates that the Task record should never have existed. E.g. A record was accidentally created against the wrong patient, against an unapproved order, against a completed order, etc. Service Providers SHALL NOT filter out 'entered-in-error' Tasks so that they can see if a Task they've previously received gets marked as 'entered-in-error'. If this occurs, then they SHOULD cease service as soon as possible and, if they opt to continue service, understand that it is not considered to be 'authorized' and may therefore have limitations with respect to insurance coverage. In all other circumstances, Service Providers SHALL otherwise ignore 'entered-in-error' Tasks.

General Notes:

  • When reading Task resources from another system, all statuses must be supported. However, when updating Task status, Service Providers only need to be able to support those marked in bold. The remaining codes only need to be used when they are appropriate for the Service Provider's architecture.