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

Person table wiki updates

Clair Blacketer 2019-02-06 14:52:19 -05:00
parent 299155a5a2
commit c060194edb
1 changed files with 14 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
StandardizedClinicalDataTables/PERSON.md

@ -25,19 +25,19 @@ Field|Required|Type|Description
### Conventions ### Conventions
No.|Convention Description No.|Convention Description
:--------|:------------------------------------ :--------|:----------------------------------------------------------------------------------------------
| 1 | All tables representing patient-related Domains have a foreign-key reference to the person_id field in the PERSON table.| | 1 | All tables representing patient-related Domains have a foreign-key reference to the person_id field in the PERSON table.|
| 2 | Each person record has associated demographic attributes which are assumed to be constant for the patient throughout the course of their periods of observation. For example, the location or gender is expected to have a unique value per person, even though in life these data may change over time. | 2 | Each person record has associated demographic attributes which are assumed to be constant for the patient throughout the course of their periods of observation. For example, the location or gender is expected to have a unique value per person, even though in life these data may change over time. |
| 3 | The GENDER_CONCEPT_ID should store what is believed to be the biological or sex assigned at birth. If the data set does have gender identification information, this should be stored in the OBSERVATION table (using the gender concepts 8532-Female or 8507-Male in OBSERVATION_CONCEPT_ID)[THEMIS issue #32](https://github.com/OHDSI/Themis/issues/32).| | 3 | The GENDER_CONCEPT_ID should store what is believed to be the biological or sex assigned at birth. If the data set does have gender identification information, this should be stored in the OBSERVATION table (using the gender concepts 8532-Female or 8507-Male in OBSERVATION_CONCEPT_ID [THEMIS issue #32](https://github.com/OHDSI/Themis/issues/32)).|
| 4 | If we do not know the month or day of birth, we do not guess. A person can exist without a month or day of birth. If a person lacks a birth year that person should be dropped ([THEMIS issue #30](https://github.com/OHDSI/Themis/issues/30)).| | 4 | If we do not know the month or day of birth, we do not guess. A person can exist without a month or day of birth. If a person lacks a birth year that person should be dropped ([THEMIS issue #30](https://github.com/OHDSI/Themis/issues/30)).|
| 5 | Living patients should not have a value in PERSON.DEATH_DATETIME, nor should they have any records relating to death either in the CONDITION_OCCURRENCE or OBSERVATION tables | 5 | Living patients should not have a value in PERSON.DEATH_DATETIME, nor should they have any records relating to death either in the CONDITION_OCCURRENCE or OBSERVATION tables.|
| 6 | Only one death date per individual can be used. If a patient has clinical activity (e.g. prescriptions filled, labs performed, etc) more than 60+ days after death you may want to drop the death record as it may have been falsely reported. If multiple records of death exist on multiple days you may select the death that you deem most reliable (e.g. death at discharge) or select the latest death date. | 6 | Only one death date per individual can be used. If a patient has clinical activity (e.g. prescriptions filled, labs performed, etc) more than 60+ days after death you may want to drop the death record as it may have been falsely reported. If multiple records of death exist on multiple days you may select the death that you deem most reliable (e.g. death at discharge) or select the latest death date.|
| 7 | If multiple death records occur, the date and the person have to be the same, but the cause can be different. Can be reported by different sources as well. | 7 | If multiple death records occur, the date and the person have to be the same, but the cause can be different. Can be reported by different sources as well.|
| 8 | If PERSON.DEATH_DATETIME cannot be precisely determined from the data, the best approximation should be used. | 8 | If PERSON.DEATH_DATETIME cannot be precisely determined from the data, the best approximation should be used.|
| 9 | The DEATH_DATETIME in the PERSON table should not be used as the way to find all deaths<br><ul><li>`select * from PERSON where death_datetime is not null` should not be the practice</li><li>Rather, deaths should be found through the OBSERVATION table and the PERSON table is only used to determine which death date should be used in analysis </li></ul> | 9 | The DEATH_DATETIME in the PERSON table should not be used as the way to find all deaths <br>&nbsp;&bull;&nbsp;`select * from PERSON where death_datetime is not null` should not be the practice<br>&nbsp;&bull;&nbsp;Rather, deaths should be found through the OBSERVATION table and the PERSON table is only used to determine which death date should be used in analysis. |
| 10 | Valid Gender, Race and Ethnicity Concepts each belong to their own Domain. | 10 | Valid Gender, Race and Ethnicity Concepts each belong to their own Domain.|
| 11 | Ethnicity in the OMOP CDM follows the OMB Standards for Data on Race and Ethnicity: Only distinctions between Hispanics and Non-Hispanics are made. | 11 | Ethnicity in the OMOP CDM follows the OMB Standards for Data on Race and Ethnicity: Only distinctions between Hispanics and Non-Hispanics are made. |
| 12 | Additional information is stored through references to other tables, such as the home address (location_id) or the primary care provider. | 12 | Additional information is stored through references to other tables, such as the home address (location_id) or the primary care provider.|
| 13 | The Provider refers to the primary care provider (General Practitioner). When the primary provider is unknown for a person then leave the PROVIDER_ID blank ([THEMIS issue #36](https://github.com/OHDSI/Themis/issues/36)). | 13 | The Provider refers to the primary care provider (General Practitioner). When the primary provider is unknown for a person then leave the PROVIDER_ID blank ([THEMIS issue #36](https://github.com/OHDSI/Themis/issues/36)).|
| 14 | The Care Site refers to where the Provider typically provides the primary care. When care site for the primary provider is unknown then leave the CARE_SITE_ID blank. | 14 | The Care Site refers to where the Provider typically provides the primary care. When care site for the primary provider is unknown then leave the CARE_SITE_ID blank.|
| 15 | It is not required that all subjects from the raw data be carried over to the CDM, in fact removing people that are not of high enough quality may help researchers using the CDM. Example scenarios to remove subjects include: a person’s year of birth or age are unreasonable (e.g. born in year 0, 1800, 2999 or just lacking a year of birth), person lacks health benefits in claims database (i.e. thus you do not have a complete picture of their record), or raw data states that the person may not be of high research quality (e.g. CPRD will actually suggest which people not to use within research). Removal of a patient is not required and should be made in consideration of the raw data source. Reasons for removal of persons should be documented in the ETL documentation and METADATA table (insert row in METADATA where metadata.name='count of removed persons' and metada.value_as_string='xyz' where xyz is a number (e.g., 12). <br> An ETL should not delete persons who contribute time however have no health care utilization (e.g. an individual enrolled in insurance but does not visit a doctor or pharmacy). This individual will contribute to analysis however as a healthy / non-care seeking individual ([THEMIS issue #9](https://github.com/OHDSI/Themis/issues/9)).| | 15 | It is not required that all subjects from the raw data be carried over to the CDM, in fact removing people that are not of high enough quality may help researchers using the CDM. Example scenarios to remove subjects include: a person’s year of birth or age are unreasonable (e.g. born in year 0, 1800, 2999 or just lacking a year of birth), person lacks health benefits in claims database (i.e. thus you do not have a complete picture of their record), or raw data states that the person may not be of high research quality (e.g. CPRD will actually suggest which people not to use within research). Removal of a patient is not required and should be made in consideration of the raw data source. Reasons for removal of persons should be documented in the ETL documentation and METADATA table (insert row in METADATA where metadata.name='count of removed persons' and metada.value_as_string='xyz' where xyz is a number (e.g., 12). <br> An ETL should not delete persons who contribute time however have no health care utilization (e.g. an individual enrolled in insurance but does not visit a doctor or pharmacy). This individual will contribute to analysis however as a healthy / non-care seeking individual ([THEMIS issue #9](https://github.com/OHDSI/Themis/issues/9)).|