STU3 Candidate

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

10.3 Resource DiagnosticRequest - Content

Orders and Observations Work GroupMaturity Level: 1Compartments: Device, Encounter, Patient, Practitioner

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

10.3.1 Scope and Usage

This resource is a request resource from a FHIR workflow perspective - see Workflow.

A Diagnostic Request 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 Request 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 Request 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.

The DiagnosticRequest resource allows requesting only a single investigation. If a workflow requires requesting multiple items simultaneously, this is done using multiple instances of this resource. These instances can be linked in different ways, depending on the needs of the workflow. For guidance, refer to the Request pattern

10.3.2 Boundaries and Relationships

DiagnosticRequest 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:

  • ProcedureRequest or DiagnosticRequest 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 DiagnosticRequest. The diagnostic service might then initiate a ProcedureRequest.

The DiagnosticRequest supports references to the numerous other resources that define information about the subject - the orderer, associated encounter, body site and other supporting information. For example, Patient, Practitioner and Condition are all referenced in this resource. Some systems may choose to bundle up a DiagnosticRequest 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.

CarePlan typically references DiagnosticRequest with a stage of "plan" or "proposal", though the requests may have to be initiated and authorized outside of the CarePlan. Similarly ClinicalImpression resource can reference DiagnosticRequest as part of a follow up to plan to the assessment.

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

10.3.3 Resource Content

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. DiagnosticRequest DomainResourceA request for a diagnostic service
... identifier Σ0..*IdentifierIdentifiers assigned to this order
... definition Σ0..*Reference(Any)Protocol or definition
... basedOn Σ0..*Reference(Any)What request fulfills
... replaces Σ0..*Reference(Any)What request replaces
... requisition Σ0..1IdentifierComposite Request ID
... status ?!Σ1..1codedraft | active | suspended | completed | entered-in-error | cancelled
RequestStatus (Required)
... intent ?!Σ1..1codeproposal | plan | original-order | reflex-order
RequestIntent (Required)
... priority Σ0..1coderoutine | urgent | asap | stat
RequestPriority (Required)
... code Σ1..1CodeableConceptWhat’s being requested/ordered
LOINC Diagnostic Request Codes (Preferred)
... subject Σ1..1Reference(Patient | Group | Location | Device)Individual the test is ordered for
... context Σ0..1Reference(Encounter | EpisodeOfCare)Encounter or Episode during which request was created
... occurrence[x] Σ0..1When testing should occur
.... occurrenceDateTimedateTime
.... occurrencePeriodPeriod
.... occurrenceTimingTiming
... authoredOn Σ0..1dateTimeDate request signed
... requester Σ0..1Reference(Device | Practitioner | Organization)Who/what is requesting diagnostics
... performerType Σ0..1CodeableConceptPerformer role
Participant Roles (Example)
... performer Σ0..1Reference(Practitioner | Organization | Patient | Device | RelatedPerson)Requested perfomer
... reasonCode Σ0..*CodeableConceptExplanation/Justification for test
Condition/Problem/Diagnosis Codes (Example)
... reasonReference Σ0..*Reference(Condition | Observation)Explanation/Justification for test
... supportingInformation 0..*Reference(Any)Additional clinical information
... note 0..*AnnotationComments
... relevantHistory 0..*Reference(Provenance)Request provenance

doco Documentation for this format

UML Diagram (Legend)

