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

Table updates to person

Clair Blacketer 2019-02-06 16:03:22 -05:00
parent c1437bf9f7
commit b44af790b7
1 changed files with 4 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
StandardizedClinicalDataTables/PERSON.md

@ -28,13 +28,15 @@ 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>&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. | | 9 | The DEATH_DATETIME in the PERSON table should not be used as the way to find all deaths \
&nbsp;&bull;&nbsp;`select * from PERSON where death_datetime is not null` should not be the practice \
&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.|