Workflow-extensions - FHIR v5.0.0-ballot

Release 5 Ballot

This page is part of the FHIR Specification (v5.0.0-ballot: R5 Ballot - see ballot notes). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4

Workflow Pattern HL7 Extensions

FHIR Infrastructure Work Group

Maturity Level: N/A

Standards Status: Informative

This profile defines extensions that can be used to provide alignment with the Event and Request workflow pattern data elements for concepts that may be generally applicable but may be sufficiently uncommon that they are more appropriate to include as extensions than as core properties of the resource. See the workflow module for more discussion about this specification that are typically involved in workflow.

Content

Extensions:
workflow-generatedFrom	generatedFrom : This artifact was algorithmically produced by applying the referenced artifact to the context relevant for this request.
workflow-compliesWith	compliesWith : The action requested by this resource is intended to satisfy the expectations established by the referenced Definition resource.
workflow-adheresTo	adheresTo : The action represented by this resource has been determined to satisfy the expectations established by the referenced Definition resource.
workflow-triggeredBy	triggeredBy : This resource came into being as a result of expectations set in the referenced Definition resource. I.e. This resource represents a 'step' dictated within the protocol/order set/etc.
workflow-shallComplyWith	shallComplyWith : In satisfying this request or instantiating this definition, the expectations defined in the Definition resource are expected to be met. (This allows requirements defined elsewhere to be brought into play by reference rather than providing all of the detail in-line necessary to satisfy the referenced Definition.).
workflow-barrier	barrier : Any obstacle that limits or prevents obtaining care. Barriers in health and social care include, but are not limited to, physical barriers, psychological barriers, physiological barriers, financial barriers, geographical barriers, cultural/language barriers and resource barriers.
workflow-protectiveFactor	protectiveFactor : Characteristics or strengths of individuals, families, community situations or societies that mitigate risks and promote positivewell-being and healthy development; attributes that help to successfully navigate difficult situations; factors that may contribute to or explain positive outcomes. A trait or habit that “protects” people and makes them less likely to get a chronic disease that include, but are not limited to exercise, healthy eating, managing weight, managing blood pressure and cholesterol, managing mental health, feeling happy, strong emotional support and social connections.
workflow-reason	reason : References a resource or provides a code or text that explains why this event occurred or request was created.
workflow-supportingInfo	supportingInfo : Other resources from the patient record that may be relevant to the event. The information from these resources was either used to create the instance or is provided to help with its interpretation. This extension should not be used if more specific inline elements or extensions are available. For example, use `Observation.hasMember` instead of supportingInformation for representing the members of an Observation panel.
workflow-relatedArtifact	relatedArtifact : Documentation or 'knowledge artifacts' relevant to the base resource such as citations, supporting evidence, documentation of processes, caveats around testing methodology.
workflow-researchStudy	researchStudy : Indicates that this event is relevant to the specified research study(ies).
workflow-episodeOfCare	episodeOfCare : Identifies the episode(s) of care that this resource is relevant to. Establishes the EpisodeOfCare as a 'grouper' of resources that are relevant to that episode.
workflow-followOnOf	followOnOf : Points to a preceding event within a workflow that was a prerequisite for or provides other justification for the current action.
workflow-releaseDate	releaseDate : Indicates the date on which request or event resource that has a status of 'on-hold' or 'suspended' should be moved back to an active state.

Instantiation extensions

Prior versions of FHIR had standard elements and extensions named 'instantiatesCanonical' and 'instantiatesUri'. These were intended to link Request and Event resources to the Definition resources they were based on.

These elements have now been replaced by a number of distinct elements that are more specific about the exact nature of the relationship between Request/Event and Definition. This section provides additional guidance about how to decide which relationship to use - and what to do if the level of granularity conveyed by these extensions isn't known in the data source.

'generatedFrom' is the most straight-forward. It is *only* used when a Request resource is algorithmically generated (by human or software) from the base Definition resource. In most cases a resource 'generatedFrom' a definition will also have a 'compliesWith' relationship (as it's unusual to generate from a definition and not end up compliant with it). However, because of modifications, it's possible to start out compliant and not end that way. It's also possible to comply with a definition without having been algorithmically generated from it.
'compliesWith' and 'adheresTo' are similar. However, they apply to different types of resources. 'compliesWith' is for Request resources and means that the event(s) resulting from the Request (if executed as requested) will align with the expectations of the Definition. On the other hand, 'adheresTo' is for Events and is a direct assertion that the event aligns with the expectations of the Definition. In both cases, the data elements within the request/event have alignment with the definition.
'triggeredBy', on the other hand, doesn't indicate anything about the data elements in the Request or Event. It merely indicates that the Request or Event resource came into existence because the Definition said the action was necessary. It's possible for protocols to define that certain events need to exist without describing exactly what they need to look like. It's also possible to describe the details of resources without defining when they need to be created.
'shallComplyWith' only occurs for Request resources and is a shortcut for defining the data elements in the Request. Instead of providing details about the code, product, timing, dose, etc., the Request simply includes a reference to the Definition and says "do what it says". The obligation is placed on the system fulfilling the Request to determine how to follow the protocol.

If the specific type of instantiation isn't explicit in a mapped element from a previous release or external specification, the meaning(s) can often be determined by looking at the data, the type of resource, and business conventions. 'compliesWith' and 'adheresTo' can in principle be validated. 'shallComplyWith' will appear on requests that have minimal detail about execution. If it's not possible to determine which extension, the inter-version extensions mechanism can be used to propoagate the old-style extension into a newer FHIR release or a custom extension can be used.

Additional guidance on these extensions

External references might be an HTML page, PDF, etc. or could just be a non-resolvable URI identifier. The display extension) on canonical can be used to convey the title of the referenced artifact in addition to (or in place of) the discrete elements referencing it.