STU 3 Ballot

This page is part of the FHIR Specification (v1.6.0: STU 3 Ballot 4). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R3 R2

9.9 Resource ProcedureRequest - Content

Patient Care Work GroupMaturity Level: 1Compartments: Device, Encounter, Patient, Practitioner, RelatedPerson

A request for a procedure to be performed. May be a proposal or an order.

9.9.1 Scope and Usage

A Procedure Request is a record of a request for a procedure to be performed. It can be used to represent a procedure that is planned, that is proposed, or that is ordered, as distinguished by the value of the ProcedureRequestStatus field.

A procedure is an activity that is performed with or on a patient as part of the provision of care. Examples include surgical procedures, diagnostic procedures, endoscopic procedures, biopsies, counseling, physiotherapy, exercise, etc. Procedures may be performed by a healthcare professional, a friend or relative or in some cases by the patient themselves.

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.

9.9.2 Boundaries and Relationships

ProcedureRequest is closely related to other types of "request" resources, particularly DiagnosticRequest and ReferralRequest. 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 or DiagnosticRequest are typically used when the requesting clinician has and wishes to exercise the authority (and expertise) to decide exactly what action will be done.
  • A ReferralRequest is used when the requesting practitioner is seeking another practitioner or organization to use their own expertise and/or authority to determine the specific action to take.
  • Whether an activity is deemed to be a procedure or only a diagnostic request is typically driven by how invasive the diagnostic process is. More invasive processes are typically represented as procedures, though the dividing line may vary by organization.

Irrespective of the guidance above, systems should be prepared for some degree of overlap between these resources and be prepared to execute searches against multiple resources in cases where differentiation cannot be guaranteed. As well, in some workflows more than one type of resource or even all three might exist; e.g. Upon receiving a ReferralRequest a practitioner might initiate a DiagnosticRequest. The diagnostic service might then initiate a ProcedureRequest.

The notion of ProcedureRequest and CommunicationRequest are also closely related. The boundary between determining whether an action is considered to be training or counseling (and thus a ProcedureRequest) as opposed to a CommunicationRequest is based on whether there's a specific intent to change the mind-set of the patient. A request to merely disclose information would be considered a CommunicationRequest. Invocation of a process that will involve verification of the patient's comprehension or an attempt to change the patient's mental state would be a ProcedureRequest.

PLANNED CHANGE:

ProcedureRequest is one of the Request resources in the FHIR Workflow specification. As such, it is expected to be adjusted to align with the Request workflow pattern which will involve adding a number of additional data elements and potentially renaming a few elements. Any concerns about performing such alignment are welcome as ballot comments and/or tracker items.

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

9.9.3 Resource Content

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. ProcedureRequest ΣDomainResourceA request for a procedure to be performed
... identifier Σ0..*IdentifierUnique identifier for the request
... subject Σ1..1Reference(Patient | Group)Who the procedure should be done to
... code Σ1..1CodeableConceptWhat procedure to perform
Procedure Codes (SNOMED CT) (Example)
... bodySite Σ0..*CodeableConceptWhat part of body to perform on
SNOMED CT Body Structures (Example)
... reason[x] Σ0..1Why procedure should occur
Procedure Reason Codes (Example)
.... reasonCodeableConceptCodeableConcept
.... reasonReferenceReference(Condition)
... scheduled[x] Σ0..1When procedure should occur
.... scheduledDateTimedateTime
.... scheduledPeriodPeriod
.... scheduledTimingTiming
... encounter Σ0..1Reference(Encounter)Encounter request created during
... performer Σ0..1Reference(Practitioner | Organization | Patient | RelatedPerson)Who should perform the procedure
... status ?!Σ0..1codeproposed | draft | requested | received | accepted | in-progress | completed | suspended | rejected | aborted
ProcedureRequestStatus (Required)
... notes Σ0..*AnnotationAdditional information about desired procedure
... asNeeded[x] Σ0..1Preconditions for procedure
.... asNeededBooleanboolean
.... asNeededCodeableConceptCodeableConcept
... orderedOn Σ0..1dateTimeWhen request was created
... orderer Σ0..1Reference(Practitioner | Patient | RelatedPerson | Device)Who made request
... priority Σ0..1coderoutine | urgent | stat | asap
ProcedureRequestPriority (Required)

doco Documentation for this format

UML Diagram (Legend)

