FHIR CI-Build

This is the Continuous Integration Build of FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions icon

12.23 Resource PlanDefinition - Content

Clinical Decision Support icon Work GroupMaturity Level: 4 Trial UseSecurity Category: Business Compartments: No defined compartments

This resource allows for the definition of various types of plans as a sharable, consumable, and executable artifact. The resource is general enough to support the description of a broad range of clinical and non-clinical artifacts such as clinical decision support rules, order sets, protocols, and drug quality specifications.

12.23.1 Scope and Usage

This resource is a definition resource from a FHIR workflow perspective - see Workflow, specifically Definition.

A plan definition is a pre-defined group of actions to be taken in particular circumstances, often including conditional elements, options, and other decision points. The resource is flexible enough to be used to represent a variety of workflows, as well as clinical decision support and quality improvement assets, including order sets, protocols, and decision support rules.

PlanDefinitions can contain hierarchical groups of action definitions, where each action definition describes an activity to be performed (often in terms of an ActivityDefinition resource), and each group defines additional behavior, relationships, and applicable conditions between the actions in the overall definition.

In addition to describing what should take place, each action in a plan definition can specify when and whether the action should take place. For when the action should be taken, the trigger element specifies the action should be taken in response to some trigger occurring (such as a particular point in a workflow being reached, or as the result of a prescription being ordered). For whether the action should be taken, the condition element can be used to provide an expression that evaluates to true or false to indicate the applicability of the action to the specific context.

The process of applying a PlanDefinition to a particular context typically produces request resources representing the actions that should be performed, grouped within a RequestOrchestration to capture relationships between the resulting request resources.

Each ActivityDefinition is used to construct a specific resource, based on the definition of the activity and combined with contextual information for the particular patient that the plan definition is being applied to.

As with the ActivityDefinition, a PlanDefinition may provide information about how to transform the activity to a specific intent resource, either by specifying a StructureMap that can be used to perform the transformation completely, or by specifying values for specific elements of the resulting resource using dynamicValue elements in the action.

Note that these mechanisms are provided on both the ActivityDefinition and the PlanDefinition to allow both reusable transformation descriptions, as well as customization of those descriptions within specific contexts. As such, the transform descriptions specified on the PlanDefinition override transform descriptions defined on the ActivityDefinition.

Dynamic values within the definitions can be provided by specifying the expression directly, or by referencing an expression defined within a library. For more information on how to reference expressions within resources, refer to the Using Expressions topic.

As an example, the Low Suicide Risk example order set from the Clinical Decision Support Knowledge Artifact Specification can be represented using the PlanDefinition and ActivityDefinition structures: Low Suicide Risk Example Order Set.

In addition to the representation of PlanDefinitions, the $apply operation allows PlanDefinitions to be applied to a specific context such as a patient, practitioner, or institution. For Order Sets specifically, this operation is expected to place the orders defined by the order set, consistent with the service functional requirements defined by the Order Set specification icon.

Plan definitions also allow for the definition of goals. Actions in the plan definition can then reference these goals in order to indicate that the action should be taken in fulfillment of the goal. Note that the goal-relationship extension can be used to describe relationships between goal definitions, and the satisfies-requirement extension can be used to indicate that the goal satisfies a particular requirement.

12.23.2 Boundaries and Relationships

The PlanDefinition resource is used to describe series, sequences, or groups of actions to be taken, while the ActivityDefinition resource is used to define each specific step or activity to be performed.

As the name implies, the PlanDefinition resource is strictly definitional. It does not represent the intention to take any action, nor does it represent that any actions have been taken. Rather, the resource provides a definition that can be applied in the appropriate circumstances. When the plan definition is applied, the result will in general be a set of actions that should be (or potentially even have been) performed.

Note that the PlanDefinition still has action-level information, as well as a reference to an ActivityDefinition. The action-level information defined in the PlanDefinition itself is used to describe how the actions are related to each other within the plan, where the ActivityDefinition contains only information about the activity itself. In addition, there is some overlapping information that allows the resources to be used independently, or in combination. See the Applying a PlanDefinition section for more information.

12.23.3 References to this Resource

