[go: up one dir, main page]
FHIR Release 3 (STU)

This page is part of the FHIR Specification (v3.0.2: STU 3). 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 R3

12.3 Logical Model request - Content

A pattern to be followed by resources that represent a specific proposal, plan and/or order for some sort of action or service.

12.3.1 Scope and Usage

This is NOT a resource. It is not part of the FHIR schema and cannot appear directly in FHIR instances. It is a logical model that defines a pattern adhered to by other resources. This pattern serves two purposes:

  • It offers guidance to work groups designing resources and helps ensure consistency of content created by different work groups
  • It provides a standard "view" that might be useful for implementers in processing and manipulating all resources that adhere to the same pattern. (Tooling that supports this may become available in a future release.)

The notion of "request" encompasses all types of orders (original orders, filler representations of orders, reflex orders, etc.) as well as proposals for action to occur, recommendations, plans, scheduling, etc. Any sort of description of an activity that is "desired" where the description is specific as to the subject of the activity and the approximate timing of the activity would be considered a "Request"

12.3.2 Boundaries and Relationships

This logical model is one of three common workflow patterns. The other two patterns are Event and Definition. This pattern is followed by (or is intended to be followed by a number of other FHIR resources/

Requests are distinct from events in that an event is primarily focused on what has occurred or is occurring while requests deal with what is "desired" to occur. While creating a request or definition can be seen as a type of event, the focus of those other resources is not the "creation" but the desire/intention. Both requests and definitions deal with activities that "can" occur, but requests represent a specific intention for something to occur and are bound to a specific context of subject (e.g. patient) and time, while definitions represent mere "possibility" rather than intention and are independent of a specific subject or timeframe.

Requests are related to Task in that tasks can both request and track the fulfillment of a request. In some cases, fulfillment may also result in the creation of sub-tasks. Requests do not track their own fulfillment - i.e. requested/accepted/in-progress. This is managed through Task. The status of a request only reflects the status of the "authorization/intention", not how the request is being executed or not. It is possible for multiple tasks to be associated with the fulfillment of a single Request.

12.3.3 Background and Context

This model represents a pattern. It provides a standard list of data elements with cardinalities, data types, definitions, rationale and usage notes that will ideally be adhered to by resources that fall into the "request" workflow category. However, adherence to this pattern is not mandatory. Not all healthcare domains are the same. Concepts that may be generally applicable (and thus are included in this standard pattern) might still not be relevant everywhere or may be sufficiently uncommon that they are more appropriate to include as extensions than as core properties of the resource. Work groups are encouraged to adjust descriptions, usage notes and rationale to be specific to their resource (e.g. use the term "diagnostic test" or "prescription" rather than "request"). As well, design notes in the comments column marked with [square brackets] identifies areas where domain variation is expected and encouraged. Other variation, including differences in names, cardinalities, data types and the decision to omit an element outright are also possible, but should be discussed with the FHIR Infrastructure work group's Workflow project to ensure the rationale for non-alignment is understood, to confirm that the deviation is necessary and to identify whether any adjustments to the pattern are appropriate.

This pattern provides a linkage to the W5 list of standard data elements. Resources that adhere to this pattern should ensure their w5 mappings are consistent, as is their data element ordering.

12.3.4 Logical Model Content

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Request LogicalRequest Pattern
... identifier Σ0..*IdentifierBusiness Identifier for request/order
... definition Σ0..*Reference(Definition)Instantiates protocol or definition
... basedOn Σ0..*Reference(Request)Fulfills plan, proposal or order
... replaces Σ0..*Reference(Request)Request(s) replaced by this request
... groupIdentifier Σ0..1IdentifierComposite request this is part of
... status ?!Σ1..1codedraft | active | suspended | cancelled | completed | entered-in-error | unknown
RequestStatus (Required)
... intent ?!Σ1..1codeproposal | plan | order
RequestIntent (Required)
... priority Σ0..1coderoutine | urgent | asap | stat
RequestPriority (Required)
... code Σ0..1CodeableConceptWhat's being requested/ordered
... subject Σ1..1Reference(Patient | Group)Individual the service is ordered for
... context Σ0..1Reference(Encounter | EpisodeOfCare)Encounter / Episode associated with request
... occurrence[x] Σ0..1When service should occur
.... occurrenceDateTimedateTime
.... occurrencePeriodPeriod
.... occurrenceTimingTiming
... authoredOn Σ0..1dateTimeWhen request transitioned to being actionable
... requester ΣI0..1BackboneElementWho/what is requesting service
+ onBehalfOf can only be specified if agent is practitioner or device
.... agent Σ1..1Reference(Practitioner | Organization | Patient | RelatedPerson | Device)Individual making the request
.... onBehalfOf ΣI0..1Reference(Organization)Organization agent is acting for
... performerType Σ0..1CodeableConceptDesired kind of service performer
... performer Σ0..1Reference(Practitioner | Organization | Patient | Device | RelatedPerson)Specific desired performer
... reasonCode Σ0..*CodeableConceptWhy is service needed?
... reasonReference Σ0..*Reference(Condition | Observation)Why is service needed?
... supportingInfo 0..*Reference(Any)Extra information to use in performing request
... note 0..*AnnotationComments made about service request
... relevantHistory 0..*Reference(Provenance)Key events in history of request

doco Documentation for this format

UML Diagram (Legend)

Request (Logical)Identifiers assigned to this request by the requester, performer and other systemsidentifier : Identifier [0..*]A protocol, guideline, orderset or other definition that is adhered to in whole or in part by this requestdefinition : Reference [0..*] Definition A plan, proposal or order that is fulfilled in whole or in part by this requestbasedOn : Reference [0..*] Request Completed or terminated request(s) whose function is taken by this new requestreplaces : Reference [0..*] Request A shared identifier common to all requests that were authorized more or less simultaneously by a single author, representing the identifier of the requisition, prescription or similar formgroupIdentifier : Identifier [0..1]The current state of the request (this element modifies the meaning of other elements)status : code [1..1] Codes identifying the stage lifecycle stage of a request (Strength=Required)RequestStatus! Indicates the level of authority/intentionality associated with the request and where the request fits into the workflow chain (this element modifies the meaning of other elements)intent : code [1..1] Codes indicating the degree of authority/intentionality associated with a request (Strength=Required)RequestIntent! Indicates how quickly the {{title}} should be addressed with respect to other requestspriority : code [0..1] Identifies the level of importance to be assigned to actioning the request (Strength=Required)RequestPriority! A code that identifies the specific service or action being requestedcode : CodeableConcept [0..1]The individual or set of individuals the action is to be performed on or forsubject : Reference [1..1] Patient|Group The encounter or episode of care that establishes the context for making this requestcontext : Reference [0..1] Encounter|EpisodeOfCare The date or time(s) at which the activity or service is desired to occuroccurrence[x] : Type [0..1] dateTime|Period|Timing For draft requests, indicates the date of initial creation. For requests with other statuses, indicates the date of activationauthoredOn : dateTime [0..1]The type of individual that is desired to act upon the requestperformerType : CodeableConcept [0..1]Indicates who or what is being asked to perform the requestperformer : Reference [0..1] Practitioner|Organization|Patient| Device|RelatedPerson Describes why the request is being made in coded or textual formreasonCode : CodeableConcept [0..*]Indicates another resource whose existence justifies this requestreasonReference : Reference [0..*] Condition|Observation Information that may be needed by/relevant to the performer in their execution of this requestsupportingInfo : Reference [0..*] Any Comments made about the request by the requester, performer, subject or other participantsnote : Annotation [0..*]Links to Provenance records for past versions of this resource or fulfilling request or event resources that identify key state transitions or updates that are likely to be relevant to a user looking at the current version of the resourcerelevantHistory : Reference [0..*] Provenance RequesterThe device, practitioner, etc. who initiated the requestagent : Reference [1..1] Practitioner|Organization|Patient| RelatedPerson|Device The organization the device or practitioner was acting on behalf ofonBehalfOf : Reference [0..1] Organization The individual who initiated the request and has responsibility for its activationrequester[0..1]

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Request LogicalRequest Pattern
... identifier Σ0..*IdentifierBusiness Identifier for request/order
... definition Σ0..*Reference(Definition)Instantiates protocol or definition
... basedOn Σ0..*Reference(Request)Fulfills plan, proposal or order
... replaces Σ0..*Reference(Request)Request(s) replaced by this request
... groupIdentifier Σ0..1IdentifierComposite request this is part of
... status ?!Σ1..1codedraft | active | suspended | cancelled | completed | entered-in-error | unknown
RequestStatus (Required)
... intent ?!Σ1..1codeproposal | plan | order
RequestIntent (Required)
... priority Σ0..1coderoutine | urgent | asap | stat
RequestPriority (Required)
... code Σ0..1CodeableConceptWhat's being requested/ordered
... subject Σ1..1Reference(Patient | Group)Individual the service is ordered for
... context Σ0..1Reference(Encounter | EpisodeOfCare)Encounter / Episode associated with request
... occurrence[x] Σ0..1When service should occur
.... occurrenceDateTimedateTime
.... occurrencePeriodPeriod
.... occurrenceTimingTiming
... authoredOn Σ0..1dateTimeWhen request transitioned to being actionable
... requester ΣI0..1BackboneElementWho/what is requesting service
+ onBehalfOf can only be specified if agent is practitioner or device
.... agent Σ1..1Reference(Practitioner | Organization | Patient | RelatedPerson | Device)Individual making the request
.... onBehalfOf ΣI0..1Reference(Organization)Organization agent is acting for
... performerType Σ0..1CodeableConceptDesired kind of service performer
... performer Σ0..1Reference(Practitioner | Organization | Patient | Device | RelatedPerson)Specific desired performer
... reasonCode Σ0..*CodeableConceptWhy is service needed?
... reasonReference Σ0..*Reference(Condition | Observation)Why is service needed?
... supportingInfo 0..*Reference(Any)Extra information to use in performing request
... note 0..*AnnotationComments made about service request
... relevantHistory 0..*Reference(Provenance)Key events in history of request

doco Documentation for this format

UML Diagram (Legend)

Request (Logical)Identifiers assigned to this request by the requester, performer and other systemsidentifier : Identifier [0..*]A protocol, guideline, orderset or other definition that is adhered to in whole or in part by this requestdefinition : Reference [0..*] Definition A plan, proposal or order that is fulfilled in whole or in part by this requestbasedOn : Reference [0..*] Request Completed or terminated request(s) whose function is taken by this new requestreplaces : Reference [0..*] Request A shared identifier common to all requests that were authorized more or less simultaneously by a single author, representing the identifier of the requisition, prescription or similar formgroupIdentifier : Identifier [0..1]The current state of the request (this element modifies the meaning of other elements)status : code [1..1] Codes identifying the stage lifecycle stage of a request (Strength=Required)RequestStatus! Indicates the level of authority/intentionality associated with the request and where the request fits into the workflow chain (this element modifies the meaning of other elements)intent : code [1..1] Codes indicating the degree of authority/intentionality associated with a request (Strength=Required)RequestIntent! Indicates how quickly the {{title}} should be addressed with respect to other requestspriority : code [0..1] Identifies the level of importance to be assigned to actioning the request (Strength=Required)RequestPriority! A code that identifies the specific service or action being requestedcode : CodeableConcept [0..1]The individual or set of individuals the action is to be performed on or forsubject : Reference [1..1] Patient|Group The encounter or episode of care that establishes the context for making this requestcontext : Reference [0..1] Encounter|EpisodeOfCare The date or time(s) at which the activity or service is desired to occuroccurrence[x] : Type [0..1] dateTime|Period|Timing For draft requests, indicates the date of initial creation. For requests with other statuses, indicates the date of activationauthoredOn : dateTime [0..1]The type of individual that is desired to act upon the requestperformerType : CodeableConcept [0..1]Indicates who or what is being asked to perform the requestperformer : Reference [0..1] Practitioner|Organization|Patient| Device|RelatedPerson Describes why the request is being made in coded or textual formreasonCode : CodeableConcept [0..*]Indicates another resource whose existence justifies this requestreasonReference : Reference [0..*] Condition|Observation Information that may be needed by/relevant to the performer in their execution of this requestsupportingInfo : Reference [0..*] Any Comments made about the request by the requester, performer, subject or other participantsnote : Annotation [0..*]Links to Provenance records for past versions of this resource or fulfilling request or event resources that identify key state transitions or updates that are likely to be relevant to a user looking at the current version of the resourcerelevantHistory : Reference [0..*] Provenance RequesterThe device, practitioner, etc. who initiated the requestagent : Reference [1..1] Practitioner|Organization|Patient| RelatedPerson|Device The organization the device or practitioner was acting on behalf ofonBehalfOf : Reference [0..1] Organization The individual who initiated the request and has responsibility for its activationrequester[0..1]

 

12.3.4.1 Terminology Bindings

PathDefinitionTypeReference
Request.status Codes identifying the stage lifecycle stage of a requestRequiredRequestStatus
Request.intent Codes indicating the degree of authority/intentionality associated with a requestRequiredRequestIntent
Request.priority Identifies the level of importance to be assigned to actioning the requestRequiredRequestPriority
Request.code Codes indicating the details of what is being requested. These will vary significantly based on the type of request resource and will often be example/preferred rather than extensible/required.UnknownNo details provided yet
Request.performerType Identifies types of practitioners, devices or others that should fulfill a request. While the detailed constraints of relevant providers will vary by resource, some degree of consistency around recommended codes across request and definition resources would be desirableUnknownNo details provided yet
Request.reasonCode Codes identifying why this request was necessary. These may be clinical reasons (e.g. diagnoses, symptoms) and/or administrative reasons. While the detailed constraints of relevant reasons will vary by resource, some degree of consistency across resources around recommended codes would be desirable.UnknownNo details provided yet

12.3.4.2 Constraints

  • inv-1: On request.requester: onBehalfOf can only be specified if agent is practitioner or device (expression on request.requester: (agent.resolve().empty()) or (agent.resolve() is Device) or (agent.resolve() is Practitioner) or onBehalfOf.exists().not())

12.3.5 State Machine

The following diagram shows the "typical" state machine diagram for resources following the Request pattern. Note that not all resources will support all states, some resources may choose different names for certain states and some resources may introduce sub-states to the listed states. As well, additional transitions may be supported, including from terminal nodes (e.g. from "completed" back to "active"). That said, most resources should align with this state machine fairly well.

Typical state machine diagram for resources following the Request pattern

Note that this state machine does not reflect the execution of the request. That state is managed either through the Event resources that are based on the request or via the Task resource.

12.3.6 Fulfillment/Execution information

Request resources describe what activity is desired/authorized. They don't describe what activity has actually occurred against the request. I.e. The request resource will not indicate actual performer, actual performance time, actual action performed, etc. Information about what action (if any) has occurred against the request is tracked using the corresponding Event resource(s). Events that are associated with the request should have a basedOn link referencing the request. In addition, a linkage can be established (and information about progress in execution) may be found in Task resources that have a focus of this request.

12.3.7 Updating requests

FHIR does not impose any business rules on what sorts of changes may be made to a request. A generic FHIR server could support updating a completed request to change the subject, requester, authorized action, quantity, timing and any other such information. However, most business processes will impose significant constraints on what changes, if any, are allowed to request resources, particularly after they have transitioned to "active" or "completed". Servers are free to enforce whatever rules they deem appropriate - and to provide appropriate OperationOutcome responses detailing constraints if those rules are violated.

12.3.8 Compound Requests

There are three different ways to define "compound" requests in FHIR:

  • Shared requisition id
  • "Based on" chain
  • RequestGroup

12.3.8.1 Shared requisition id

The Request.requisitionId element allows multiple requests to be linked as having been created as part of the same "event" - generally by the same practitioner at the same time for the same subject. The "requisitionId" represents the identifier of the prescription, lab requisition or other form that was shared by all items. The common information (patient/practitioner/authoredOn) can be seen by examining any of the Request instances that share that requisitionId If there are common comments or notes that span the entire requisition, they should be captured as Observation or Communication instances linked to relevant Request instances using Request.supportingInfo.

Each "component" behaves as an independent request and has its own status that changes independently. In general the requisitionId, practitioner, authoredOn and subject for each will be immutable, but there may be situations where some workflows allow them to change. The shared requisitionId allows business processes dependent on "simultaneous/requisition-based ordering" such as payment rules to know that the requests were ordered at the same time.

12.3.8.2 "Based on" chain

In this case "components" of a parent request are not treated as components, but rather as separate orders that are executed as part of the fulfillment process for the parent order. For example, a lab order might spawn child orders to draw the specimen, treat the specimen, run several tests and to create the report. Each "child" Request would use Request.basedOn to reference the original Request. In this case, there's a relationship between the statuses of the base Request and the fulfilling Requests, but they transition separately and may not transition in the same manner. For example, if the original lab order were updated to "suspended", the initial blood draw request might be complete. The other requests might change to either "suspended" or even "aborted" and a subsequent update of the lab order back to active might require spawning additional fulfilling orders, perhaps to draw a new specimen.

basedOn is distinct from the notion of replaces. In a "based on" relationship both resources are "active" and in force and the authority cascades from the initial request to the request that is based on that original request. In a "replaces" relationship, the target resource is no longer in force and should have a status of "completed" or "cancelled" or some other terminal state.

12.3.8.3 RequestGroup

This approach makes use of the RequestGroup resource which allows the assertion of complex timing and other dependencies between a collection of requests. These effectively become one overall Request instance with a single status. All resources referenced by the RequestGroup must have an intent of "option", meaning that they cannot be interpretted independently - and that changes to them must take into account the impact on referencing resources. Typically these will either be contained resources or tightly controlled or immutable instances based on ActivityDefinitions that can safely be referenced without concern of them changing independent of referencing Requests.

The status of the parent request automatically cascades to the component "options". If there is a need for divergent statuses, these must be handled by creating "child" using the "basedOn" approach above. They should have a basedOn relationship with both the "parent" Request as well as the specific "option" Request they are tied to.