ProcedureRequest (DomainResource)Identifiers assigned to this order by the order or by the receiveridentifier : Identifier [0..*]The person, animal or group that should receive the proceduresubject : Reference [1..1] « Patient|Group »The specific procedure that is ordered. Use text if the exact nature of the procedure cannot be codedcode : CodeableConcept [1..1] « A code to identify a specific procedure . (Strength=Example)Procedure Codes (SNOMED CT)?? »Indicates the sites on the subject's body where the procedure should be performed (I.e. the target sites)bodySite : CodeableConcept [0..*] « A code that identifies the anatomical location. (Strength=Example)SNOMED CT Body Structures?? »The reason why the procedure is being proposed or ordered. This procedure request may be motivated by a Condition for instancereason[x] : Type [0..1] « CodeableConcept|Reference(Condition); A code that explains the reason why a procedure is required. (Strength=Example) Procedure Reason ?? »The timing schedule for the proposed or ordered procedure. The Schedule data type allows many different expressions. E.g. "Every 8 hours"; "Three times a day"; "1/2 an hour before breakfast for 10 days from 23-Dec 2011:"; "15 Oct 2013, 17 Oct 2013 and 1 Nov 2013"scheduled[x] : Type [0..1] « dateTime|Period|Timing »The encounter within which the procedure proposal or request was createdencounter : Reference [0..1] « Encounter »For example, the surgeon, anaethetist, endoscopist, etcperformer : Reference [0..1] « Practitioner|Organization|Patient| RelatedPerson »The status of the order (this element modifies the meaning of other elements)status : code [0..1] « The status of the request. (Strength=Required)ProcedureRequestStatus! »Any other notes associated with this proposal or order - e.g. provider instructionsnotes : Annotation [0..*]If a CodeableConcept is present, it indicates the pre-condition for performing the procedureasNeeded[x] : Type [0..1] « boolean|CodeableConcept »The time when the request was madeorderedOn : dateTime [0..1]The healthcare professional responsible for proposing or ordering the procedureorderer : Reference [0..1] « Practitioner|Patient|RelatedPerson| Device »The clinical priority associated with this orderpriority : code [0..1] « The priority of the request. (Strength=Required)ProcedureRequestPriority! »

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 Unique identifier for the request --></identifier>
 <subject><!-- 1..1 Reference(Patient|Group) Who the procedure should be done to --></subject>
 <code><!-- 1..1 CodeableConcept What procedure to perform --></code>
 <bodySite><!-- 0..* CodeableConcept What part of body to perform on --></bodySite>
 <reason[x]><!-- 0..1 CodeableConcept|Reference(Condition) Why procedure should occur --></reason[x]>
 <scheduled[x]><!-- 0..1 dateTime|Period|Timing When procedure should occur --></scheduled[x]>
 <encounter><!-- 0..1 Reference(Encounter) Encounter request created during --></encounter>
 <performer><!-- 0..1 Reference(Practitioner|Organization|Patient|RelatedPerson) Who should perform the procedure --></performer>
 <status value="[code]"/><!-- 0..1 proposed | draft | requested | received | accepted | in-progress | completed | suspended | rejected | aborted -->
 <notes><!-- 0..* Annotation Additional information about desired procedure --></notes>
 <asNeeded[x]><!-- 0..1 boolean|CodeableConcept Preconditions for procedure --></asNeeded[x]>
 <orderedOn value="[dateTime]"/><!-- 0..1 When request was created -->
 <orderer><!-- 0..1 Reference(Practitioner|Patient|RelatedPerson|Device) Who made request --></orderer>
 <priority value="[code]"/><!-- 0..1 routine | urgent | stat | asap -->
</ProcedureRequest>

JSON Template

