STU 3 Ballot

This page is part of the FHIR Specification (v1.6.0: STU 3 Ballot 4). 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.

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.

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

Note that the Diagnostic Request 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 Request may be required. This can be achieved by using an Task resource, with the Diagnostic Request referenced from the Task.details, or by using the Diagnostic Request 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, 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..1IdentifierIdentifier of composite request
... status ?!Σ0..1codedraft | active | suspended | completed | entered-in-error | cancelled
RequestStatus (Required)
... stage ?!Σ1..1CodeableConceptproposal | plan | original-order | reflex-order
DiagnosticRequestStage (Extensible)
... 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
... authored Σ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
... reason Σ0..*CodeableConceptExplanation/Justification for test
Condition/Problem/Diagnosis Codes (Example)
... 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 »Composite request this is part ofrequisition : Identifier [0..1]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)RequestStatus! »Whether the request is a proposal, plan, an original order or a reflex order (this element modifies the meaning of other elements)stage : CodeableConcept [1..1] « The kind of diagnostic request (Strength=Extensible)DiagnosticRequestStage+ »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 actionableauthored : 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. This is often for billing purposes. May relate to the resources referred to in supportingInformationreason : CodeableConcept [0..*] « Diagnosis or problem codes justifying the reason for requesting the diagnostic investigation. (Strength=Example)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 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 Identifier of composite request --></requisition>
 <status value="[code]"/><!-- 0..1 draft | active | suspended | completed | entered-in-error | cancelled -->
 <stage><!-- 1..1 CodeableConcept proposal | plan | original-order | reflex-order --></stage>
 <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]>
 <authored 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>
 <reason><!-- 0..* CodeableConcept Explanation/Justification for test --></reason>
 <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 }, // Identifier of composite request
  "status" : "<code>", // draft | active | suspended | completed | entered-in-error | cancelled
  "stage" : { CodeableConcept }, // R!  proposal | plan | original-order | reflex-order
  "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 },
  "authored" : "<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
  "reason" : [{ CodeableConcept }], // 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 Identifier of composite request
  fhir:DiagnosticRequest.status [ code ]; # 0..1 draft | active | suspended | completed | entered-in-error | cancelled
  fhir:DiagnosticRequest.stage [ CodeableConcept ]; # 1..1 proposal | plan | original-order | reflex-order
  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.authored [ 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.reason [ CodeableConcept ], ... ; # 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
DiagnosticRequest.basedOn added
DiagnosticRequest.replaces added
DiagnosticRequest.requisition added
DiagnosticRequest.status Change value set from http://hl7.org/fhir/ValueSet/diagnostic-order-status to http://hl7.org/fhir/ValueSet/request-status
DiagnosticRequest.stage added
DiagnosticRequest.code added
DiagnosticRequest.context Renamed from encounter to context
Add Reference(EpisodeOfCare)
DiagnosticRequest.occurrence[x] added
DiagnosticRequest.authored added
DiagnosticRequest.requester Renamed from orderer to requester
Add Reference(Device), Add Reference(Organization)
DiagnosticRequest.performerType added
DiagnosticRequest.performer added
DiagnosticRequest.supportingInformation Remove Reference(Observation), Remove Reference(Condition), Remove Reference(DocumentReference), Add Reference(Resource)
DiagnosticRequest.relevantHistory added
DiagnosticOrder.specimen deleted
DiagnosticOrder.priority 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..1IdentifierIdentifier of composite request
... status ?!Σ0..1codedraft | active | suspended | completed | entered-in-error | cancelled
RequestStatus (Required)
... stage ?!Σ1..1CodeableConceptproposal | plan | original-order | reflex-order
DiagnosticRequestStage (Extensible)
... 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
... authored Σ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
... reason Σ0..*CodeableConceptExplanation/Justification for test
Condition/Problem/Diagnosis Codes (Example)
... 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 »Composite request this is part ofrequisition : Identifier [0..1]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)RequestStatus! »Whether the request is a proposal, plan, an original order or a reflex order (this element modifies the meaning of other elements)stage : CodeableConcept [1..1] « The kind of diagnostic request (Strength=Extensible)DiagnosticRequestStage+ »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 actionableauthored : 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. This is often for billing purposes. May relate to the resources referred to in supportingInformationreason : CodeableConcept [0..*] « Diagnosis or problem codes justifying the reason for requesting the diagnostic investigation. (Strength=Example)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 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 Identifier of composite request --></requisition>
 <status value="[code]"/><!-- 0..1 draft | active | suspended | completed | entered-in-error | cancelled -->
 <stage><!-- 1..1 CodeableConcept proposal | plan | original-order | reflex-order --></stage>
 <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]>
 <authored 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>
 <reason><!-- 0..* CodeableConcept Explanation/Justification for test --></reason>
 <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 }, // Identifier of composite request
  "status" : "<code>", // draft | active | suspended | completed | entered-in-error | cancelled
  "stage" : { CodeableConcept }, // R!  proposal | plan | original-order | reflex-order
  "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 },
  "authored" : "<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
  "reason" : [{ CodeableConcept }], // 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 Identifier of composite request
  fhir:DiagnosticRequest.status [ code ]; # 0..1 draft | active | suspended | completed | entered-in-error | cancelled
  fhir:DiagnosticRequest.stage [ CodeableConcept ]; # 1..1 proposal | plan | original-order | reflex-order
  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.authored [ 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.reason [ CodeableConcept ], ... ; # 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
DiagnosticRequest.basedOn added
DiagnosticRequest.replaces added
DiagnosticRequest.requisition added
DiagnosticRequest.status Change value set from http://hl7.org/fhir/ValueSet/diagnostic-order-status to http://hl7.org/fhir/ValueSet/request-status
DiagnosticRequest.stage added
DiagnosticRequest.code added
DiagnosticRequest.context Renamed from encounter to context
Add Reference(EpisodeOfCare)
DiagnosticRequest.occurrence[x] added
DiagnosticRequest.authored added
DiagnosticRequest.requester Renamed from orderer to requester
Add Reference(Device), Add Reference(Organization)
DiagnosticRequest.performerType added
DiagnosticRequest.performer added
DiagnosticRequest.supportingInformation Remove Reference(Observation), Remove Reference(Condition), Remove Reference(DocumentReference), Add Reference(Resource)
DiagnosticRequest.relevantHistory added
DiagnosticOrder.specimen deleted
DiagnosticOrder.priority 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)

