This page is part of the FHIR Specification (v0.11: DSTU 1 Ballot 3). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions

Resource DiagnosticOrder - Content 4.17

A request for a diagnostic investigation service to be performed.

The resource name as it appears in a RESTful URL is [root]/diagnosticorder/

A Diagnostic Order is a record of a request for a set of diagnostic investigations to be performed. The investigation will lead to a Diagnostic Report that summarizes the outcome of the investigation, and includes any useful data and/or images that are relevant to the treatment/management of the subject.

The principal intention of the Diagnostic Order is to support ordering diagnostic investigations on patients (which includes non-human patients in veterinary medicine). However in many contexts, healthcare related processes include performing diagnostic investigations on groups of subjects, devices involved in the provision of healthcare, and even environmental locations such as ducts, bodies of water, etc. The Diagnostic Order supports all these usages.

The general work flow that this resource facilitates is that a clinical system creates a diagnostic order. The diagnostic order is then exchanged, perhaps via intermediaries, with a system that represents a diagnostic service that can perform the investigation as a request to do so. The diagnostic service will update the request as the work is performed, and then finally issue a report that references the requests that it fulfills.

Note that the Diagnostic Order itself is not a request to perform the investigation - it is just a record of the fact that a request was made. The Diagnostic Request must be paired with an Order resource to convey the actual instruction, or part of an explicit messaging or service workflow that carries the instruction.

Resource Content 4.17.1

<DiagnosticOrder xmlns="http://hl7.org/fhir">
 <!-- from Resource: extension, narrative, and contained -->
 <subject><!-- 1..1 Resource(Patient|Group|Location|Device) Who/what test is about --></subject>
 <orderer><!-- 0..1 Resource(Practitioner) Who ordered the test --></orderer>
 <identifier><!-- 0..* Identifier Identifiers assigned to this order --></identifier>
 <encounter><!-- 0..1 Resource(Encounter) The encounter that this diagnostic order is associated with --></encounter>
 <clinicalNotes value="[string]"/><!-- 0..1 Explanation/Justification for test -->
 <specimen><!-- 0..* Resource(Specimen) If the whole order relates to specific specimens --></specimen>
 <status value="[code]"/><!-- 0..1 requested | received | accepted | inprogress | review | complete | suspended | rejected | failed -->
 <priority value="[code]"/><!-- 0..1 normal | urgent | stat -->
 <event>  <!-- 0..* A list of events of interest in the lifecycle -->
  <status value="[code]"/><!-- 1..1 requested | received | accepted | inprogress | review | complete | suspended | rejected | failed -->
  <date value="[dateTime]"/><!-- 1..1 The date at which the event happened -->
  <actor><!-- 0..1 Resource(Practitioner|Device) Who recorded or did this --></actor>
 </event>
 <item>  <!-- 0..* The items the orderer requested -->
  <code><!-- 1..1 CodeableConcept Code for this item --></code>
  <specimen><!-- 0..* Resource(Specimen) If this item relates to specific specimens --></specimen>
  <bodySite><!-- 0..1 CodeableConcept Location of requested test (if applicable) --></bodySite>
  <status value="[code]"/><!-- 0..1 requested | received | accepted | inprogress | review | complete | suspended | rejected | failed -->
  <event><!-- 0..* Content as for DiagnosticOrder.event Events specific to this item --></event>
 </item>
</DiagnosticOrder>

Alternate definitions: Schema/Schematron, Resource Profile

Terminology Bindings 4.17.1.1

Path	Definition	Type	Reference
DiagnosticOrder.status DiagnosticOrder.event.status DiagnosticOrder.item.status	The status of a diagnostic order	Fixed	http://hl7.org/fhir/diagnostic-order-status
DiagnosticOrder.priority	The clinical priority of a diagnostic order	Fixed	http://hl7.org/fhir/diagnostic-order-priority
DiagnosticOrder.item.code	Codes for tests/services that can be performed by diagnostic services	Example	http://hl7.org/fhir/vs/diagnostic-requests
DiagnosticOrder.item.bodySite	Codes describing anatomical locations. May include laterality	Example	http://hl7.org/fhir/vs/body-site

Notes: 4.17.2

• In normal practice, there would always be at least one item in a request (no point requesting nothing), but the minimum cardinality is 0 so that a workflow can quote order details (identifiers, requester) without having to list the items
• Typically the system placing the order sets the status to requested. There after, the order is maintained by the receiver that updates the status as the request is processed
• If the request has multiple items that have their own life cycles, then the items will have their own status while the overall diagnostic order is (usually) "in progress"
• The event list is not the same as an audit trail - it is a view of the important things that happened in the past. Typically, there would only be one entry for any given status, and systems may not record all the status events
• Many investigation requests will create a need for specimens, but in these cases, the request itself is not actually about the specimens. This specimen elements in this resource are provided for when the diagnostic investigation is requested on already existing specimens
• A single specimen should not appear in both DiagnosticOrder.specimen and DiagnosticOrder.item.specimen
• The clinical notes may be used to decide how the diagnostic investigation will be performed, or even if it will be performed at all

Search Parameters 4.17.3

Search Parameters for RESTful searches. The standard parameters also apply. See Searching for more information.

Name / Type	Description	Paths
_id : token	The logical resource id associated with the resource (must be supported by all servers)
actor : reference	Who recorded or did this	DiagnosticOrder.event.actor, DiagnosticOrder.item.event.actor
bodysite : token	Location of requested test (if applicable)	DiagnosticOrder.item.bodySite
code : token	Code for this item	DiagnosticOrder.item.code
date : date	The date at which the event happened	DiagnosticOrder.event.date
encounter : reference	The encounter that this diagnostic order is associated with	DiagnosticOrder.encounter
identifier : token	Identifiers assigned to this order	DiagnosticOrder.identifier
item-date : date	The date at which the event happened	DiagnosticOrder.item.event.date
item-past-status : token	requested | received | accepted | inprogress | review | complete | suspended | rejected | failed	DiagnosticOrder.item.event.status
item-status : token	requested | received | accepted | inprogress | review | complete | suspended | rejected | failed	DiagnosticOrder.item.status
item-status-date : composite	A combination of item-past-status and item-date
orderer : reference	Who ordered the test	DiagnosticOrder.orderer
past-status : token	requested | received | accepted | inprogress | review | complete | suspended | rejected | failed	DiagnosticOrder.event.status
specimen : reference	If the whole order relates to specific specimens	DiagnosticOrder.specimen, DiagnosticOrder.item.specimen
status : token	requested | received | accepted | inprogress | review | complete | suspended | rejected | failed	DiagnosticOrder.status
status-date : composite	A combination of past-status and date
subject : reference	Who/what test is about	DiagnosticOrder.subject