{doco
  "resourceType" : "ProcedureRequest",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "identifier" : [{ Identifier }], // Unique identifier for the request
  "subject" : { Reference(Patient|Group) }, // R!  Who the procedure should be done to
  "code" : { CodeableConcept }, // R!  What procedure to perform
  "bodySite" : [{ CodeableConcept }], // What part of body to perform on
  // reason[x]: Why procedure should occur. One of these 2:
  "reasonCodeableConcept" : { CodeableConcept },
  "reasonReference" : { Reference(Condition) },
  // scheduled[x]: When procedure should occur. One of these 3:
  "scheduledDateTime" : "<dateTime>",
  "scheduledPeriod" : { Period },
  "scheduledTiming" : { Timing },
  "encounter" : { Reference(Encounter) }, // Encounter request created during
  "performer" : { Reference(Practitioner|Organization|Patient|RelatedPerson) }, // Who should perform the procedure
  "status" : "<code>", // proposed | draft | requested | received | accepted | in-progress | completed | suspended | rejected | aborted
  "notes" : [{ Annotation }], // Additional information about desired procedure
  // asNeeded[x]: Preconditions for procedure. One of these 2:
  "asNeededBoolean" : <boolean>,
  "asNeededCodeableConcept" : { CodeableConcept },
  "orderedOn" : "<dateTime>", // When request was created
  "orderer" : { Reference(Practitioner|Patient|RelatedPerson|Device) }, // Who made request
  "priority" : "<code>" // routine | urgent | stat | asap
}

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..* Unique identifier for the request
  fhir:ProcedureRequest.subject [ Reference(Patient|Group) ]; # 1..1 Who the procedure should be done to
  fhir:ProcedureRequest.code [ CodeableConcept ]; # 1..1 What procedure to perform
  fhir:ProcedureRequest.bodySite [ CodeableConcept ], ... ; # 0..* What part of body to perform on
  # ProcedureRequest.reason[x] : 0..1 Why procedure should occur. One of these 2
    fhir:ProcedureRequest.reasonCodeableConcept [ CodeableConcept ]
    fhir:ProcedureRequest.reasonReference [ Reference(Condition) ]
  # ProcedureRequest.scheduled[x] : 0..1 When procedure should occur. One of these 3
    fhir:ProcedureRequest.scheduledDateTime [ dateTime ]
    fhir:ProcedureRequest.scheduledPeriod [ Period ]
    fhir:ProcedureRequest.scheduledTiming [ Timing ]
  fhir:ProcedureRequest.encounter [ Reference(Encounter) ]; # 0..1 Encounter request created during
  fhir:ProcedureRequest.performer [ Reference(Practitioner|Organization|Patient|RelatedPerson) ]; # 0..1 Who should perform the procedure
  fhir:ProcedureRequest.status [ code ]; # 0..1 proposed | draft | requested | received | accepted | in-progress | completed | suspended | rejected | aborted
  fhir:ProcedureRequest.notes [ Annotation ], ... ; # 0..* Additional information about desired procedure
  # ProcedureRequest.asNeeded[x] : 0..1 Preconditions for procedure. One of these 2
    fhir:ProcedureRequest.asNeededBoolean [ boolean ]
    fhir:ProcedureRequest.asNeededCodeableConcept [ CodeableConcept ]
  fhir:ProcedureRequest.orderedOn [ dateTime ]; # 0..1 When request was created
  fhir:ProcedureRequest.orderer [ Reference(Practitioner|Patient|RelatedPerson|Device) ]; # 0..1 Who made request
  fhir:ProcedureRequest.priority [ code ]; # 0..1 routine | urgent | stat | asap
]

Changes since DSTU2

ProcedureRequest No Changes

See the Full Difference for further information

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. ProcedureRequest ΣDomainResourceA request for a procedure to be performed
... identifier Σ0..*IdentifierUnique identifier for the request
... subject Σ1..1Reference(Patient | Group)Who the procedure should be done to
... code Σ1..1CodeableConceptWhat procedure to perform
Procedure Codes (SNOMED CT) (Example)
... bodySite Σ0..*CodeableConceptWhat part of body to perform on
SNOMED CT Body Structures (Example)
... reason[x] Σ0..1Why procedure should occur
Procedure Reason Codes (Example)
.... reasonCodeableConceptCodeableConcept
.... reasonReferenceReference(Condition)
... scheduled[x] Σ0..1When procedure should occur
.... scheduledDateTimedateTime
.... scheduledPeriodPeriod
.... scheduledTimingTiming
... encounter Σ0..1Reference(Encounter)Encounter request created during
... performer Σ0..1Reference(Practitioner | Organization | Patient | RelatedPerson)Who should perform the procedure
... status ?!Σ0..1codeproposed | draft | requested | received | accepted | in-progress | completed | suspended | rejected | aborted
ProcedureRequestStatus (Required)
... notes Σ0..*AnnotationAdditional information about desired procedure
... asNeeded[x] Σ0..1Preconditions for procedure
.... asNeededBooleanboolean
.... asNeededCodeableConceptCodeableConcept
... orderedOn Σ0..1dateTimeWhen request was created
... orderer Σ0..1Reference(Practitioner | Patient | RelatedPerson | Device)Who made request
... priority Σ0..1coderoutine | urgent | stat | asap
ProcedureRequestPriority (Required)

