Procedure

Stable ID

The id is derived from the patient, the date the procedure was performed, and the procedure code.

The encounter link described below is not part of the id, so the same procedure carries the same id in both bundles.

Because only date and code identify a procedure, two genuinely distinct occurrences of the same procedure on the same day are indistinguishable and collapse into a single Procedure resource.

Fields

Field	Cardinality	Notes
`meta.profile`	1..1	Always set to the US Core Procedure profile URL.
`status`	1..1	Always `completed`. Only performed procedures are published — planned, cancelled, and in-progress procedures do not appear.
`subject`	1..1	Reference to the Patient.
`code`	1..1	A single coding for the procedure performed.
`performedDateTime`	0..1	The date the procedure was performed.
`performer.actor`	0..1	Contained PractitionerRole built from the procedure’s provider and facility. Omitted when neither is known.
`encounter`	0..1	Patient Summary only. References the Encounter for the visit the procedure was performed at. Never set in the Patient Everything bundle.

category, bodySite, reasonCode, outcome, and note are not populated.

Bundle	Where procedures come from
Patient Everything	All procedures on the patient’s record, independent of any visit.
Patient Summary	Only procedures attached to a visit that was selected for the summary — including procedures on follow-up visits. Each is linked to its visit via `encounter`.

Bundle

Where procedures come from

Patient Everything

All procedures on the patient’s record, independent of any visit.

Patient Summary

Only procedures attached to a visit that was selected for the summary — including procedures on follow-up visits. Each is linked to its visit via encounter.

Welcome

Product

FHIR

Implementation

APIs

Stable ID

Fields

Procedure sourcing

​Stable ID

​Fields

​Procedure sourcing

Stable ID

Fields

Procedure sourcing