US Core Implementation Guide
8.0.0-ballot - Ballot 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 8.0.0-ballot 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: 8.0.0-ballot
Standards status: Trial-use Maturity Level: 3 Computable Name: USCoreProcedureProfile
Other Identifiers: OID:2.16.840.1.113883.4.642.40.2.42.52

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. who was involved in the procedure
  2. a reason or indication for referral or consultation*

*see guidance below

Profile Specific Implementation Guidance:

  • *The Procedure.performed is mandatory if Procedure.status is 'completed' or 'in-progress'.</span>
  • *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:

Changes since version 7.0.0:

  • The data elements list has changed
  • 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 Required
    ... 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
    ... performer 0..* BackboneElement 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: The people who performed the procedure
    .... actor 1..1 Reference(US Core Practitioner Profile | US Core PractitionerRole Profile | US Core Organization Profile | US Core Patient Profile | US Core RelatedPerson Profile | Device) 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: The reference to the practitioner
    ... 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
    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 Required
    ... 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
    ... performer Σ 0..* BackboneElement 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: The people who performed the procedure
    .... modifierExtension ?!Σ 0..* Extension Extensions that cannot be ignored even if unrecognized
    .... actor Σ 1..1 Reference(US Core Practitioner Profile) 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: The reference to the practitioner
    ... 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
    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 Required
    ... 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(US Core Practitioner Profile | US Core PractitionerRole Profile | US Core Organization Profile | US Core Patient Profile | US Core RelatedPerson Profile | 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
    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 Required
    ... 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
    ... performer 0..* BackboneElement 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: The people who performed the procedure
    .... actor 1..1 Reference(US Core Practitioner Profile | US Core PractitionerRole Profile | US Core Organization Profile | US Core Patient Profile | US Core RelatedPerson Profile | Device) 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: The reference to the practitioner
    ... 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
    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 Required
    ... 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
    ... performer Σ 0..* BackboneElement 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: The people who performed the procedure
    .... modifierExtension ?!Σ 0..* Extension Extensions that cannot be ignored even if unrecognized
    .... actor Σ 1..1 Reference(US Core Practitioner Profile) 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜: The reference to the practitioner
    ... 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
    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 Required
    ... 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(US Core Practitioner Profile | US Core PractitionerRole Profile | US Core Organization Profile | US Core Patient Profile | US Core RelatedPerson Profile | 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
    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)