12.23.4 Resource Content

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. PlanDefinition TU DomainResource The definition of a plan for a series of actions, independent of any specific patient or context
+ Warning: Name should be usable as an identifier for the module by machine processing applications such as code generation
+ Warning: goalid should reference the id of a goal definition
+ Warning: targetId should reference the id of an action

Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
Interfaces Implemented: MetadataResource
... url ΣC 0..1 uri Canonical identifier for this plan definition, represented as a URI (globally unique)
+ Warning: URL should not contain | or # - these characters make processing canonical references problematic
... identifier Σ 0..* Identifier Additional identifier for the plan definition

... version Σ 0..1 string Business version of the plan definition
... versionAlgorithm[x] Σ 0..1 How to compare versions
Binding: Version Algorithm (Extensible)
.... versionAlgorithmString string
.... versionAlgorithmCoding Coding
... name ΣC 0..1 string Name for this plan definition (computer friendly)
... title ΣT 0..1 string Name for this plan definition (human friendly)
... subtitle T 0..1 string Subordinate title of the plan definition
... type Σ 0..1 CodeableConcept order-set | clinical-protocol | eca-rule | workflow-definition
Binding: Plan Definition Type (Extensible)
... status ?!Σ 1..1 code draft | active | retired | unknown
Binding: PublicationStatus (Required)
... experimental Σ 0..1 boolean For testing only - never for real usage
... subject[x] 0..1 Type of individual the plan definition is focused on
Binding: Participant Resource Types (Extensible)
.... subjectCodeableConcept CodeableConcept
.... subjectReference Reference(Group | MedicinalProductDefinition | SubstanceDefinition | AdministrableProductDefinition | ManufacturedItemDefinition | PackagedProductDefinition)
.... subjectCanonical canonical(EvidenceVariable)
... date Σ 0..1 dateTime Date last changed
... publisher ΣT 0..1 string Name of the publisher/steward (organization or individual)
... contact Σ 0..* ContactDetail Contact details for the publisher

... description ΣT 0..1 markdown Natural language description of the plan definition
... useContext Σ 0..* UsageContext The context that the content is intended to support

... jurisdiction ΣXD 0..* CodeableConcept Intended jurisdiction for plan definition (if applicable)
Binding: Jurisdiction ValueSet (Extensible)

... purpose T 0..1 markdown Why this plan definition is defined
... usage T 0..1 markdown Describes the clinical usage of the plan
... copyright 0..1 markdown Use and/or publishing restrictions
... copyrightLabel T 0..1 string Copyright holder and year(s)
... approvalDate 0..1 date When the plan definition was approved by publisher
... lastReviewDate 0..1 date When the plan definition was last reviewed by the publisher
... effectivePeriod Σ 0..1 Period When the plan definition is expected to be used
... topic XD 0..* CodeableConcept E.g. Education, Treatment, Assessment
Binding: Definition Topic (Example)

... author 0..* ContactDetail Who authored the content

... editor 0..* ContactDetail Who edited the content

... reviewer 0..* ContactDetail Who reviewed the content

... endorser 0..* ContactDetail Who endorsed the content

... relatedArtifact 0..* RelatedArtifact Additional documentation, citations

... library 0..* canonical(Library) Logic used by the plan definition

... goal C 0..* BackboneElement What the plan is trying to accomplish

.... category 0..1 CodeableConcept E.g. Treatment, dietary, behavioral
Binding: Goal Category (Example)
.... description 1..1 CodeableConcept Code or text describing the goal
Binding: SNOMED CT Clinical Findings (Example)
.... priority 0..1 CodeableConcept high-priority | medium-priority | low-priority
Binding: Goal Priority (Preferred)
.... start 0..1 CodeableConcept When goal pursuit begins
Binding: Goal Start Event (Example)
.... addresses 0..* CodeableConcept What does the goal address
Binding: Condition/Problem/Diagnosis Codes (Example)

.... documentation 0..* RelatedArtifact Supporting documentation for the goal

.... target 0..* BackboneElement Target outcome for the goal

..... measure 0..1 CodeableConcept The parameter whose value is to be tracked
Binding: LOINC Codes (Example)
..... detail[x] 0..1 The target value to be achieved
...... detailQuantity Quantity
...... detailRange Range
...... detailCodeableConcept CodeableConcept
...... detailString string
...... detailBoolean boolean
...... detailInteger integer
...... detailRatio Ratio
..... due 0..1 Duration Reach goal within
... actor 0..* BackboneElement Actors within the plan

