US Core Implementation Guide
7.0.0 - STU7 United States of America flag

US Core Implementation Guide, published by HL7 International / Cross-Group Projects. This guide is not an authorized publication; it is the continuous build for version 7.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/US-Core/ and changes regularly. See the Directory of published versions

Resource Profile: US Core Procedure Profile

Official URL: http://hl7.org/fhir/us/core/StructureDefinition/us-core-procedure Version: 7.0.0
Standards status: Trial-use Maturity Level: 3 Computable Name: USCoreProcedureProfile
Other Identifiers: OID:2.16.840.1.113883.4.642.40.2.42.46

Copyright/Legal: Used by permission of HL7 International, all rights reserved Creative Commons License

The US Core Procedure Profile inherits from the FHIR Procedure resource; refer to it for scope and usage definitions. This profile meets the requirements of the U.S. Core Data for Interoperability (USCDI) Procedures Data Class. It sets minimum expectations for the Procedure resource to record, search, and fetch procedure information associated with a patient. It specifies which core elements, extensions, vocabularies, and value sets SHALL be present and constrains how the elements are used. Providing the floor for standards development for specific use cases promotes interoperability and adoption.

Example Usage Scenarios:

The following are example usage scenarios for this profile:

  • Query for procedures performed on a Patient
  • Record or update a procedure performed on a Patient

Mandatory and Must Support Data Elements

The following data elements must always be present (Mandatory definition) or must be supported if the data is present in the sending system (Must Support definition). They are presented below in a simple human-readable explanation. Profile specific guidance and examples are provided as well. The Formal Views below provides the formal summary, definitions, and terminology requirements.

Each Procedure Must Have:

  1. a status
  2. a code that identifies the type of procedure performed on the patient*
  3. a patient
  4. when the procedure was performed*

Each Procedure Must Support:

  1. the encounter associated with the procedure

Additional USCDI Requirements:

This Additional USCDI Requirements element is not Mandatory or Must Support but is required for ONC Health IT certification testing and is included in the formal definition of the profile and the Procedure examples.

  1. a reason or indication for referral or consultation*

*see guidance below

Profile Specific Implementation Guidance:

  • *The Procedure.code is mandatory if Procedure.status is ‘completed’ or ‘in-progress’.
  • *The Procedure.code has an additional binding of “current” and a base “preferred” binding.
    • For the conformance rules on the current binding for coded data, review this section in the General Requirements page.
    • Procedure codes can be taken from SNOMED-CT, CPT, HCPCS II, ICD-10-PCS, CDT, or LOINC.
      • Only LOINC concepts that reflect actual procedures SHOULD be used
  • A procedure including an implantable device SHOULD use Procedure.focalDevice referencing the US Core Implantable Device Profile.
  • See the Screening and Assessments guidance page for more information when exchanging Social Determinants of Health (SDOH) Procedures

  • *Servers and Clients SHALL support both US Core ServiceRequest and US Core Procedure Profiles for communicating the reason or justification for a referral as Additional USCDI Requirements. Typically, the reason or justification for a referral or consultation is communicated through Procedure.basedOn linking the Procedure to the US Core ServiceRequest Profile that includes either ServiceRequest.reasonCode or ServiceRequest.reasonReference. When the Procedure does not have an associated ServiceRequest, it is communicated through the US Core Procedure Profile’s Procedure.reasonCode or Procedure.reasonReference. Depending on the procedure being documented, a server will select the appropriate Profile to use.
    • Although both Procedure.reasonCode and Procedure.reasonReference are marked as Additional USCDI Requirements, the certifying server system is not required to support both, but SHALL support at least one of these elements. The certifying client application SHALL support both elements.
      • when using Procedure.reasonReference:
        • Servers SHALL support at least one target resource in Procedure.reasonReference. Clients SHALL support all target resources in Procedure.reasonReference.
        • The referenced resources SHOULD be a US Core Profile as documented in Referencing US Core Profiles.

Usage:

Formal Views of Profile Content

Description of Profiles, Differentials, Snapshots and how the different presentations work.

