Procedure
Introduction
Scope and Usage
Procedure is one of the event resources in the FHIR workflow specification.
This resource is used to record the details of current and historical procedures performed on, with, or for a patient, practitioner, device, organization, or location. Examples include surgical procedures, diagnostic procedures, endoscopic procedures, biopsies, counseling, physiotherapy, personal support services, adult day care services, non-emergency transportation, home modification, exercise, verification of enrollment qualifications for a social program etc. Procedures may be performed by a healthcare professional, a service provider, a friend or relative or in some cases by the patient themselves.
Procedures can be performed on other non-patient subjects. For example, a procedure can represent an inspection to verify temperature or humidity for storage at a given location. Additionally, a procedure can represent the verification of the practitioner's qualifications for accreditation.
This resource provides summary information about the occurrence of the procedure and is not intended to provide real-time snapshots of a procedure as it unfolds, though for long-running procedures such as psychotherapy, it could represent summary level information about overall progress. The creation of a resource to support detailed real-time procedure information awaits the identification of a specific implementation use-case to share such information.
Boundaries and Relationships
The Procedure resource should not be used to capture an event if a more specific resource already exists - e.g. immunizations, drug administrations, communications, and nutrition intake. The boundary between determining whether an action is a Procedure (training or counseling) as opposed to a Communication is based on whether there's a specific intent to change the mind-set of the patient. Mere disclosure of information would be considered a Communication. A process that involves verification of the patient's comprehension or to change the patient's mental state would be a Procedure.
Note that many diagnostic processes are procedures that generate Observations and DiagnosticReports. In many cases, such an observation does not require an explicit representation of the procedure used to create the observation, but where there are details of interest about how the diagnostic procedure was performed, the Procedure resource is used to describe the activity.
Some diagnostic procedures might not have a Procedure record. The Procedure record is only necessary when there is a need to capture information about the physical intervention that was performed to capture the diagnostic information (e.g. anesthetic, incision, scope size, etc.)
A Task is a workflow step such as canceling an order, fulfilling an order, signing an order, merging a set of records, admitting a patient. Procedures are actions that are intended to result in a physical or mental change to or for the subject (e.g. surgery, physiotherapy, training, counseling). A Task resource often exists in parallel with clinical resources. For example, a Task might request fulfillment of a ServiceRequest ordering a Procedure.
Notes
Use of Procedure properties
Many of the elements of Procedure have inherent relationships and may be conveyed by the Procedure.code or in the text element of the Procedure.code property. I.e. you may be able to infer category, bodySite and even indication. Whether these other properties will be populated may vary by implementation.
Care should be taken to avoid nonsensical combinations/statements; e.g. "name=amputation, bodySite=heart".
Sometimes a complex procedure may consist of several subordinate procedures. In these cases, the list of procedures may be unwieldy for those attempting to view a procedure list. Two properties support ways of filtering and selecting procedures: the partOf property, which associates subordinate procedures to their containing procedures, and could be used to filter out those with partOf values in a higher-level list, and the category, which could be use to flag procedures that are, e.g., billable.
There are other activities that may be captured by an EHR that might not be of value to other providers (e.g. shaving, anesthesia, time admitted to recovery, etc.). The boundary between these classes may vary and is up to the judgment of the implementer. An option for capturing information of potential value that doesn't merit the name "procedure" is to use the note property.
Use of Procedure.used
For devices, these are devices that are incidental to / or used to perform the procedure - scalpels, gauze, endoscopes, etc. Devices that are the focus of the procedure should appear in Procedure.device instead.
StructureDefinition
Elements (Simplified)
- Procedure [0..*]: - An action that is being or was performed on an individual or entity
- Procedure.identifier [0..*]: Identifier External Identifiers for this procedure
- Procedure.basedOn [0..*]: [Reference(CarePlan](/Reference(CarePlan), ServiceRequest, MedicationRequest)) A request for this procedure
- Procedure.partOf [0..*]: [Reference(Procedure](/Reference(Procedure), Observation, MedicationAdministration)) Part of referenced event
- Procedure.status [1..1]: code required:event-status preparation | in-progress | not-done | on-hold | stopped | completed | entered-in-error | unknown
- Procedure.statusReason [0..1]: CodeableConcept example:procedure-not-performed-reason Reason for current status
- Procedure.category [0..*]: CodeableConcept example:procedure-category Classification of the procedure
- Procedure.code [0..1]: CodeableConcept example:procedure-code Identification of the procedure
- Procedure.subject [1..1]: [Reference(Patient](/Reference(Patient), Group, Device, Practitioner, Organization, Location)) Individual or entity the procedure was performed on
- Procedure.focus [0..1]: [Reference(Patient](/Reference(Patient), Group, RelatedPerson, Practitioner, Organization, CareTeam, PractitionerRole, Specimen)) Who is the target of the procedure when it is not the subject of record only
- Procedure.encounter [0..1]: Reference(Encounter) The Encounter during which this Procedure was created
- Procedure.occurrence[x] [0..1]: dateTime, Period, string, Age, Range, Timing When the procedure occurred or is occurring
- Procedure.recorded [0..1]: dateTime When the procedure was first captured in the subject's record
- Procedure.recorder [0..1]: [Reference(Patient](/Reference(Patient), RelatedPerson, Practitioner, PractitionerRole)) Who recorded the procedure
- Procedure.reported[x] [0..1]: boolean, [Reference(Patient](/Reference(Patient), RelatedPerson, Practitioner, PractitionerRole, Organization)) Reported rather than primary record
- Procedure.performer [0..*]: BackboneElement Who performed the procedure and what they did
- Procedure.performer.function [0..1]: CodeableConcept example:participant-role Type of performance
- Procedure.performer.actor [1..1]: [Reference(Practitioner](/Reference(Practitioner), PractitionerRole, Organization, Patient, RelatedPerson, Device, CareTeam, HealthcareService)) Who performed the procedure
- Procedure.performer.onBehalfOf [0..1]: Reference(Organization) Organization the device or practitioner was acting for
- Procedure.performer.period [0..1]: Period When the performer performed the procedure
- Procedure.location [0..1]: Reference(Location) Where the procedure happened
- Procedure.reason [0..*]: CodeableReference example:procedure-reason The justification that the procedure was performed
- Procedure.bodySite [0..*]: CodeableConcept example:body-site Target body sites
- Procedure.bodyStructure [0..1]: Reference(BodyStructure) Target body structure
- Procedure.outcome [0..*]: CodeableReference example:procedure-outcome The result of procedure
- Procedure.report [0..*]: [Reference(DiagnosticReport](/Reference(DiagnosticReport), DocumentReference, Composition, Bundle)) Any report resulting from the procedure
- Procedure.complication [0..*]: CodeableReference example:condition-code Complication following the procedure
- Procedure.followUp [0..*]: CodeableReference example:procedure-followup Instructions for follow up
- Procedure.note [0..*]: Annotation Additional information about the procedure
- Procedure.focalDevice [0..*]: BackboneElement Manipulated, implanted, or removed device
- Procedure.focalDevice.action [0..1]: CodeableConcept preferred:device-action Kind of change to device
- Procedure.focalDevice.manipulated [1..1]: Reference(Device) Device that was changed
- Procedure.used [0..*]: CodeableReference example:device-type Items used during procedure
- Procedure.supportingInfo [0..*]: Reference(Resource) Extra information relevant to the procedure
Mappings
- Procedure Mappings — 77 mapping entries
Implementation Guide
implementationguide-Procedure-core.xml
<?xml version="1.0" encoding="UTF-8"?>
<ImplementationGuide xmlns="http://hl7.org/fhir">
<id value="Procedure-core"/>
<version value="0.1"/>
<name value="ProcedureHL7Extensions"/>
<title value="Procedure H L7 Extensions"/>
<status value="draft"/>
<date value="2015-02-12T00:00:00.000"/>
<publisher value="Health Level Seven, Inc. - FHIR WG"/>
<description value="Defines common extensions used with or related to the Procedure resource"/>
</ImplementationGuide>
Resource Packs
list-Procedure-packs.xml
<?xml version="1.0" encoding="UTF-8"?>
<List xmlns="http://hl7.org/fhir">
<id value="Procedure-packs"/>
<status value="current"/>
<mode value="working"/>
<entry>
<item>
<reference value="ImplementationGuide/Procedure-core"/>
</item>
</entry>
</List>
Search Parameters
- based-on — reference — A request for this procedure —
Procedure.basedOn - category — token — Classification of the procedure —
Procedure.category - code — token — A code to identify a procedure —
Procedure.code - date — date — When the procedure occurred or is occurring —
Procedure.occurrence.ofType(dateTime) | Procedure.occurrence.ofType(Period) | Procedure.occurrence.ofType(Timing) - encounter — reference — The Encounter during which this Procedure was created —
Procedure.encounter - identifier — token — A unique identifier for a procedure —
Procedure.identifier - location — reference — Where the procedure happened —
Procedure.location - part-of — reference — Part of referenced event —
Procedure.partOf - patient — reference — Search by subject - a patient —
Procedure.subject.where(resolve() is Patient) - performer — reference — Who performed the procedure —
Procedure.performer.actor - reason-code — token — Reference to a concept (by class) —
Procedure.reason.concept - reason-reference — reference — Reference to a resource (by instance) —
Procedure.reason.reference - report — reference — Any report resulting from the procedure —
Procedure.report - status — token — preparation | in-progress | not-done | on-hold | stopped | completed | entered-in-error | unknown —
Procedure.status - subject — reference — Search by subject —
Procedure.subject
Examples
- ambulation — procedure-example-ambulation — Example of ambulation procedure
- appendectomy-narrative — procedure-example-appendectomy-narrative — Example of an appendectomy procedure that is primarily narrative
- biopsy — procedure-example-biopsy — Example of a Biopsy
- colon-biopsy — procedure-example-colon-biopsy — Example of biopsy procedure that was part of a colonoscopy
- colonoscopy — procedure-example-colonoscopy — Example of colonoscopy procedure with complication
- education — procedure-example-education — Example of patient education
- example — procedure-example — General Procedure Example
- example-implant — procedure-example-implant — Example of a device manipulation
- f001 — procedure-example-f001-heart — Real-world procedure example
- f002 — procedure-example-f002-lung — Real-world procedure example
- f003 — procedure-example-f003-abscess — Real-world procedure example
- f004 — procedure-example-f004-tracheotomy — Real-world procedure example
- f201 — procedure-example-f201-tpf — Real-world procedure example
- HCBS — procedure-example-HCBS — Example of personal care services provided at person's home
- ob — procedure-example-ob — Example of an obstetric procedure
- physical-therapy — procedure-example-physical-therapy — Example of a physical therapy evaluation procedure
- physicaltherapy-neck — procedure-example-physicaltherapy-neck — Example of a physical therapy neck manipulation procedure
- procedure-example — procedure-example
- procedure-example-ambulation — procedure-example-ambulation
- procedure-example-appendectomy-narrative — procedure-example-appendectomy-narrative
- procedure-example-biopsy — procedure-example-biopsy
- procedure-example-colon-biopsy — procedure-example-colon-biopsy
- procedure-example-colonoscopy — procedure-example-colonoscopy
- procedure-example-education — procedure-example-education
- procedure-example-F001 — procedure-example-F001
- procedure-example-f001-heart — procedure-example-f001-heart
- procedure-example-F002 — procedure-example-F002
- procedure-example-f002-lung — procedure-example-f002-lung
- procedure-example-F003 — procedure-example-F003
- procedure-example-f003-abscess — procedure-example-f003-abscess
- procedure-example-F004 — procedure-example-F004
- procedure-example-f004-tracheotomy — procedure-example-f004-tracheotomy
- procedure-example-f201-tpf — procedure-example-f201-tpf
- procedure-example-HCBS — procedure-example-HCBS
- procedure-example-implant — procedure-example-implant
- procedure-example-ob — procedure-example-ob
- procedure-example-physical-therapy — procedure-example-physical-therapy
- procedure-example-physicaltherapy-neck — procedure-example-physicaltherapy-neck
- procedure-examples-header — procedure-examples-header
Mapping Exceptions
procedure-event-mapping-exceptions.xml
Divergent Elements
- Event.identifier → Procedure.identifier
- shortUnmatched | reason=Unknown | pattern=Business identifier for procedure | resource=External Identifiers for this procedure
- definitionUnmatched | reason=Unknown | pattern=Business identifiers assigned to this procedure by the performer and/or other systems. These identifiers remain constant as the resource is updated and propagates from server to server. | resource=Business identifiers assigned to this procedure by the performer or other systems which remain constant as the resource is updated and is propagated from server to server.
- commentsUnmatched | reason=Unknown | pattern=Note: This is a business identifier, not a resource identifier (see discussion). It is best practice for the identifier to only appear on a single resource instance, however business practices may occasionally dictate that multiple resource instances with the same identifier can exist - possibly even with different resource types. For example, multiple Patient and a Person resource instance might share the same social insurance number. | resource=This is a business identifier, not a resource identifier (see discussion). It is best practice for the identifier to only appear on a single resource instance, however business practices may occasionally dictate that multiple resource instances with the same identifier can exist - possibly even with different resource types. For example, multiple Patient and Person resource instances might share the same social insurance number.
- Event.basedOn → Procedure.basedOn
- missingTypes | reason=Unknown | pattern=Reference(Request)
- extraTypes | reason=Unknown
- shortUnmatched | reason=Unknown | pattern=Fulfills plan, proposal or order | resource=A request for this procedure
- definitionUnmatched | reason=Unknown | pattern=A plan, proposal or order that is fulfilled in whole or in part by this procedure. | resource=A reference to a resource that contains details of the request for this procedure.
- requirementsUnmatched | reason=Unknown | pattern=Allows tracing of authorization for the procedure and tracking whether proposals/recommendations were acted upon.
- Event.partOf → Procedure.partOf
- missingTypes | reason=Unknown | pattern=Reference(Event)
- extraTypes | reason=Unknown
- commentsUnmatched | reason=Unknown | pattern=Not to be used to link an procedure to an Encounter - use 'context' for that. | resource=The MedicationAdministration resource has a partOf reference to Procedure, but this is not a circular reference. For example, the anesthesia MedicationAdministration is part of the surgical Procedure (MedicationAdministration.partOf = Procedure). For example, the procedure to insert the IV port for an IV medication administration is part of the medication administration (Procedure.partOf = MedicationAdministration).
- Event.status → Procedure.status
- shortUnmatched | reason=Unknown | pattern=preparation | in-progress | not-done | suspended | aborted | completed | entered-in-error | unknown | resource=preparation | in-progress | not-done | on-hold | stopped | completed | entered-in-error | unknown
- definitionUnmatched | reason=Unknown | pattern=The current state of the procedure. | resource=A code specifying the state of the procedure. Generally, this will be the in-progress or completed state.
- commentsUnmatched | reason=Unknown | pattern=A nominal state-transition diagram can be found in the (Event pattern documentation
Unknown does not represent "other" - one of the defined statuses must apply. Unknown is used when the authoring system is not sure what the current status is. | resource=The "unknown" code is not to be used to convey other statuses. The "unknown" code should be used when one of the statuses applies, but the authoring system doesn't know the current state of the procedure.
This element is labeled as a modifier because the status contains codes that mark the resource as not currently valid.
- Event.statusReason → Procedure.statusReason
- summary | reason=Unknown | pattern=false
- commentsUnmatched | reason=Unknown | pattern=This is generally only used for "exception" statuses such as "not-done", "suspended" or "cancelled". The reason for performing the event at all is captured in reasonCode, not here. . | resource=This is generally only used for "exception" statuses such as "not-done", "suspended" or "aborted". The reason for performing the event at all is captured in reasonCode, not here.
- Event.code → Procedure.code
- shortUnmatched | reason=Unknown | pattern=What service was done | resource=Identification of the procedure
- definitionUnmatched | reason=Unknown | pattern=A code that identifies the specific service or action that was or is being performed. | resource=The specific procedure that is performed. Use text if the exact nature of the procedure cannot be coded (e.g. "Laparoscopic Appendectomy").
- Event.subject → Procedure.subject
- extraTypes | reason=Unknown
- shortUnmatched | reason=Unknown | pattern=Individual service was done for/to | resource=Individual or entity the procedure was performed on
- definitionUnmatched | reason=Unknown | pattern=The individual or set of individuals the action is being or was performed on. | resource=On whom or on what the procedure was performed. This is usually an individual human, but can also be performed on animals, groups of humans or animals, organizations or practitioners (for licensing), locations or devices (for safety inspections or regulatory authorizations). If the actual focus of the procedure is different from the subject, the focus element specifies the actual focus of the procedure.
- requirementsUnmatched | reason=Unknown | pattern=Links the procedure to the Patient context. May also affect access control.
- Event.encounter → Procedure.encounter
- shortUnmatched | reason=Unknown | pattern=Encounter the procedure is part of | resource=The Encounter during which this Procedure was created
- definitionUnmatched | reason=Unknown | pattern=The Encounter during which this procedure was created or to which the creation of this record is tightly associated. | resource=The Encounter during which this Procedure was created or performed or to which the creation of this record is tightly associated.
- commentsUnmatched | reason=Unknown | pattern=This will typically be the encounter the procedure was created during, but some procedures may be initiated prior to or after the official completion of an encounter but still be tied to the context of the encounter (e.g. pre-admission lab tests). | resource=This will typically be the encounter the event occurred within, but some activities may be initiated prior to or after the official completion of an encounter but still be tied to the context of the encounter.
- requirementsUnmatched | reason=Unknown | pattern=Links the procedure to the Encounter context. May also affect access control.
- Event.occurrence[x] → Procedure.occurrence[x]
- extraTypes | reason=Unknown
- shortUnmatched | reason=Unknown | pattern=When procedure occurred/is occurring | resource=When the procedure occurred or is occurring
- definitionUnmatched | reason=Unknown | pattern=The date, period or timing when the procedure did occur or is occurring. | resource=Estimated or actual date, date-time, period, or age when the procedure did occur or is occurring. Allows a period to support complex procedures that span more than one date, and also allows for the length of the procedure to be captured.
- commentsUnmatched | reason=Unknown | pattern=This indicates when the activity actually occurred or is occurring, not when it was asked/requested/ordered to occur. For the latter, look at the occurence element of the Request this {{event}} is "basedOn". The status code allows differentiation of whether the timing reflects a historic event or an ongoing event. Ongoing events should not include an upper bound in the Period or Timing.bounds. . | resource=This indicates when the procedure actually occurred or is occurring, not when it was asked/requested/ordered to occur. For the latter, look at the occurence element of the Request this Procedure is "basedOn". The status code allows differentiation of whether the timing reflects a historic event or an ongoing event. Ongoing events should not include an upper bound in the Period or Timing.bounds.
Age is generally used when the patient reports an age at which the procedure was performed. Range is generally used when the patient reports an age range when the procedure was performed, such as sometime between 20-25 years old. dateTime supports a range of precision due to some procedures being reported as past procedures that might not have millisecond precision while other procedures performed and documented during the encounter might have more precise UTC timestamps with timezone.
- Event.recorded → Procedure.recorded
- shortUnmatched | reason=Unknown | pattern=When procedure was first captured in the subject's record | resource=When the procedure was first captured in the subject's record
- definitionUnmatched | reason=Unknown | pattern=The date the occurrence of the procedure was first captured in the record - potentially significantly after the occurrence of the event. | resource=The date the occurrence of the procedure was first captured in the record regardless of Procedure.status (potentially after the occurrence of the event).
- commentsUnmatched | reason=Unknown | pattern=The recorded date indicates the date when the data was placed in the record maintained by the performing practitioner, or the date of disclosure by Patient or RelatedPerson, not a date of record transfer. If the record is transferred from one system to another (in paper or electronic form), it does not create a distinct recorded date. In most cases, performing practitioners will record on the same date the event occurred, but sometimes there are delays. If information is being relayed second-hand, the recorded date indicates when the system is first made aware of the data.
The recorded date is NOT intended to be the same as a database.createdTimestamp - that would be captured as part of resource.meta or possibly Provenance.
It is possible for the same event to be disclosed to different systems at different times. E.g. a patient might tell two different clinicians about a historical event at different visits. If the disclosure is from the patient rather than record transfer from clinician A to B, the recorded date would be the date each respective clinician put the data in their record. If the data flowed from clinician A to B, the recorded date would remain the recorded date as initially set in clinician A's system.
- Event.performer → Procedure.performer
- extraTypes | reason=Unknown
- shortUnmatched | reason=Unknown | pattern=Who performed procedure and what they did | resource=Who performed the procedure and what they did
- Event.performer.function → Procedure.performer.function
- definitionUnmatched | reason=Unknown | pattern=Distinguishes the type of involvement of the performer in the procedure.. | resource=Distinguishes the type of involvement of the performer in the procedure. For example, surgeon, anaesthetist, endoscopist.
- Event.performer.actor → Procedure.performer.actor
- extraTypes | reason=Unknown
- shortUnmatched | reason=Unknown | pattern=Who performed procedure | resource=Who performed the procedure
- Event.reason → Procedure.reason
- shortUnmatched | reason=Unknown | pattern=Why was procedure performed? | resource=The justification that the procedure was performed
- definitionUnmatched | reason=Unknown | pattern=Describes why the procedure occurred in coded or textual form or Indicates another resource whose existence justifies this procedure. | resource=The coded reason or reference why the procedure was performed. This may be a coded entity of some type, be present as text, or be a reference to one of several resources that justify the procedure.
- commentsUnmatched | reason=Unknown | pattern=Textual reasons can be captured using reasonCode.text. | resource=Use Procedure.reason.concept when a code sufficiently describes the reason. Use Procedure.reason.reference when referencing a resource, which allows more information to be conveyed, such as onset date. For a single Procedure.reason, if both Procedure.reason.concept and Procedure.reason.reference are present, they are expected to be consistent with each other.
- Event.note → Procedure.note
- shortUnmatched | reason=Unknown | pattern=Comments made about the event | resource=Additional information about the procedure
- definitionUnmatched | reason=Unknown | pattern=Comments made about the procedure by the performer, subject or other participants. | resource=Any other notes and comments about the procedure.
Unmapped Elements
- Event.relevantHistory — Unknown
- Event.location — Unknown
- Event.category — Unknown
- Event.product — Unknown
procedure-fivews-mapping-exceptions.xml
Divergent Elements
- FiveWs.subject → Procedure.focus
Unmapped Elements
- FiveWs.cause — Unknown
- FiveWs.version — Unknown
- FiveWs.witness — Unknown
- FiveWs.init — Unknown
- FiveWs.who — Unknown
- FiveWs.grade — Unknown
- FiveWs.planned — Unknown