.... title T 0..1 string User-visible title
.... description T 0..1 markdown Describes the actor
.... option 1..* BackboneElement Who or what can be this actor

..... type 0..1 code careteam | device | group | healthcareservice | location | organization | patient | practitioner | practitionerrole | relatedperson
Binding: Action Participant Type (Required)
..... typeCanonical 0..1 canonical(CapabilityStatement) Who or what can participate
..... typeReference 0..1 Reference(CareTeam | Device | DeviceDefinition | Endpoint | Group | HealthcareService | Location | Organization | Patient | Practitioner | PractitionerRole | RelatedPerson) Who or what can participate
..... role 0..1 CodeableConcept E.g. Nurse, Surgeon, Parent
Binding: Action Participant Role icon (Example)
... action C 0..* BackboneElement Action defined by the plan

.... linkId 0..1 string Unique id for the action in the PlanDefinition
.... prefix 0..1 string User-visible prefix for the action (e.g. 1. or A.)
.... title T 0..1 string User-visible title
.... description T 0..1 markdown Brief description of the action
.... textEquivalent T 0..1 markdown Static text equivalent of the action, used if the dynamic aspects cannot be interpreted by the receiving system
.... priority 0..1 code routine | urgent | asap | stat
Binding: RequestPriority (Required)
.... code 0..1 CodeableConcept Code representing the meaning of the action or sub-actions
Binding: Action Code (Example)
.... reason 0..* CodeableConcept Why the action should be performed
Binding: Action Reason Code (Example)

.... documentation 0..* RelatedArtifact Supporting documentation for the intended performer of the action

.... goalId C 0..* id What goals this action supports

.... subject[x] 0..1 Type of individual the action is focused on
Binding: Participant Resource Types (Extensible)
..... subjectCodeableConcept CodeableConcept
..... subjectReference Reference(Group)
..... subjectCanonical canonical()
.... trigger 0..* TriggerDefinition When the action should be triggered

.... condition 0..* BackboneElement Whether or not the action is applicable

..... kind 1..1 code applicability | start | stop
Binding: Action Condition Kind (Required)
..... expression 0..1 Expression Boolean-valued expression
.... input C 0..* BackboneElement Input data requirements
+ Rule: Input data elements must have a requirement or a relatedData, but not both

..... title T 0..1 string User-visible title
..... requirement C 0..1 DataRequirement What data is provided
..... relatedData C 0..1 id What data is provided
.... output C 0..* BackboneElement Output data definition
+ Rule: Output data element must have a requirement or a relatedData, but not both

..... title T 0..1 string User-visible title
..... requirement C 0..1 DataRequirement What data is provided
..... relatedData C 0..1 string What data is provided
.... relatedAction C 0..* BackboneElement Relationship to another action

..... targetId C 1..1 id What action is this related to
..... relationship 1..1 code before | before-start | before-end | concurrent | concurrent-with-start | concurrent-with-end | after | after-start | after-end
Binding: Action Relationship Type (Required)
..... endRelationship 0..1 code before | before-start | before-end | concurrent | concurrent-with-start | concurrent-with-end | after | after-start | after-end
Binding: Action Relationship Type (Required)
..... offset[x] 0..1 Time offset for the relationship
...... offsetDuration Duration
...... offsetRange Range
.... timing[x] 0..1 When the action should take place
..... timingAge Age
..... timingDuration Duration
..... timingRange Range
..... timingTiming Timing
.... location 0..1 CodeableReference(Location) Where it should happen
.... participant 0..* BackboneElement Who should participate in the action