This structure is derived from Procedure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Procedure C 0..* Procedure An action that is being or was performed on a patient
us-core-7: Performed SHALL be present if the status is 'completed' or 'in-progress'
... basedOn 0..* Reference(US Core CarePlan Profile | US Core ServiceRequest Profile) 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: A request for this procedure
... status SC 1..1 code preparation | in-progress | not-done | on-hold | stopped | completed | entered-in-error | unknown
Binding: EventStatus (required)
... code S 1..1 CodeableConcept Identification of the procedure
Binding: US Core Procedure Codes (preferred): Codes describing the type of Procedure

Additional BindingsPurpose
US Core Procedure Codes Current
... subject S 1..1 Reference(US Core Patient Profile S | Group) Who the procedure was performed on
... encounter S 0..1 Reference(US Core Encounter Profile) Encounter associated with the procedure
... performed[x] SC 0..1 When the procedure was performed
.... performedDateTime dateTime S
.... performedPeriod Period
.... performedString string
.... performedAge Age
.... performedRange Range
... reasonCode 0..* CodeableConcept 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: Coded reason procedure performed
Binding: US Core Condition Codes (extensible)
... reasonReference 0..* Reference(Condition | Observation | Procedure | DiagnosticReport | DocumentReference) 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: US Core Profile justifying the reason procedure performed

doco Documentation for this format

Terminology Bindings (Differential)

PathConformanceValueSetURI
Procedure.statusrequiredEventStatus
http://hl7.org/fhir/ValueSet/event-status
from the FHIR Standard
Procedure.codepreferredUSCoreProcedureCodes
Additional Bindings Purpose Documentation
US Core Procedure Codes Current

US Core uses the current additional binding from FHIR R5 for this coded element for more flexibility when exchanging legacy and text-only data.

http://hl7.org/fhir/us/core/ValueSet/us-core-procedure-code
from this IG
Procedure.reasonCodeextensibleUSCoreConditionCodes
http://hl7.org/fhir/us/core/ValueSet/us-core-condition-code
from this IG

Constraints

IdGradePath(s)DetailsRequirements
us-core-7errorProcedurePerformed SHALL be present if the status is 'completed' or 'in-progress'
: (status='completed' or status='in-progress') implies performed.exists()
NameFlagsCard.TypeDescription & Constraintsdoco
.. Procedure C 0..* Procedure An action that is being or was performed on a patient
us-core-7: Performed SHALL be present if the status is 'completed' or 'in-progress'
... implicitRules ?!Σ 0..1 uri A set of rules under which this content was created
... modifierExtension ?! 0..* Extension Extensions that cannot be ignored
... basedOn Σ 0..* Reference(US Core CarePlan Profile | US Core ServiceRequest Profile) 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: A request for this procedure
... status ?!SΣC 1..1 code preparation | in-progress | not-done | on-hold | stopped | completed | entered-in-error | unknown
Binding: EventStatus (required)
... code SΣ 1..1 CodeableConcept Identification of the procedure
Binding: US Core Procedure Codes (preferred): Codes describing the type of Procedure

Additional BindingsPurpose
US Core Procedure Codes Current
... subject SΣ 1..1 Reference(US Core Patient Profile) Who the procedure was performed on
... encounter SΣ 0..1 Reference(US Core Encounter Profile) Encounter associated with the procedure
... performed[x] SΣC 0..1 When the procedure was performed
.... performedDateTime dateTime
... reasonCode Σ 0..* CodeableConcept 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: Coded reason procedure performed
Binding: US Core Condition Codes (extensible)
... reasonReference Σ 0..* Reference(Condition | Observation | Procedure | DiagnosticReport | DocumentReference) 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: US Core Profile justifying the reason procedure performed

doco Documentation for this format

Terminology Bindings

PathConformanceValueSetURI
Procedure.statusrequiredEventStatus
http://hl7.org/fhir/ValueSet/event-status
from the FHIR Standard
Procedure.codepreferredUSCoreProcedureCodes
Additional Bindings Purpose Documentation
US Core Procedure Codes Current

US Core uses the current additional binding from FHIR R5 for this coded element for more flexibility when exchanging legacy and text-only data.

