A record of a request for service such as diagnostic investigations, treatments, or operations to be performed. When the ServiceRequest is active, it represents an authorization to perform the service.

Identifiers assigned to this order instance by the orderer and/or the receiver and/or order fulfiller.

The identifier.type element is used to distinguish between the identifiers assigned by the orderer (known as the 'Placer' in HL7 v2) V2) and the producer of the observations in response to the order (known as the 'Filler' in HL7 v2). V2). For further discussion and examples see the resource notes section below.

The URL pointing to an externally maintained protocol, guideline, orderset or other definition that is adhered to in whole or in part Plan/proposal/order fulfilled by this ServiceRequest. Cardinality 0..* Type uri Summary true Comments This might be an HTML page, PDF, etc. or could just be a non-resolvable URI identifier. request.

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

A shared identifier common to all service requests that were authorized more or less simultaneously by a single author, representing the composite or group identifier.

Some business processes need to know if multiple items were ordered as part of the same "requisition" for billing or other purposes.

Requests are linked either by a "basedOn" relationship (i.e. one request is fulfilling another) or by having a common requisition. Requests that are part of the same requisition are generally treated independently from the perspective of changing their state or maintaining them after initial creation.

The status of the order.

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, competed, cancelled revoked or suspended. placed on-hold. States relating to the activities of the performer are reflected on either the corresponding event (see Event Pattern for general discussion) or using the Task resource.

Provides reason why the service request status is what it is. The statusReason can be used to explain why a service request is suspended, cancelled, or on hold, including administrative and clinical reasons.

This is generally not present when the service request has a status of 'active' or 'completed'. There is potential overlap between ServiceRequest.reason (why the service is being requested) and ServiceRequest.statusReason (why the request is in its current status) early in the performance of the request when the reason for the service request might influence the initial status.

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

This element is labeled as expected to be immutable. E.g. A 'proposal' instance should never change to be a modifier because 'plan' instance or 'order' instance. Instead, a new instance 'basedOn' the intent alters when and how prior instance should be created with the resource new 'intent' value.

One exception to this is actually applicable. that the granularity of ServiceRequest.intent is allowed to change. For example, a ServiceRequest 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.

A code that classifies the service for searching, sorting and display purposes (e.g. "Surgical Procedure").

Used for filtering what service request are retrieved and displayed.

There may be multiple axis of categorization depending on the context or use case for retrieving or displaying the resource. The level of granularity is defined by the category concepts in the value set.

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

Set this to true if the record is saying that the service/procedure should NOT be performed.

Used for do not ambulate, do not elevate head of bed, do not flush NG tube, do not take blood pressure on a certain arm, etc.

In general, only the code and timeframe will be present, though occasional additional qualifiers such as body site or even performer could be included to narrow the scope of the prohibition. If the ServiceRequest.code and ServiceRequest.doNotPerform both contain negation, that will reinforce prohibition and should not have a double negative interpretation.

A code or reference that identifies a particular service (i.e., procedure, diagnostic investigation, or panel of investigations) that have has been requested.

Many laboratory and radiology procedure codes embed the specimen/organ system in the test order name, for example, serum or serum/plasma glucose, or a chest x-ray. The specimen might not be recorded separately from the test code. The PlanDefinition may be used when you want to group multiple activities together (e.g., order set that are part of a plan).

Additional details and instructions about the how the services are to be delivered. For example, and an order for a urinary catheter may have an order detail for an external or indwelling catheter, or an order for a bandage may require additional instructions specifying how the bandage should be applied. Questions or additional information to be gathered from a patient may be included here.

For existing information from the medical record intended to support the delivery of the requested services, use the supportingInformation element. supportingInformnation.element - e.g. to share information with the lab about a patient's age, gender, or current medications.

Indicates the context of the order details by reference.

The parameter details for the service being requested.

An amount A value representing the additional detail or instructions for the order (e.g., catheter insertion, body elevation, descriptive device configuration and/or setting instructions).

Indicates a value for example $1,500 home modification), the order detail.

CodeableConcept values are indented to express concepts that would normally be coded - when a ratio ( code is not available for example, 20 half day visits per month), a concept, CodeableConcept.text can be used. When the data is a text or not a range (2.0 to 1.8 Gy per fraction). single identifiable concept, string should be used.

An amount of service being requested.

When ordering a service the number of service items may need to be specified separately from the the service item.

The amount of service being requested can be a quantity (e.g., $1,500 for home modification request), a ratio (e.g., 20 for a request of home visits to occur each month), or a range (e.g., 8-10 for physiotherapy sessions).

On whom or what the service is to be performed. This is usually a human patient, but can also be requested on animals, groups of humans or animals, devices such as dialysis machines, or even locations (typically for environmental scans).

The actual focus of a service request when it is not the subject of record representing something or someone associated with the subject such as a spouse, parent, fetus, or donor. The focus of a service request could also be an existing condition, an intervention, the subject's diet, another service request on the subject, or a body structure such as tumor or implanted device.