10.3.3.1 Terminology Bindings

PathDefinitionTypeReference
DiagnosticRequest.status The status of a diagnostic order.RequiredRequestStatus
DiagnosticRequest.stage The kind of diagnostic requestExtensibleDiagnosticRequestStage
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.reason 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.

NameTypeDescriptionPaths
author-datedateWhen the request transitioned to being actionableDiagnosticRequest.authored
based-onreferencePlan/proposal/order fulfilled by this requestDiagnosticRequest.basedOn
(Any)
codetokenWhat’s being requested/orderedDiagnosticRequest.code
definitionreferenceProtocol or definition followed by this requestDiagnosticRequest.definition
(Any)
encounterreferenceEncounter or Episode during which request was createdDiagnosticRequest.context
(EpisodeOfCare, Encounter)
event-datedateWhen service should occurDiagnosticRequest.occurrenceDateTime, DiagnosticRequest.occurrencePeriod
fillerreferenceDesired performer for serviceDiagnosticRequest.performer
(Practitioner, Organization, Device, Patient, RelatedPerson)
identifiertokenBusiness identifier for request/orderDiagnosticRequest.identifier
patientreferenceIndividual the service is ordered forDiagnosticRequest.subject
(Patient)
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
stagetokenproposal | plan | original-order |reflex-orderDiagnosticRequest.stage
statustokenentered-in-error | draft | active |suspended | completed DiagnosticRequest.status
subjectreferenceIndividual the service is ordered forDiagnosticRequest.subject
(Group, Device, Patient, Location)