CDM +THEMIS Workgroup Meeting 21Jan2020

[clairblacketer]

Hi Everyone,

Tomorrow we have a CDM workgroup meeting at 9am eastern where we will be discussing the PROVIDER table. The Skype meeting link can be found on our homepage https://ohdsi.github.io/CommonDataModel/index.html and the straw-man description of the PROVIDER table is below. Please review and come ready to discuss.

Clair

cdmFieldName	userGuidance	etlConventions
provider_id	It is assumed that every provider with a different unique identifier is in fact a different person and should be treated independently.	Any person linkage that needs to occur to uniquely identify Providers ought to be done prior to writing this table. This identifier can be the original id from the source data provided it is an integer, otherwise it can be an autogenerated number.
provider_name
npi	This is the National Provider Number issued to health care providers in the US by the Centers for Medicare and Medicaid Services (CMS)
dea	This is the identifier issued by the DEA, a US federal agency, that allows a provider to write prescriptions for controlled substances.
specialty_concept_id	This field represents the most common specialty that occurs in the data, should the provider have more than one.	If a Provider has more than one Specialty, the main or most often exerted specialty should be recorded.
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 specialty should be recorded.
year_of_birth
gender_concept_id
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 value as it appears in the source.
specialty_source_value
specialty_source_concept_id	This is often zero as many sites use propietary codes to store physician speciality	If the source data codes provider specialty in an OMOP supported vocabulary store the concept_id here.
gender_source_value
gender_source_concept_id

[clairblacketer]

Thank you to everyone who joined today! Below is the agreed upon language for the PROVIDER table.

cdmFieldName	userGuidance	etlConventions	DQ checks/THEMIS Rules
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.	No duplicates, as in there cannot be duplicate records with the same provider_source_value.
provider_name
npi	This is the National Provider Number issued to health care providers in the US by the Centers for Medicare and Medicaid Services (CMS).
dea	This is the identifier issued by the DEA, a US federal agency, that allows a provider to write prescriptions for controlled substances.
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.	If a Provider has more than one Specialty, there are two options: 1. Choose a concept_id with an “Is a” relationship 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. If a provider’s specialty is not represented either as a singular concept or a concept with an “Is a” relationship to the multiple specialties, put a zero in this field and record the specialty in the specialty_source_value.	Check that records with a concept_id are in the provider domain, check that they are all standard concepts.
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.	Check that these values have a foreign key relationship with the CARE_SITE_ID in the CARE_SITE table.
year_of_birth
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.	Check that records with a concept_id are in the gender domain, check that they are all standard concepts.
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 value as it appears in the source.
specialty_source_value	This is the provider’s specialty as it appears in the source data.	Put the provider specialty 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.
specialty_source_concept_id	This is often zero as many sites use propietary codes to store physician speciality.	If the source data codes provider specialty in an OMOP supported vocabulary store the concept_id here.	Check that these values have a foreign key relationship with CONCEPT_ID field in the CONCEPT table.
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.
gender_source_concept_id	This is often zero as many sites use propietary codes to store provider gender.	If the source data codes provider gender in an OMOP supported vocabulary store the concept_id here.	Check that these values have a foreign key relationship with CONCEPT_ID field in the CONCEPT table.