--- type: "resource" title: "SupplyRequest" resource: "SupplyRequest" --- # SupplyRequest ## Introduction ## Scope and Usage **This resource is a _request_ resource from a FHIR workflow perspective - see [Workflow](workflow). It is the intent of the Orders and Observation Workgroup to align this resource with the workflow pattern for [_request_ resources](workflow).** The SupplyRequest resource expresses the need to deliver an item, while the SupplyDelivery tracks the actual delivery. The SupplyRequest resource is meant for logistics functions only, not for associating a clinical use of the item, which would be done through the clinical resources such as ServiceRequest, DeviceRequest, MedicationRequest resources. The SupplyRequest relates to the Patient resource (in the deliverTo) but that is meant exclusively only for purposes of having a destination for delivery, not a clinical use. The scope of the SupplyRequest resource is for recording the request of supplies used in the healthcare process to be delivered to a particular location. This includes supplies specifically used in the treatment of patients as well as supply movement within an institution e.g. transport a set of supplies from materials management to a service unit (nurse station). This resource does not include the provisioning of transportation services. The SupplyRequest resource allows requesting only a single item. If a workflow requires requesting multiple items simultaneously, this is done using multiple instances of this resource. These instances can be linked in different ways, depending on the needs of the workflow. For guidance, refer to [the Request pattern](request#compound) ## Boundaries and Relationships The SupplyRequest resource represents an authorization for a supply to be provided. The [SupplyDelivery](supplydelivery) resource documents the movement of supply as a result of the SupplyRequest being acted upon. Details of the actions performed as a result of the SupplyRequest are handled by the [Task](task) resource (which may reference the SupplyRequest in \`Task.focus\`) or by using a messaging or workflow service where the request is explicit or implicit. For further information about this separation of responsibilities, refer to the [Fulfillment/Execution](https://www.hl7.org/fhir/request.html#fulfillment) section of the Request pattern. The SupplyRequest resource is used for _inventory management_. When requesting medication, substances and devices when there is a patient focus or instructions regarding their use, [DeviceRequest](devicerequest) or [MedicationRequest](medicationrequest) should be used instead. For [DeviceDispense](https://build.fhir.org/ig/HL7/oo-incubator/StructureDefinition-DeviceDispense.html), [MedicationDispense](medicationdispense), and [BiologicallyDerivedProductDispense](biologicallyderivedproductdispense), a SupplyRequest does not document the formal association of a device, medication, biologically derived product, or supply item to a patient. The DeviceDispense (or MedicationDispense or BiologicallyDerivceProductDispense) is used to formally document that the device, medication, biologically derived product or supply item is to be used by or for a patient in a medical activity. To determine the purchase date, a search of DeviceRequest, SupplyRequest, DeviceDispense, or SupplyDelivery as defined in an implementation guide can be done , as the context of the use case actually determines which date of either resource is considered the purchase date. ## StructureDefinition ### Elements (Simplified) - **[SupplyRequest](/supplyrequest-definitions#SupplyRequest)** [0..*]: - Request for a medication, substance or device - **[SupplyRequest.identifier](/supplyrequest-definitions#SupplyRequest.identifier)** [0..*]: [Identifier](/Identifier) Business Identifier for SupplyRequest - **[SupplyRequest.status](/supplyrequest-definitions#SupplyRequest.status)** [0..1]: [code](/code) required:[supplyrequest-status](/valueset-supplyrequest-status) draft | active | suspended + - **[SupplyRequest.intent](/supplyrequest-definitions#SupplyRequest.intent)** [1..1]: [code](/code) required:[request-intent](/valueset-request-intent) proposal | solicit-offer | offer-response | plan | directive | order | original-order | reflex-order | filler-order | instance-order | option - **[SupplyRequest.basedOn](/supplyrequest-definitions#SupplyRequest.basedOn)** [0..*]: Reference([Resource](/Resource)) What other request is fulfilled by this supply request - **[SupplyRequest.replaces](/supplyrequest-definitions#SupplyRequest.replaces)** [0..*]: [Reference(ServiceRequest](/Reference(ServiceRequest), [MedicationRequest](/MedicationRequest), [RequestOrchestration](/RequestOrchestration), [CarePlan](/CarePlan), [DeviceRequest](/DeviceRequest), [CommunicationRequest](/CommunicationRequest), [NutritionOrder](/NutritionOrder), [VisionPrescription](/VisionPrescription), [SupplyRequest)](/SupplyRequest)) What request replaces - **[SupplyRequest.groupIdentifier](/supplyrequest-definitions#SupplyRequest.groupIdentifier)** [0..1]: [Identifier](/Identifier) Composite request this is part of - **[SupplyRequest.category](/supplyrequest-definitions#SupplyRequest.category)** [0..1]: [CodeableConcept](/CodeableConcept) example:[supplyrequest-kind](/valueset-supplyrequest-kind) The kind of supply (central, non-stock, etc.) - **[SupplyRequest.priority](/supplyrequest-definitions#SupplyRequest.priority)** [0..1]: [code](/code) required:[request-priority](/valueset-request-priority) routine | urgent | asap | stat - **[SupplyRequest.deliverFor](/supplyrequest-definitions#SupplyRequest.deliverFor)** [0..1]: Reference([Patient](/Patient)) The patient for who the supply request is for - **[SupplyRequest.item](/supplyrequest-definitions#SupplyRequest.item)** [1..1]: [CodeableReference](/CodeableReference) example:[supply-item](/valueset-supply-item) Medication, Substance, or Device requested to be supplied - **[SupplyRequest.quantity](/supplyrequest-definitions#SupplyRequest.quantity)** [1..1]: [Quantity](/Quantity) The requested amount of the item indicated - **[SupplyRequest.parameter](/supplyrequest-definitions#SupplyRequest.parameter)** [0..*]: [BackboneElement](/BackboneElement) Ordered item details - **[SupplyRequest.parameter.code](/supplyrequest-definitions#SupplyRequest.parameter.code)** [0..1]: [CodeableConcept](/CodeableConcept) Item detail - **[SupplyRequest.parameter.value[x]](/supplyrequest-definitions#SupplyRequest.parameter.value%5Bx%5D)** [0..1]: [CodeableConcept](/CodeableConcept), [Quantity](/Quantity), [Range](/Range), [boolean](/boolean) Value of detail - **[SupplyRequest.occurrence[x]](/supplyrequest-definitions#SupplyRequest.occurrence%5Bx%5D)** [0..1]: [dateTime](/dateTime), [Period](/Period), [Timing](/Timing) When the request should be fulfilled - **[SupplyRequest.authoredOn](/supplyrequest-definitions#SupplyRequest.authoredOn)** [0..1]: [dateTime](/dateTime) When the request was made - **[SupplyRequest.requester](/supplyrequest-definitions#SupplyRequest.requester)** [0..1]: [Reference(Practitioner](/Reference(Practitioner), [PractitionerRole](/PractitionerRole), [Organization](/Organization), [Patient](/Patient), [RelatedPerson](/RelatedPerson), [Device](/Device), [CareTeam)](/CareTeam)) Individual making the request - **[SupplyRequest.supplier](/supplyrequest-definitions#SupplyRequest.supplier)** [0..*]: [Reference(Organization](/Reference(Organization), [HealthcareService)](/HealthcareService)) Who is intended to fulfill the request - **[SupplyRequest.reason](/supplyrequest-definitions#SupplyRequest.reason)** [0..*]: [CodeableReference](/CodeableReference) example:[supplyrequest-reason](/valueset-supplyrequest-reason) The reason why the supply item was requested - **[SupplyRequest.deliverFrom](/supplyrequest-definitions#SupplyRequest.deliverFrom)** [0..1]: [Reference(Organization](/Reference(Organization), [Location)](/Location)) The origin of the supply - **[SupplyRequest.deliverTo](/supplyrequest-definitions#SupplyRequest.deliverTo)** [0..1]: [Reference(Organization](/Reference(Organization), [Location](/Location), [Patient](/Patient), [RelatedPerson)](/RelatedPerson)) The destination of the supply - **[SupplyRequest.requestedPerformer](/supplyrequest-definitions#SupplyRequest.requestedPerformer)** [0..*]: [CodeableReference](/CodeableReference) Who should perform the SupplyRequest ## Mappings - [SupplyRequest Mappings](/supplyrequest-mappings) — 66 mapping entries ## Resource Packs ### list-SupplyRequest-packs.xml ```xml ``` ## Search Parameters - [category](/supplyrequest-search#category) — **token** — The kind of supply (central, non-stock, etc.) — `SupplyRequest.category` - [date](/supplyrequest-search#date) — **date** — When the request was made — `SupplyRequest.authoredOn` - [identifier](/supplyrequest-search#identifier) — **token** — Business Identifier for SupplyRequest — `SupplyRequest.identifier` - [replaces](/supplyrequest-search#replaces) — **reference** — What request replaces — `SupplyRequest.replaces` - [requester](/supplyrequest-search#requester) — **reference** — Individual making the request — `SupplyRequest.requester` - [patient](/supplyrequest-search#patient) — **reference** — The patient or subject for whom the supply is destined — `SupplyRequest.deliverFor` - [status](/supplyrequest-search#status) — **token** — draft | active | suspended + — `SupplyRequest.status` - [subject](/supplyrequest-search#subject) — **reference** — The destination of the supply — `SupplyRequest.deliverTo` - [supplier](/supplyrequest-search#supplier) — **reference** — Who is intended to fulfill the request — `SupplyRequest.supplier` [Full Search Parameters](/supplyrequest-search) ## Examples - [simpleorder](/supplyrequest-example-simpleorder) — supplyrequest-example-simpleorder — Simple order for resupply - [supplyrequest-example](/supplyrequest-example-supplyrequest-example) — supplyrequest-example - [supplyrequest-example-simpleorder](/supplyrequest-example-supplyrequest-example-simpleorder) — supplyrequest-example-simpleorder - [supplyrequest-examples-header](/supplyrequest-example-supplyrequest-examples-header) — supplyrequest-examples-header [Full Examples](/supplyrequest-examples) ## Mapping Exceptions ### supplyrequest-fivews-mapping-exceptions.xml ### Divergent Elements - **FiveWs.class** → **SupplyRequest.intent** - **FiveWs.what[x]** → **SupplyRequest.parameter** ### Unmapped Elements - **FiveWs.cause** — Unknown - **FiveWs.version** — Unknown - **FiveWs.witness** — Unknown - **FiveWs.where** — Unknown - **FiveWs.context** — Unknown - **FiveWs.init** — Unknown - **FiveWs.source** — Unknown - **FiveWs.who** — Unknown - **FiveWs.done** — Unknown - **FiveWs.subject** — Unknown ### supplyrequest-request-mapping-exceptions.xml ### Divergent Elements - **Request.identifier** → **SupplyRequest.identifier** - shortUnmatched | reason=Unknown | pattern=Business Identifier for supply request | resource=Business Identifier for SupplyRequest - definitionUnmatched | reason=Unknown | pattern=Business identifiers assigned to this supply request by the author and/or other systems. These identifiers remain constant as the resource is updated and propagates from server to server. | resource=Business identifiers assigned to this SupplyRequest by the author and/or other systems. These identifiers remain constant as the resource is updated and propagates from server to server. - commentsUnmatched | reason=Unknown | pattern=The identifier.type element is used to distinguish between the identifiers assigned by the requester/placer and the performer/filler. Note: This is a business identifier, not a resource identifier (see [discussion](resource.html#identifiers)). It is best practice for the identifier to only appear on a single resource instance, however business practices may occasionally dictate that multiple resource instances with the same identifier can exist - possibly even with different resource types. For example, multiple Patient and a Person resource instance might share the same social insurance number. | resource=The identifier.type element is used to distinguish between the identifiers assigned by the requester/placer and the performer/filler. - requirementsUnmatched | reason=Unknown | pattern=Allows identification of the supply request as it is known by various participating systems and in a way that remains consistent across servers. | resource=Allows identification of the request as it is known by various participating systems and in a way that remains consistent across servers. - **Request.basedOn** → **SupplyRequest.basedOn** - missingTypes | reason=Unknown | pattern=Reference(Request) - extraTypes | reason=Unknown - shortUnmatched | reason=Unknown | pattern=Fulfills plan, proposal or order | resource=What other request is fulfilled by this supply request - definitionUnmatched | reason=Unknown | pattern=A higher-level request resource (i.e. a plan, proposal or order) that is fulfilled in whole or in part by this supply request. Authorization from the 'basedOn' request flows through to the referencing supply request. | resource=Plan/proposal/order fulfilled by this request. - commentsUnmatched | reason=Unknown | pattern=basedOn represents the 'authorization' chain for an action, not the 'reason for action'. For example, an order might be placed on hold under the authorization for a surgery. However the 'reason' for placing the hold is "to avoid interaction with anesthesia medications" . - requirementsUnmatched | reason=Unknown | pattern=Allows tracing of authorization for the request and tracking whether proposals/recommendations were acted upon. - **Request.replaces** → **SupplyRequest.replaces** - missingTypes | reason=Unknown | pattern=Reference(Request) - extraTypes | reason=Unknown - shortUnmatched | reason=Unknown | pattern=Request(s) replaced by this supply request | resource=What request replaces - definitionUnmatched | reason=Unknown | pattern=Completed or terminated request(s) whose function is taken by this new supply request. | resource=The request takes the place of the referenced completed or terminated request(s). - commentsUnmatched | reason=Unknown | pattern=The replacement could be because the initial request was immediately rejected (due to an issue) or because the previous request was completed, but the need for the action described by the request remains ongoing. - requirementsUnmatched | reason=Unknown | pattern=Allows tracing the continuation of a therapy or administrative process instantiated through multiple requests. - **Request.groupIdentifier** → **SupplyRequest.groupIdentifier** - definitionUnmatched | reason=Unknown | pattern=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 form. | resource=A shared identifier common to multiple independent Request instances that were activated/authorized more or less simultaneously by a single author. The presence of the same identifier on each request ties those requests together and may have business ramifications in terms of reporting of results, billing, etc. E.g. a requisition number shared by a set of lab tests ordered together, or a prescription number shared by all meds ordered at one time. - requirementsUnmatched | reason=Unknown | pattern=Some business processes need to know if multiple items were ordered as part of the same "prescription" or "requisition" for billing or other purposes. - **Request.status** → **SupplyRequest.status** - shortUnmatched | reason=Unknown | pattern=draft | active | on-hold | revoked | completed | entered-in-error | unknown | resource=draft | active | suspended + - definitionUnmatched | reason=Unknown | pattern=The current state of the supply request. | resource=Status of the supply request. - commentsUnmatched | reason=Unknown | pattern=The status is generally fully in the control of the requester - they determine whether the order is draft or active and, after it has been activated, completed, cancelled or suspended. States relating to the activities of the performer are reflected on either the corresponding]](s) or using the]] resource. A nominal state-transition diagram can be found in the] documentation Unknown does not represent "other" - one of the defined statuses must apply. Unknown is used when the authoring system is not sure what the current status is. A status of 'active' when doNotPerform is true means that the request to not perform is currently in force. A status of completed for a "doNotPerform" request indicates that the period of non-performance is now satisfied and the request no longer holds. - **Request.intent** → **SupplyRequest.intent** - shortUnmatched | reason=Unknown | pattern=proposal | plan | order (immutable) | resource=proposal | solicit-offer | offer-response | plan | directive | order | original-order | reflex-order | filler-order | instance-order | option - definitionUnmatched | reason=Unknown | pattern=Indicates the level of authority/intentionality associated with the supply request and where the request fits into the workflow chain. | resource=Whether the request is a proposal, plan, or an original order. - commentsUnmatched | reason=Unknown | pattern=This element is expected to be immutable. E.g. A "proposal" instance should never change to be a "plan" instance or "order" instance. Instead, a new instance 'basedOn' the prior instance should be created with the new 'intent' value. One exception to this is that the granularity of Request.intent is allowed to change. For example, a Request identified as an "order" might later be clarified to be a "filler-order". Or, in rarer cases (to meet recipient constraints), the reverse might also occur. When resources map to this element, they are free to define as many codes as necessary to cover their space and will map to "proposal, plan or order". Can have multiple codes that map to one of these. E.g. "original order", "encoded order", "reflex order" would all map to "order". Expectation is that the set of codes is mutually exclusive or a strict all-encompassing hierarchy. | resource=This element is immutable. It cannot be changed for the same resource instance. It is expected that the type of requester will be restricted for different stages of a SupplyRequest. For example, Proposals can be created by a patient, relatedPerson, Practitioner or Device. Plans can be created by Practitioners, Patients, RelatedPersons and Devices. Original orders can be created by a Practitioner only. An instance-order is an instantiation of a request or order and may be used to populate Medication Administration Record. This element is labeled as a modifier because the intent alters when and how the resource is actually applicable. - requirementsUnmatched | reason=Unknown | pattern=Proposals/recommendations, plans and orders all use the same structure and can exist in the same fulfillment chain. - **Request.priority** → **SupplyRequest.priority** - definitionUnmatched | reason=Unknown | pattern=Indicates how quickly the supply request should be addressed with respect to other requests. | resource=Indicates how quickly this SupplyRequest should be addressed with respect to other requests. - **Request.category** → **SupplyRequest.category** - shortUnmatched | reason=Unknown | pattern=Partitions the supply request into one or more categories that can be used to filter searching, to govern access control and/or to guide system behavior. | resource=The kind of supply (central, non-stock, etc.) - definitionUnmatched | reason=Unknown | pattern=Partitions the supply request into one or more categories that can be used to filter searching, to govern access control and/or to guide system behavior. | resource=Category of supply, e.g. central, non-stock, etc. This is used to support work flows associated with the supply process. - requirementsUnmatched | reason=Unknown | pattern=Categorization might be done automatically (inferred by code) or manually by user assertion. The absence of a category may limit the ability to determine when the element should be handled, so strong consideration should be given to how systems will be able to determine category values for legacy data and how data that cannot be categorized will be handled. As well, some categories might not be mutually exclusive, so systems should prepare for multiple declared categories - even within a single category 'axis'. In general, there should not be a 'strong' binding ('required' or 'extensible') on the category element overall. Instead, the element can be sliced and bindings can be asserted that apply to particular repetitions. - **Request.product** → **SupplyRequest.item** - shortUnmatched | reason=Unknown | pattern=Product requested/ordered | resource=Medication, Substance, or Device requested to be supplied - definitionUnmatched | reason=Unknown | pattern=Indicates the product whose supply or manipulation is authorized by this supply request. | resource=The item that is requested to be supplied. This is either a link to a resource representing the details of the item or a code that identifies the item from a known list. - **Request.subject** → **SupplyRequest.deliverFor** - missingTypes | reason=Unknown | pattern=Reference(Group) - summary | reason=Unknown | pattern=true - shortUnmatched | reason=Unknown | pattern=Individual the service is ordered/prohibited for | resource=The patient for who the supply request is for - definitionUnmatched | reason=Unknown | pattern=The individual or set of individuals the action is to be performed/not performed on or for. | resource=The patient to whom the supply will be given or for whom they will be used. - requirementsUnmatched | reason=Unknown | pattern=Links the request to the Patient context. - **Request.occurrence[x]** → **SupplyRequest.occurrence[x]** - shortUnmatched | reason=Unknown | pattern=When service should (not) occur | resource=When the request should be fulfilled - definitionUnmatched | reason=Unknown | pattern=The date or time(s) at which the activity or service is desired to occur or not occur. | resource=When the request should be fulfilled. - **Request.authoredOn** → **SupplyRequest.authoredOn** - shortUnmatched | reason=Unknown | pattern=When request was created/transitioned to active | resource=When the request was made - definitionUnmatched | reason=Unknown | pattern=For draft supply requests, indicates the date of initial creation. For requests with other statuses, indicates the date of activation. | resource=When the request was made. - **Request.requester** → **SupplyRequest.requester** - extraTypes | reason=Unknown - shortUnmatched | reason=Unknown | pattern=Who/what is requesting service | resource=Individual making the request - definitionUnmatched | reason=Unknown | pattern=Who initiated the {{request}} and has responsibility for its activation. | resource=The device, practitioner, etc. who initiated the request. - **Request.performer** → **SupplyRequest.supplier** - missingTypes | reason=Unknown | pattern=Reference(Practitioner, PractitionerRole, CareTeam, Patient, Device, RelatedPerson) - shortUnmatched | reason=Unknown | pattern=Specific desired (non)performer | resource=Who is intended to fulfill the request - definitionUnmatched | reason=Unknown | pattern=Indicates who or what is being asked to perform (or not perform) the {{request}}. | resource=Who is intended to fulfill the request. - **Request.deliverTo** → **SupplyRequest.deliverTo** - missingTypes | reason=Unknown | pattern=Reference(Practitioner, PractitionerRole, HealthcareService, CareTeam, Device, Endpoint) - summary | reason=Unknown | pattern=true - shortUnmatched | reason=Unknown | pattern=Who should receive result of supply request | resource=The destination of the supply - definitionUnmatched | reason=Unknown | pattern=Identifies the entity(ies) who should receive the results of executing the supply request (or the location to which the results should be delivered). | resource=Where the supply is destined to go. - **Request.reason** → **SupplyRequest.reason** - summary | reason=Unknown | pattern=true - shortUnmatched | reason=Unknown | pattern=Why is service (not) needed? | resource=The reason why the supply item was requested - definitionUnmatched | reason=Unknown | pattern=Describes why the request is being made in coded or textual form, or Indicates another resource whose existence justifies this request. | resource=The reason why the supply item was requested. - commentsUnmatched | reason=Unknown | pattern=Textual reasons can be captured using reasonCode.text. If doNoPerform is true, this will be the reason why the request is being made to not act. ### Unmapped Elements - **Request.insurance** — Unknown - **Request.supportingInfo** — Unknown - **Request.note** — Unknown - **Request.encounter** — Unknown - **Request.reported** — Unknown - **Request.relevantHistory** — Unknown - **Request.code** — Unknown - **Request.statusReason** — Unknown - **Request.performerType** — Unknown - **Request.doNotPerform** — Unknown