An encounter that provides additional information about the healthcare context in which this request is made.

The date/time at which the requested service should occur.

Indicates that the service (e.g., procedure, lab test) should be performed when needed (Boolean option).

If a CodeableConcept is present, it indicates Indicates specific criteria that need to be met to perform the pre-condition service (e.g., lab results or symptoms).

When the request transitioned to being actionable.

The individual who initiated the request and has responsibility for its activation.

This not the dispatcher, but rather who is the authorizer. This element is not intended to handle delegation which would generally be managed through the Provenance resource. The requestor is expected to receive the provided results (if any) of the ServiceRequest. If other additional recipients of results are required, use a CommunicationRequest resource based on the ServiceRequest and with the appropriate code in the CommunicationRequest.category element. Group is only allowed in the circumstance where the group represents a family or a household, and should not represent groups of Practitioners. In those instances it is preferable to use more specific resources such as Organization.

Desired type of performer for doing the requested service.

This is a role, not a participation type. In other words, does not describe the task but describes the capacity. For example, “compounding pharmacy”, “psychiatrist” or “internal referral”.

The desired performer for doing the requested service. For example, the surgeon, dermatopathologist, endoscopist, etc.

If multiple performers are present, it is interpreted as a list of alternative performers without any preference regardless of order. If order of preference is needed use the request-performerOrder extension http://hl7.org/fhir/StructureDefinition/request-performerOrder . Use CareTeam to represent a group of performers (for example, Practitioner A and Practitioner B). Group is only allowed in the circumstance where the group represents a family or a household, and should not represent groups of Practitioners. In those instances it is preferable to use more specific resources such as Organization, CareTeam, or HealthcareService instead.

The preferred location(s) where the procedure should actually happen in coded or free text form. E.g. at home or nursing day care center.

The reason or the indication for requesting the service (e.g., procedure, lab test).

This element represents why the referral request is being made and may be used to decide how the service will be performed, or even if it will be performed at all. To be as specific as possible, a reference to Observation or Condition should be used if available. Otherwise when referencing DiagnosticReport it should contain a finding in DiagnosticReport.conclusion and/or DiagnosticReport.conclusionCode . When using a reference to DocumentReference , the target document should contain clear findings language providing the relevant reason for this service request. Use the CodeableConcept text element in ServiceRequest.reasonCode reason.concept.text element if the data is free (uncoded) text as shown in the CT Scan example .

Insurance plans, coverage extensions, pre-authorizations and/or pre-determinations that may be needed for delivering the requested service.

Additional clinical information about the patient or specimen that may influence the services or their interpretations. This information includes diagnosis, clinical findings and other observations. In laboratory ordering these are typically referred to as "ask 'ask at order entry questions (AOEs)". (AOEs).' This includes observations explicitly requested by the producer (filler) to provide context or supporting information needed to complete the order. For example, reporting the amount of inspired oxygen for blood gas measurements.

To represent information about how the services are to be delivered delivered, use the instructions orderDetail element.

One or more specimens that the laboratory procedure will use.

Many diagnostic procedures need a specimen, but Most commonly the request itself is not actually about association between the specimen. This element Specimen and ServiceRequest resources will be from the Specimen to the ServiceRequest, as usually the ServiceRequest is created first and provides the authorization for when the diagnostic specimen to be collected, and the reference to the ServiceRequest is requested recorded using the Specimen.request element. The ServiceRequest.specimen element, on the other hand, is being deprecated and is discouraged from use and is intended to be removed in a future release. In the less common cases where the specimen to be used to perform the test is already existing specimens known and available and needs to be specified at the request points time the ServiceRequest is created, it is preferable to use the new 'specimenSuggestion' extension on the ServiceRequest resource, which enables specifying a particular specimen to be used either by a direct reference, more generally by a coded concept specifying the specimen type, or by the context of another ServiceRequest and any existing specimen(s) that may be associated with that request. When a specimen is referenced, it applies to. Conversely, if is expected to be used. If for some reason the request specified specimen is entered first unable to be used (doesn't exist, wrong specimen type, insufficient quantity or quality, etc.), the decision to collect another specimen or to not perform the test must be based on established policies or determined by some other means agreed to with an unknown specimen, then the Specimen resource points requester. References to specimens for purposes other than performing a test/procedure should be made using ServiceRequest.supportingInfo or the ServiceRequest. Specimen.parent, where the Specimen.parent would enable descendency and ServiceRequest.supportingInfo provides a general reference for context.

Anatomic location where the procedure should be performed. This is the target site.

Knowing where the procedure is performed is important for tracking if multiple sites are possible.

Any other notes and comments made about the service request. For example, internal billing notes.

Instructions in terms that are understood by the patient or consumer.

Instructions in terms that are understood by the patient or consumer.

Key events in the history of the request.

This might 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.