doco Documentation for this format

UML Diagram (Legend)

ProcedureRequest (DomainResource)Identifiers assigned to this order by the order or by the receiveridentifier : Identifier [0..*]The person, animal or group that should receive the proceduresubject : Reference [1..1] « Patient|Group »The specific procedure that is ordered. Use text if the exact nature of the procedure cannot be codedcode : CodeableConcept [1..1] « A code to identify a specific procedure . (Strength=Example)Procedure Codes (SNOMED CT)?? »Indicates the sites on the subject's body where the procedure should be performed (I.e. the target sites)bodySite : CodeableConcept [0..*] « A code that identifies the anatomical location. (Strength=Example)SNOMED CT Body Structures?? »The reason why the procedure is being proposed or ordered. This procedure request may be motivated by a Condition for instancereason[x] : Type [0..1] « CodeableConcept|Reference(Condition); A code that explains the reason why a procedure is required. (Strength=Example) Procedure Reason ?? »The timing schedule for the proposed or ordered procedure. The Schedule data type allows many different expressions. E.g. "Every 8 hours"; "Three times a day"; "1/2 an hour before breakfast for 10 days from 23-Dec 2011:"; "15 Oct 2013, 17 Oct 2013 and 1 Nov 2013"scheduled[x] : Type [0..1] « dateTime|Period|Timing »The encounter within which the procedure proposal or request was createdencounter : Reference [0..1] « Encounter »For example, the surgeon, anaethetist, endoscopist, etcperformer : Reference [0..1] « Practitioner|Organization|Patient| RelatedPerson »The status of the order (this element modifies the meaning of other elements)status : code [0..1] « The status of the request. (Strength=Required)ProcedureRequestStatus! »Any other notes associated with this proposal or order - e.g. provider instructionsnotes : Annotation [0..*]If a CodeableConcept is present, it indicates the pre-condition for performing the procedureasNeeded[x] : Type [0..1] « boolean|CodeableConcept »The time when the request was madeorderedOn : dateTime [0..1]The healthcare professional responsible for proposing or ordering the procedureorderer : Reference [0..1] « Practitioner|Patient|RelatedPerson| Device »The clinical priority associated with this orderpriority : code [0..1] « The priority of the request. (Strength=Required)ProcedureRequestPriority! »

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 Unique identifier for the request --></identifier>
 <subject><!-- 1..1 Reference(Patient|Group) Who the procedure should be done to --></subject>
 <code><!-- 1..1 CodeableConcept What procedure to perform --></code>
 <bodySite><!-- 0..* CodeableConcept What part of body to perform on --></bodySite>
 <reason[x]><!-- 0..1 CodeableConcept|Reference(Condition) Why procedure should occur --></reason[x]>
 <scheduled[x]><!-- 0..1 dateTime|Period|Timing When procedure should occur --></scheduled[x]>
 <encounter><!-- 0..1 Reference(Encounter) Encounter request created during --></encounter>
 <performer><!-- 0..1 Reference(Practitioner|Organization|Patient|RelatedPerson) Who should perform the procedure --></performer>
 <status value="[code]"/><!-- 0..1 proposed | draft | requested | received | accepted | in-progress | completed | suspended | rejected | aborted -->
 <notes><!-- 0..* Annotation Additional information about desired procedure --></notes>
 <asNeeded[x]><!-- 0..1 boolean|CodeableConcept Preconditions for procedure --></asNeeded[x]>
 <orderedOn value="[dateTime]"/><!-- 0..1 When request was created -->
 <orderer><!-- 0..1 Reference(Practitioner|Patient|RelatedPerson|Device) Who made request --></orderer>
 <priority value="[code]"/><!-- 0..1 routine | urgent | stat | asap -->
</ProcedureRequest>

JSON Template

