Supply of Products for Healthcare (SUPPLY), published by IHE Pharmacy Technical Committee. This guide is not an authorized publication; it is the continuous build for version 0.3.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/IHE/pharm-supply/ and changes regularly. See the Directory of published versions

Actors and Transactions overview

This section defines the actors and transactions in this implementation guide.

The figure below shows the actors directly involved in the MHD Profile and the relevant transactions between them.

Table : Supply - Actors and Transactions

Actors	Transactions	Optionality
Supply Requester	Supply Request [PHARM-S1]	O
	Supply Request [PHARM-S2]	O
Supply Request Filler	Supply Request [PHARM-S1]	O
	Supply Request [PHARM-S2]	O
Supplier	Supply Notice [PHARM-S3]	O
	Receipt Notice [PHARM-S4]	O
Supply Receiver	Supply Notice [PHARM-S3]	O
	Receipt Notice [PHARM-S4]	O
Inventory Reporter	Inventory Status [PHARM-S5]	O
	Inventory Update [PHARM-S6]	O
	Inventory Query [PHARM-S7]	O
Inventory Manager	Inventory Status [PHARM-S5]	O
	Inventory Update [PHARM-S6]	O
	Inventory Query [PHARM-S7]	O

---

Ordering

For the ordering aspects of supply request, two actors are considered:

Supply Requester

Issues requests for supply. The request can be triggered by any of several events - periodic reordering, minimum reached, etc.

• Sends supply request - transaction PHARM-S1.
• Receives updates on supply request status - transaction PHARM-S2.

Supply Request filler

Receives and handles the supply request. The handling can be to respond (e.g. with approval) and/or to forward the request (e.g. to the actual supplier).

• Sends updates on supply request status - transaction PHARM-S2.
• Receives supply request - transaction PHARM-S1.

These actors can be chained - in a specific implementation, a system can be both a Requester and a Request Filler. For example a local pharmacy requesting products from a local pharmacy who then contacts the local supplier who then contacts the national distributor. In this case the central pharmacy receives requests from wards or remote pharmacies, and sends approved/updated requests to the supplier or distributor (thus acting as a Request Filler and Requester in the same process). This chaining is the reason why the transactions are optional - for example an actor that is only forwarding the request after approval may implement only the Supply Request transaction, but not support receiving the status.

Delivery

The delivery considers two actors:

Supplier

The supplier sends or forwards the items to a receiver and updates the information about such sending:

• Sends shipment notices - transaction PHARM-S3.
• Receives delivery notices - transaction PHARM-S4.

Receiver

This actor represents the intended or actual receiver of the products.

• Sends delivery notices - transaction PHARM-S4.
• Receives shipment notices - transaction PHARM-S3.

These actors can also be chained in any implementation. For example, a warehouse (as a Supplier) sends items to a retailer (Receiver) who then send them (now as a Supplier) to the Central Pharmacy (which takes the role of Receiver).

Inventory

The inventory management module supports the tracking and counting of inventory items and status (i.e. inventory counts). It is consists of two essential mechanisms: Inventory status updates, and inventory consumption.

Inventory status updates concerns the monitoring and reporting of inventory locations - i.e. the availability (or not) of inventory items. The actors are:

Inventory reporter

Provides information about the inventory in a location
This actor is typically implemented by systems associated with one or several inventory location - e.g a storage area, or an automated distribution system…
An Inventory reporter can inform the present item count (snapshot mode, used for reporting stock counts), or may inform about differential updates (differential mode, used for reporting stock increase or decrease).

Inventory Manager

Receives inventory information (for the purpose of forwarding or taking further action e.g. deciding on reordering)

• Sends inventory reports - transaction PHARM-S5.
• Sends inventory updates - transaction PHARM-S6.
• Receives inventory queries - transaction PHARM-S7.

These actors are expected to be combined, depending of the system configurations and inventory management policies. For example, an automated distribution system (like a smart cart) may keep track of the items it contain on, to decide about reordering; it may also send such information (acting as as an Inventory Reporter) to another system (Inventory Manager) so that the other system can decide whether / when to reorder.

Inventory Reporter
(Item Consumer)

reports a updates of inventory (to an Inventory Manager).

Since this is a differential update of inventory, it can also used report consumption (usage) or stock increases when necessary, e.g. returning products to inventory.

Consumption: Most times a consumption is not explicitly reported, but corresponds with a dispense or administration of a product (removing it from available inventory) or a disposal. In this sense, the consumption report is just a differential update of inventory. Consumption informs of usage of inventory: When an item is taken from inventory but not necessarily associated with an administration, it is said to be consumed. These are the common cases:

• A tablet is accidentally dropped on the floor. From an inventory perspective it is consumed. For multi-use products, two options are possible:
• A bottle of disinfecting gel is put in the ward. When it is fully used, it is reported as consumed (and replaced).
• A jar of cream is picked from the ward closet to be used for a patient. Since it can be used only for that patient, it is consumed from ward inventory as soon as it is picked.

The inventory reporter:

• Sends inventory reports - transaction PHARM-S5.
• Sends inventory updates - transaction PHARM-S6.
• Receives inventory queries - transaction PHARM-S7.