STU 3 Ballot

This page is part of the FHIR Specification (v1.6.0: STU 3 Ballot 4). 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

??.?? 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.

??.??.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.)

??.??.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/

??.??.3 Background and Context

This resource 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.

??.??.4 Logical Model Content

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Request LogicalRequest Pattern
... identifier Σ0..1IdentifierBusiness Identifer 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
... requisition Σ0..1IdentifierComposite request this is part of
... status ?!Σ1..1codedraft | active | suspended | cancelled | completed | entered-in-error
RequestStatus (Required)
... stage ?!Σ1..1CodeableConceptproposal | plan | order +
RequestStage (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
... authored Σ0..1dateTimeWhen request transitioned to being actionable
... requester Σ0..1Reference(Practitioner | Organization | Patient | RelatedPerson | Device)Who/what is requesting service
... 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..1Reference(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..1]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 formrequisition : 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)stage : CodeableConcept [1..1] « Codes indicating the degree of authority/intentionality associated with a request (Strength=Required)RequestStage! »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 activationauthored : dateTime [0..1]The individual who initiated the request and has responsibility for its activationrequester : Reference [0..1] « Practitioner|Organization|Patient| RelatedPerson|Device »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..1] « 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 »

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Request LogicalRequest Pattern
... identifier Σ0..1IdentifierBusiness Identifer 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
... requisition Σ0..1IdentifierComposite request this is part of
... status ?!Σ1..1codedraft | active | suspended | cancelled | completed | entered-in-error
RequestStatus (Required)
... stage ?!Σ1..1CodeableConceptproposal | plan | order +
RequestStage (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
... authored Σ0..1dateTimeWhen request transitioned to being actionable
... requester Σ0..1Reference(Practitioner | Organization | Patient | RelatedPerson | Device)Who/what is requesting service
... 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..1Reference(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..1]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 formrequisition : 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)stage : CodeableConcept [1..1] « Codes indicating the degree of authority/intentionality associated with a request (Strength=Required)RequestStage! »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 activationauthored : dateTime [0..1]The individual who initiated the request and has responsibility for its activationrequester : Reference [0..1] « Practitioner|Organization|Patient| RelatedPerson|Device »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..1] « 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 »

 

??.??.4.1 Terminology Bindings

PathDefinitionTypeReference
Request.status Codes identifying the stage lifecycle stage of a requestRequiredRequestStatus
Request.stage Codes indicating the degree of authority/intentionality associated with a requestRequiredRequestStage
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