http://hl7.org/fhir/us/core/ValueSet/us-core-procedure-code
from this IG
Procedure.reasonCodeextensibleUSCoreConditionCodes
http://hl7.org/fhir/us/core/ValueSet/us-core-condition-code
from this IG

Constraints

IdGradePath(s)DetailsRequirements
us-core-7errorProcedurePerformed SHALL be present if the status is 'completed' or 'in-progress'
: (status='completed' or status='in-progress') implies performed.exists()
NameFlagsCard.TypeDescription & Constraintsdoco
.. Procedure C 0..* Procedure An action that is being or was performed on a patient
us-core-7: Performed SHALL be present if the status is 'completed' or 'in-progress'
... id Σ 0..1 id Logical id of this artifact
... meta Σ 0..1 Meta Metadata about the resource
... implicitRules ?!Σ 0..1 uri A set of rules under which this content was created
... language 0..1 code Language of the resource content
Binding: CommonLanguages (preferred): A human language.

Additional BindingsPurpose
AllLanguages Max Binding
... text 0..1 Narrative Text summary of the resource, for human interpretation
... contained 0..* Resource Contained, inline Resources
... extension 0..* Extension Additional content defined by implementations
... modifierExtension ?! 0..* Extension Extensions that cannot be ignored
... identifier Σ 0..* Identifier External Identifiers for this procedure
... instantiatesCanonical Σ 0..* canonical(PlanDefinition | ActivityDefinition | Measure | OperationDefinition | Questionnaire) Instantiates FHIR protocol or definition
... instantiatesUri Σ 0..* uri Instantiates external protocol or definition
... basedOn Σ 0..* Reference(US Core CarePlan Profile | US Core ServiceRequest Profile) 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: A request for this procedure
... partOf Σ 0..* Reference(Procedure | Observation | MedicationAdministration) Part of referenced event
... status ?!SΣC 1..1 code preparation | in-progress | not-done | on-hold | stopped | completed | entered-in-error | unknown
Binding: EventStatus (required)
... statusReason Σ 0..1 CodeableConcept Reason for current status
Binding: ProcedureNotPerformedReason(SNOMED-CT) (example): A code that identifies the reason a procedure was not performed.

... category Σ 0..1 CodeableConcept Classification of the procedure
Binding: ProcedureCategoryCodes(SNOMEDCT) (example): A code that classifies a procedure for searching, sorting and display purposes.

... code SΣ 1..1 CodeableConcept Identification of the procedure
Binding: US Core Procedure Codes (preferred): Codes describing the type of Procedure

Additional BindingsPurpose
US Core Procedure Codes Current
... subject SΣ 1..1 Reference(US Core Patient Profile S | Group) Who the procedure was performed on
... encounter SΣ 0..1 Reference(US Core Encounter Profile) Encounter associated with the procedure
... performed[x] SΣC 0..1 When the procedure was performed
.... performedDateTime dateTime S
.... performedPeriod Period
.... performedString string
.... performedAge Age
.... performedRange Range
... recorder Σ 0..1 Reference(Patient | RelatedPerson | Practitioner | PractitionerRole) Who recorded the procedure
... asserter Σ 0..1 Reference(Patient | RelatedPerson | Practitioner | PractitionerRole) Person who asserts this procedure
... performer Σ 0..* BackboneElement The people who performed the procedure
.... id 0..1 string Unique id for inter-element referencing
.... extension 0..* Extension Additional content defined by implementations
.... modifierExtension ?!Σ 0..* Extension Extensions that cannot be ignored even if unrecognized
.... function Σ 0..1 CodeableConcept Type of performance
Binding: ProcedurePerformerRoleCodes (example): A code that identifies the role of a performer of the procedure.

