mz-health/OMOP
mz-health
/
OMOP
mirror of https://github.com/OHDSI/CommonDataModel.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update OMOP_CDMv5.4_Field_Level.csv 

Updated Location table with Robert Miller's suggestions in forum post : https://forums.ohdsi.org/t/themis-topic-location-table-non-u-s-address-locations/3828/3
This commit is contained in:
Elizabeth Betts 2021-08-18 18:49:31 +01:00
parent 7bc145ca0c
commit df8226bcf9
1 changed files with 10 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
inst/csv/OMOP_CDMv5.4_Field_Level.csv
View File

@ -254,18 +254,16 @@ FACT_RELATIONSHIP,fact_id_1,Yes,integer,,,No,No,,,,,
FACT_RELATIONSHIP,domain_concept_id_2,Yes,integer,,,No,Yes,CONCEPT,CONCEPT_ID,,,
FACT_RELATIONSHIP,fact_id_2,Yes,integer,,,No,No,,,,,
FACT_RELATIONSHIP,relationship_concept_id,Yes,integer,,,No,Yes,CONCEPT,CONCEPT_ID,,,
LOCATION,location_id,Yes,integer,The unique key given to a unique Location.,Each instance of a Location in the source data should be assigned this unique key.,Yes,No,,,,,
LOCATION,address_1,No,varchar(50),This is the first line of the address.,,No,No,,,,,
LOCATION,address_2,No,varchar(50),This is the second line of the address,,No,No,,,,,
LOCATION,city,No,varchar(50),,,No,No,,,,,
LOCATION,state,No,varchar(2),,,No,No,,,,,
LOCATION,zip,No,varchar(9),,"Zip codes are handled as strings of up to 9 characters length. For US addresses, these represent either a 3-digit abbreviated Zip code as provided by many sources for patient protection reasons, the full 5-digit Zip or the 9-digit (ZIP + 4) codes. Unless for specific reasons analytical methods should expect and utilize only the first 3 digits. For international addresses, different rules apply.",No,No,,,,,
LOCATION,county,No,varchar(20),,,No,No,,,,,
LOCATION,location_source_value,No,varchar(50),,"Put the verbatim value for the location here, as it shows up in the source. ",No,No,,,,,
LOCATION,country_concept_id,No,integer,The Concept Id representing the country. Values should conform to the [Geography](https://athena.ohdsi.org/search-terms/terms?domain=Geography&standardConcept=Standard&page=1&pageSize=15&query=&boosts) domain. ,,,,,,,,
LOCATION,country_source_value,No,varchar(80),The name of the country.,,,,,,,,
LOCATION,latitude,No,float,,Must be between -90 and 90.,,,,,,,
LOCATION,longitude,No,float,,Must be between -180 and 180.,,,,,,,
LOCATION,location_id,Yes,integer,A unique identifier for each geographic location,Each instance of a Location in the source data should be assigned this unique key.,Yes,No,,,,,
LOCATION,address_1,No,varchar(50),"The address field 1, typically used for the street address, as it appears in the source data",,No,No,,,,,
LOCATION,address_2,No,varchar(50),"The address field 2, typically used for additional detail such as buildings, suites, floors, as it appears in the source data",,No,No,,,,,
LOCATION,city,No,varchar(50),The city field as it appears in the source data,,No,No,,,,,
LOCATION,district,No,varchar(50),The district field as it appears in the source data,,No,No,,,,,
LOCATION,postal_area,No,varchar(9),The zip or postal code,"Zip codes are handled as strings of up to 9 characters length. For US addresses, these represent either a 3-digit abbreviated Zip code as provided by many sources for patient protection reasons, the full 5-digit Zip or the 9-digit (ZIP + 4) codes. Unless for specific reasons analytical methods should expect and utilize only the first 3 digits. For international addresses, different rules apply.",No,No,,,,,
LOCATION,country,No,varchar(50),The country as it appears in the source data,,No,No,,,,,
LOCATION,latitude,No,numeric,,Must be between -90 and 90.,No,No,,,,,
LOCATION,longitude,No,numeric,,Must be between -180 and 180.,No,No,,,,,
LOCATION,location_source_value,No,varchar(50),The verbatim information that is used to uniquely identify the location as it appears in the source data,"Put the verbatim value for the location here, as it shows up in the source. ",No,No,,,,,
CARE_SITE,care_site_id,Yes,integer,,Assign an id to each unique combination of location_id and place_of_service_source_value,Yes,No,,,,,
CARE_SITE,care_site_name,No,varchar(255),The name of the care_site as it appears in the source data,,No,No,,,,,
CARE_SITE,place_of_service_concept_id,No,integer,"This is a high-level way of characterizing a Care Site. Typically, however, Care Sites can provide care in multiple settings (inpatient, outpatient, etc.) and this granularity should be reflected in the visit.","Choose the concept in the visit domain that best represents the setting in which healthcare is provided in the Care Site. If most visits in a Care Site are Inpatient, then the place_of_service_concept_id should represent Inpatient. If information is present about a unique Care Site (e.g. Pharmacy) then a Care Site record should be created. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=2&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,,,

1 cdmTableName cdmFieldName isRequired cdmDatatype userGuidance etlConventions isPrimaryKey isForeignKey fkTableName fkFieldName fkDomain fkClass unique DQ identifiers
254 PROVIDER provider_source_value specialty_source_concept_id No varchar(50) integer Use this field to link back to providers in the source data. This is typically used for error checking of ETL logic. This is often zero as many sites use proprietary codes to store physician speciality. 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. If the source data codes provider specialty in an OMOP supported vocabulary store the concept_id here. No No Yes CONCEPT CONCEPT_ID
255 PROVIDER specialty_source_value gender_source_value No varchar(50) 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. This is provider's gender as it appears in the source data. 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. 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. No No
256 PROVIDER specialty_source_concept_id gender_source_concept_id No integer This is often zero as many sites use proprietary codes to store physician speciality. This is often zero as many sites use proprietary codes to store provider gender. If the source data codes provider specialty in an OMOP supported vocabulary store the concept_id here. If the source data codes provider gender in an OMOP supported vocabulary store the concept_id here. No Yes CONCEPT CONCEPT_ID
257 PROVIDER PAYER_PLAN_PERIOD gender_source_value payer_plan_period_id No Yes varchar(50) integer This is provider's gender as it appears in the source data. A unique identifier for each unique combination of a Person, Payer, Plan, and Period of time. 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. No Yes No Yes PERSON PERSON_ID
258 PROVIDER PAYER_PLAN_PERIOD gender_source_concept_id person_id No Yes integer This is often zero as many sites use proprietary codes to store provider gender. The Person covered by the Plan. If the source data codes provider gender in an OMOP supported vocabulary store the concept_id here. A single Person can have multiple, overlapping, PAYER_PLAN_PERIOD records No Yes CONCEPT PERSON CONCEPT_ID PERSON_ID
259 PAYER_PLAN_PERIOD payer_plan_period_id payer_plan_period_start_date Yes integer date A unique identifier for each unique combination of a Person, Payer, Plan, and Period of time. Start date of Plan coverage. Yes No Yes No PERSON PERSON_ID
260 PAYER_PLAN_PERIOD person_id payer_plan_period_end_date Yes integer date The Person covered by the Plan. End date of Plan coverage. A single Person can have multiple, overlapping, PAYER_PLAN_PERIOD records No Yes No PERSON PERSON_ID
261 PAYER_PLAN_PERIOD payer_plan_period_start_date payer_concept_id Yes No date integer Start date of Plan coverage. This field represents the organization who reimburses the provider which administers care to the Person. Map the Payer directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same payer, though the name of the Payer is not necessary. [Accepted Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Payer&standardConcept=Standard&page=1&pageSize=15&query=). No No Yes CONCEPT CONCEPT_ID
262 PAYER_PLAN_PERIOD payer_plan_period_end_date payer_source_value Yes No date varchar(50) End date of Plan coverage. This is the Payer as it appears in the source data. No No
263 PAYER_PLAN_PERIOD payer_concept_id payer_source_concept_id No integer This field represents the organization who reimburses the provider which administers care to the Person. Map the Payer directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same payer, though the name of the Payer is not necessary. [Accepted Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Payer&standardConcept=Standard&page=1&pageSize=15&query=). If the source data codes the Payer in an OMOP supported vocabulary store the concept_id here. No Yes CONCEPT CONCEPT_ID
264 PAYER_PLAN_PERIOD payer_source_value plan_concept_id No varchar(50) integer This is the Payer as it appears in the source data. This field represents the specific health benefit Plan the Person is enrolled in. Map the Plan directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same health benefit Plan though the name of the Plan is not necessary. [Accepted Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Plan&standardConcept=Standard&page=1&pageSize=15&query=). No No Yes CONCEPT CONCEPT_ID
265 PAYER_PLAN_PERIOD payer_source_concept_id plan_source_value No integer varchar(50) This is the health benefit Plan of the Person as it appears in the source data. If the source data codes the Payer in an OMOP supported vocabulary store the concept_id here. No Yes No CONCEPT CONCEPT_ID
266 PAYER_PLAN_PERIOD plan_concept_id plan_source_concept_id No integer This field represents the specific health benefit Plan the Person is enrolled in. Map the Plan directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same health benefit Plan though the name of the Plan is not necessary. [Accepted Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Plan&standardConcept=Standard&page=1&pageSize=15&query=). If the source data codes the Plan in an OMOP supported vocabulary store the concept_id here. No Yes CONCEPT CONCEPT_ID
PAYER_PLAN_PERIOD plan_source_value No varchar(50) This is the health benefit Plan of the Person as it appears in the source data. No No
PAYER_PLAN_PERIOD plan_source_concept_id No integer If the source data codes the Plan in an OMOP supported vocabulary store the concept_id here. No Yes CONCEPT CONCEPT_ID
267 PAYER_PLAN_PERIOD sponsor_concept_id No integer This field represents the sponsor of the Plan who finances the Plan. This includes self-insured, small group health plan and large group health plan. Map the sponsor directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same sponsor though the name of the sponsor is not necessary. [Accepted Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Sponsor&standardConcept=Standard&page=1&pageSize=15&query=). No Yes CONCEPT CONCEPT_ID
268 PAYER_PLAN_PERIOD sponsor_source_value No varchar(50) The Plan sponsor as it appears in the source data. No No
269 PAYER_PLAN_PERIOD sponsor_source_concept_id No integer If the source data codes the sponsor in an OMOP supported vocabulary store the concept_id here. No Yes CONCEPT CONCEPT_ID