View raw Markdown
type: resourceresource: SupplyDelivery

SupplyDelivery

Introduction

Scope and Usage

[%stu-note dstu%] This resource can represent different stages of supply delivery. After a request to create two separate resources to address dispatch vs. reception, current discussion concluded that one resource with multiple, extensible stages provided a better approach to support the variety of needs to document the different steps. HL7 seeks specific feedback on the implementability of one resource type with multiple stages (likely represented in a future IG with specific profiles to determine specific attributes/value sets applicable to each stage - see valueset-supplydelivery-stage), or whether two (or more) resource types would be more adequate. [%end-note%]

This resource is an event resource from a FHIR workflow perspective - see Workflow. It is the intent of the Orders and Observation Workgroup to align this resource with the workflow pattern for event resources.

The SupplyDelivery is used to document the dispatch (e.g., time of dispatch, content) and/or receipt (e.g., time or receipt, content) of, e.g., supplies, people, devices, patients, biologically derived products. This includes delivery of supplies within or across institution such as transport a set of supplies from materials management to a service unit, e.g., nurse station, or biologically derived products from the supplier to the hospital. This resource does not include the provisioning of transportation services. The SupplyDelivery does not imply that this supply has already been dispensed to the that patient or person, while it could be reserved for that patient or person. Those associations are done in dedicated resources such as the MedicationDispense and DeviceDispense.

Sample use cases include:

The SupplyDelivery enables the documentation of the one or more relevant stages, such as dispatch of and reception of a shipment. One may opt to document multiple stages given a particular use case, e.g., shipments of biologically derived products in a tightly controlled process, or only use a singular stage to summarize the shipment. Examples would include the dispatch and reception stages that in certain use cases need to be documented separately using two or more instances.

Boundaries and Relationships

The DeviceDispense and MedicationDispense resources are used to associate the device or medication with the specific patient for their use, while SupplyDelivery is solely focused on location and movement where the targeted patient or other person (e.g., devices used by a clinician), if included, are for delivery context only.

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.

The Transport resource documents the movement of the supplies, people, patients, etc. between dispatch and receipt including, e.g., time of movement, transporter, average temperature during transport.

Notes

Workflow Considerations

The SupplyDelivery resource captures events associated with the movement of bulk supplies. It is used to document supply chain events including dispatch and reception.

The SupplyDelivery.stage element shall be used to indicate which workflow stage is being represented.

Returns are handled in a similar way as a dispatch and reception events.

For some SupplyDelivery instances there is a specific need to articulate if the event represents a dispatch or receipt, due to unique traceability requirements inherent to some transported products. This is particularly true when dispatch and receipt occurs across organizational boundaries with each party only having their "half" of the conversation. SupplyDelivery can be used for these events through the use of the SupplyDelivery.stage element.

It is intended that a delivery and subsequent return would be documented as two different instances of the SupplyDelivery resource. In workflow terms a SupplyDelivery is the response to a SupplyRequest, and in the case of a return, you would still have a SupplyRequest initiating that return. The SupplyDelivery instances represent one or more distinct stages of the response to a SupplyRequest from beginning to end, and receiving the product (even if you will ultimately ship it back) is a terminal event.

Some connected systems would see both instances of the SupplyDelivery events while others would only see the portion their organization is responsible for.

Examples:

Blood stock replenishment:

  1. A hospital transfusion laboratory places a SupplyRequest order for blood stock replenishment. The order is for 40 x O+ red blood cells, 35 x A+ red cells, 10 x O- red cells and 10 x A- red cells.
  2. The community blood bank receives the order and prepares the consignment. A SupplyDelivery representing a dispatch event is created that corresponds to the physical dispatch advice note.
  3. On receipt of the consignment the transfusion laboratory inspects and scans each received unit, and a SupplyDelivery representing the receipt event is created.

Hospital consumables:

  1. A service unit (hospital ward) needs to re-stock a number of consumables - 5 packs disposable hand towels, 200 disposable cups, and 100 disposable plates.
  2. A request is issued from the ward manager to materials management (SupplyRequest). The SupplyRequest has identifier MM278145.
  3. Materials management select the items and prepare them for delivery along with a dispatch document (SupplyDelivery stage=dispatch).
  4. The delivery is transported from materials management to the ward.
  5. Ward staff receive the delivery, check the physical items against the dispatch record and document the receipt (SupplyDelivery stage=reception).

StructureDefinition

Elements (Simplified)

Mappings

Implementation Guide

implementationguide-SupplyDelivery-core.xml

<?xml version="1.0" encoding="UTF-8"?>

<ImplementationGuide xmlns="http://hl7.org/fhir">
  <id value="SupplyDelivery-core"/>
  <extension url="http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm">
    <valueInteger value="5"/>
  </extension>
  <identifier>
    <system value="urn:ietf:rfc:3986"/>
    <value value="urn:oid:2.16.840.1.113883.4.642.30.4"/>
  </identifier>
  <version value="0.01"/>
  <name value="SupplyDeliveryStages"/>
  <title value="SupplyDelivery Profiles"/>
  <status value="draft"/>
  <date value="2018-08-11T08:17:46.560"/>
  <publisher value="Health Level Seven International (Orders and Observations Workgroup)"/>
  <description value="Defines constraints and extensions on the SupplyDelivery resource."/>
</ImplementationGuide>

Resource Packs

list-SupplyDelivery-packs.xml

<?xml version="1.0" encoding="UTF-8"?>

<List xmlns="http://hl7.org/fhir">
  <id value="SupplyDelivery-packs"/>
  <status value="current"/>
  <mode value="working"/>
  <entry>
    <item>
      <reference value="ImplementationGuide/SupplyDelivery-core"/>
    </item>
  </entry>
</List>

Search Parameters

Full Search Parameters

Examples

Full Examples

Mapping Exceptions

supplydelivery-event-mapping-exceptions.xml

Divergent Elements

[The allowed reference resources may be adjusted as appropriate for the event resource].

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. | resource=This element is labeled as a modifier because the status contains codes that mark the resource as not currently valid.

Unmapped Elements

supplydelivery-fivews-mapping-exceptions.xml

Unmapped Elements