.... actor Σ 1..1 Reference(Practitioner | PractitionerRole | Organization | Patient | RelatedPerson | Device) The reference to the practitioner
.... onBehalfOf 0..1 Reference(Organization) Organization the device or practitioner was acting for
... location Σ 0..1 Reference(Location) Where the procedure happened
... reasonCode Σ 0..* CodeableConcept 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: Coded reason procedure performed
Binding: US Core Condition Codes (extensible)
... reasonReference Σ 0..* Reference(Condition | Observation | Procedure | DiagnosticReport | DocumentReference) 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: US Core Profile justifying the reason procedure performed
... bodySite Σ 0..* CodeableConcept Target body sites
Binding: SNOMEDCTBodyStructures (example): Codes describing anatomical locations. May include laterality.


... outcome Σ 0..1 CodeableConcept The result of procedure
Binding: ProcedureOutcomeCodes(SNOMEDCT) (example): An outcome of a procedure - whether it was resolved or otherwise.

... report 0..* Reference(DiagnosticReport | DocumentReference | Composition) Any report resulting from the procedure
... complication 0..* CodeableConcept Complication following the procedure
Binding: Condition/Problem/DiagnosisCodes (example): Codes describing complications that resulted from a procedure.


... complicationDetail 0..* Reference(Condition) A condition that is a result of the procedure
... followUp 0..* CodeableConcept Instructions for follow up
Binding: ProcedureFollowUpCodes(SNOMEDCT) (example): Specific follow up required for a procedure e.g. removal of sutures.


... note 0..* Annotation Additional information about the procedure
... focalDevice 0..* BackboneElement Manipulated, implanted, or removed device
.... id 0..1 string Unique id for inter-element referencing
.... extension 0..* Extension Additional content defined by implementations
.... modifierExtension ?!Σ 0..* Extension Extensions that cannot be ignored even if unrecognized
.... action 0..1 CodeableConcept Kind of change to device
Binding: ProcedureDeviceActionCodes (preferred): A kind of change that happened to the device during the procedure.

.... manipulated 1..1 Reference(Device) Device that was changed
... usedReference 0..* Reference(Device | Medication | Substance) Items used during procedure
... usedCode 0..* CodeableConcept Coded items used during the procedure
Binding: FHIRDeviceTypes (example): Codes describing items used during a procedure.



doco Documentation for this format

Terminology Bindings

PathConformanceValueSetURI
Procedure.languagepreferredCommonLanguages
Additional Bindings Purpose
AllLanguages Max Binding
http://hl7.org/fhir/ValueSet/languages
from the FHIR Standard
Procedure.statusrequiredEventStatus
http://hl7.org/fhir/ValueSet/event-status
from the FHIR Standard
Procedure.statusReasonexampleProcedureNotPerformedReason(SNOMED-CT)
http://hl7.org/fhir/ValueSet/procedure-not-performed-reason
from the FHIR Standard
Procedure.categoryexampleProcedureCategoryCodes(SNOMEDCT)
http://hl7.org/fhir/ValueSet/procedure-category
from the FHIR Standard
Procedure.codepreferredUSCoreProcedureCodes
Additional Bindings Purpose Documentation
US Core Procedure Codes Current

US Core uses the current additional binding from FHIR R5 for this coded element for more flexibility when exchanging legacy and text-only data.

http://hl7.org/fhir/us/core/ValueSet/us-core-procedure-code
from this IG
Procedure.performer.functionexampleProcedurePerformerRoleCodes
http://hl7.org/fhir/ValueSet/performer-role
from the FHIR Standard
Procedure.reasonCodeextensibleUSCoreConditionCodes
http://hl7.org/fhir/us/core/ValueSet/us-core-condition-code
from this IG
Procedure.bodySiteexampleSNOMEDCTBodyStructures
http://hl7.org/fhir/ValueSet/body-site
from the FHIR Standard
Procedure.outcomeexampleProcedureOutcomeCodes(SNOMEDCT)
http://hl7.org/fhir/ValueSet/procedure-outcome
from the FHIR Standard
Procedure.complicationexampleCondition/Problem/DiagnosisCodes
http://hl7.org/fhir/ValueSet/condition-code
from the FHIR Standard
Procedure.followUpexampleProcedureFollowUpCodes(SNOMEDCT)
http://hl7.org/fhir/ValueSet/procedure-followup
from the FHIR Standard
Procedure.focalDevice.actionpreferredProcedureDeviceActionCodes
http://hl7.org/fhir/ValueSet/device-action
from the FHIR Standard
Procedure.usedCodeexampleFHIRDeviceTypes
http://hl7.org/fhir/ValueSet/device-kind
from the FHIR Standard