..... actorId 0..1 string What actor
..... type 0..1 code careteam | device | group | healthcareservice | location | organization | patient | practitioner | practitionerrole | relatedperson
Binding: Action Participant Type (Required)
..... typeCanonical 0..1 canonical(CapabilityStatement) Who or what can participate
..... typeReference 0..1 Reference(CareTeam | Device | DeviceDefinition | Endpoint | Group | HealthcareService | Location | Organization | Patient | Practitioner | PractitionerRole | RelatedPerson) Who or what can participate
..... role 0..1 CodeableConcept E.g. Nurse, Surgeon, Parent
Binding: Action Participant Role icon (Example)
..... function 0..1 CodeableConcept E.g. Author, Reviewer, Witness, etc
Binding: Action Participant Function (Example)
.... type 0..1 CodeableConcept create | update | remove | fire-event
Binding: Action Type (Extensible)
.... groupingBehavior 0..1 code visual-group | logical-group | sentence-group
Binding: Action Grouping Behavior (Required)
.... selectionBehavior 0..1 code any | all | all-or-none | exactly-one | at-most-one | one-or-more
Binding: Action Selection Behavior (Required)
.... requiredBehavior 0..1 code must | could | must-unless-documented
Binding: Action Required Behavior (Required)
.... precheckBehavior 0..1 code yes | no
Binding: Action Precheck Behavior (Required)
.... cardinalityBehavior 0..1 code single | multiple
Binding: Action Cardinality Behavior (Required)
.... definition[x] 0..1 Description of the activity to be performed
..... definitionCanonical canonical(ActivityDefinition | MessageDefinition | ObservationDefinition | PlanDefinition | Questionnaire | SpecimenDefinition)
..... definitionUri uri
.... transform 0..1 canonical(StructureMap) Transform to apply the template
.... dynamicValue 0..* BackboneElement Dynamic aspects of the definition

..... path 0..1 string The path to the element to be set dynamically
..... expression 0..1 Expression An expression that provides the dynamic value for the customization
.... action 0..* see action A sub-action

... asNeeded[x] Σ 0..1 Preconditions for service
Binding: SNOMED CT Medication As Needed Reason Codes (Example)
.... asNeededBoolean boolean
.... asNeededCodeableConcept CodeableConcept

doco Documentation for this format icon

See the Extensions for this resource

 

Additional definitions: Master Definition XML + JSON, XML Schema/Schematron + JSON Schema, ShEx (for Turtle) , the spreadsheet version & the dependency analysis

12.23.4.1 Terminology Bindings

Path ValueSet Type Documentation
PlanDefinition.versionAlgorithm[x] VersionAlgorithm Extensible

Indicates the mechanism used to compare versions to determine which is more current.
PlanDefinition.type PlanDefinitionType Extensible

The type of PlanDefinition.
PlanDefinition.status PublicationStatus Required

The lifecycle status of an artifact.
PlanDefinition.subject[x] ParticipantResourceTypes Extensible

All Resource Types that represent participant resources
PlanDefinition.jurisdiction JurisdictionValueSet Extensible

This value set defines a base set of codes for country, country subdivision and region for indicating where a resource is intended to be used.

Note: The codes for countries and country subdivisions are taken from ISO 3166 icon while the codes for "supra-national" regions are from UN Standard country or area codes for statistical use (M49) icon.
PlanDefinition.topic DefinitionTopic Example

High-level categorization of the definition, used for searching, sorting, and filtering.
PlanDefinition.goal.category GoalCategory Example

Example codes for grouping goals to use for filtering or presentation.
PlanDefinition.goal.description SNOMEDCTClinicalFindings Example

This value set includes all the "Clinical finding" SNOMED CT icon codes - concepts where concept is-a 404684003 (Clinical finding (finding)).
PlanDefinition.goal.priority GoalPriority Preferred

Indicates the level of importance associated with reaching or sustaining a goal.
PlanDefinition.goal.start GoalStartEvent Example

Identifies types of events that might trigger the start of a goal.
PlanDefinition.goal.addresses ConditionProblemDiagnosisCodes Example

Example value set for Condition/Problem/Diagnosis codes.
PlanDefinition.goal.target.measure LOINCCodes (a valid code from LOINC icon) Example

This value set includes all LOINC codes
PlanDefinition.actor.option.type ActionParticipantType Required

The type of participant for the action.
PlanDefinition.actor.option.role ActionParticipantRole icon Example

Either a practitioner role or a relationship type. Note from UTG import - may have been a temporary entry that subsequently disappeared from the FHIR source; unable to locate. Version set to 0.1.0
PlanDefinition.action.priority RequestPriority Required

Identifies the level of importance to be assigned to actioning the request.
PlanDefinition.action.code ActionCode Example

Provides examples of actions to be performed.
PlanDefinition.action.reason ActionReasonCode Example

Provides examples of reasons for actions to be performed.
PlanDefinition.action.subject[x] ParticipantResourceTypes Extensible

All Resource Types that represent participant resources
PlanDefinition.action.condition.kind ActionConditionKind Required

