DSTU2 STU 3 Candidate
This page is part of the FHIR Specification (v1.0.2: DSTU 2). The current version which supercedes this version is

This page is part of the FHIR Specification (v1.4.0: STU 3 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 . For a full list of available versions, see the Directory of published versions

4.22 4.33 Resource DiagnosticOrder - Content Resource DiagnosticOrder - Content

A record of a request for a diagnostic investigation service to be performed.
Orders and Observations Orders and Observations Work Group Work Group Maturity Level : 1 Maturity Level : 1 Compartments : : Device , , Encounter , , Patient , , Practitioner

A record of a request for a diagnostic investigation service to be performed.

4.22.1 Scope and Usage 4.33.1 Scope and Usage 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.

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.

4.22.2 Boundaries and Relationships 4.33.2 Boundaries and Relationships DiagnosticOrder is closely related to other types of "request" resources, particularly

DiagnosticOrder is closely related to other types of "request" resources, particularly ReferralRequest and ProcedureRequest . In fact, for some services, it may be appropriate to use any one of these resources to request that the service be performed. Which one is used may be driven by organization practice and by context. When it is unclear which to use, the following principles may be helpful: and ProcedureRequest or DiagnosticOrder are typically used when the requesting clinician has and wishes to exercise the authority (and expertise) to decide exactly what action will be done. A ReferralRequest is used when the requesting practitioner is seeking another practitioner or organization to use their own expertise and/or authority to determine the specific action to take. Whether an activity is deemed to be a procedure or only a diagnostic order is typically driven by how invasive the diagnostic process is. More invasive processes are typically represented as procedures, though the dividing line will vary by organization. Irrespective of the guidance above, systems should be prepared for some degree of overlap between these resources and be prepared to execute searches against multiple resources in cases where differentiation cannot be guaranteed. As well, in some workflows more than one type of resource or even all three might exist; e.g. Upon receiving a ReferralRequest a practitioner might initiate a DiagnosticOrder. The diagnostic service might then initiate a ProcedureRequest. The DiagnosticOrder supports references to the numerous other resources that define information about the subject - the orderer, associated encounter, specimen, body site and other supporting information. For example, . In fact, for some services, it may be appropriate to use any one of these resources to request that the service be performed. Which one is used may be driven by organization practice and by context. When it is unclear which to use, the following principles may be helpful:

  • ProcedureRequest or DiagnosticOrder are typically used when the requesting clinician has and wishes to exercise the authority (and expertise) to decide exactly what action will be done.
  • A ReferralRequest is used when the requesting practitioner is seeking another practitioner or organization to use their own expertise and/or authority to determine the specific action to take.
  • Whether an activity is deemed to be a procedure or only a diagnostic order is typically driven by how invasive the diagnostic process is. More invasive processes are typically represented as procedures, though the dividing line will vary by organization.
Irrespective of the guidance above, systems should be prepared for some degree of overlap between these resources and be prepared to execute searches against multiple resources in cases where differentiation cannot be guaranteed. As well, in some workflows more than one type of resource or even all three might exist; e.g. Upon receiving a ReferralRequest a practitioner might initiate a DiagnosticOrder. The diagnostic service might then initiate a ProcedureRequest.

The DiagnosticOrder supports references to the numerous other resources that define information about the subject - the orderer, associated encounter, specimen, body site and other supporting information. For example, Patient , , Practitioner , , Specimen and and Condition are all referenced in this resource. Some systems may choose to bundle up a DiagnosticOrder and this referenced information into a Document for delivery to the recipient. However, REST, Messaging and Services are also valid architectures for managing referrals and may be more appropriate where active workflow management is needed. The CarePlan resource can be used to describe more sophisticated requests for combinations of services and DiagnosticOrder may be referenced as part of a CarePlan. Similarly ClinicalImpression resource can reference DiagnosticOrder as part of a follow up to plan to the assessment. Note that the Diagnostic Order itself is not a request to perform the investigation - but rather a record of the fact that a request was made. To actually initiate the workflow beyond simply the existence of a Diagnostic Order may be required. This can be achieved by using an Order resource, with the Diagnostic Order referenced from the Order.details, or by using the Diagnostic are all referenced in this resource. Some systems may choose to bundle up a DiagnosticOrder and this referenced information into a Document for delivery to the recipient. However, REST, Messaging and Services are also valid architectures for managing referrals and may be more appropriate where active workflow management is needed.

The CarePlan resource can be used to describe more sophisticated requests for combinations of services and DiagnosticOrder may be referenced as part of a CarePlan. Similarly ClinicalImpression resource can reference DiagnosticOrder as part of a follow up to plan to the assessment.

Note that the Diagnostic Order itself is not a request to perform the investigation - but rather a record of the fact that a request was made. To actually initiate the workflow beyond simply the existence of a Diagnostic Order may be required. This can be achieved by using an Order resource in the context of an messaging or service workflow where the request is explicit or implicit." This resource is referenced by resource, with the Diagnostic Order referenced from the Order.details, or by using the Diagnostic Order resource in the context of an messaging or service workflow where the request is explicit or implicit."

This resource is referenced by CarePlan , , ClinicalImpression , , DiagnosticReport , , ImagingStudy and , Procedure and ReferralRequest

4.22.3 Resource Content 4.33.3 Resource Content

Structure

0..1 0..1
Name Flags Card. Type Description & Constraints Description & Constraints doco
. . DiagnosticOrder DomainResource A request for a diagnostic service A request for a diagnostic service
. . subject . identifier Σ 1..1 0..* Reference ( Patient | Group | Location | Device Identifier ) Who and/or what test is about Identifiers assigned to this order
. . orderer . status ?! Σ 0..1 Reference ( Practitioner code ) Who ordered the test proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed | entered-in-error
DiagnosticOrderStatus ( Required )
. . identifier . priority Σ 0..* 0..1 Identifier code Identifiers assigned to this order routine | urgent | stat | asap
DiagnosticOrderPriority ( Required )
. . encounter . subject Σ 0..1 1..1 Reference ( Encounter Patient | Group | Location | Device ) The encounter that this diagnostic order is associated with Who and/or what test is about
. . reason . encounter 0..* Σ CodeableConcept 0..1 Explanation/Justification for test Condition/Problem/Diagnosis Codes Reference ( Example Encounter ) The encounter that this diagnostic order is associated with
. . supportingInformation . orderer Σ 0..* 0..1 Reference ( Observation | Condition | DocumentReference Practitioner ) Additional clinical information Who ordered the test
. . specimen . reason 0..* Reference ( Specimen CodeableConcept ) If the whole order relates to specific specimens Explanation/Justification for test
Condition/Problem/Diagnosis Codes ( Example )
. . status . supportingInformation ?! Σ code 0..* proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed DiagnosticOrderStatus Reference ( Required Observation | Condition | DocumentReference ) Additional clinical information
. . priority . specimen Σ code 0..* routine | urgent | stat | asap DiagnosticOrderPriority Reference ( Required Specimen ) If the whole order relates to specific specimens
. . . event 0..* BackboneElement A list of events of interest in the lifecycle A list of events of interest in the lifecycle
. . . . status Σ 1..1 code proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed | entered-in-error
DiagnosticOrderStatus ( ( Required )
. . . . description Σ 0..1 CodeableConcept More information about the event and its context More information about the event and its context
Diagnostic Order Event Codes ( Diagnostic Order Event Codes ( Example )
. . . . dateTime Σ 1..1 dateTime The date at which the event happened The date at which the event happened
. . . . actor 0..1 Reference ( Practitioner | | Device ) Who recorded or did this Who recorded or did this
. . . item 0..* BackboneElement The items the orderer requested The items the orderer requested
. . . . code Σ 1..1 CodeableConcept Code to indicate the item (test or panel) being ordered Code to indicate the item (test or panel) being ordered
LOINC Diagnostic Order Codes ( LOINC Diagnostic Order Codes ( Preferred )
. . . . specimen 0..* Reference ( Specimen ) If this item relates to specific specimens If this item relates to specific specimens
. . . . bodySite 0..1 CodeableConcept Location of requested test (if applicable) Location of requested test (if applicable)
SNOMED CT Body Structures ( SNOMED CT Body Structures ( Example )
. . . . status Σ 0..1 code proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed | entered-in-error
DiagnosticOrderStatus ( ( Required )
. . . . event Σ 0..* see see event Events specific to this item Events specific to this item
. . . note 0..* Annotation Other notes and comments Other notes and comments

Documentation for this format doco Documentation for this format

UML Diagram UML Diagram

DiagnosticOrder ( ( DomainResource ) Identifiers assigned to this order instance by the orderer and/or the receiver and/or order fulfiller identifier : Identifier [0..*] The status of the order (this element modifies the meaning of other elements) status : code [0..1] « The status of a diagnostic order. (Strength=Required) DiagnosticOrderStatus ! » The clinical priority associated with this order priority : code [0..1] « The clinical priority of a diagnostic order. (Strength=Required) DiagnosticOrderPriority ! » Who or what the investigation is to be performed on. 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) 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) subject : : Reference [1..1] « [1..1] « Patient | Group | Location | Device » » The practitioner that holds legal responsibility for ordering the investigation An encounter that provides additional information about the healthcare context in which this request is made orderer : encounter : Reference [0..1] « Practitioner » Identifiers assigned to this order instance by the orderer and/or the receiver and/or order fulfiller identifier : Identifier [0..*] [0..1] « Encounter » An encounter that provides additional information about the healthcare context in which this request is made The practitioner that holds legal responsibility for ordering the investigation encounter : orderer : Reference [0..1] « Encounter » [0..1] « Practitioner » An explanation or justification for why this diagnostic investigation is being requested. This is often for billing purposes. May relate to the resources referred to in supportingInformation An explanation or justification for why this diagnostic investigation is being requested. This is often for billing purposes. May relate to the resources referred to in supportingInformation reason : : CodeableConcept [0..*] « [0..*] « Diagnosis or problem codes justifying the reason for requesting the diagnostic investigation. (Strength=Example) Diagnosis or problem codes justifying the reason for requesting the diagnostic investigation. (Strength=Example) Condition/Problem/Diagnosis ?? » Condition/Problem/Diagnosis ?? » 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 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 supportingInformation : : Reference [0..*] « [0..*] « Observation | Condition | DocumentReference » » One or more specimens that the diagnostic investigation is about One or more specimens that the diagnostic investigation is about specimen : : Reference [0..*] « [0..*] « Specimen » The status of the order (this element modifies the meaning of other elements) status : code [0..1] « The status of a diagnostic order. (Strength=Required) DiagnosticOrderStatus ! » The clinical priority associated with this order priority : code [0..1] « The clinical priority of a diagnostic order. (Strength=Required) DiagnosticOrderPriority ! » » Any other notes associated with this patient, specimen or order (e.g. "patient hates needles") Any other notes associated with this patient, specimen or order (e.g. "patient hates needles") note : : Annotation [0..*] [0..*] Event The status for the event The status for the event status : : code [1..1] « [1..1] « The status of a diagnostic order. (Strength=Required) The status of a diagnostic order. (Strength=Required) DiagnosticOrderStatus ! » ! » Additional information about the event that occurred - e.g. if the status remained unchanged Additional information about the event that occurred - e.g. if the status remained unchanged description : : CodeableConcept [0..1] « [0..1] « Additional information about an event that occurred to a diagnostic order - e.g. if the status remained unchanged. (Strength=Example) Additional information about an event that occurred to a diagnostic order - e.g. if the status remained unchanged. (Strength=Example) Diagnostic Order Event ?? » Diagnostic Order Event ?? » The date/time at which the event occurred The date/time at which the event occurred dateTime : : dateTime [1..1] [1..1] The person responsible for performing or recording the action The person responsible for performing or recording the action actor : : Reference [0..1] « [0..1] « Practitioner | Device » » Item A code that identifies a particular diagnostic investigation, or panel of investigations, that have been requested A code that identifies a particular diagnostic investigation, or panel of investigations, that have been requested code : : CodeableConcept [1..1] « [1..1] « Codes for tests/services that can be performed by diagnostic services. (Strength=Preferred) Codes for tests/services that can be performed by diagnostic services. (Strength=Preferred) LOINC Diagnostic Order ? » LOINC Diagnostic Order ? » If the item is related to a specific specimen If the item is related to a specific specimen specimen : : Reference [0..*] « [0..*] « Specimen » » Anatomical location where the request test should be performed. This is the target site Anatomical location where the request test should be performed. This is the target site bodySite : : CodeableConcept [0..1] « [0..1] « Codes describing anatomical locations. May include laterality. (Strength=Example) Codes describing anatomical locations. May include laterality. (Strength=Example) SNOMED CT Body Structures SNOMED CT Body Structures ?? » ?? » The status of this individual item within the order The status of this individual item within the order status : : code [0..1] « [0..1] « The status of a diagnostic order. (Strength=Required) The status of a diagnostic order. (Strength=Required) DiagnosticOrderStatus ! » ! » A summary of the events of interest that have occurred as the request is processed; e.g. when the order was made, various processing steps (specimens received), when it was completed A summary of the events of interest that have occurred as the request is processed; e.g. when the order was made, various processing steps (specimens received), when it was completed event [0..*] A summary of the events of interest that have occurred as this item of the request is processed A summary of the events of interest that have occurred as this item of the request is processed event [0..*] The specific diagnostic investigations that are requested as part of this request. Sometimes, there can only be one item per request, but in most contexts, more than one investigation can be requested The specific diagnostic investigations that are requested as part of this request. Sometimes, there can only be one item per request, but in most contexts, more than one investigation can be requested item [0..*]

XML Template XML Template 

<DiagnosticOrder xmlns="http://hl7.org/fhir"> doco
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <</subject>
 <</orderer>

 <identifier><!-- 0..* Identifier Identifiers assigned to this order --></identifier>
 <status value="[code]"/><!-- 0..1 proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed | entered-in-error -->
 <priority value="[code]"/><!-- 0..1 routine | urgent | stat | asap -->
 <subject><!-- 1..1 Reference(Patient|Group|Location|Device) Who and/or what test is about --></subject>

 <encounter><!-- 0..1 Reference(Encounter) The encounter that this diagnostic order is associated with --></encounter>
 <orderer><!-- 0..1 Reference(Practitioner) Who ordered the test --></orderer>

 <reason><!-- 0..* CodeableConcept Explanation/Justification for test --></reason>
 <supportingInformation><!-- 0..* Reference(Observation|Condition|
   DocumentReference) Additional clinical information --></supportingInformation>
 <specimen><!-- 0..* Reference(Specimen) If the whole order relates to specific specimens --></specimen>
 <
 <

 <event>  <!-- 0..* A list of events of interest in the lifecycle -->
  <

  <status value="[code]"/><!-- 1..1 proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed | entered-in-error -->

  <description><!-- 0..1 CodeableConcept More information about the event and its context --></description>
  <dateTime value="[dateTime]"/><!-- 1..1 The date at which the event happened -->
  <actor><!-- 0..1 Reference(Practitioner|Device) Who recorded or did this --></actor>
 </event>
 <item>  <!-- 0..* The items the orderer requested -->
  <code><!-- 1..1 CodeableConcept Code to indicate the item (test or panel) being ordered --></code>
  <specimen><!-- 0..* Reference(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 proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed | entered-in-error -->

  <event><!-- 0..* Content as for DiagnosticOrder.event Events specific to this item --></event>
 </item>
 <note><!-- 0..* Annotation Other notes and comments --></note>
</DiagnosticOrder>

JSON Template JSON Template 

{doco
  "resourceType" : "DiagnosticOrder",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "
  "

  "identifier" : [{ Identifier }], // Identifiers assigned to this order
  "status" : "<code>", // proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed | entered-in-error
  "priority" : "<code>", // routine | urgent | stat | asap
  "subject" : { Reference(Patient|Group|Location|Device) }, // R!  Who and/or what test is about

  "encounter" : { Reference(Encounter) }, // The encounter that this diagnostic order is associated with
  "orderer" : { Reference(Practitioner) }, // Who ordered the test

  "reason" : [{ CodeableConcept }], // Explanation/Justification for test
  "supportingInformation" : [{ Reference(Observation|Condition|
   DocumentReference) }], // Additional clinical information
  "specimen" : [{ Reference(Specimen) }], // If the whole order relates to specific specimens
  "
  "

  "event" : [{ // A list of events of interest in the lifecycle
    "

    "status" : "<code>", // R!  proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed | entered-in-error

    "description" : { CodeableConcept }, // More information about the event and its context
    "dateTime" : "<dateTime>", // R!  The date at which the event happened
    "actor" : { Reference(Practitioner|Device) } // Who recorded or did this
  }],
  "item" : [{ // The items the orderer requested
    "code" : { CodeableConcept }, // R!  Code to indicate the item (test or panel) being ordered
    "specimen" : [{ Reference(Specimen) }], // If this item relates to specific specimens
    "bodySite" : { CodeableConcept }, // Location of requested test (if applicable)
    "

    "status" : "<code>", // proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed | entered-in-error

    "event" : [{ Content as for DiagnosticOrder.event }] // Events specific to this item
  }],
  "note" : [{ Annotation }] // Other notes and comments
}

Structure

0..1 0..1
Name Flags Card. Type Description & Constraints Description & Constraints doco
. . DiagnosticOrder DomainResource A request for a diagnostic service A request for a diagnostic service
. . subject . identifier Σ 1..1 0..* Reference ( Patient | Group | Location | Device Identifier ) Who and/or what test is about Identifiers assigned to this order
. . orderer . status ?! Σ 0..1 Reference ( Practitioner code ) Who ordered the test proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed | entered-in-error
DiagnosticOrderStatus ( Required )
. . identifier . priority Σ 0..* 0..1 Identifier code Identifiers assigned to this order routine | urgent | stat | asap
DiagnosticOrderPriority ( Required )
. . encounter . subject Σ 0..1 1..1 Reference ( Encounter Patient | Group | Location | Device ) The encounter that this diagnostic order is associated with Who and/or what test is about
. . reason . encounter 0..* Σ CodeableConcept 0..1 Explanation/Justification for test Condition/Problem/Diagnosis Codes Reference ( Example Encounter ) The encounter that this diagnostic order is associated with
. . supportingInformation . orderer Σ 0..* 0..1 Reference ( Observation | Condition | DocumentReference Practitioner ) Additional clinical information Who ordered the test
. . specimen . reason 0..* Reference ( Specimen CodeableConcept ) If the whole order relates to specific specimens Explanation/Justification for test
Condition/Problem/Diagnosis Codes ( Example )
. . status . supportingInformation ?! Σ code 0..* proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed DiagnosticOrderStatus Reference ( Required Observation | Condition | DocumentReference ) Additional clinical information
. . priority . specimen Σ code 0..* routine | urgent | stat | asap DiagnosticOrderPriority Reference ( Required Specimen ) If the whole order relates to specific specimens
. . . event 0..* BackboneElement A list of events of interest in the lifecycle A list of events of interest in the lifecycle
. . . . status Σ 1..1 code proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed | entered-in-error
DiagnosticOrderStatus ( ( Required )
. . . . description Σ 0..1 CodeableConcept More information about the event and its context More information about the event and its context
Diagnostic Order Event Codes ( Diagnostic Order Event Codes ( Example )
. . . . dateTime Σ 1..1 dateTime The date at which the event happened The date at which the event happened
. . . . actor 0..1 Reference ( Practitioner | | Device ) Who recorded or did this Who recorded or did this
. . . item 0..* BackboneElement The items the orderer requested The items the orderer requested
. . . . code Σ 1..1 CodeableConcept Code to indicate the item (test or panel) being ordered Code to indicate the item (test or panel) being ordered
LOINC Diagnostic Order Codes ( LOINC Diagnostic Order Codes ( Preferred )
. . . . specimen 0..* Reference ( Specimen ) If this item relates to specific specimens If this item relates to specific specimens
. . . . bodySite 0..1 CodeableConcept Location of requested test (if applicable) Location of requested test (if applicable)
SNOMED CT Body Structures ( SNOMED CT Body Structures ( Example )
. . . . status Σ 0..1 code proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed | entered-in-error
DiagnosticOrderStatus ( ( Required )
. . . . event Σ 0..* see see event Events specific to this item Events specific to this item
. . . note 0..* Annotation Other notes and comments Other notes and comments

Documentation for this format doco Documentation for this format

UML Diagram UML Diagram

DiagnosticOrder ( ( DomainResource ) Identifiers assigned to this order instance by the orderer and/or the receiver and/or order fulfiller identifier : Identifier [0..*] The status of the order (this element modifies the meaning of other elements) status : code [0..1] « The status of a diagnostic order. (Strength=Required) DiagnosticOrderStatus ! » The clinical priority associated with this order priority : code [0..1] « The clinical priority of a diagnostic order. (Strength=Required) DiagnosticOrderPriority ! » Who or what the investigation is to be performed on. 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) 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) subject : : Reference [1..1] « [1..1] « Patient | Group | Location | Device » » The practitioner that holds legal responsibility for ordering the investigation An encounter that provides additional information about the healthcare context in which this request is made orderer : encounter : Reference [0..1] « Practitioner » Identifiers assigned to this order instance by the orderer and/or the receiver and/or order fulfiller identifier : Identifier [0..*] [0..1] « Encounter » An encounter that provides additional information about the healthcare context in which this request is made The practitioner that holds legal responsibility for ordering the investigation encounter : orderer : Reference [0..1] « Encounter » [0..1] « Practitioner » An explanation or justification for why this diagnostic investigation is being requested. This is often for billing purposes. May relate to the resources referred to in supportingInformation An explanation or justification for why this diagnostic investigation is being requested. This is often for billing purposes. May relate to the resources referred to in supportingInformation reason : : CodeableConcept [0..*] « [0..*] « Diagnosis or problem codes justifying the reason for requesting the diagnostic investigation. (Strength=Example) Diagnosis or problem codes justifying the reason for requesting the diagnostic investigation. (Strength=Example) Condition/Problem/Diagnosis ?? » Condition/Problem/Diagnosis ?? » 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 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 supportingInformation : : Reference [0..*] « [0..*] « Observation | Condition | DocumentReference » » One or more specimens that the diagnostic investigation is about One or more specimens that the diagnostic investigation is about specimen : : Reference [0..*] « [0..*] « Specimen » The status of the order (this element modifies the meaning of other elements) status : code [0..1] « The status of a diagnostic order. (Strength=Required) DiagnosticOrderStatus ! » The clinical priority associated with this order priority : code [0..1] « The clinical priority of a diagnostic order. (Strength=Required) DiagnosticOrderPriority ! » » Any other notes associated with this patient, specimen or order (e.g. "patient hates needles") Any other notes associated with this patient, specimen or order (e.g. "patient hates needles") note : : Annotation [0..*] [0..*] Event The status for the event The status for the event status : : code [1..1] « [1..1] « The status of a diagnostic order. (Strength=Required) The status of a diagnostic order. (Strength=Required) DiagnosticOrderStatus ! » ! » Additional information about the event that occurred - e.g. if the status remained unchanged Additional information about the event that occurred - e.g. if the status remained unchanged description : : CodeableConcept [0..1] « [0..1] « Additional information about an event that occurred to a diagnostic order - e.g. if the status remained unchanged. (Strength=Example) Additional information about an event that occurred to a diagnostic order - e.g. if the status remained unchanged. (Strength=Example) Diagnostic Order Event ?? » Diagnostic Order Event ?? » The date/time at which the event occurred The date/time at which the event occurred dateTime : : dateTime [1..1] [1..1] The person responsible for performing or recording the action The person responsible for performing or recording the action actor : : Reference [0..1] « [0..1] « Practitioner | Device » » Item A code that identifies a particular diagnostic investigation, or panel of investigations, that have been requested A code that identifies a particular diagnostic investigation, or panel of investigations, that have been requested code : : CodeableConcept [1..1] « [1..1] « Codes for tests/services that can be performed by diagnostic services. (Strength=Preferred) Codes for tests/services that can be performed by diagnostic services. (Strength=Preferred) LOINC Diagnostic Order ? » LOINC Diagnostic Order ? » If the item is related to a specific specimen If the item is related to a specific specimen specimen : : Reference [0..*] « [0..*] « Specimen » » Anatomical location where the request test should be performed. This is the target site Anatomical location where the request test should be performed. This is the target site bodySite : : CodeableConcept [0..1] « [0..1] « Codes describing anatomical locations. May include laterality. (Strength=Example) Codes describing anatomical locations. May include laterality. (Strength=Example) SNOMED CT Body Structures SNOMED CT Body Structures ?? » ?? » The status of this individual item within the order The status of this individual item within the order status : : code [0..1] « [0..1] « The status of a diagnostic order. (Strength=Required) The status of a diagnostic order. (Strength=Required) DiagnosticOrderStatus ! » ! » A summary of the events of interest that have occurred as the request is processed; e.g. when the order was made, various processing steps (specimens received), when it was completed A summary of the events of interest that have occurred as the request is processed; e.g. when the order was made, various processing steps (specimens received), when it was completed event [0..*] A summary of the events of interest that have occurred as this item of the request is processed A summary of the events of interest that have occurred as this item of the request is processed event [0..*] The specific diagnostic investigations that are requested as part of this request. Sometimes, there can only be one item per request, but in most contexts, more than one investigation can be requested The specific diagnostic investigations that are requested as part of this request. Sometimes, there can only be one item per request, but in most contexts, more than one investigation can be requested item [0..*]

XML Template XML Template 

<DiagnosticOrder xmlns="http://hl7.org/fhir"> doco
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <</subject>
 <</orderer>

 <identifier><!-- 0..* Identifier Identifiers assigned to this order --></identifier>
 <status value="[code]"/><!-- 0..1 proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed | entered-in-error -->
 <priority value="[code]"/><!-- 0..1 routine | urgent | stat | asap -->
 <subject><!-- 1..1 Reference(Patient|Group|Location|Device) Who and/or what test is about --></subject>

 <encounter><!-- 0..1 Reference(Encounter) The encounter that this diagnostic order is associated with --></encounter>
 <orderer><!-- 0..1 Reference(Practitioner) Who ordered the test --></orderer>

 <reason><!-- 0..* CodeableConcept Explanation/Justification for test --></reason>
 <supportingInformation><!-- 0..* Reference(Observation|Condition|
   DocumentReference) Additional clinical information --></supportingInformation>
 <specimen><!-- 0..* Reference(Specimen) If the whole order relates to specific specimens --></specimen>
 <
 <

 <event>  <!-- 0..* A list of events of interest in the lifecycle -->
  <

  <status value="[code]"/><!-- 1..1 proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed | entered-in-error -->

  <description><!-- 0..1 CodeableConcept More information about the event and its context --></description>
  <dateTime value="[dateTime]"/><!-- 1..1 The date at which the event happened -->
  <actor><!-- 0..1 Reference(Practitioner|Device) Who recorded or did this --></actor>
 </event>
 <item>  <!-- 0..* The items the orderer requested -->
  <code><!-- 1..1 CodeableConcept Code to indicate the item (test or panel) being ordered --></code>
  <specimen><!-- 0..* Reference(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 proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed | entered-in-error -->

  <event><!-- 0..* Content as for DiagnosticOrder.event Events specific to this item --></event>
 </item>
 <note><!-- 0..* Annotation Other notes and comments --></note>
</DiagnosticOrder>

JSON Template JSON Template 

{doco
  "resourceType" : "DiagnosticOrder",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "
  "

  "identifier" : [{ Identifier }], // Identifiers assigned to this order
  "status" : "<code>", // proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed | entered-in-error
  "priority" : "<code>", // routine | urgent | stat | asap
  "subject" : { Reference(Patient|Group|Location|Device) }, // R!  Who and/or what test is about

  "encounter" : { Reference(Encounter) }, // The encounter that this diagnostic order is associated with
  "orderer" : { Reference(Practitioner) }, // Who ordered the test

  "reason" : [{ CodeableConcept }], // Explanation/Justification for test
  "supportingInformation" : [{ Reference(Observation|Condition|
   DocumentReference) }], // Additional clinical information
  "specimen" : [{ Reference(Specimen) }], // If the whole order relates to specific specimens
  "
  "

  "event" : [{ // A list of events of interest in the lifecycle
    "

    "status" : "<code>", // R!  proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed | entered-in-error

    "description" : { CodeableConcept }, // More information about the event and its context
    "dateTime" : "<dateTime>", // R!  The date at which the event happened
    "actor" : { Reference(Practitioner|Device) } // Who recorded or did this
  }],
  "item" : [{ // The items the orderer requested
    "code" : { CodeableConcept }, // R!  Code to indicate the item (test or panel) being ordered
    "specimen" : [{ Reference(Specimen) }], // If this item relates to specific specimens
    "bodySite" : { CodeableConcept }, // Location of requested test (if applicable)
    "

    "status" : "<code>", // proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed | entered-in-error

    "event" : [{ Content as for DiagnosticOrder.event }] // Events specific to this item
  }],
  "note" : [{ Annotation }] // Other notes and comments
}

  Alternate definitions:

Alternate definitions: Schema / Schematron , Resource Profile ( , Resource Profile ( XML , , JSON ), ), Questionnaire

4.22.3.1 Terminology Bindings 4.33.3.1 Terminology Bindings

DiagnosticOrder.reason Diagnosis or problem codes justifying the reason for requesting the diagnostic investigation. Example Condition/Problem/Diagnosis Codes
Path Definition Type Reference
DiagnosticOrder.status
DiagnosticOrder.event.status
DiagnosticOrder.item.status DiagnosticOrder.item.status 		The status of a diagnostic order. The status of a diagnostic order. Required DiagnosticOrderStatus
DiagnosticOrder.priority DiagnosticOrder.priority The clinical priority of a diagnostic order. The clinical priority of a diagnostic order. Required DiagnosticOrderPriority
DiagnosticOrder.reason Diagnosis or problem codes justifying the reason for requesting the diagnostic investigation. Example Condition/Problem/Diagnosis Codes
DiagnosticOrder.event.description DiagnosticOrder.event.description Additional information about an event that occurred to a diagnostic order - e.g. if the status remained unchanged. Additional information about an event that occurred to a diagnostic order - e.g. if the status remained unchanged. Example Diagnostic Order Event Codes Diagnostic Order Event Codes
DiagnosticOrder.item.code DiagnosticOrder.item.code Codes for tests/services that can be performed by diagnostic services. Codes for tests/services that can be performed by diagnostic services. Preferred LOINC Diagnostic Order Codes LOINC Diagnostic Order Codes
DiagnosticOrder.item.bodySite DiagnosticOrder.item.bodySite Codes describing anatomical locations. May include laterality. Codes describing anatomical locations. May include laterality. Example SNOMED CT Body Structures SNOMED CT Body Structures

4.22.4 Notes: 4.33.4 Notes: 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 - DiagnosticOrder.specimen should only be used when the entire order relates to a single specimen, and then there is no need to repeat it for each item The reason is often for billing purposes. May relate to the resources referred to in supportingInformation and used to decide how the diagnostic investigation will be performed, or even if it will be performed at all The identifier.type element is used to distinguish between the identifiers assigned by the orderer (known as the 'Placer' in HL7 v2

  • 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 - DiagnosticOrder.specimen should only be used when the entire order relates to a single specimen, and then there is no need to repeat it for each item
  • The reason is often for billing purposes. May relate to the resources referred to in supportingInformation and used to decide how the diagnostic investigation will be performed, or even if it will be performed at all
  • 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) . Use the identifier type code "PLAC" for the Placer Identifier and "FILL" for the Filler identifier. See the example code below: ) and the producer of the observations in response to the order (known as the 'Filler' in HL7 v2) . Use the identifier type code "PLAC" for the Placer Identifier and "FILL" for the Filler identifier. See the example code below: 
    

<!-- Placer identifier-->
  <identifier>
		<type>
			<coding>
				<system value="http://hl7.org/fhir/identifier-type"/>
				<code value="PLAC"/>
			</coding>
			<text value="Placer"/>
		</type>
		<system value="urn:oid:1.3.4.5.6.7"/>
		<value value="2345234234234"/>
	</identifier>
<!-- Filler identifier-->
  <identifier>
		<type>
			<coding>
				<system value="http://hl7.org/fhir/identifier-type"/>
				<code value="PLAC"/>
			</coding>
			<text value="Placer"/>
		</type>
	<system value=" http://hl7.org/fhir/identifier-type"/>
	<value value="567890"/>
  </identifier>

4.22.5 Search Parameters 4.33.5 Search Parameters Search parameters for this resource. The common parameters also apply. See

Search parameters for this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services. for more information about searching in REST, messaging, and services.

© HL7.org 2011+. FHIR DSTU2 (v1.0.2-7202) generated on Sat, Oct 24, 2015 07:43+1100. Links: Search
Name Type Description Paths
actor reference Who recorded or did this Who recorded or did this DiagnosticOrder.event.actor, DiagnosticOrder.item.event.actor DiagnosticOrder.event.actor, DiagnosticOrder.item.event.actor
( Device , , Practitioner )
bodysite token Location of requested test (if applicable) Location of requested test (if applicable) DiagnosticOrder.item.bodySite
code token Code to indicate the item (test or panel) being ordered Code to indicate the item (test or panel) being ordered DiagnosticOrder.item.code
encounter reference The encounter that this diagnostic order is associated with The encounter that this diagnostic order is associated with DiagnosticOrder.encounter
( Encounter )
event-date date The date at which the event happened The date at which the event happened DiagnosticOrder.event.dateTime
event-status token proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed | entered-in-error DiagnosticOrder.event.status
event-status-date composite A combination of past-status and date A combination of past-status and date
identifier token Identifiers assigned to this order Identifiers assigned to this order DiagnosticOrder.identifier
item-date date The date at which the event happened The date at which the event happened DiagnosticOrder.item.event.dateTime
item-past-status token proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed | entered-in-error DiagnosticOrder.item.event.status
item-status token proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed | entered-in-error DiagnosticOrder.item.status
item-status-date composite A combination of item-past-status and item-date A combination of item-past-status and item-date
orderer reference Who ordered the test Who ordered the test DiagnosticOrder.orderer
( Practitioner )
patient reference Who and/or what test is about Who and/or what test is about DiagnosticOrder.subject
( Patient )
specimen reference If the whole order relates to specific specimens If the whole order relates to specific specimens DiagnosticOrder.specimen, DiagnosticOrder.item.specimen DiagnosticOrder.specimen, DiagnosticOrder.item.specimen
( Specimen )
status token proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed | entered-in-error DiagnosticOrder.status
subject reference Who and/or what test is about Who and/or what test is about DiagnosticOrder.subject
( Device , , Location , , Patient , , Group )