Constraints

IdGradePath(s)DetailsRequirements
us-core-7errorProcedurePerformed SHALL be present if the status is 'completed' or 'in-progress'
: (status='completed' or status='in-progress') implies performed.exists()

Differential View

This structure is derived from Procedure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Procedure C 0..* Procedure An action that is being or was performed on a patient
us-core-7: Performed SHALL be present if the status is 'completed' or 'in-progress'
... basedOn 0..* Reference(US Core CarePlan Profile | US Core ServiceRequest Profile) 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: A request for this procedure
... status SC 1..1 code preparation | in-progress | not-done | on-hold | stopped | completed | entered-in-error | unknown
Binding: EventStatus (required)
... code S 1..1 CodeableConcept Identification of the procedure
Binding: US Core Procedure Codes (preferred): Codes describing the type of Procedure

Additional BindingsPurpose
US Core Procedure Codes Current
... subject S 1..1 Reference(US Core Patient Profile S | Group) Who the procedure was performed on
... encounter S 0..1 Reference(US Core Encounter Profile) Encounter associated with the procedure
... performed[x] SC 0..1 When the procedure was performed
.... performedDateTime dateTime S
.... performedPeriod Period
.... performedString string
.... performedAge Age
.... performedRange Range
... reasonCode 0..* CodeableConcept 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: Coded reason procedure performed
Binding: US Core Condition Codes (extensible)
... reasonReference 0..* Reference(Condition | Observation | Procedure | DiagnosticReport | DocumentReference) 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: US Core Profile justifying the reason procedure performed

doco Documentation for this format

Terminology Bindings (Differential)

PathConformanceValueSetURI
Procedure.statusrequiredEventStatus
http://hl7.org/fhir/ValueSet/event-status
from the FHIR Standard
Procedure.codepreferredUSCoreProcedureCodes
Additional Bindings Purpose Documentation
US Core Procedure Codes Current

US Core uses the current additional binding from FHIR R5 for this coded element for more flexibility when exchanging legacy and text-only data.

http://hl7.org/fhir/us/core/ValueSet/us-core-procedure-code
from this IG
Procedure.reasonCodeextensibleUSCoreConditionCodes
http://hl7.org/fhir/us/core/ValueSet/us-core-condition-code
from this IG

Constraints

IdGradePath(s)DetailsRequirements
us-core-7errorProcedurePerformed SHALL be present if the status is 'completed' or 'in-progress'
: (status='completed' or status='in-progress') implies performed.exists()

Key Elements View

NameFlagsCard.TypeDescription & Constraintsdoco
.. Procedure C 0..* Procedure An action that is being or was performed on a patient
us-core-7: Performed SHALL be present if the status is 'completed' or 'in-progress'
... implicitRules ?!Σ 0..1 uri A set of rules under which this content was created
... modifierExtension ?! 0..* Extension Extensions that cannot be ignored
... basedOn Σ 0..* Reference(US Core CarePlan Profile | US Core ServiceRequest Profile) 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: A request for this procedure
... status ?!SΣC 1..1 code preparation | in-progress | not-done | on-hold | stopped | completed | entered-in-error | unknown
Binding: EventStatus (required)
... code SΣ 1..1 CodeableConcept Identification of the procedure
Binding: US Core Procedure Codes (preferred): Codes describing the type of Procedure

Additional BindingsPurpose
US Core Procedure Codes Current
... subject SΣ 1..1 Reference(US Core Patient Profile) Who the procedure was performed on
... encounter SΣ 0..1 Reference(US Core Encounter Profile) Encounter associated with the procedure
... performed[x] SΣC 0..1 When the procedure was performed
.... performedDateTime dateTime
... reasonCode Σ 0..* CodeableConcept 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: Coded reason procedure performed
Binding: US Core Condition Codes (extensible)
... reasonReference Σ 0..* Reference(Condition | Observation | Procedure | DiagnosticReport | DocumentReference) 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: US Core Profile justifying the reason procedure performed