DiagnosticRequest (DomainResource)Identifiers assigned to this order instance by the orderer and/or the receiver and/or order fulfilleridentifier : Identifier [0..*]Protocol or definition followed by this requestdefinition : Reference [0..*] « Any »Plan/proposal/order fulfilled by this requestbasedOn : Reference [0..*] « Any »The request takes the place of the referenced completed or terminated request(s)replaces : Reference [0..*] « Any »A shared identifier common to all diagnostic requests that were authorized more or less simultaneously by a single author, representing the composite or group identifierrequisition : Identifier [0..1]The status of the order (this element modifies the meaning of other elements)status : code [1..1] « The status of a diagnostic order. (Strength=Required)RequestStatus! »Whether the request is a proposal, plan, an original order or a reflex order (this element modifies the meaning of other elements)intent : code [1..1] « The kind of diagnostic request (Strength=Required)RequestIntent! »Indicates how quickly the {{title}} should be addressed with respect to other requestspriority : code [0..1] « Identifies the level of importance to be assigned to actioning the request (Strength=Required)RequestPriority! »A code that identifies a particular diagnostic investigation, or panel of investigations, that have been requestedcode : CodeableConcept [1..1] « Codes for tests/services that can be performed by diagnostic services. (Strength=Preferred)LOINC Diagnostic Request ? »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] « Patient|Group|Location|Device »An encounter or episode of care that provides additional information about the healthcare context in which this request is madecontext : Reference [0..1] « Encounter|EpisodeOfCare »The date/time at which the diagnostic testing should occuroccurrence[x] : Type [0..1] « dateTime|Period|Timing »When the request transitioned to being actionableauthoredOn : dateTime [0..1]Who/what is requesting diagnostics. The practitioner that holds legal responsibility for ordering the investigationrequester : Reference [0..1] « Device|Practitioner|Organization »Desired type of performer for doing the diagnostic testing. (performerType : CodeableConcept [0..1] « Indicates specific responsibility of an individual within the care team, such as "Primary physician", "Team coordinator", "Caregiver", etc. (Strength=Example)Participant Roles?? »The desired perfomer for doing the diagnostic testingperformer : Reference [0..1] « Practitioner|Organization|Patient| Device|RelatedPerson »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 supportingInformationreasonCode : CodeableConcept [0..*] « Diagnosis or problem codes justifying the reason for requesting the diagnostic investigation. (Strength=Example)Condition/Problem/Diagnosis ?? »Indicates another resource that provides a justification for why this diagnostic investigation is being requested. May relate to the resources referred to in supportingInformationreasonReference : Reference [0..*] « Condition|Observation »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 ordersupportingInformation : Reference [0..*] « Any »Any other notes and comments made about the service request. (e.g. "patient hates needles")note : Annotation [0..*]Key events in the history of the requestrelevantHistory : Reference [0..*] « Provenance »

XML Template

<DiagnosticRequest xmlns="http://hl7.org/fhir"> doco
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <identifier><!-- 0..* Identifier Identifiers assigned to this order --></identifier>
 <definition><!-- 0..* Reference(Any) Protocol or definition --></definition>
 <basedOn><!-- 0..* Reference(Any) What request fulfills --></basedOn>
 <replaces><!-- 0..* Reference(Any) What request replaces --></replaces>
 <requisition><!-- 0..1 Identifier Composite Request ID --></requisition>
 <status value="[code]"/><!-- 1..1 draft | active | suspended | completed | entered-in-error | cancelled -->
 <intent value="[code]"/><!-- 1..1 proposal | plan | original-order | reflex-order -->
 <priority value="[code]"/><!-- 0..1 routine | urgent | asap | stat -->
 <code><!-- 1..1 CodeableConcept What’s being requested/ordered --></code>
 <subject><!-- 1..1 Reference(Patient|Group|Location|Device) Individual the test is ordered for --></subject>
 <context><!-- 0..1 Reference(Encounter|EpisodeOfCare) Encounter or Episode during which request was created --></context>
 <occurrence[x]><!-- 0..1 dateTime|Period|Timing When testing should occur --></occurrence[x]>
 <authoredOn value="[dateTime]"/><!-- 0..1 Date request signed -->
 <requester><!-- 0..1 Reference(Device|Practitioner|Organization) Who/what is requesting diagnostics --></requester>
 <performerType><!-- 0..1 CodeableConcept Performer role --></performerType>
 <performer><!-- 0..1 Reference(Practitioner|Organization|Patient|Device|
   RelatedPerson) Requested perfomer --></performer>
 <reasonCode><!-- 0..* CodeableConcept Explanation/Justification for test --></reasonCode>
 <reasonReference><!-- 0..* Reference(Condition|Observation) Explanation/Justification for test --></reasonReference>
 <supportingInformation><!-- 0..* Reference(Any) Additional clinical information --></supportingInformation>
 <note><!-- 0..* Annotation Comments --></note>
 <relevantHistory><!-- 0..* Reference(Provenance) Request provenance --></relevantHistory>
</DiagnosticRequest>

JSON Template

{doco
  "resourceType" : "DiagnosticRequest",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "identifier" : [{ Identifier }], // Identifiers assigned to this order
  "definition" : [{ Reference(Any) }], // Protocol or definition
  "basedOn" : [{ Reference(Any) }], // What request fulfills
  "replaces" : [{ Reference(Any) }], // What request replaces
  "requisition" : { Identifier }, // Composite Request ID
  "status" : "<code>", // R!  draft | active | suspended | completed | entered-in-error | cancelled
  "intent" : "<code>", // R!  proposal | plan | original-order | reflex-order
  "priority" : "<code>", // routine | urgent | asap | stat
  "code" : { CodeableConcept }, // R!  What’s being requested/ordered
  "subject" : { Reference(Patient|Group|Location|Device) }, // R!  Individual the test is ordered for
  "context" : { Reference(Encounter|EpisodeOfCare) }, // Encounter or Episode during which request was created
  // occurrence[x]: When testing should occur. One of these 3:
  "occurrenceDateTime" : "<dateTime>",
  "occurrencePeriod" : { Period },
  "occurrenceTiming" : { Timing },
  "authoredOn" : "<dateTime>", // Date request signed
  "requester" : { Reference(Device|Practitioner|Organization) }, // Who/what is requesting diagnostics
  "performerType" : { CodeableConcept }, // Performer role
  "performer" : { Reference(Practitioner|Organization|Patient|Device|
   RelatedPerson) }, // Requested perfomer
  "reasonCode" : [{ CodeableConcept }], // Explanation/Justification for test
  "reasonReference" : [{ Reference(Condition|Observation) }], // Explanation/Justification for test
  "supportingInformation" : [{ Reference(Any) }], // Additional clinical information
  "note" : [{ Annotation }], // Comments
  "relevantHistory" : [{ Reference(Provenance) }] // Request provenance
}

Turtle Template

@prefix fhir: <http://hl7.org/fhir/> .doco


[ a fhir:DiagnosticRequest;
  fhir:nodeRole fhir:treeRoot; # if this is the parser root

  # from Resource: .id, .meta, .implicitRules, and .language
  # from DomainResource: .text, .contained, .extension, and .modifierExtension
  fhir:DiagnosticRequest.identifier [ Identifier ], ... ; # 0..* Identifiers assigned to this order
  fhir:DiagnosticRequest.definition [ Reference(Any) ], ... ; # 0..* Protocol or definition
  fhir:DiagnosticRequest.basedOn [ Reference(Any) ], ... ; # 0..* What request fulfills
  fhir:DiagnosticRequest.replaces [ Reference(Any) ], ... ; # 0..* What request replaces
  fhir:DiagnosticRequest.requisition [ Identifier ]; # 0..1 Composite Request ID
  fhir:DiagnosticRequest.status [ code ]; # 1..1 draft | active | suspended | completed | entered-in-error | cancelled
  fhir:DiagnosticRequest.intent [ code ]; # 1..1 proposal | plan | original-order | reflex-order
  fhir:DiagnosticRequest.priority [ code ]; # 0..1 routine | urgent | asap | stat
  fhir:DiagnosticRequest.code [ CodeableConcept ]; # 1..1 What’s being requested/ordered
  fhir:DiagnosticRequest.subject [ Reference(Patient|Group|Location|Device) ]; # 1..1 Individual the test is ordered for
  fhir:DiagnosticRequest.context [ Reference(Encounter|EpisodeOfCare) ]; # 0..1 Encounter or Episode during which request was created
  # DiagnosticRequest.occurrence[x] : 0..1 When testing should occur. One of these 3
    fhir:DiagnosticRequest.occurrenceDateTime [ dateTime ]
    fhir:DiagnosticRequest.occurrencePeriod [ Period ]
    fhir:DiagnosticRequest.occurrenceTiming [ Timing ]
  fhir:DiagnosticRequest.authoredOn [ dateTime ]; # 0..1 Date request signed
  fhir:DiagnosticRequest.requester [ Reference(Device|Practitioner|Organization) ]; # 0..1 Who/what is requesting diagnostics
  fhir:DiagnosticRequest.performerType [ CodeableConcept ]; # 0..1 Performer role
  fhir:DiagnosticRequest.performer [ Reference(Practitioner|Organization|Patient|Device|RelatedPerson) ]; # 0..1 Requested perfomer
  fhir:DiagnosticRequest.reasonCode [ CodeableConcept ], ... ; # 0..* Explanation/Justification for test
  fhir:DiagnosticRequest.reasonReference [ Reference(Condition|Observation) ], ... ; # 0..* Explanation/Justification for test
  fhir:DiagnosticRequest.supportingInformation [ Reference(Any) ], ... ; # 0..* Additional clinical information
  fhir:DiagnosticRequest.note [ Annotation ], ... ; # 0..* Comments
  fhir:DiagnosticRequest.relevantHistory [ Reference(Provenance) ], ... ; # 0..* Request provenance
]

Changes since DSTU2

DiagnosticRequest Name Changed from DiagnosticOrder to DiagnosticRequest
DiagnosticRequest.definition added Element
DiagnosticRequest.basedOn added Element
DiagnosticRequest.replaces added Element
DiagnosticRequest.requisition added Element
DiagnosticRequest.status Min Cardinality changed from 0 to 1
Change value set from http://hl7.org/fhir/ValueSet/diagnostic-order-status to http://hl7.org/fhir/ValueSet/request-status
DiagnosticRequest.intent added Element
DiagnosticRequest.priority Change value set from http://hl7.org/fhir/ValueSet/diagnostic-order-priority to http://hl7.org/fhir/ValueSet/request-priority
DiagnosticRequest.code added Element
DiagnosticRequest.context Renamed from encounter to context
Add Reference(EpisodeOfCare)
DiagnosticRequest.occurrence[x] added Element
DiagnosticRequest.authoredOn added Element
DiagnosticRequest.requester Renamed from orderer to requester
Add Reference(Device), Add Reference(Organization)
DiagnosticRequest.performerType added Element
DiagnosticRequest.performer added Element
DiagnosticRequest.reasonCode added Element
DiagnosticRequest.reasonReference added Element
DiagnosticRequest.supportingInformation Remove Reference(Observation), Remove Reference(Condition), Remove Reference(DocumentReference), Add Reference(Resource)
DiagnosticRequest.relevantHistory added Element
DiagnosticOrder.reason deleted
DiagnosticOrder.specimen deleted
DiagnosticOrder.event deleted
DiagnosticOrder.item deleted

See the Full Difference for further information

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. DiagnosticRequest DomainResourceA request for a diagnostic service
... identifier Σ0..*IdentifierIdentifiers assigned to this order
... definition Σ0..*Reference(Any)Protocol or definition
... basedOn Σ0..*Reference(Any)What request fulfills
... replaces Σ0..*Reference(Any)What request replaces
... requisition Σ0..1IdentifierComposite Request ID
... status ?!Σ1..1codedraft | active | suspended | completed | entered-in-error | cancelled
RequestStatus (Required)
... intent ?!Σ1..1codeproposal | plan | original-order | reflex-order
RequestIntent (Required)
... priority Σ0..1coderoutine | urgent | asap | stat
RequestPriority (Required)
... code Σ1..1CodeableConceptWhat’s being requested/ordered
LOINC Diagnostic Request Codes (Preferred)
... subject Σ1..1Reference(Patient | Group | Location | Device)Individual the test is ordered for
... context Σ0..1Reference(Encounter | EpisodeOfCare)Encounter or Episode during which request was created
... occurrence[x] Σ0..1When testing should occur
.... occurrenceDateTimedateTime
.... occurrencePeriodPeriod
.... occurrenceTimingTiming
... authoredOn Σ0..1dateTimeDate request signed
... requester Σ0..1Reference(Device | Practitioner | Organization)Who/what is requesting diagnostics
... performerType Σ0..1CodeableConceptPerformer role
Participant Roles (Example)
... performer Σ0..1Reference(Practitioner | Organization | Patient | Device | RelatedPerson)Requested perfomer
... reasonCode Σ0..*CodeableConceptExplanation/Justification for test
Condition/Problem/Diagnosis Codes (Example)
... reasonReference Σ0..*Reference(Condition | Observation)Explanation/Justification for test
... supportingInformation 0..*Reference(Any)Additional clinical information
... note 0..*AnnotationComments
... relevantHistory 0..*Reference(Provenance)Request provenance

doco Documentation for this format

UML Diagram (Legend)

DiagnosticRequest (DomainResource)Identifiers assigned to this order instance by the orderer and/or the receiver and/or order fulfilleridentifier : Identifier [0..*]Protocol or definition followed by this requestdefinition : Reference [0..*] « Any »Plan/proposal/order fulfilled by this requestbasedOn : Reference [0..*] « Any »The request takes the place of the referenced completed or terminated request(s)replaces : Reference [0..*] « Any »A shared identifier common to all diagnostic requests that were authorized more or less simultaneously by a single author, representing the composite or group identifierrequisition : Identifier [0..1]The status of the order (this element modifies the meaning of other elements)status : code [1..1] « The status of a diagnostic order. (Strength=Required)RequestStatus! »Whether the request is a proposal, plan, an original order or a reflex order (this element modifies the meaning of other elements)intent : code [1..1] « The kind of diagnostic request (Strength=Required)RequestIntent! »Indicates how quickly the {{title}} should be addressed with respect to other requestspriority : code [0..1] « Identifies the level of importance to be assigned to actioning the request (Strength=Required)RequestPriority! »A code that identifies a particular diagnostic investigation, or panel of investigations, that have been requestedcode : CodeableConcept [1..1] « Codes for tests/services that can be performed by diagnostic services. (Strength=Preferred)LOINC Diagnostic Request ? »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] « Patient|Group|Location|Device »An encounter or episode of care that provides additional information about the healthcare context in which this request is madecontext : Reference [0..1] « Encounter|EpisodeOfCare »The date/time at which the diagnostic testing should occuroccurrence[x] : Type [0..1] « dateTime|Period|Timing »When the request transitioned to being actionableauthoredOn : dateTime [0..1]Who/what is requesting diagnostics. The practitioner that holds legal responsibility for ordering the investigationrequester : Reference [0..1] « Device|Practitioner|Organization »Desired type of performer for doing the diagnostic testing. (performerType : CodeableConcept [0..1] « Indicates specific responsibility of an individual within the care team, such as "Primary physician", "Team coordinator", "Caregiver", etc. (Strength=Example)Participant Roles?? »The desired perfomer for doing the diagnostic testingperformer : Reference [0..1] « Practitioner|Organization|Patient| Device|RelatedPerson »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 supportingInformationreasonCode : CodeableConcept [0..*] « Diagnosis or problem codes justifying the reason for requesting the diagnostic investigation. (Strength=Example)Condition/Problem/Diagnosis ?? »Indicates another resource that provides a justification for why this diagnostic investigation is being requested. May relate to the resources referred to in supportingInformationreasonReference : Reference [0..*] « Condition|Observation »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 ordersupportingInformation : Reference [0..*] « Any »Any other notes and comments made about the service request. (e.g. "patient hates needles")note : Annotation [0..*]Key events in the history of the requestrelevantHistory : Reference [0..*] « Provenance »

XML Template

<DiagnosticRequest xmlns="http://hl7.org/fhir"> doco
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <identifier><!-- 0..* Identifier Identifiers assigned to this order --></identifier>
 <definition><!-- 0..* Reference(Any) Protocol or definition --></definition>
 <basedOn><!-- 0..* Reference(Any) What request fulfills --></basedOn>
 <replaces><!-- 0..* Reference(Any) What request replaces --></replaces>
 <requisition><!-- 0..1 Identifier Composite Request ID --></requisition>
 <status value="[code]"/><!-- 1..1 draft | active | suspended | completed | entered-in-error | cancelled -->
 <intent value="[code]"/><!-- 1..1 proposal | plan | original-order | reflex-order -->
 <priority value="[code]"/><!-- 0..1 routine | urgent | asap | stat -->
 <code><!-- 1..1 CodeableConcept What’s being requested/ordered --></code>
 <subject><!-- 1..1 Reference(Patient|Group|Location|Device) Individual the test is ordered for --></subject>
 <context><!-- 0..1 Reference(Encounter|EpisodeOfCare) Encounter or Episode during which request was created --></context>
 <occurrence[x]><!-- 0..1 dateTime|Period|Timing When testing should occur --></occurrence[x]>
 <authoredOn value="[dateTime]"/><!-- 0..1 Date request signed -->
 <requester><!-- 0..1 Reference(Device|Practitioner|Organization) Who/what is requesting diagnostics --></requester>
 <performerType><!-- 0..1 CodeableConcept Performer role --></performerType>
 <performer><!-- 0..1 Reference(Practitioner|Organization|Patient|Device|
   RelatedPerson) Requested perfomer --></performer>
 <reasonCode><!-- 0..* CodeableConcept Explanation/Justification for test --></reasonCode>
 <reasonReference><!-- 0..* Reference(Condition|Observation) Explanation/Justification for test --></reasonReference>
 <supportingInformation><!-- 0..* Reference(Any) Additional clinical information --></supportingInformation>
 <note><!-- 0..* Annotation Comments --></note>
 <relevantHistory><!-- 0..* Reference(Provenance) Request provenance --></relevantHistory>
</DiagnosticRequest>

JSON Template

{doco
  "resourceType" : "DiagnosticRequest",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "identifier" : [{ Identifier }], // Identifiers assigned to this order
  "definition" : [{ Reference(Any) }], // Protocol or definition
  "basedOn" : [{ Reference(Any) }], // What request fulfills
  "replaces" : [{ Reference(Any) }], // What request replaces
  "requisition" : { Identifier }, // Composite Request ID
  "status" : "<code>", // R!  draft | active | suspended | completed | entered-in-error | cancelled
  "intent" : "<code>", // R!  proposal | plan | original-order | reflex-order
  "priority" : "<code>", // routine | urgent | asap | stat
  "code" : { CodeableConcept }, // R!  What’s being requested/ordered
  "subject" : { Reference(Patient|Group|Location|Device) }, // R!  Individual the test is ordered for
  "context" : { Reference(Encounter|EpisodeOfCare) }, // Encounter or Episode during which request was created
  // occurrence[x]: When testing should occur. One of these 3:
  "occurrenceDateTime" : "<dateTime>",
  "occurrencePeriod" : { Period },
  "occurrenceTiming" : { Timing },
  "authoredOn" : "<dateTime>", // Date request signed
  "requester" : { Reference(Device|Practitioner|Organization) }, // Who/what is requesting diagnostics
  "performerType" : { CodeableConcept }, // Performer role
  "performer" : { Reference(Practitioner|Organization|Patient|Device|
   RelatedPerson) }, // Requested perfomer
  "reasonCode" : [{ CodeableConcept }], // Explanation/Justification for test
  "reasonReference" : [{ Reference(Condition|Observation) }], // Explanation/Justification for test
  "supportingInformation" : [{ Reference(Any) }], // Additional clinical information
  "note" : [{ Annotation }], // Comments
  "relevantHistory" : [{ Reference(Provenance) }] // Request provenance
}

Turtle Template

@prefix fhir: <http://hl7.org/fhir/> .doco


[ a fhir:DiagnosticRequest;
  fhir:nodeRole fhir:treeRoot; # if this is the parser root

  # from Resource: .id, .meta, .implicitRules, and .language
  # from DomainResource: .text, .contained, .extension, and .modifierExtension
  fhir:DiagnosticRequest.identifier [ Identifier ], ... ; # 0..* Identifiers assigned to this order
  fhir:DiagnosticRequest.definition [ Reference(Any) ], ... ; # 0..* Protocol or definition
  fhir:DiagnosticRequest.basedOn [ Reference(Any) ], ... ; # 0..* What request fulfills
  fhir:DiagnosticRequest.replaces [ Reference(Any) ], ... ; # 0..* What request replaces
  fhir:DiagnosticRequest.requisition [ Identifier ]; # 0..1 Composite Request ID
  fhir:DiagnosticRequest.status [ code ]; # 1..1 draft | active | suspended | completed | entered-in-error | cancelled
  fhir:DiagnosticRequest.intent [ code ]; # 1..1 proposal | plan | original-order | reflex-order
  fhir:DiagnosticRequest.priority [ code ]; # 0..1 routine | urgent | asap | stat
  fhir:DiagnosticRequest.code [ CodeableConcept ]; # 1..1 What’s being requested/ordered
  fhir:DiagnosticRequest.subject [ Reference(Patient|Group|Location|Device) ]; # 1..1 Individual the test is ordered for
  fhir:DiagnosticRequest.context [ Reference(Encounter|EpisodeOfCare) ]; # 0..1 Encounter or Episode during which request was created
  # DiagnosticRequest.occurrence[x] : 0..1 When testing should occur. One of these 3
    fhir:DiagnosticRequest.occurrenceDateTime [ dateTime ]
    fhir:DiagnosticRequest.occurrencePeriod [ Period ]
    fhir:DiagnosticRequest.occurrenceTiming [ Timing ]
  fhir:DiagnosticRequest.authoredOn [ dateTime ]; # 0..1 Date request signed
  fhir:DiagnosticRequest.requester [ Reference(Device|Practitioner|Organization) ]; # 0..1 Who/what is requesting diagnostics
  fhir:DiagnosticRequest.performerType [ CodeableConcept ]; # 0..1 Performer role
  fhir:DiagnosticRequest.performer [ Reference(Practitioner|Organization|Patient|Device|RelatedPerson) ]; # 0..1 Requested perfomer
  fhir:DiagnosticRequest.reasonCode [ CodeableConcept ], ... ; # 0..* Explanation/Justification for test
  fhir:DiagnosticRequest.reasonReference [ Reference(Condition|Observation) ], ... ; # 0..* Explanation/Justification for test
  fhir:DiagnosticRequest.supportingInformation [ Reference(Any) ], ... ; # 0..* Additional clinical information
  fhir:DiagnosticRequest.note [ Annotation ], ... ; # 0..* Comments
  fhir:DiagnosticRequest.relevantHistory [ Reference(Provenance) ], ... ; # 0..* Request provenance
]

Changes since DSTU2

DiagnosticRequest Name Changed from DiagnosticOrder to DiagnosticRequest
DiagnosticRequest.definition added Element
DiagnosticRequest.basedOn added Element
DiagnosticRequest.replaces added Element
DiagnosticRequest.requisition added Element
DiagnosticRequest.status Min Cardinality changed from 0 to 1
Change value set from http://hl7.org/fhir/ValueSet/diagnostic-order-status to http://hl7.org/fhir/ValueSet/request-status
DiagnosticRequest.intent added Element
DiagnosticRequest.priority Change value set from http://hl7.org/fhir/ValueSet/diagnostic-order-priority to http://hl7.org/fhir/ValueSet/request-priority
DiagnosticRequest.code added Element
DiagnosticRequest.context Renamed from encounter to context
Add Reference(EpisodeOfCare)
DiagnosticRequest.occurrence[x] added Element
DiagnosticRequest.authoredOn added Element
DiagnosticRequest.requester Renamed from orderer to requester
Add Reference(Device), Add Reference(Organization)
DiagnosticRequest.performerType added Element
DiagnosticRequest.performer added Element
DiagnosticRequest.reasonCode added Element
DiagnosticRequest.reasonReference added Element
DiagnosticRequest.supportingInformation Remove Reference(Observation), Remove Reference(Condition), Remove Reference(DocumentReference), Add Reference(Resource)
DiagnosticRequest.relevantHistory added Element
DiagnosticOrder.reason deleted
DiagnosticOrder.specimen deleted
DiagnosticOrder.event deleted
DiagnosticOrder.item deleted

See the Full Difference for further information

 

Alternate definitions: Master Definition (XML, JSON), XML Schema/Schematron (for ) + JSON Schema, ShEx (for Turtle), JSON-LD (for RDF as JSON-LD),

10.3.3.1 Terminology Bindings

PathDefinitionTypeReference
DiagnosticRequest.status The status of a diagnostic order.RequiredRequestStatus
DiagnosticRequest.intent The kind of diagnostic requestRequiredRequestIntent
DiagnosticRequest.priority Identifies the level of importance to be assigned to actioning the requestRequiredRequestPriority
DiagnosticRequest.code Codes for tests/services that can be performed by diagnostic services.PreferredLOINC Diagnostic Request Codes
DiagnosticRequest.performerType Indicates specific responsibility of an individual within the care team, such as "Primary physician", "Team coordinator", "Caregiver", etc.ExampleParticipant Roles
DiagnosticRequest.reasonCode Diagnosis or problem codes justifying the reason for requesting the diagnostic investigation.ExampleCondition/Problem/Diagnosis Codes

10.3.4 Notes:

  • Many investigation requests will create a need for specimens, although the request itself is not about the specimens. The Specimen resource may reference this resource or the 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 reason element is often for billing purposes. It may relate to the resources referred to in supportingInformation element and may be 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: 
    
<!-- 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>

10.3.5 Search Parameters

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

NameTypeDescriptionPathsIn Common
author-datedateWhen the request transitioned to being actionableDiagnosticRequest.authoredOn
based-onreferencePlan/proposal/order fulfilled by this requestDiagnosticRequest.basedOn
(Any)
codetokenWhat’s being requested/orderedDiagnosticRequest.code8 Resources
definitionreferenceProtocol or definition followed by this requestDiagnosticRequest.definition
(Any)
encounterreferenceEncounter or Episode during which request was createdDiagnosticRequest.context
(EpisodeOfCare, Encounter)		12 Resources
event-datedateWhen service should occurDiagnosticRequest.occurrenceDateTime, DiagnosticRequest.occurrencePeriod
fillerreferenceDesired performer for serviceDiagnosticRequest.performer
(Practitioner, Organization, Device, Patient, RelatedPerson)
identifiertokenBusiness identifier for request/orderDiagnosticRequest.identifier26 Resources
intenttokenproposal | plan | original-order |reflex-orderDiagnosticRequest.intent
patientreferenceIndividual the service is ordered forDiagnosticRequest.subject
(Patient)		31 Resources
prioritytokenroutine | urgent | asap | statDiagnosticRequest.priority
replacesreferenceRequest takes the place of referenced completed or terminated requestsDiagnosticRequest.replaces
(Any)
requesterreferenceWho/what is requesting service DiagnosticRequest.requester
(Practitioner, Organization, Device)
requisitiontokenComposite request this is part ofDiagnosticRequest.requisition
statustokenentered-in-error | draft | active |suspended | completed DiagnosticRequest.status
subjectreferenceIndividual the service is ordered forDiagnosticRequest.subject
(Group, Device, Patient, Location)