Release 4B R5 Final QA

This page is part of the FHIR Specification (v4.3.0: R4B (v5.0.0-draft-final: Final QA Preview for R5 - STU 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-instantiatesCanonical
instantiatesCanonical :

Instantiation extensions

The URL pointing 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 FHIR-defined protocol, guideline, orderset or other definition number of distinct elements that is adhered are more specific about the exact nature of the relationship between Request/Event and Definition. This section provides additional guidance about how to in whole or in part decide which relationship to use - and what to do if the level of granularity conveyed by these extensions isn't known in the event data source.

  • 'generatedFrom' is the most straight-forward. It is *only* used when a Request resource is algorithmically generated (by human or request software) from the base Definition resource. workflow-instantiatesUri instantiatesUri : The URL pointing In most cases a resource 'generatedFrom' a definition will also have a 'compliesWith' relationship (as it's unusual to an externally maintained protocol, guideline, orderset or other 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 is adhered way. It's also possible to in whole or in part by 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 or request resource. workflow-reasonCode reasonCode : Describes why 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 occurred 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 coded the Request or textual form. workflow-reasonReference reasonReference : Indicates another Event. It merely indicates that the Request or Event resource whose came into existence justifies this event. workflow-supportingInfo supportingInfo : Other resources from because the patient record Definition said the action was necessary. It's possible for protocols to define that may be relevant certain events need to exist without describing exactly what they need to look like. It's also possible to describe the event. The information from these details of resources was either used without defining when they need to create be created.
  • 'shallComplyWith' only occurs for Request resources and is a shortcut for defining the instance or 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 provided placed on the system fulfilling the Request to help with its interpretation. This extension should not be used if more determine how to follow the protocol.

If the specific inline elements or extensions are available. For example, use Observation.hasMember instead type of supportingInformation for representing instantiation isn't explicit in a mapped element from a previous release or external specification, the members meaning(s) can often be determined by looking at the data, the type of an Observation panel. workflow-relatedArtifact relatedArtifact : Documentation or 'knowledge artifacts' relevant 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 base resource such as citations, supporting evidence, documentation of processes, caveats around testing methodology. workflow-researchStudy inter-version extensions researchStudy : Indicates that this event is relevant mechanism can be used to propoagate the specified research study(ies). old-style extension into a newer FHIR release or a custom extension can be used.

workflow-episodeOfCare episodeOfCare :

Additional guidance on these extensions

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