doco Documentation for this format

Terminology Bindings

PathConformanceValueSetURI
Procedure.statusrequiredEventStatus
http://hl7.org/fhir/ValueSet/event-status
from the FHIR Standard
Procedure.codepreferredUSCoreProcedureCodes
Additional Bindings Purpose Documentation
US Core Procedure Codes Current

US Core uses the current additional binding from FHIR R5 for this coded element for more flexibility when exchanging legacy and text-only data.

http://hl7.org/fhir/us/core/ValueSet/us-core-procedure-code
from this IG
Procedure.reasonCodeextensibleUSCoreConditionCodes
http://hl7.org/fhir/us/core/ValueSet/us-core-condition-code
from this IG

Constraints

IdGradePath(s)DetailsRequirements
us-core-7errorProcedurePerformed SHALL be present if the status is 'completed' or 'in-progress'
: (status='completed' or status='in-progress') implies performed.exists()

Snapshot View

NameFlagsCard.TypeDescription & Constraintsdoco
.. Procedure C 0..* Procedure An action that is being or was performed on a patient
us-core-7: Performed SHALL be present if the status is 'completed' or 'in-progress'
... id Σ 0..1 id Logical id of this artifact
... meta Σ 0..1 Meta Metadata about the resource
... implicitRules ?!Σ 0..1 uri A set of rules under which this content was created
... language 0..1 code Language of the resource content
Binding: CommonLanguages (preferred): A human language.

Additional BindingsPurpose
AllLanguages Max Binding
... text 0..1 Narrative Text summary of the resource, for human interpretation
... contained 0..* Resource Contained, inline Resources
... extension 0..* Extension Additional content defined by implementations
... modifierExtension ?! 0..* Extension Extensions that cannot be ignored
... identifier Σ 0..* Identifier External Identifiers for this procedure
... instantiatesCanonical Σ 0..* canonical(PlanDefinition | ActivityDefinition | Measure | OperationDefinition | Questionnaire) Instantiates FHIR protocol or definition
... instantiatesUri Σ 0..* uri Instantiates external protocol or definition
... basedOn Σ 0..* Reference(US Core CarePlan Profile | US Core ServiceRequest Profile) 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: A request for this procedure
... partOf Σ 0..* Reference(Procedure | Observation | MedicationAdministration) Part of referenced event
... status ?!SΣC 1..1 code preparation | in-progress | not-done | on-hold | stopped | completed | entered-in-error | unknown
Binding: EventStatus (required)
... statusReason Σ 0..1 CodeableConcept Reason for current status
Binding: ProcedureNotPerformedReason(SNOMED-CT) (example): A code that identifies the reason a procedure was not performed.

... category Σ 0..1 CodeableConcept Classification of the procedure
Binding: ProcedureCategoryCodes(SNOMEDCT) (example): A code that classifies a procedure for searching, sorting and display purposes.

... code SΣ 1..1 CodeableConcept Identification of the procedure
Binding: US Core Procedure Codes (preferred): Codes describing the type of Procedure

Additional BindingsPurpose
US Core Procedure Codes Current
... subject SΣ 1..1 Reference(US Core Patient Profile S | Group) Who the procedure was performed on
... encounter SΣ 0..1 Reference(US Core Encounter Profile) Encounter associated with the procedure
... performed[x] SΣC 0..1 When the procedure was performed
.... performedDateTime dateTime S
.... performedPeriod Period
.... performedString string
.... performedAge Age
.... performedRange Range
... recorder Σ 0..1 Reference(Patient | RelatedPerson | Practitioner | PractitionerRole) Who recorded the procedure
... asserter Σ 0..1 Reference(Patient | RelatedPerson | Practitioner | PractitionerRole) Person who asserts this procedure
... performer Σ 0..* BackboneElement The people who performed the procedure
.... id 0..1 string Unique id for inter-element referencing
.... extension 0..* Extension Additional content defined by implementations
.... modifierExtension ?!Σ 0..* Extension Extensions that cannot be ignored even if unrecognized
.... function Σ 0..1 CodeableConcept Type of performance
Binding: ProcedurePerformerRoleCodes (example): A code that identifies the role of a performer of the procedure.

