This page is part of the FHIR Specification (v1.8.0: STU 3 Draft). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions
Detailed Descriptions for the elements in the DiagnosticRequest resource.
DiagnosticRequest | |
Definition | A record of a request for a diagnostic investigation service to be performed. |
Control | 1..1 |
DiagnosticRequest.identifier | |
Definition | Identifiers assigned to this order instance by the orderer and/or the receiver and/or order fulfiller. |
Note | This is a business identifer, not a resource identifier (see discussion) |
Control | 0..* |
Type | Identifier |
Summary | true |
Comments | The identifier.type element is used to distinguish between the identifiers assigned by the orderer (known as the 'Placer' in HL7 v2) and the producer of the observations in response to the order (known as the 'Filler' in HL7 v2). For further discussion and examples see the notes section below. |
DiagnosticRequest.definition | |
Definition | Protocol or definition followed by this request. |
Control | 0..* |
Type | Reference(Any) |
Summary | true |
DiagnosticRequest.basedOn | |
Definition | Plan/proposal/order fulfilled by this request. |
Control | 0..* |
Type | Reference(Any) |
Summary | true |
DiagnosticRequest.replaces | |
Definition | The request takes the place of the referenced completed or terminated request(s). |
Control | 0..* |
Type | Reference(Any) |
Summary | true |
DiagnosticRequest.requisition | |
Definition | A shared identifier common to all diagnostic requests that were authorized more or less simultaneously by a single author, representing the composite or group identifier. |
Control | 0..1 |
Type | Identifier |
Requirements | Some business processes need to know if multiple items were ordered as part of the same "requisition" for billing or other purposes. |
Alternate Names | grouperId; groupIdentifier |
Summary | true |
Comments | 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. |
DiagnosticRequest.status | |
Definition | The status of the order. |
Control | 1..1 |
Terminology Binding | RequestStatus (Required) |
Type | code |
Is Modifier | true |
Summary | true |
Comments | 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 or suspended. 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. |
DiagnosticRequest.intent | |
Definition | Whether the request is a proposal, plan, an original order or a reflex order. |
Control | 1..1 |
Terminology Binding | RequestIntent (Required) |
Type | code |
Is Modifier | true |
Summary | true |
DiagnosticRequest.priority | |
Definition | Indicates how quickly the {{title}} should be addressed with respect to other requests. |
Control | 0..1 |
Terminology Binding | RequestPriority (Required) |
Type | code |
Meaning if Missing | If missing, this task should be performed with normal priority |
Summary | true |
DiagnosticRequest.code | |
Definition | A code that identifies a particular diagnostic investigation, or panel of investigations, that have been requested. |
Control | 1..1 |
Terminology Binding | LOINC Diagnostic Request Codes (Preferred) |
Type | CodeableConcept |
Summary | true |
Comments | Many laboratory tests and radiology tests embed the specimen/organ system in the test name, for example, serum or serum/plasma glucose, or a chest xray. The specimen may not be recorded separately from the test code. |
DiagnosticRequest.subject | |
Definition | On whom or what the investigation is to be performed. This is usually a human patient, but diagnostic tests can also be requested on animals, groups of humans or animals, devices such as dialysis machines, or even locations (typically for environmental scans). |
Control | 1..1 |
Type | Reference(Patient | Group | Location | Device) |
Summary | true |
DiagnosticRequest.context | |
Definition | An encounter or episode of care that provides additional information about the healthcare context in which this request is made. |
Control | 0..1 |
Type | Reference(Encounter | EpisodeOfCare) |
Summary | true |
DiagnosticRequest.occurrence[x] | |
Definition | The date/time at which the diagnostic testing should occur. |
Control | 0..1 |
Type | dateTime|Period|Timing |
[x] Note | See Choice of Data Types for further information about how to use [x] |
Summary | true |
DiagnosticRequest.authoredOn | |
Definition | When the request transitioned to being actionable. |
Control | 0..1 |
Type | dateTime |
Summary | true |
DiagnosticRequest.requester | |
Definition | Who/what is requesting diagnostics. The practitioner that holds legal responsibility for ordering the investigation. |
Control | 0..1 |
Type | Reference(Device | Practitioner | Organization) |
Summary | true |
Comments | This not the dispatcher, but rather who is authorizing. |
DiagnosticRequest.performerType | |
Definition | Desired type of performer for doing the diagnostic testing. (. |
Control | 0..1 |
Terminology Binding | Participant Roles (Example) |
Type | CodeableConcept |
Summary | true |
Comments | this is a role, not aparticipation type. I.e. doesn’t describe the task, describes the capacity. Examples “compounding pharmacy” or “psychiatrist” or “internal referral”. |
DiagnosticRequest.performer | |
Definition | The desired perfomer for doing the diagnostic testing. |
Control | 0..1 |
Type | Reference(Practitioner | Organization | Patient | Device | RelatedPerson) |
Summary | true |
Comments | Use an extension or listing alternative alternative performers and/or roles and/or preference. |
DiagnosticRequest.reasonCode | |
Definition | An explanation or justification for why this diagnostic investigation is being requested in coded or textual form. This is often for billing purposes. May relate to the resources referred to in supportingInformation. |
Control | 0..* |
Terminology Binding | Condition/Problem/Diagnosis Codes (Example) |
Type | CodeableConcept |
Summary | true |
Comments | This may be used to decide how the diagnostic investigation will be performed, or even if it will be performed at all. Use CodeableConcept text element if the data is free (uncoded) text as shown in the CT Scan example. |
DiagnosticRequest.reasonReference | |
Definition | Indicates another resource that provides a justification for why this diagnostic investigation is being requested. May relate to the resources referred to in supportingInformation. |
Control | 0..* |
Type | Reference(Condition | Observation) |
Summary | true |
Comments | This may be used to decide how the diagnostic investigation will be performed, or even if it will be performed at all. Use CodeableConcept text element if the data is free (uncoded) text as shown in the CT Scan example. |
DiagnosticRequest.supportingInformation | |
Definition | Additional clinical information about the patient or specimen that may influence test interpretations. This includes observations explicitly requested by the producer(filler) to provide context or supporting information needed to complete the order. |
Control | 0..* |
Type | Reference(Any) |
Alternate Names | Ask at order entry question; AOE |
Comments | This information includes diagnosis, clinical findings and other observations. In laboratory ordering these are typically referred to as "ask at order entry questions (AOEs)". Examples include reporting the amount of inspired oxygen for blood gasses, the point in the menstrual cycle for cervical pap tests, and other conditions that influence test interpretations. |
DiagnosticRequest.note | |
Definition | Any other notes and comments made about the service request. (e.g. "patient hates needles"). |
Control | 0..* |
Type | Annotation |
DiagnosticRequest.relevantHistory | |
Definition | Key events in the history of the request. |
Control | 0..* |
Type | Reference(Provenance) |
Comments | 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. |