Defines the kinds of conditions that can appear on actions.
PlanDefinition.action.relatedAction.relationship ActionRelationshipType Required

Defines the types of relationships between actions.
PlanDefinition.action.relatedAction.endRelationship ActionRelationshipType Required

Defines the types of relationships between actions.
PlanDefinition.action.participant.type ActionParticipantType Required

The type of participant for the action.
PlanDefinition.action.participant.role ActionParticipantRole icon Example

Either a practitioner role or a relationship type. Note from UTG import - may have been a temporary entry that subsequently disappeared from the FHIR source; unable to locate. Version set to 0.1.0
PlanDefinition.action.participant.function ActionParticipantFunction Example

The function performed by the participant for the action.
PlanDefinition.action.type ActionType Extensible

The type of action to be performed.
PlanDefinition.action.groupingBehavior ActionGroupingBehavior Required

Defines organization behavior of a group.
PlanDefinition.action.selectionBehavior ActionSelectionBehavior Required

Defines selection behavior of a group.
PlanDefinition.action.requiredBehavior ActionRequiredBehavior Required

Defines expectations around whether an action or action group is required.
PlanDefinition.action.precheckBehavior ActionPrecheckBehavior Required

Defines selection frequency behavior for an action or group.
PlanDefinition.action.cardinalityBehavior ActionCardinalityBehavior Required

Defines behavior for an action or a group for how many times that item may be repeated.
PlanDefinition.asNeeded[x] SNOMEDCTMedicationAsNeededReasonCodes Example

This value set includes all clinical findings from SNOMED CT - provided as an exemplar value set.

12.23.4.2 Constraints

UniqueKeyLevelLocationDescriptionExpression
img cnl-0Warning (base)Name should be usable as an identifier for the module by machine processing applications such as code generationname.exists() implies name.matches('^[A-Z]([A-Za-z0-9_]){1,254}$')
img pld-0Rule PlanDefinition.action.inputInput data elements must have a requirement or a relatedData, but not bothrequirement.exists() xor relatedData.exists()
img pld-1Rule PlanDefinition.action.outputOutput data element must have a requirement or a relatedData, but not bothrequirement.exists() xor relatedData.exists()
img cnl-1Warning PlanDefinition.urlURL should not contain | or # - these characters make processing canonical references problematicexists() implies matches('^[^|# ]+$')
img pld-3Warning (base)goalid should reference the id of a goal definition%context.repeat(action).where((goalId in %context.goal.id).not()).exists().not()
img pld-4Warning (base)targetId should reference the id of an action%context.repeat(action).relatedAction.where((targetId in %context.repeat(action).id).not()).exists().not()

12.23.4.3 Applying a PlanDefinition

The following diagram illustrates the relationship between the PlanDefinition and ActivityDefinition resources, as well as a typical realization to RequestOrchestration and Request-pattern resources. The resources depicted on the left side of the arrow are definition resources, while the ones on the right side of the arrow are request resources, with the arrow representing the $apply operation:

relationship-between-action-and-activity-definition

The PlanDefinition and ActivityDefinition resources support the representation of a broad range of use cases including order sets, flow sheets, event-condition-action rules, clinical protocols, and research trials. To support this range of use cases, as well as the variability in capabilities of systems that use these types of artifacts, this specification is not prescriptive about exactly how these definitions are applied to produce request and event resources. However, the approach depicted above provides a general framework for the process, and the following steps provide more detail on the potential approach:

  1. Create a Bundle resource to contain the overall results of the realization.
  2. Create a RequestOrchestration resource focused on the Patient in context and linked to the PlanDefinition using the instantiatesCanonical element
  3. Set the first entry of the Bundle to the newly created RequestOrchestration resource
  4. Create Goal resources based on the goal definitions in the PlanDefinition
  5. Process each action element of the PlanDefinition