.... actor Σ 1..1 Reference(Practitioner | PractitionerRole | Organization | Patient | RelatedPerson | Device) The reference to the practitioner
.... onBehalfOf 0..1 Reference(Organization) Organization the device or practitioner was acting for
... location Σ 0..1 Reference(Location) Where the procedure happened
... reasonCode Σ 0..* CodeableConcept 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: Coded reason procedure performed
Binding: US Core Condition Codes (extensible)
... reasonReference Σ 0..* Reference(Condition | Observation | Procedure | DiagnosticReport | DocumentReference) 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: US Core Profile justifying the reason procedure performed
... bodySite Σ 0..* CodeableConcept Target body sites
Binding: SNOMEDCTBodyStructures (example): Codes describing anatomical locations. May include laterality.


... outcome Σ 0..1 CodeableConcept The result of procedure
Binding: ProcedureOutcomeCodes(SNOMEDCT) (example): An outcome of a procedure - whether it was resolved or otherwise.

... report 0..* Reference(DiagnosticReport | DocumentReference | Composition) Any report resulting from the procedure
... complication 0..* CodeableConcept Complication following the procedure
Binding: Condition/Problem/DiagnosisCodes (example): Codes describing complications that resulted from a procedure.


... complicationDetail 0..* Reference(Condition) A condition that is a result of the procedure
... followUp 0..* CodeableConcept Instructions for follow up
Binding: ProcedureFollowUpCodes(SNOMEDCT) (example): Specific follow up required for a procedure e.g. removal of sutures.


... note 0..* Annotation Additional information about the procedure
... focalDevice 0..* BackboneElement Manipulated, implanted, or removed device
.... id 0..1 string Unique id for inter-element referencing
.... extension 0..* Extension Additional content defined by implementations
.... modifierExtension ?!Σ 0..* Extension Extensions that cannot be ignored even if unrecognized
.... action 0..1 CodeableConcept Kind of change to device
Binding: ProcedureDeviceActionCodes (preferred): A kind of change that happened to the device during the procedure.

.... manipulated 1..1 Reference(Device) Device that was changed
... usedReference 0..* Reference(Device | Medication | Substance) Items used during procedure
... usedCode 0..* CodeableConcept Coded items used during the procedure
Binding: FHIRDeviceTypes (example): Codes describing items used during a procedure.



doco Documentation for this format

Terminology Bindings

PathConformanceValueSetURI
Procedure.languagepreferredCommonLanguages
Additional Bindings Purpose
AllLanguages Max Binding
http://hl7.org/fhir/ValueSet/languages
from the FHIR Standard
Procedure.statusrequiredEventStatus
http://hl7.org/fhir/ValueSet/event-status
from the FHIR Standard
Procedure.statusReasonexampleProcedureNotPerformedReason(SNOMED-CT)
http://hl7.org/fhir/ValueSet/procedure-not-performed-reason
from the FHIR Standard
Procedure.categoryexampleProcedureCategoryCodes(SNOMEDCT)
http://hl7.org/fhir/ValueSet/procedure-category
from the FHIR Standard
Procedure.codepreferredUSCoreProcedureCodes
Additional Bindings Purpose Documentation
US Core Procedure Codes Current

US Core uses the current additional binding from FHIR R5 for this coded element for more flexibility when exchanging legacy and text-only data.

