Record of transport of item.

Identifier for the transport event that is used to identify it across multiple disparate systems.

This identifier is typically assigned by the dispenser, and may be used to reference the delivery when exchanging information about it with other systems.

The URL pointing to a FHIR-defined protocol, guideline, orderset or other definition that is adhered to in whole or in part by this Transport.

Enables a formal definition of how the transport is to be performed, enabling automation.

The URL pointing to an externally maintained protocol, guideline, orderset or other definition that is adhered to in whole or in part by this Transport.

Enables a formal definition of how the transport is to be performed (e.g. using BPMN, BPEL, XPDL or other formal notation to be associated with a transport), enabling automation.

BasedOn refers to a higher-level authorization that triggered the creation of the transport. It references a "request" resource such as a ServiceRequest or Transport, which is distinct from the "request" resource the Transport is seeking to fulfill. This latter resource is referenced by FocusOn. For example, based on a ServiceRequest (= BasedOn), a transport is created to fulfill a procedureRequest ( = FocusOn ) to transport a specimen to the lab.

An identifier that links together multiple transports and other requests that were created in the same context.

Billing and/or reporting can be linked to whether multiple requests were created as a single unit.

A larger event of which this particular event is a component or step.

E.g. Drug administration as part of a procedure, procedure as part of observation, etc.

Not to be used to link an event to an Encounter - use Event.context for that.

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

A code specifying the state of the transport event.

An explanation as to why this transport is held, failed, was refused, etc.

This applies to the current status. Look at the history of the transport to see reasons for past statuses.

Indicates the "level" of actionability associated with the Transport, i.e. i+R[9]Cs this a proposed transport, a planned transport, an actionable transport, etc.

This element is immutable. Proposed transports, planned transports, etc. must be distinct instances.

In most cases, Transports will have an intent of "order".

Indicates how quickly the Transport should be addressed with respect to other requests.

Used to identify the service level expected while performing a transport.

A name or code (or both) briefly describing what the transport involves.

The title (eg "My Transports", "Outstanding Transports for Patient X") should go into the code.

A free-text description of what is to be performed.

The request being actioned or the resource being manipulated by this transport.

Used to identify the thing to be done.

If multiple resources need to be manipulated, use sub-transports. (This ensures that status can be tracked independently for each referenced resource.).

The entity who benefits from the performance of the service specified in the transport (e.g., the patient).

Used to track transports outstanding for a beneficiary. Do not use to track the transport owner or creator (see owner and creator respectively). This can also affect access control.

The healthcare event (e.g. a patient and healthcare provider interaction) during which this transport was created.

For some transports it may be important to know the link between the encounter the transport originated within.

Identifies the completion time of the event (the occurrence).

The date and time this transport was created.

Most often used along with lastUpdated to track duration of the transport to supporting monitoring and management.

The date and time of last modification to this transport.

Used along with history to track transport activity and time in a particular transport state. This enables monitoring and management.

The creator of the transport.

Identifies who created this transport. May be used by access control mechanisms (e.g., to ensure that only the creator can cancel a transport).

The kind of participant that should perform the transport.

Use to distinguish transports on different activity queues.

Individual organization or Device currently responsible for transport execution.

Identifies who is expected to perform this transport.

Transports may be created with an owner not yet identified.

Principal physical location where this transport is performed.

Ties the event to where the records are likely kept and provides context around the event occurrence (e.g. if it occurred inside or outside a dedicated healthcare setting).

Insurance plans, coverage extensions, pre-authorizations and/or pre-determinations that may be relevant to the Transport.

Free-text information captured about the transport as it progresses.

Links to Provenance records for past versions of this Transport that identify key state transitions or updates that are likely to be relevant to a user looking at the current version of the transport.

This element does not point to the Provenance associated with the current version of the resource - as it would be created after this version existed. The Provenance for the current version can be retrieved with a _revinclude.

If the Transport.focus is a request resource and the transport is seeking fulfillment (i.e. is asking for the request to be actioned), this element identifies any limitations on what parts of the referenced request should be actioned.

Sometimes when fulfillment is sought, you don't want full fulfillment.

Indicates the number of times the requested action should occur.

E.g. order that requests monthly lab tests, fulfillment is sought for 1.

Over what time-period is fulfillment sought.

E.g. order that authorizes 1 year's services. Fulfillment is sought for next 3 months.

Note that period.high is the due date representing the time by which the transport should be completed.

For requests that are targeted to more than one potential recipient/target, to identify who is fulfillment is sought for.

Additional information that may be needed in the execution of the transport.

Resources and data used to perform the transport. This data is used in the business logic of transport execution, and is stored separately because it varies between workflows.

A code or description indicating how the input is intended to be used as part of the transport execution.

Inputs are named to enable transport automation to bind data and pass it from one transport to the next.

If referencing a BPMN workflow or Protocol, the "system" is the URL for the workflow definition and the code is the "name" of the required input.

The value of the input parameter as a basic type.

Outputs produced by the Transport.

Resources and data produced during the execution the transport. This data is generated by the business logic of transport execution, and is stored separately because it varies between workflows.

The name of the Output parameter.

Outputs are named to enable transport automation to bind data and pass it from one transport to the next.

The value of the Output parameter as a basic type.

Transport outputs can take any form.

The desired or final location for the transport.

The current location for the entity to be transported.

A description or code indicating why this transport needs to be performed.

This should only be included if there is no focus or if it differs from the reason indicated on the focus.

A resource reference indicating why this transport needs to be performed.

Transports might be justified based on an Observation, a Condition, a past or planned procedure, etc. This should only be included if there is no focus or if it differs from the reason indicated on the focus. Use the CodeableConcept text element in Transport.reasonCode if the data is free (uncoded) text.

The transport event prior to this one.