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 Group Maturity Level: 3 Trial Use Compartments: 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

Name Flags Card. Type Description & Constraints doco
.. ProcedureRequest DomainResource A request for a procedure or diagnostic to be performed
Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
... identifier Σ0..*Identifier Identifiers 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..1Identifier Composite Request ID
... status ?!Σ1..1code draft | active | suspended | completed | entered-in-error | cancelled
RequestStatus (Required)
... intent ?!Σ1..1code proposal | plan | order +
RequestIntent (Required)
... priority Σ0..1code routine | urgent | asap | stat
RequestPriority (Required)
... doNotPerform ?!Σ0..1boolean True if procedure should not be performed
... category Σ0..*CodeableConcept Classification of procedure
Procedure Category Codes (SNOMED CT) (Example)
... code Σ1..1CodeableConcept What 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..1dateTime Date request signed
... requester Σ0..1BackboneElement Who/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..1CodeableConcept Performer role
Participant Roles (Example)
... performer Σ0..1Reference(Practitioner | Organization | Patient | Device | RelatedPerson | HealthcareService)Requested perfomer
... reasonCode Σ0..*CodeableConcept Explanation/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..*CodeableConcept Location on Body
SNOMED CT Body Structures (Example)
... note 0..*Annotation Comments
... 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

Name Flags Card. Type Description & Constraints doco
.. ProcedureRequest DomainResource A request for a procedure or diagnostic to be performed
Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
... identifier Σ0..*Identifier Identifiers 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..1Identifier Composite Request ID
... status ?!Σ1..1code draft | active | suspended | completed | entered-in-error | cancelled
RequestStatus (Required)
... intent ?!Σ1..1code proposal | plan | order +
RequestIntent (Required)
... priority Σ0..1code routine | urgent | asap | stat
RequestPriority (Required)
... doNotPerform ?!Σ0..1boolean True if procedure should not be performed
... category Σ0..*CodeableConcept Classification of procedure
Procedure Category Codes (SNOMED CT) (Example)
... code Σ1..1CodeableConcept What 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..1dateTime Date request signed
... requester Σ0..1BackboneElement Who/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..1CodeableConcept Performer role
Participant Roles (Example)
... performer Σ0..1Reference(Practitioner | Organization | Patient | Device | RelatedPerson | HealthcareService)Requested perfomer
... reasonCode Σ0..*CodeableConcept Explanation/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..*CodeableConcept Location on Body
SNOMED CT Body Structures (Example)
... note 0..*Annotation Comments
... 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.Required RequestStatus
ProcedureRequest.intent The kind of procedure or diagnostic requestRequired RequestIntent
ProcedureRequest.priority Identifies the level of importance to be assigned to actioning the requestRequired RequestPriority
ProcedureRequest.category Classification of the procedureExample Procedure 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).Example Procedure 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.Example SNOMED 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.Example Participant Roles
ProcedureRequest.reasonCode Diagnosis or problem codes justifying the reason for requesting the procedure or diagnostic investigation.Example Procedure Reason Codes
ProcedureRequest.bodySite Codes describing anatomical locations. May include laterality.Example SNOMED 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.

Name Type Description Expression In Common
authored date Date request signed ProcedureRequest.authoredOn
based-on reference What request fulfills ProcedureRequest.basedOn
(Any)
body-site token Where procedure is going to be done ProcedureRequest.bodySite
code token What is being requested/ordered ProcedureRequest.code 8 Resources
context reference Encounter or Episode during which request was created ProcedureRequest.context
(EpisodeOfCare, Encounter)
definition reference Protocol or definition ProcedureRequest.definition
(PlanDefinition, ActivityDefinition)
encounter reference An encounter in which this request is made ProcedureRequest.context
(Encounter) 11 Resources
identifier token Identifiers assigned to this order ProcedureRequest.identifier 25 Resources
intent token proposal | plan | order + ProcedureRequest.intent
occurrence date When procedure should occur ProcedureRequest.occurrence
patient reference Search by subject - a patient ProcedureRequest.subject
(Patient) 30 Resources
performer reference Requested perfomer ProcedureRequest.performer
(Practitioner, Organization, Device, Patient, HealthcareService, RelatedPerson)
performer-type token Performer role ProcedureRequest.performerType
priority token routine | urgent | asap | stat ProcedureRequest.priority
replaces reference What request replaces ProcedureRequest.replaces
(Any)
requester reference Individual making the request ProcedureRequest.requester.agent
(Practitioner, Organization, Device)
requisition token Composite Request ID ProcedureRequest.requisition
specimen reference Specimen to be tested ProcedureRequest.specimen
(Specimen)
status token draft | active | suspended | completed | entered-in-error | cancelled ProcedureRequest.status
subject reference Search by subject ProcedureRequest.subject
(Group, Device, Patient, Location)

AltStyle によって変換されたページ (->オリジナル) /