{doco
  "resourceType" : "ProcedureRequest",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "identifier" : [{ Identifier }], // Unique identifier for the request
  "subject" : { Reference(Patient|Group) }, // R!  Who the procedure should be done to
  "code" : { CodeableConcept }, // R!  What procedure to perform
  "bodySite" : [{ CodeableConcept }], // What part of body to perform on
  // reason[x]: Why procedure should occur. One of these 2:
  "reasonCodeableConcept" : { CodeableConcept },
  "reasonReference" : { Reference(Condition) },
  // scheduled[x]: When procedure should occur. One of these 3:
  "scheduledDateTime" : "<dateTime>",
  "scheduledPeriod" : { Period },
  "scheduledTiming" : { Timing },
  "encounter" : { Reference(Encounter) }, // Encounter request created during
  "performer" : { Reference(Practitioner|Organization|Patient|RelatedPerson) }, // Who should perform the procedure
  "status" : "<code>", // proposed | draft | requested | received | accepted | in-progress | completed | suspended | rejected | aborted
  "notes" : [{ Annotation }], // Additional information about desired procedure
  // asNeeded[x]: Preconditions for procedure. One of these 2:
  "asNeededBoolean" : <boolean>,
  "asNeededCodeableConcept" : { CodeableConcept },
  "orderedOn" : "<dateTime>", // When request was created
  "orderer" : { Reference(Practitioner|Patient|RelatedPerson|Device) }, // Who made request
  "priority" : "<code>" // routine | urgent | stat | asap
}

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..* Unique identifier for the request
  fhir:ProcedureRequest.subject [ Reference(Patient|Group) ]; # 1..1 Who the procedure should be done to
  fhir:ProcedureRequest.code [ CodeableConcept ]; # 1..1 What procedure to perform
  fhir:ProcedureRequest.bodySite [ CodeableConcept ], ... ; # 0..* What part of body to perform on
  # ProcedureRequest.reason[x] : 0..1 Why procedure should occur. One of these 2
    fhir:ProcedureRequest.reasonCodeableConcept [ CodeableConcept ]
    fhir:ProcedureRequest.reasonReference [ Reference(Condition) ]
  # ProcedureRequest.scheduled[x] : 0..1 When procedure should occur. One of these 3
    fhir:ProcedureRequest.scheduledDateTime [ dateTime ]
    fhir:ProcedureRequest.scheduledPeriod [ Period ]
    fhir:ProcedureRequest.scheduledTiming [ Timing ]
  fhir:ProcedureRequest.encounter [ Reference(Encounter) ]; # 0..1 Encounter request created during
  fhir:ProcedureRequest.performer [ Reference(Practitioner|Organization|Patient|RelatedPerson) ]; # 0..1 Who should perform the procedure
  fhir:ProcedureRequest.status [ code ]; # 0..1 proposed | draft | requested | received | accepted | in-progress | completed | suspended | rejected | aborted
  fhir:ProcedureRequest.notes [ Annotation ], ... ; # 0..* Additional information about desired procedure
  # ProcedureRequest.asNeeded[x] : 0..1 Preconditions for procedure. One of these 2
    fhir:ProcedureRequest.asNeededBoolean [ boolean ]
    fhir:ProcedureRequest.asNeededCodeableConcept [ CodeableConcept ]
  fhir:ProcedureRequest.orderedOn [ dateTime ]; # 0..1 When request was created
  fhir:ProcedureRequest.orderer [ Reference(Practitioner|Patient|RelatedPerson|Device) ]; # 0..1 Who made request
  fhir:ProcedureRequest.priority [ code ]; # 0..1 routine | urgent | stat | asap
]

Changes since DSTU2

ProcedureRequest No Changes

See the Full Difference for further information

 

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

9.9.3.1 Terminology Bindings

PathDefinitionTypeReference
ProcedureRequest.code A code to identify a specific procedure .ExampleProcedure Codes (SNOMED CT)
ProcedureRequest.bodySite A code that identifies the anatomical location.ExampleSNOMED CT Body Structures
ProcedureRequest.reason[x] A code that explains the reason why a procedure is required.ExampleProcedure Reason Codes
ProcedureRequest.status The status of the request.RequiredProcedureRequestStatus
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.UnknownNo details provided yet
ProcedureRequest.priority The priority of the request.RequiredProcedureRequestPriority

Notes to reviewers:

At this time, the code bindings are placeholders to be fleshed out upon further review by the community.

9.9.4 Search Parameters

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

NameTypeDescriptionPaths
encounterreferenceEncounter request created duringProcedureRequest.encounter
(Encounter)
identifiertokenA unique identifier of the Procedure RequestProcedureRequest.identifier
ordererreferenceWho made requestProcedureRequest.orderer
(Practitioner, Device, Patient, RelatedPerson)
patientreferenceSearch by subject - a patientProcedureRequest.subject
(Patient)
performerreferenceWho should perform the procedureProcedureRequest.performer
(Practitioner, Organization, Patient, RelatedPerson)
subjectreferenceSearch by subjectProcedureRequest.subject
(Group, Patient)