FHIR Release 3 (STU)

This page is part of the FHIR Specification (v3.0.2: STU 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 . Page versions: R3 R2

12.15 Resource ProcedureRequest - Content

Orders and Observations Work GroupMaturity Level: 3 Trial UseCompartments: Device, Encounter, Patient, Practitioner, RelatedPerson

A record of a request for diagnostic investigations, treatments, or operations to be performed.

12.15.1 Scope and Usage

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

ProcedureRequest is a record of a request for a procedure to be planned, proposed, or performed, as distinguished by the ProcedureRequest.intent field value, with or on a patient. Examples of procedures include diagnostic tests/studies, endoscopic procedures, counseling, biopsies, therapies (e.g., physio-, social-, psychological-), (exploratory) surgeries or procedures, exercises, and other clinical interventions. Procedures may be performed by a healthcare professional, a friend or relative or in some cases by the patient themselves. The procedure will lead to either a Procedure or DiagnosticReport, that in turn may reference one or more Observations, that summarizes the performance of the procedures and associated documentation such as observations, images, findings that are relevant to the treatment/management of the subject.

The principal intention of ProcedureRequest is to support ordering procedures for one patient (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. ProcedureRequest supports all these usages. The procedure request may represent an order that is entered by a practitioner in a CPOE system as well as a proposal made by a clinical decision support (CDS) system based on a patient's clinical record and context of care. Planned procedures referenced by a CarePlan may also be represented by this resource.

The general work flow that this resource facilitates is that a clinical system creates a procedure request. The procedure request is then accessed by or exchanged with a system, perhaps via intermediaries, that represents an organization (e.g., diagnostic or imaging service, surgical team, physical therapy department) that can perform the procedure. The organization receiving the procedure request will, after it accepts the request, update the request as the work is performed, and then finally issue a report that references the requests that it fulfilled.

The ProcedureRequest resource allows requesting only a single procedure. If a workflow requires requesting multiple procedures 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

12.15.2 Boundaries and Relationships

ProcedureRequest, ReferralRequest, and CommunicationRequest are closely related. In fact, for some services, it may be appropriate to use any one of these resources to request that the procedure 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 is 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.
  • A CommunicationRequest is a request to merely disclose information whereas a ProcedureRequest is used when an action is considered to be training or counseling - i.e. when the process will involve verification of the patient's comprehension or an attempt to change the patient's mental state.

Irrespective of this guidance, 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. In some workflows more than one type of resource might exist. For example, upon receiving a ReferralRequest a practitioner might initiate a ProcedureRequest.

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

12.15.3 Resource Content

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. ProcedureRequest DomainResourceA request for a procedure or diagnostic to be performed
Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
... identifier Σ0..*IdentifierIdentifiers assigned to this order
... definition Σ0..*Reference(ActivityDefinition | PlanDefinition)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 | order +
RequestIntent (Required)
... priority Σ0..1coderoutine | urgent | asap | stat
RequestPriority (Required)
... doNotPerform ?!Σ0..1booleanTrue if procedure should not be performed
... category Σ0..*CodeableConceptClassification of procedure
Procedure Category Codes (SNOMED CT) (Example)
... code Σ1..1CodeableConceptWhat is being requested/ordered
Procedure Codes (SNOMED CT) (Example)
... subject Σ1..1Reference(Patient | Group | Location | Device)Individual the service is ordered for
... context Σ0..1Reference(Encounter | EpisodeOfCare)Encounter or Episode during which request was created
... occurrence[x] Σ0..1When procedure should occur
.... occurrenceDateTimedateTime
.... occurrencePeriodPeriod
.... occurrenceTimingTiming
... asNeeded[x] Σ0..1Preconditions for procedure or diagnostic
SNOMED CT Medication As Needed Reason Codes (Example)
.... asNeededBooleanboolean
.... asNeededCodeableConceptCodeableConcept
... authoredOn Σ0..1dateTimeDate request signed
... requester Σ0..1BackboneElementWho/what is requesting procedure or diagnostic
.... agent Σ1..1Reference(Device | Practitioner | Organization)Individual making the request
.... onBehalfOf Σ0..1Reference(Organization)Organization agent is acting for
... performerType Σ0..1CodeableConceptPerformer role
Participant Roles (Example)
... performer Σ0..1Reference(Practitioner | Organization | Patient | Device | RelatedPerson | HealthcareService)Requested perfomer
... reasonCode Σ0..*CodeableConceptExplanation/Justification for test
Procedure Reason Codes (Example)
... reasonReference Σ0..*Reference(Condition | Observation)Explanation/Justification for test
... supportingInfo 0..*Reference(Any)Additional clinical information
... specimen Σ0..*Reference(Specimen)Procedure Samples
... bodySite Σ0..*CodeableConceptLocation on Body
SNOMED CT Body Structures (Example)
... note 0..*AnnotationComments
... relevantHistory 0..*Reference(Provenance)Request provenance

doco Documentation for this format

UML Diagram (Legend)

ProcedureRequest (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..*] ActivityDefinition|PlanDefinition 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 procedure or 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 procedure or 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 procedure or diagnostic request (Strength=Required)RequestIntent! Indicates how quickly the ProcedureRequest 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! Set this to true if the record is saying that the procedure should NOT be performed (this element modifies the meaning of other elements)doNotPerform : boolean [0..1]A code that classifies the procedure for searching, sorting and display purposes (e.g. "Surgical Procedure")category : CodeableConcept [0..*] Classification of the procedure (Strength=Example)Procedure Category Codes (SNO...?? A code that identifies a particular procedure, diagnostic investigation, or panel of investigations, that have been requestedcode : CodeableConcept [1..1] Codes for tests/services that can be performed by procedure or diagnostic services. For laboratory, LOINC is (preferred)[http://hl7.org/fhir/STU3/terminologies.html#preferred] and a valueset using LOINC Order codes is available [here](valueset-diagnostic-requests.html). (Strength=Example)Procedure Codes (SNOMED CT)?? On whom or what the procedure or diagnostic is to be performed. This is usually a human patient, but 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 If a CodeableConcept is present, it indicates the pre-condition for performing the procedure. For example "pain", "on flare-up", etcasNeeded[x] : Type [0..1] boolean|CodeableConcept; A coded concept identifying the pre-condition that should hold prior to performing a procedure. For example "pain", "on flare-up", etc. (Strength=Example)SNOMED CT Medication As Neede...?? When the request transitioned to being actionableauthoredOn : dateTime [0..1]Desired type of performer for doing the diagnostic testingperformerType : 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 testing. For example, the surgeon, dermatopathologist, endoscopist, etcperformer : Reference [0..1] Practitioner|Organization|Patient| Device|RelatedPerson|HealthcareService 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 procedure or diagnostic investigation. (Strength=Example)Procedure Reason ?? 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 the procedure or diagnostics or their interpretations. This information includes diagnosis, clinical findings and other observations. In laboratory ordering these are typically referred to as "ask at order entry questions (AOEs)". This includes observations explicitly requested by the producer (filler) to provide context or supporting information needed to complete the order. For example, reporting the amount of inspired oxygen for blood gas measurementssupportingInfo : Reference [0..*] Any One or more specimens that the laboratory procedure will usespecimen : Reference [0..*] Specimen Anatomic location where the procedure should be performed. This is the target sitebodySite : CodeableConcept [0..*] Codes describing anatomical locations. May include laterality. (Strength=Example)SNOMED CT Body Structures?? Any other notes and comments made about the service request. For example, letting provider know that "patient hates needles" or other provider instructionsnote : Annotation [0..*]Key events in the history of the requestrelevantHistory : Reference [0..*] Provenance RequesterThe device, practitioner or organization who initiated the requestagent : Reference [1..1] Device|Practitioner|Organization The organization the device or practitioner was acting on behalf ofonBehalfOf : Reference [0..1] Organization The individual who initiated the request and has responsibility for its activationrequester[0..1]

XML Template

<ProcedureRequest 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(ActivityDefinition|PlanDefinition) 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 | order + -->
 <priority value="[code]"/><!-- 0..1 routine | urgent | asap | stat -->
 <doNotPerform value="[boolean]"/><!-- 0..1 True if procedure should not be performed -->
 <category><!-- 0..* CodeableConcept Classification of procedure --></category>
 <code><!-- 1..1 CodeableConcept What is being requested/ordered --></code>
 <subject><!-- 1..1 Reference(Patient|Group|Location|Device) Individual the service 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 procedure should occur --></occurrence[x]>
 <asNeeded[x]><!-- 0..1 boolean|CodeableConcept Preconditions for procedure or diagnostic --></asNeeded[x]>
 <authoredOn value="[dateTime]"/><!-- 0..1 Date request signed -->
 <requester>  <!-- 0..1 Who/what is requesting procedure or diagnostic -->
  <agent><!-- 1..1 Reference(Device|Practitioner|Organization) Individual making the request --></agent>
  <onBehalfOf><!-- 0..1 Reference(Organization) Organization agent is acting for --></onBehalfOf>
 </requester>
 <performerType><!-- 0..1 CodeableConcept Performer role --></performerType>
 <performer><!-- 0..1 Reference(Practitioner|Organization|Patient|Device|
   RelatedPerson|HealthcareService) Requested perfomer --></performer>
 <reasonCode><!-- 0..* CodeableConcept Explanation/Justification for test --></reasonCode>
 <reasonReference><!-- 0..* Reference(Condition|Observation) Explanation/Justification for test --></reasonReference>
 <supportingInfo><!-- 0..* Reference(Any) Additional clinical information --></supportingInfo>
 <specimen><!-- 0..* Reference(Specimen) Procedure Samples --></specimen>
 <bodySite><!-- 0..* CodeableConcept Location on Body --></bodySite>
 <note><!-- 0..* Annotation Comments --></note>
 <relevantHistory><!-- 0..* Reference(Provenance) Request provenance --></relevantHistory>
</ProcedureRequest>

JSON Template

{doco
  "resourceType" : "ProcedureRequest",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "identifier" : [{ Identifier }], // Identifiers assigned to this order
  "definition" : [{ Reference(ActivityDefinition|PlanDefinition) }], // 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 | order +
  "priority" : "<code>", // routine | urgent | asap | stat
  "doNotPerform" : <boolean>, // True if procedure should not be performed
  "category" : [{ CodeableConcept }], // Classification of procedure
  "code" : { CodeableConcept }, // R!  What is being requested/ordered
  "subject" : { Reference(Patient|Group|Location|Device) }, // R!  Individual the service is ordered for
  "context" : { Reference(Encounter|EpisodeOfCare) }, // Encounter or Episode during which request was created
  // occurrence[x]: When procedure should occur. One of these 3:
  "occurrenceDateTime" : "<dateTime>",
  "occurrencePeriod" : { Period },
  "occurrenceTiming" : { Timing },
  // asNeeded[x]: Preconditions for procedure or diagnostic. One of these 2:
  "asNeededBoolean" : <boolean>,
  "asNeededCodeableConcept" : { CodeableConcept },
  "authoredOn" : "<dateTime>", // Date request signed
  "requester" : { // Who/what is requesting procedure or diagnostic
    "agent" : { Reference(Device|Practitioner|Organization) }, // R!  Individual making the request
    "onBehalfOf" : { Reference(Organization) } // Organization agent is acting for
  },
  "performerType" : { CodeableConcept }, // Performer role
  "performer" : { Reference(Practitioner|Organization|Patient|Device|
   RelatedPerson|HealthcareService) }, // Requested perfomer
  "reasonCode" : [{ CodeableConcept }], // Explanation/Justification for test
  "reasonReference" : [{ Reference(Condition|Observation) }], // Explanation/Justification for test
  "supportingInfo" : [{ Reference(Any) }], // Additional clinical information
  "specimen" : [{ Reference(Specimen) }], // Procedure Samples
  "bodySite" : [{ CodeableConcept }], // Location on Body
  "note" : [{ Annotation }], // Comments
  "relevantHistory" : [{ Reference(Provenance) }] // Request provenance
}

Turtle Template

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


[ a fhir:ProcedureRequest;
  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:ProcedureRequest.identifier [ Identifier ], ... ; # 0..* Identifiers assigned to this order
  fhir:ProcedureRequest.definition [ Reference(ActivityDefinition|PlanDefinition) ], ... ; # 0..* Protocol or definition
  fhir:ProcedureRequest.basedOn [ Reference(Any) ], ... ; # 0..* What request fulfills
  fhir:ProcedureRequest.replaces [ Reference(Any) ], ... ; # 0..* What request replaces
  fhir:ProcedureRequest.requisition [ Identifier ]; # 0..1 Composite Request ID
  fhir:ProcedureRequest.status [ code ]; # 1..1 draft | active | suspended | completed | entered-in-error | cancelled
  fhir:ProcedureRequest.intent [ code ]; # 1..1 proposal | plan | order +
  fhir:ProcedureRequest.priority [ code ]; # 0..1 routine | urgent | asap | stat
  fhir:ProcedureRequest.doNotPerform [ boolean ]; # 0..1 True if procedure should not be performed
  fhir:ProcedureRequest.category [ CodeableConcept ], ... ; # 0..* Classification of procedure
  fhir:ProcedureRequest.code [ CodeableConcept ]; # 1..1 What is being requested/ordered
  fhir:ProcedureRequest.subject [ Reference(Patient|Group|Location|Device) ]; # 1..1 Individual the service is ordered for
  fhir:ProcedureRequest.context [ Reference(Encounter|EpisodeOfCare) ]; # 0..1 Encounter or Episode during which request was created
  # ProcedureRequest.occurrence[x] : 0..1 When procedure should occur. One of these 3
    fhir:ProcedureRequest.occurrenceDateTime [ dateTime ]
    fhir:ProcedureRequest.occurrencePeriod [ Period ]
    fhir:ProcedureRequest.occurrenceTiming [ Timing ]
  # ProcedureRequest.asNeeded[x] : 0..1 Preconditions for procedure or diagnostic. One of these 2
    fhir:ProcedureRequest.asNeededBoolean [ boolean ]
    fhir:ProcedureRequest.asNeededCodeableConcept [ CodeableConcept ]
  fhir:ProcedureRequest.authoredOn [ dateTime ]; # 0..1 Date request signed
  fhir:ProcedureRequest.requester [ # 0..1 Who/what is requesting procedure or diagnostic
    fhir:ProcedureRequest.requester.agent [ Reference(Device|Practitioner|Organization) ]; # 1..1 Individual making the request
    fhir:ProcedureRequest.requester.onBehalfOf [ Reference(Organization) ]; # 0..1 Organization agent is acting for
  ];
  fhir:ProcedureRequest.performerType [ CodeableConcept ]; # 0..1 Performer role
  fhir:ProcedureRequest.performer [ Reference(Practitioner|Organization|Patient|Device|RelatedPerson|HealthcareService) ]; # 0..1 Requested perfomer
  fhir:ProcedureRequest.reasonCode [ CodeableConcept ], ... ; # 0..* Explanation/Justification for test
  fhir:ProcedureRequest.reasonReference [ Reference(Condition|Observation) ], ... ; # 0..* Explanation/Justification for test
  fhir:ProcedureRequest.supportingInfo [ Reference(Any) ], ... ; # 0..* Additional clinical information
  fhir:ProcedureRequest.specimen [ Reference(Specimen) ], ... ; # 0..* Procedure Samples
  fhir:ProcedureRequest.bodySite [ CodeableConcept ], ... ; # 0..* Location on Body
  fhir:ProcedureRequest.note [ Annotation ], ... ; # 0..* Comments
  fhir:ProcedureRequest.relevantHistory [ Reference(Provenance) ], ... ; # 0..* Request provenance
]

Changes since DSTU2

ProcedureRequest
ProcedureRequest.definition
  • Added Element
ProcedureRequest.basedOn
  • Added Element
ProcedureRequest.replaces
  • Added Element
ProcedureRequest.requisition
  • Added Element
ProcedureRequest.status
  • Min Cardinality changed from 0 to 1
  • Change value set from http://hl7.org/fhir/ValueSet/procedure-request-status to http://hl7.org/fhir/ValueSet/request-status
ProcedureRequest.intent
  • Added Element
ProcedureRequest.priority
  • Change value set from http://hl7.org/fhir/ValueSet/procedure-request-priority to http://hl7.org/fhir/ValueSet/request-priority
ProcedureRequest.doNotPerform
  • Added Element
ProcedureRequest.category
  • Added Element
ProcedureRequest.subject
  • Add Reference(Location), Add Reference(Device)
ProcedureRequest.context
  • Renamed from encounter to context
  • Add Reference(EpisodeOfCare)
ProcedureRequest.occurrence[x]
  • Added Element
ProcedureRequest.authoredOn
  • Renamed from orderedOn to authoredOn
ProcedureRequest.requester
  • Added Element
ProcedureRequest.requester.agent
  • Added Element
ProcedureRequest.requester.onBehalfOf
  • Added Element
ProcedureRequest.performerType
  • Added Element
ProcedureRequest.performer
  • Add Reference(Device), Add Reference(HealthcareService)
ProcedureRequest.reasonCode
  • Added Element
ProcedureRequest.reasonReference
  • Added Element
ProcedureRequest.supportingInfo
  • Added Element
ProcedureRequest.specimen
  • Added Element
ProcedureRequest.note
  • Renamed from notes to note
ProcedureRequest.relevantHistory
  • Added Element
ProcedureRequest.reason[x]
  • deleted
ProcedureRequest.scheduled[x]
  • deleted
ProcedureRequest.orderer
  • deleted

See the Full Difference for further information

This analysis is available as XML or JSON.

See R2 <--> R3 Conversion Maps (status = 6 tests that all execute ok. 5 fail round-trip testing and 6 r3 resources are invalid (9 errors).).

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. ProcedureRequest DomainResourceA request for a procedure or diagnostic to be performed
Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
... identifier Σ0..*IdentifierIdentifiers assigned to this order
... definition Σ0..*Reference(ActivityDefinition | PlanDefinition)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 | order +
RequestIntent (Required)
... priority Σ0..1coderoutine | urgent | asap | stat
RequestPriority (Required)
... doNotPerform ?!Σ0..1booleanTrue if procedure should not be performed
... category Σ0..*CodeableConceptClassification of procedure
Procedure Category Codes (SNOMED CT) (Example)
... code Σ1..1CodeableConceptWhat is being requested/ordered
Procedure Codes (SNOMED CT) (Example)
... subject Σ1..1Reference(Patient | Group | Location | Device)Individual the service is ordered for
... context Σ0..1Reference(Encounter | EpisodeOfCare)Encounter or Episode during which request was created
... occurrence[x] Σ0..1When procedure should occur
.... occurrenceDateTimedateTime
.... occurrencePeriodPeriod
.... occurrenceTimingTiming
... asNeeded[x] Σ0..1Preconditions for procedure or diagnostic
SNOMED CT Medication As Needed Reason Codes (Example)
.... asNeededBooleanboolean
.... asNeededCodeableConceptCodeableConcept
... authoredOn Σ0..1dateTimeDate request signed
... requester Σ0..1BackboneElementWho/what is requesting procedure or diagnostic
.... agent Σ1..1Reference(Device | Practitioner | Organization)Individual making the request
.... onBehalfOf Σ0..1Reference(Organization)Organization agent is acting for
... performerType Σ0..1CodeableConceptPerformer role
Participant Roles (Example)
... performer Σ0..1Reference(Practitioner | Organization | Patient | Device | RelatedPerson | HealthcareService)Requested perfomer
... reasonCode Σ0..*CodeableConceptExplanation/Justification for test
Procedure Reason Codes (Example)
... reasonReference Σ0..*Reference(Condition | Observation)Explanation/Justification for test
... supportingInfo 0..*Reference(Any)Additional clinical information
... specimen Σ0..*Reference(Specimen)Procedure Samples
... bodySite Σ0..*CodeableConceptLocation on Body
SNOMED CT Body Structures (Example)
... note 0..*AnnotationComments
... relevantHistory 0..*Reference(Provenance)Request provenance

doco Documentation for this format

UML Diagram (Legend)

ProcedureRequest (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..*] ActivityDefinition|PlanDefinition 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 procedure or 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 procedure or 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 procedure or diagnostic request (Strength=Required)RequestIntent! Indicates how quickly the ProcedureRequest 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! Set this to true if the record is saying that the procedure should NOT be performed (this element modifies the meaning of other elements)doNotPerform : boolean [0..1]A code that classifies the procedure for searching, sorting and display purposes (e.g. "Surgical Procedure")category : CodeableConcept [0..*] Classification of the procedure (Strength=Example)Procedure Category Codes (SNO...?? A code that identifies a particular procedure, diagnostic investigation, or panel of investigations, that have been requestedcode : CodeableConcept [1..1] Codes for tests/services that can be performed by procedure or diagnostic services. For laboratory, LOINC is (preferred)[http://hl7.org/fhir/STU3/terminologies.html#preferred] and a valueset using LOINC Order codes is available [here](valueset-diagnostic-requests.html). (Strength=Example)Procedure Codes (SNOMED CT)?? On whom or what the procedure or diagnostic is to be performed. This is usually a human patient, but 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 If a CodeableConcept is present, it indicates the pre-condition for performing the procedure. For example "pain", "on flare-up", etcasNeeded[x] : Type [0..1] boolean|CodeableConcept; A coded concept identifying the pre-condition that should hold prior to performing a procedure. For example "pain", "on flare-up", etc. (Strength=Example)SNOMED CT Medication As Neede...?? When the request transitioned to being actionableauthoredOn : dateTime [0..1]Desired type of performer for doing the diagnostic testingperformerType : 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 testing. For example, the surgeon, dermatopathologist, endoscopist, etcperformer : Reference [0..1] Practitioner|Organization|Patient| Device|RelatedPerson|HealthcareService 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 procedure or diagnostic investigation. (Strength=Example)Procedure Reason ?? 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 the procedure or diagnostics or their interpretations. This information includes diagnosis, clinical findings and other observations. In laboratory ordering these are typically referred to as "ask at order entry questions (AOEs)". This includes observations explicitly requested by the producer (filler) to provide context or supporting information needed to complete the order. For example, reporting the amount of inspired oxygen for blood gas measurementssupportingInfo : Reference [0..*] Any One or more specimens that the laboratory procedure will usespecimen : Reference [0..*] Specimen Anatomic location where the procedure should be performed. This is the target sitebodySite : CodeableConcept [0..*] Codes describing anatomical locations. May include laterality. (Strength=Example)SNOMED CT Body Structures?? Any other notes and comments made about the service request. For example, letting provider know that "patient hates needles" or other provider instructionsnote : Annotation [0..*]Key events in the history of the requestrelevantHistory : Reference [0..*] Provenance RequesterThe device, practitioner or organization who initiated the requestagent : Reference [1..1] Device|Practitioner|Organization The organization the device or practitioner was acting on behalf ofonBehalfOf : Reference [0..1] Organization The individual who initiated the request and has responsibility for its activationrequester[0..1]

XML Template

<ProcedureRequest 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(ActivityDefinition|PlanDefinition) 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 | order + -->
 <priority value="[code]"/><!-- 0..1 routine | urgent | asap | stat -->
 <doNotPerform value="[boolean]"/><!-- 0..1 True if procedure should not be performed -->
 <category><!-- 0..* CodeableConcept Classification of procedure --></category>
 <code><!-- 1..1 CodeableConcept What is being requested/ordered --></code>
 <subject><!-- 1..1 Reference(Patient|Group|Location|Device) Individual the service 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 procedure should occur --></occurrence[x]>
 <asNeeded[x]><!-- 0..1 boolean|CodeableConcept Preconditions for procedure or diagnostic --></asNeeded[x]>
 <authoredOn value="[dateTime]"/><!-- 0..1 Date request signed -->
 <requester>  <!-- 0..1 Who/what is requesting procedure or diagnostic -->
  <agent><!-- 1..1 Reference(Device|Practitioner|Organization) Individual making the request --></agent>
  <onBehalfOf><!-- 0..1 Reference(Organization) Organization agent is acting for --></onBehalfOf>
 </requester>
 <performerType><!-- 0..1 CodeableConcept Performer role --></performerType>
 <performer><!-- 0..1 Reference(Practitioner|Organization|Patient|Device|
   RelatedPerson|HealthcareService) Requested perfomer --></performer>
 <reasonCode><!-- 0..* CodeableConcept Explanation/Justification for test --></reasonCode>
 <reasonReference><!-- 0..* Reference(Condition|Observation) Explanation/Justification for test --></reasonReference>
 <supportingInfo><!-- 0..* Reference(Any) Additional clinical information --></supportingInfo>
 <specimen><!-- 0..* Reference(Specimen) Procedure Samples --></specimen>
 <bodySite><!-- 0..* CodeableConcept Location on Body --></bodySite>
 <note><!-- 0..* Annotation Comments --></note>
 <relevantHistory><!-- 0..* Reference(Provenance) Request provenance --></relevantHistory>
</ProcedureRequest>

JSON Template

{doco
  "resourceType" : "ProcedureRequest",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "identifier" : [{ Identifier }], // Identifiers assigned to this order
  "definition" : [{ Reference(ActivityDefinition|PlanDefinition) }], // 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 | order +
  "priority" : "<code>", // routine | urgent | asap | stat
  "doNotPerform" : <boolean>, // True if procedure should not be performed
  "category" : [{ CodeableConcept }], // Classification of procedure
  "code" : { CodeableConcept }, // R!  What is being requested/ordered
  "subject" : { Reference(Patient|Group|Location|Device) }, // R!  Individual the service is ordered for
  "context" : { Reference(Encounter|EpisodeOfCare) }, // Encounter or Episode during which request was created
  // occurrence[x]: When procedure should occur. One of these 3:
  "occurrenceDateTime" : "<dateTime>",
  "occurrencePeriod" : { Period },
  "occurrenceTiming" : { Timing },
  // asNeeded[x]: Preconditions for procedure or diagnostic. One of these 2:
  "asNeededBoolean" : <boolean>,
  "asNeededCodeableConcept" : { CodeableConcept },
  "authoredOn" : "<dateTime>", // Date request signed
  "requester" : { // Who/what is requesting procedure or diagnostic
    "agent" : { Reference(Device|Practitioner|Organization) }, // R!  Individual making the request
    "onBehalfOf" : { Reference(Organization) } // Organization agent is acting for
  },
  "performerType" : { CodeableConcept }, // Performer role
  "performer" : { Reference(Practitioner|Organization|Patient|Device|
   RelatedPerson|HealthcareService) }, // Requested perfomer
  "reasonCode" : [{ CodeableConcept }], // Explanation/Justification for test
  "reasonReference" : [{ Reference(Condition|Observation) }], // Explanation/Justification for test
  "supportingInfo" : [{ Reference(Any) }], // Additional clinical information
  "specimen" : [{ Reference(Specimen) }], // Procedure Samples
  "bodySite" : [{ CodeableConcept }], // Location on Body
  "note" : [{ Annotation }], // Comments
  "relevantHistory" : [{ Reference(Provenance) }] // Request provenance
}

Turtle Template

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


[ a fhir:ProcedureRequest;
  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:ProcedureRequest.identifier [ Identifier ], ... ; # 0..* Identifiers assigned to this order
  fhir:ProcedureRequest.definition [ Reference(ActivityDefinition|PlanDefinition) ], ... ; # 0..* Protocol or definition
  fhir:ProcedureRequest.basedOn [ Reference(Any) ], ... ; # 0..* What request fulfills
  fhir:ProcedureRequest.replaces [ Reference(Any) ], ... ; # 0..* What request replaces
  fhir:ProcedureRequest.requisition [ Identifier ]; # 0..1 Composite Request ID
  fhir:ProcedureRequest.status [ code ]; # 1..1 draft | active | suspended | completed | entered-in-error | cancelled
  fhir:ProcedureRequest.intent [ code ]; # 1..1 proposal | plan | order +
  fhir:ProcedureRequest.priority [ code ]; # 0..1 routine | urgent | asap | stat
  fhir:ProcedureRequest.doNotPerform [ boolean ]; # 0..1 True if procedure should not be performed
  fhir:ProcedureRequest.category [ CodeableConcept ], ... ; # 0..* Classification of procedure
  fhir:ProcedureRequest.code [ CodeableConcept ]; # 1..1 What is being requested/ordered
  fhir:ProcedureRequest.subject [ Reference(Patient|Group|Location|Device) ]; # 1..1 Individual the service is ordered for
  fhir:ProcedureRequest.context [ Reference(Encounter|EpisodeOfCare) ]; # 0..1 Encounter or Episode during which request was created
  # ProcedureRequest.occurrence[x] : 0..1 When procedure should occur. One of these 3
    fhir:ProcedureRequest.occurrenceDateTime [ dateTime ]
    fhir:ProcedureRequest.occurrencePeriod [ Period ]
    fhir:ProcedureRequest.occurrenceTiming [ Timing ]
  # ProcedureRequest.asNeeded[x] : 0..1 Preconditions for procedure or diagnostic. One of these 2
    fhir:ProcedureRequest.asNeededBoolean [ boolean ]
    fhir:ProcedureRequest.asNeededCodeableConcept [ CodeableConcept ]
  fhir:ProcedureRequest.authoredOn [ dateTime ]; # 0..1 Date request signed
  fhir:ProcedureRequest.requester [ # 0..1 Who/what is requesting procedure or diagnostic
    fhir:ProcedureRequest.requester.agent [ Reference(Device|Practitioner|Organization) ]; # 1..1 Individual making the request
    fhir:ProcedureRequest.requester.onBehalfOf [ Reference(Organization) ]; # 0..1 Organization agent is acting for
  ];
  fhir:ProcedureRequest.performerType [ CodeableConcept ]; # 0..1 Performer role
  fhir:ProcedureRequest.performer [ Reference(Practitioner|Organization|Patient|Device|RelatedPerson|HealthcareService) ]; # 0..1 Requested perfomer
  fhir:ProcedureRequest.reasonCode [ CodeableConcept ], ... ; # 0..* Explanation/Justification for test
  fhir:ProcedureRequest.reasonReference [ Reference(Condition|Observation) ], ... ; # 0..* Explanation/Justification for test
  fhir:ProcedureRequest.supportingInfo [ Reference(Any) ], ... ; # 0..* Additional clinical information
  fhir:ProcedureRequest.specimen [ Reference(Specimen) ], ... ; # 0..* Procedure Samples
  fhir:ProcedureRequest.bodySite [ CodeableConcept ], ... ; # 0..* Location on Body
  fhir:ProcedureRequest.note [ Annotation ], ... ; # 0..* Comments
  fhir:ProcedureRequest.relevantHistory [ Reference(Provenance) ], ... ; # 0..* Request provenance
]

Changes since DSTU2

ProcedureRequest
ProcedureRequest.definition
  • Added Element
ProcedureRequest.basedOn
  • Added Element
ProcedureRequest.replaces
  • Added Element
ProcedureRequest.requisition
  • Added Element
ProcedureRequest.status
  • Min Cardinality changed from 0 to 1
  • Change value set from http://hl7.org/fhir/ValueSet/procedure-request-status to http://hl7.org/fhir/ValueSet/request-status
ProcedureRequest.intent
  • Added Element
ProcedureRequest.priority
  • Change value set from http://hl7.org/fhir/ValueSet/procedure-request-priority to http://hl7.org/fhir/ValueSet/request-priority
ProcedureRequest.doNotPerform
  • Added Element
ProcedureRequest.category
  • Added Element
ProcedureRequest.subject
  • Add Reference(Location), Add Reference(Device)
ProcedureRequest.context
  • Renamed from encounter to context
  • Add Reference(EpisodeOfCare)
ProcedureRequest.occurrence[x]
  • Added Element
ProcedureRequest.authoredOn
  • Renamed from orderedOn to authoredOn
ProcedureRequest.requester
  • Added Element
ProcedureRequest.requester.agent
  • Added Element
ProcedureRequest.requester.onBehalfOf
  • Added Element
ProcedureRequest.performerType
  • Added Element
ProcedureRequest.performer
  • Add Reference(Device), Add Reference(HealthcareService)
ProcedureRequest.reasonCode
  • Added Element
ProcedureRequest.reasonReference
  • Added Element
ProcedureRequest.supportingInfo
  • Added Element
ProcedureRequest.specimen
  • Added Element
ProcedureRequest.note
  • Renamed from notes to note
ProcedureRequest.relevantHistory
  • Added Element
ProcedureRequest.reason[x]
  • deleted
ProcedureRequest.scheduled[x]
  • deleted
ProcedureRequest.orderer
  • deleted

See the Full Difference for further information

This analysis is available as XML or JSON.

See R2 <--> R3 Conversion Maps (status = 6 tests that all execute ok. 5 fail round-trip testing and 6 r3 resources are invalid (9 errors).).

 

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

12.15.3.1 Terminology Bindings

PathDefinitionTypeReference
ProcedureRequest.status The status of a procedure or diagnostic order.RequiredRequestStatus
ProcedureRequest.intent The kind of procedure or diagnostic requestRequiredRequestIntent
ProcedureRequest.priority Identifies the level of importance to be assigned to actioning the requestRequiredRequestPriority
ProcedureRequest.category Classification of the procedureExampleProcedure Category Codes (SNOMED CT)
ProcedureRequest.code Codes for tests/services that can be performed by procedure or diagnostic services. For laboratory, LOINC is (preferred)[http://hl7.org/fhir/STU3/terminologies.html#preferred] and a valueset using LOINC Order codes is available [here](valueset-diagnostic-requests.html).ExampleProcedure Codes (SNOMED CT)
ProcedureRequest.asNeeded[x] A coded concept identifying the pre-condition that should hold prior to performing a procedure. For example "pain", "on flare-up", etc.ExampleSNOMED CT Medication As Needed Reason Codes
ProcedureRequest.performerType Indicates specific responsibility of an individual within the care team, such as "Primary physician", "Team coordinator", "Caregiver", etc.ExampleParticipant Roles
ProcedureRequest.reasonCode Diagnosis or problem codes justifying the reason for requesting the procedure or diagnostic investigation.ExampleProcedure Reason Codes
ProcedureRequest.bodySite Codes describing anatomical locations. May include laterality.ExampleSNOMED CT Body Structures

12.15.4 Notes:

  • Many procedure requests will create a need to specify a specimen, body site, or body system. The request code will often have this information embedded in it - for example, 'serum glucose' or 'chest xray'. Alternatively, the specimen or bodysite element may be used to specify it.
  • The ProcedureRequest should only reference the Specimen resource directly when the diagnostic investigation is requested on already existing specimens. Conversely, if the request is entered first with an uncollected specimen, the Specimen resource will reference the DiagnosticRequest resource when it is created.
  • The reasonCode element is often for billing purposes. It may relate to the resources referred to in supportinginfo element and may be used to decide how a procedure or diagnostic investigation will be performed, or even if it will be performed at all

12.15.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.

NameTypeDescriptionExpressionIn Common
authoreddateDate request signedProcedureRequest.authoredOn
based-onreferenceWhat request fulfillsProcedureRequest.basedOn
(Any)
body-sitetokenWhere procedure is going to be doneProcedureRequest.bodySite
codetokenWhat is being requested/orderedProcedureRequest.code8 Resources
contextreferenceEncounter or Episode during which request was createdProcedureRequest.context
(EpisodeOfCare, Encounter)
definitionreferenceProtocol or definitionProcedureRequest.definition
(PlanDefinition, ActivityDefinition)
encounterreferenceAn encounter in which this request is madeProcedureRequest.context
(Encounter)		11 Resources
identifiertokenIdentifiers assigned to this orderProcedureRequest.identifier25 Resources
intenttokenproposal | plan | order +ProcedureRequest.intent
occurrencedateWhen procedure should occurProcedureRequest.occurrence
patientreferenceSearch by subject - a patientProcedureRequest.subject
(Patient)		30 Resources
performerreferenceRequested perfomerProcedureRequest.performer
(Practitioner, Organization, Device, Patient, HealthcareService, RelatedPerson)
performer-typetokenPerformer roleProcedureRequest.performerType
prioritytokenroutine | urgent | asap | statProcedureRequest.priority
replacesreferenceWhat request replacesProcedureRequest.replaces
(Any)
requesterreferenceIndividual making the requestProcedureRequest.requester.agent
(Practitioner, Organization, Device)
requisitiontokenComposite Request IDProcedureRequest.requisition
specimenreferenceSpecimen to be testedProcedureRequest.specimen
(Specimen)
statustokendraft | active | suspended | completed | entered-in-error | cancelledProcedureRequest.status
subjectreferenceSearch by subjectProcedureRequest.subject
(Group, Device, Patient, Location)