http://hl7.org/fhir/us/core/ValueSet/us-core-procedure-code
from this IG
Procedure.performer.functionexampleProcedurePerformerRoleCodes
http://hl7.org/fhir/ValueSet/performer-role
from the FHIR Standard
Procedure.reasonCodeextensibleUSCoreConditionCodes
http://hl7.org/fhir/us/core/ValueSet/us-core-condition-code
from this IG
Procedure.bodySiteexampleSNOMEDCTBodyStructures
http://hl7.org/fhir/ValueSet/body-site
from the FHIR Standard
Procedure.outcomeexampleProcedureOutcomeCodes(SNOMEDCT)
http://hl7.org/fhir/ValueSet/procedure-outcome
from the FHIR Standard
Procedure.complicationexampleCondition/Problem/DiagnosisCodes
http://hl7.org/fhir/ValueSet/condition-code
from the FHIR Standard
Procedure.followUpexampleProcedureFollowUpCodes(SNOMEDCT)
http://hl7.org/fhir/ValueSet/procedure-followup
from the FHIR Standard
Procedure.focalDevice.actionpreferredProcedureDeviceActionCodes
http://hl7.org/fhir/ValueSet/device-action
from the FHIR Standard
Procedure.usedCodeexampleFHIRDeviceTypes
http://hl7.org/fhir/ValueSet/device-kind
from the FHIR Standard

Constraints

IdGradePath(s)DetailsRequirements
us-core-7errorProcedurePerformed SHALL be present if the status is 'completed' or 'in-progress'
: (status='completed' or status='in-progress') implies performed.exists()

 

Other representations of profile: CSV, Excel, Schematron

Notes:


Quick Start


Below is an overview of the required Server RESTful FHIR interactions for this profile - for example, search and read operations - when supporting the US Core interactions to access this profile’s information (Profile Support + Interaction Support). Note that systems that support only US Core Profiles (Profile Only Support) are not required to support these interactions. See the US Core Server CapabilityStatement for a complete list of supported RESTful interactions for this IG.

  • See the Scopes Format section for a description of the SMART scopes syntax.
  • See the Search Syntax section for a description of the US Core search syntax.
  • See the General Requirements section for additional rules and expectations when a server requires status parameters.
  • See the General Guidance section for additional guidance on searching for multiple patients.

US Core Scopes

Servers providing access to procedure data SHALL support these US Core SMART Scopes:

Mandatory Search Parameters:

The following search parameters and search parameter combinations SHALL be supported:

  1. SHALL support searching for all procedures for a patient using the patient search parameter:

    GET [base]/Procedure?patient={Type/}[id]

    Example:

    1. GET [base]/Procedure?patient=1291938

    Implementation Notes: Fetches a bundle of all Procedure resources for the specified patient (how to search by reference)

  2. SHALL support searching using the combination of the patient and date search parameters:

    • including support for these date comparators: gt,lt,ge,le
    • including optional support for AND search on date (e.g.date=[date]&date=[date]]&...)

    GET [base]/Procedure?patient={Type/}[id]&date={gt|lt|ge|le}[date]{&date={gt|lt|ge|le}[date]&...}

    Example:

    1. GET [base]/Procedure?patient=1137192&date=ge2019-01-14

    Implementation Notes: Fetches a bundle of all Procedure resources for the specified patient and date (how to search by reference and how to search by token)

Optional Search Parameters:

The following search parameter combinations SHOULD be supported:

  1. SHOULD support searching using the combination of the patient and status search parameters:
    • including support for OR search on status (e.g.status={system|}[code],{system|}[code],...)

    GET [base]/Procedure?patient={Type/}[id]&status={system|}[code]{,{system|}[code],...}

    Example:

    1. GET [base]/Procedure?patient=1137192&status=completed

    Implementation Notes: Fetches a bundle of all Procedure resources for the specified patient and status (how to search by reference and how to search by token)

  2. SHOULD support searching using the combination of the patient and code and date search parameters:
    • including optional support for OR search on code (e.g.code={system|}[code],{system|}[code],...)
    • including support for these date comparators: gt,lt,ge,le
    • including optional support for AND search on date (e.g.date=[date]&date=[date]]&...)

    GET [base]/Procedure?patient={Type/}[id]&code={system|}[code]{,{system|}[code],...}&date={gt|lt|ge|le}[date]{&date={gt|lt|ge|le}[date]&...}

    Example:

    1. GET [base]/Procedure?patient=1137192&date=ge2019-01-14T00:00:00Z&code=http://snomed.info/sct|35637008

    Implementation Notes: Fetches a bundle of all Procedure resources for the specified patient and date and procedure code(s). SHOULD support search by multiple codes. (how to search by reference and how to search by token and how to search by date)