Processing for each action proceeds according to the following steps:

  1. Determine applicability by evaluating the applicability conditions defined for the element
  2. If the action is applicable, determine whether the action is a group or a single, atomic activity (does the action have child actions?)
  3. If the action is atomic, process according to the following steps:
    • Create an action element in the RequestOrchestration. If the element has a linkId, set the linkId> element of the new action to the same value. Note that for legacy PlanDefinitions, this action linking was accomplished with the id element, so for backwards compatibility, implementations may set the id element of the newly created action as well.
    • Apply the elements of the action to the corresponding elements of the newly created action in the RequestOrchestration such as title, description, textEquivalent, timing, and so on
    • Carry any start and stop conditions defined in the plan action forward to the request group action.
    • There are multiple possibilities for the definition element, but for the ones that specifically refer to another definitional resource, the behavior is:
      • ActivityDefinition:
        1. Create the target resource as described in the Applying an ActivityDefinition topic
        2. Reference the resulting resource in the resource element of the action and add the resource as an entry in the overall result Bundle.
        3. Set the intent of the target resource to option so that it is clearly indicated as part of a RequestOrchestration. Note that the ActivityDefinition/$apply operation will not necessarily produce the resource with this status, so this is an important step.
        4. Apply any overrides based on the elements of the action (see the section on Overlap below for details)
      • MessageDefinition: Construct a Message according to the definition given by the target
      • ObservationDefinition: Support the documentation of an Observation as defined by the target
      • PlanDefinition:
        1. Create a RequestOrchestration by applying the target PlanDefinition
        2. Reference the resulting resource in the resource element of the action and add it as an entry in the overall result Bundle.
        3. Set the intent of the RequestOrchestration to option so that it is clearly indicated as part of a RequestOrchestration.
        4. Apply any overrides based on the elements of the action such as title, description, and dynamicValue.
      • Questionnaire: Set the resource element of the action to the Questionnaire, indicating that the activity to be performed is filling out the given questionnaire.
      • SpecimenDefinition: Support the collection of a Specimen as defined by the target
  4. If the action is a group, determine which actions to process based on the behaviors specified in the group. Note that this aspect of the process may require input from a user. In these cases, either the choices made by the user can be provided as input to the process, or the process can be performed as part of a user-entry workflow that enables user input to be provided as necessary. If no behaviors are specified, default behavior for each behavior element is assumed (i.e. logical-group, all actions apply and are optional, no action is pre-selected, and all actions are assumed singular).

The parameters to the $apply operation are available within dynamicValue CQL and FHIRPath expressions as context variables, accessible by the name of the parameter prefixed with a percent (%) symbol. For example, to access the subject given to the apply, use the expression %subject. The value of the %subject context variable in a dynamicValue expression is determined using the current subject, as specified by the subject element on the PlanDefinition, current PlanDefinition.action, or ActivityDefinition.

In addition to the $apply operation parameters, the context variable %action can be used within the path element of a dynamicValue to specify the current action target. For example, to specify the path to the description element of the current action, use %action.description.

Note that result of this operation is transient (i.e. none of the resources created by the operation are persisted in the server, they are all returned as contained resources in the result). The result effectively represents a proposed set of activities, and it is up to the caller to determine whether and how those activities are actually carried out.

12.23.4.4 Event Resources

The ActivityDefinition resource may only specify Request resource types to facilitate considering user input as part of processing the result of any automated clinical reasoning processes. To support creation of event resources, such as Observations, RiskAssessments, and DetectedIssues, use a Task resource with the focus of the task set to the event resource to be created.

12.23.4.5 Overlap with ActivityDefinition

As noted in the Boundaries section, there is some overlap between the content that can be represented within the action element of a PlanDefinition, and the elements of the ActivityDefinition resource. This overlap allows for both resources to be used independently, as well as in combination. For example, a PlanDefinition may be used without any supporting ActivityDefinitions to describe a particular workflow, where it is sufficient to describe the actions simply as textual descriptions of what needs to take place. On the other hand, the PlanDefinition may be used together with ActivityDefinition to provide a detailed structural representation of the activities to be performed.

In general, where there is overlap, the elements from the PlanDefinition provide overriding behavior. Specifically, the following elements of action overlap with ActivityDefinition:

