Represents a request for a patient to employ a medical device. The device may be an implantable device, or an external assistive device, such as a walker.

Identifiers assigned to this order by the orderer or by the receiver.

Protocol or definition followed by this request. For example: The proposed act must be performed if the indicated conditions occur, e.g.., shortness of breath, SpO2 less than x%.

Plan/proposal/order fulfilled by this request.

The request takes the place of the referenced completed or terminated request(s).

Composite request this is part of.

The status of the request.

Whether the request is a proposal, plan, an original order or a reflex order.

The details of the device to be used.

The patient who will use the device.

An encounter that provides additional context in which this request is made.

The timing schedule for the use of the device. The Schedule data type allows many different expressions, for example. "Every 8 hours"; "Three times a day"; "1/2 an hour before breakfast for 10 days from 23-Dec 2011:"; "15 Oct 2013, 17 Oct 2013 and 1 Nov 2013".

When the request transitioned to being actionable.

Who/what is requesting diagnostics. The practitioner that holds legal responsibility for ordering the investigation.

Desired type of performer for doing the diagnostic testing.

The desired perfomer for doing the diagnostic testing.

Reason or justification for the use of this device.

Reason or justification for the use of this device.

Additional clinical information about the patient that may influence the request fulfilment. For example, this may includes body where on the subject's the device will be used ( i.e. the target site).

Knowing where the device is targeted is important for tracking if multiple sites are possible.

Details about this request that were not represented at all or sufficiently in one of the attributes provided in a class. These may include for example a comment, an instruction, or a note associated with the statement.

Key events in the history of the request.

This may not include provenances for all versions of the request – only those deemed “relevant” or important. This SHALL NOT include the Provenance associated with this current version of the resource. (If that provenance is deemed to be a “relevant” change, it will need to be added as part of a later update. Until then, it can be queried directly as the Provenance that points to this version using _revinclude All Provenances should have some historical version of this Request as their subject.