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".
• *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.

Changes since version 7.0.0:

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:

• resource level scopes: <patient|user|system>/Procedure.rs

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)