The PROVIDER table contains a list of uniquely identified healthcare
providers. These are individuals providing hands-on healthcare to
patients, such as physicians, nurses, midwives, physical therapists
etc.
Many sources do not make a distinction between individual and
institutional providers. The PROVIDER table contains the individual
providers. If the source, instead of uniquely identifying individual
providers, only provides limited information such as specialty,
generic or ‘pooled’ Provider records are listed in the PROVIDER
table.
|
CDM Field
|
User Guide
|
ETL Conventions
|
Datatype
|
Required
|
Primary Key
|
Foreign Key
|
FK Table
|
FK Domain
|
|
provider_id
|
It is assumed that every provider with a different unique
identifier is in fact a different person and should be treated
independently.
|
This identifier can be the original id from the source data
provided it is an integer, otherwise it can be an autogenerated
number.
|
integer
|
Yes
|
Yes
|
No
|
|
|
|
provider_name
|
|
This field is not necessary as it is not necessary to have the
actual identity of the Provider. Rather, the idea is to uniquely
and anonymously identify providers of care across the database.
|
varchar(255)
|
No
|
No
|
No
|
|
|
|
npi
|
This is the National Provider Number issued to health care
providers in the US by the Centers for Medicare and Medicaid
Services (CMS).
|
|
varchar(20)
|
No
|
No
|
No
|
|
|
|
dea
|
This is the identifier issued by the DEA, a US federal agency,
that allows a provider to write prescriptions for controlled
substances.
|
|
varchar(20)
|
No
|
No
|
No
|
|
|
|
specialty_concept_id
|
This field either represents the most common specialty that
occurs in the data or the most specific concept that represents
all specialties listed, should the provider have more than one.
This includes physician specialties such as internal medicine,
emergency medicine, etc. and allied health professionals such as
nurses, midwives, and pharmacists.
|
If a Provider has more than one Specialty, there are two
options: 1. Choose a concept_id which is a common ancestor to
the multiple specialties, or, 2. Choose the specialty that
occurs most often for the provider. Concepts in this field
should be Standard with a domain of Provider. Accepted
Concepts.
|
integer
|
No
|
No
|
Yes
|
CONCEPT
|
|
|
care_site_id
|
This is the CARE_SITE_ID for the location that the provider
primarily practices in.
|
If a Provider has more than one Care Site, the main or most
often exerted CARE_SITE_ID should be recorded.
|
integer
|
No
|
No
|
Yes
|
CARE_SITE
|
|
|
year_of_birth
|
|
|
integer
|
No
|
No
|
No
|
|
|
|
gender_concept_id
|
This field represents the recorded gender of the provider in the
source data.
|
If given, put a concept from the gender domain representing the
recorded gender of the provider. Accepted
Concepts.
|
integer
|
No
|
No
|
Yes
|
CONCEPT
|
Gender
|
|
provider_source_value
|
Use this field to link back to providers in the source data.
This is typically used for error checking of ETL logic.
|
Some use cases require the ability to link back to providers in
the source data. This field allows for the storing of the
provider identifier as it appears in the source.
|
varchar(50)
|
No
|
No
|
No
|
|
|
|
specialty_source_value
|
This is the kind of provider or specialty as it appears in the
source data. This includes physician specialties such as
internal medicine, emergency medicine, etc. and allied health
professionals such as nurses, midwives, and pharmacists.
|
Put the kind of provider as it appears in the source data. This
field is up to the discretion of the ETL-er as to whether this
should be the coded value from the source or the text
description of the lookup value.
|
varchar(50)
|
No
|
No
|
No
|
|
|
|
specialty_source_concept_id
|
This is often zero as many sites use proprietary codes to store
physician speciality.
|
If the source data codes provider specialty in an OMOP supported
vocabulary store the concept_id here.
|
integer
|
No
|
No
|
Yes
|
CONCEPT
|
|
|
gender_source_value
|
This is provider’s gender as it appears in the source data.
|
Put the provider’s gender as it appears in the source data. This
field is up to the discretion of the ETL-er as to whether this
should be the coded value from the source or the text
description of the lookup value.
|
varchar(50)
|
No
|
No
|
No
|
|
|
|
gender_source_concept_id
|
This is often zero as many sites use proprietary codes to store
provider gender.
|
If the source data codes provider gender in an OMOP supported
vocabulary store the concept_id here.
|
integer
|
No
|
No
|
Yes
|
CONCEPT
|
|
link