PROCEDURE_OCCURRENCE

Table Description

This table contains records of activities or processes ordered by, or carried out by, a healthcare provider on the patient with a diagnostic or therapeutic purpose.

User Guide

Lab tests are not a procedure, if something is observed with an expected resulting amount and unit then it should be a measurement. Phlebotomy is a procedure but so trivial that it tends to be rarely captured. It can be assumed that there is a phlebotomy procedure associated with many lab tests, therefore it is unnecessary to add them as separate procedures. If the user finds the same procedure over concurrent days, it is assumed those records are part of a procedure lasting more than a day. This logic is in lieu of the procedure_end_date, which will be added in a future version of the CDM.

ETL Conventions

When dealing with duplicate records, the ETL must determine whether to sum them up into one record or keep them separate. Things to consider are: - Same Procedure - Same PROCEDURE_DATETIME - Same Visit Occurrence or Visit Detail - Same Provider - Same Modifier for Procedures. Source codes and source text fields mapped to Standard Concepts of the Procedure Domain have to be recorded here.

CDM Field	User Guide	ETL Conventions	Datatype	Required	Primary Key	Foreign Key	FK Table	FK Domain
procedure_occurrence_id	The unique key given to a procedure record for a person. Refer to the ETL for how duplicate procedures during the same visit were handled.	Each instance of a procedure occurrence in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same procedure within the same visit. It is valid to keep these duplicates and assign them individual, unique, PROCEDURE_OCCURRENCE_IDs, though it is up to the ETL how they should be handled.	integer	Yes	Yes	No
person_id	The PERSON_ID of the PERSON for whom the procedure is recorded. This may be a system generated code.		integer	Yes	No	Yes	PERSON
procedure_concept_id	The PROCEDURE_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source value which represents a procedure	The CONCEPT_ID that the PROCEDURE_SOURCE_VALUE maps to. Only records whose source values map to standard concepts with a domain of “Procedure” should go in this table. Accepted Concepts.	integer	Yes	No	Yes	CONCEPT	Procedure
procedure_date	Use this date to determine the date the procedure started.	This is meant to be the start date of the procedure. It will be renamed in a future version to PROCEDURE_START_DATE.	date	Yes	No	No
procedure_datetime		If the procedure has a start time in the native date, use this field to house that information. This will be renamed in a future version to PROCEDURE_START_DATETIME.	datetime	No	No	No
procedure_end_date	Use this field to house the date that the procedure ended.	This is meant to be the end date of the procedure. It is not required and for most cases will be the same as the PROCEDURE_START_DATE.	date	No	No	No
procedure_end_datetime	Use this field to house the datetime that the procedure ended.	This is meant to house the end datetime of the procedure and will most often be used in conjunction with the procedure_start_datetime to determine the length of the procedure.	datetime	No	No	No
procedure_type_concept_id	This field can be used to determine the provenance of the Procedure record, as in whether the procedure was from an EHR system, insurance claim, registry, or other sources.	Choose the PROCEDURE_TYPE_CONCEPT_ID that best represents the provenance of the record, for example whether it came from an EHR record or billing claim. If a procedure is recorded as an EHR encounter, the PROCEDURE_TYPE_CONCEPT would be ‘EHR encounter record’. Accepted Concepts. A more detailed explanation of each Type Concept can be found on the vocabulary wiki.	integer	Yes	No	Yes	CONCEPT	Type Concept
modifier_concept_id	The modifiers are intended to give additional information about the procedure but as of now the vocabulary is under review.	It is up to the ETL to choose how to map modifiers if they exist in source data. These concepts are typically distinguished by ‘Modifier’ concept classes (e.g., ‘CPT4 Modifier’ as part of the ‘CPT4’ vocabulary). If there is more than one modifier on a record, one should be chosen that pertains to the procedure rather than provider. Accepted Concepts.	integer	No	No	Yes	CONCEPT
quantity	If the quantity value is omitted, a single procedure is assumed.	If a Procedure has a quantity of ‘0’ in the source, this should default to ‘1’ in the ETL. If there is a record in the source it can be assumed the exposure occurred at least once	integer	No	No	No
provider_id	The provider associated with the procedure record, e.g. the provider who performed the Procedure.	The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record, for example the admitting vs attending physician on an EHR record.	integer	No	No	Yes	PROVIDER
visit_occurrence_id	The visit during which the procedure occurred.	Depending on the structure of the source data, this may have to be determined based on dates. If a PROCEDURE_DATE occurs within the start and end date of a Visit it is a valid ETL choice to choose the VISIT_OCCURRENCE_ID from the Visit that subsumes it, even if not explicitly stated in the data. While not required, an attempt should be made to locate the VISIT_OCCURRENCE_ID of the PROCEDURE_OCCURRENCE record.	integer	No	No	Yes	VISIT_OCCURRENCE
visit_detail_id	The VISIT_DETAIL record during which the Procedure occurred. For example, if the Person was in the ICU at the time of the Procedure the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit.	Same rules apply as for the VISIT_OCCURRENCE_ID.	integer	No	No	Yes	VISIT_DETAIL
procedure_source_value	This field houses the verbatim value from the source data representing the procedure that occurred. For example, this could be an CPT4 or OPCS4 code.	Use this value to look up the source concept id and then map the source concept id to a standard concept id.	varchar(50)	No	No	No
procedure_source_concept_id	This is the concept representing the procedure source value and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Procedure necessary for a given analytic use case. Consider using PROCEDURE_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.	If the PROCEDURE_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.	integer	No	No	Yes	CONCEPT
modifier_source_value		The original modifier code from the source is stored here for reference.	varchar(50)	No	No	No