Element Behavior
title The title element in ActivityDefinition is the title of the activity "as defined", where the title element in PlanDefinition reflects the title in the scope of the plan.
description The description element in ActivityDefinition is the description of the activity "as defined", where the description element in PlanDefinition reflects the description in the scope of the plan.
code The code element in ActivityDefinition represents the meaning of the activity "as defined", where the code element in PlanDefinition represents the meaning in the scope of the plan.
documentation The documentation element in PlanDefinition represents additional documentation for the action specific to the scope of the plan, where the relatedArtifact element in ActivityDefinition provides documentation specific to the activity itself.
timing The timing element in ActivityDefinition represents timings associated within the activity itself, where the timing element in PlanDefinition represents the timing of the activity with respect to the plan and its other actions. When a timing is provided on both, the timing defined in the plan generally takes precedence.
asNeeded The asNeeded element allows pre-conditions to be associated with an action or activity. When asNeeded is specified on both, the value specified in the plan generally takes precedence.
participant The participant element in ActivityDefinition represents what type of actor is expected to perform the activity generally, where the participant element in PlanDefinition represents the type of actor that is expected to perform the activity in the context of the plan.
transform The transform element in ActivityDefinition describes the transformation of the definition to a request or event resource in general, where the transform element in PlanDefinition describes the transformation within the scope of the plan. When a transform is present in both, the transform in the plan takes precedence.
dynamicValue The dynamicValue element in ActivityDefinition defines values for elements of the target request or event resource in general, where the dynamicValue element in PlanDefinition defines values within the scope of the plan. When dynamic values are present in both, the dynamic values from the ActivityDefinition are applied first (in the order in which they appear on the ActivityDefinition), followed by the dynamic values from the PlanDefinition (in the order in which they appear on the PlanDefinition).

12.23.5 Search Parameters

Search parameters for this resource. See also the full list of search parameters for this resource, and check the Extensions registry for search parameters on extensions related to this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.

Name Type Description Expression In Common
composed-of reference What resource is being referenced PlanDefinition.relatedArtifact.where(type='composed-of').resource
(Any)		 5 Resources
context token A use context assigned to the plan definition (PlanDefinition.useContext.value.ofType(CodeableConcept)) 30 Resources
context-quantity quantity A quantity- or range-valued use context assigned to the plan definition (PlanDefinition.useContext.value.ofType(Quantity)) | (PlanDefinition.useContext.value.ofType(Range)) 30 Resources
context-type token A type of use context assigned to the plan definition PlanDefinition.useContext.code 30 Resources
context-type-quantity composite A use context type and quantity- or range-based value assigned to the plan definition On PlanDefinition.useContext:
  context-type: code
  context-quantity: value.ofType(Quantity) | value.ofType(Range)		 30 Resources
context-type-value composite A use context type and value assigned to the plan definition On PlanDefinition.useContext:
  context-type: code
  context: value.ofType(CodeableConcept)		 30 Resources
date date The plan definition publication date PlanDefinition.date 31 Resources
definition reference Activity or plan definitions used by plan definition PlanDefinition.action.definition.ofType(canonical) | PlanDefinition.action.definition.ofType(uri)
(SpecimenDefinition, MessageDefinition, Questionnaire, ObservationDefinition, PlanDefinition, ActivityDefinition)
depends-on reference What resource is being referenced PlanDefinition.relatedArtifact.where(type='depends-on').resource | PlanDefinition.library
(Library, Any)		 5 Resources
derived-from reference What resource is being referenced PlanDefinition.relatedArtifact.where(type='derived-from').resource
(Any)		 9 Resources
description string The description of the plan definition PlanDefinition.description 29 Resources
effective date The time during which the plan definition is intended to be in use PlanDefinition.effectivePeriod 12 Resources
identifier token External identifier for the plan definition PlanDefinition.identifier 35 Resources
jurisdiction token Intended jurisdiction for the plan definition PlanDefinition.jurisdiction 27 Resources
name string Computationally friendly name of the plan definition PlanDefinition.name 28 Resources
predecessor reference What resource is being referenced PlanDefinition.relatedArtifact.where(type='predecessor').resource
(Any)		 9 Resources
publisher string Name of the publisher of the plan definition PlanDefinition.publisher 31 Resources
status token The current status of the plan definition PlanDefinition.status 35 Resources
successor reference What resource is being referenced PlanDefinition.relatedArtifact.where(type='successor').resource
(Any)		 5 Resources
title string The human-friendly name of the plan definition PlanDefinition.title 28 Resources
topic token Topics associated with the module PlanDefinition.topic 10 Resources
type token The type of artifact the plan (e.g. order-set, eca-rule, protocol) PlanDefinition.type
url uri The uri that identifies the plan definition PlanDefinition.url 34 Resources
version token The business version of the plan definition PlanDefinition.version 32 Resources