Repository for OMOP CDM conventions as defined by THEMIS. These can be reference lists of concepts, pieces of standardized code for data generation or quality certification, and debates.
License: Apache License 2.0
| Type | Notes |
|---|---|
| ITEM | The medical event (condition, procedure, ...) type should be determined independent of the target domain. For example, if a procedure code in the facility header record is mapped to an observation, the event type should be concept id 42865905, Facility Header, where the domain is 'Type Concept' and the vocabulary id is 'Procedure Type', even though the event will reside in Observation. |
| FORUM POST | http://forums.ohdsi.org/t/how-to-determine-event-type-concept-when-vocabulary-maps-to-a-different-domain/5955/15 |
| SOLUTION | Themis convention that the event type is determined by the source of the data without regard to the target domain of the source code and that any concept in the 'Type Concept' domain is a valid event type concept regardless of the table the event resides in. |
| NEXT STEPS | Create a forum post for discussion. |
| TYPE | NOTES |
|---|---|
| ITEM | This idea came up in regards to loss of people, who to include, who not to include. |
| FORUM POST | http://forums.ohdsi.org/t/eliminating-persons-themis-wg3-topic-2/3974 |
| SOLUTION | RECOMMENDATION 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). RULE 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. |
| NEXT STEPS | Work with @clairblacketer to have posted on the PERSON page under the CDM Wiki under convensions. https://github.com/OHDSI/CommonDataModel/wiki/PERSON1 |
| TYPE | NOTES |
|---|---|
| ITEM | PERSON Conversion Number 15 states that it is okay to drop persons when they are not of high quality. How does one track the number of person that were dropped between the raw data and the CDM? |
| FORUM POST | http://forums.ohdsi.org/t/metadata-and-annotations-wg/4242/32 (not specific to this topic - general thread) |
| SOLUTION | We should track this information of person loss in the METADATA table and check that this was done via ACHILLES HEEL. |
| NEXT STEPS | Add convention to METADATA: It is encouraged that when a CDM ETL deletes persons from the data for one reason or another that that information be tracked in the METADATA table. For example, if an ETL deletes persons when they are missing data, then the METADATA table should capture the count of persons deleted for this specific rule. If no persons are deleted between the raw and CDM this should also be captured in the METADATA table.Add ACHILLES HEEL rule that checks patient loss is documented in the METADATA table. Asking @alondhe if this is a best way to document this. |
| TYPE | NOTES |
|---|---|
| ITEM | Do we want to or not want to standardize what goes into various source_value fields. Every table has one and currently is free to use in any way the ETLer wants. There is standardization under the SOURCE_CONCEPT_ID field. However, it only works if people (i) use it, (ii) if the source code is covered by a Standardized Vocabulary, or (iii) if people make their own concepts (the so-called 2-Billionaires). |
| FORUM POST | http://forums.ohdsi.org/t/themis-question-what-do-people-put-in-the-source-value-fields/4092/15 |
| SOLUTION | Verbatim information from the source data, typically used in ETL to map to CONCEPT_ID, and not to be used by any standard analytics. There is no standardization for these fields and these columns can be used as the local CDM builders see fit. A typical example would be an ICD-9 code without the decimal from an administrative claim as condition_source_value = '78702' which is how it appeared in the source. |
| NEXT STEPS | Work with CDM WG to update the "Data Model Conventions" part of the wiki in the SOURCEVALUE description cell and change it to the below statement. https://github.com/OHDSI/CommonDataModel/wiki/Data-Model-Conventions |
| TYPE | NOTES |
|---|---|
| ITEM | Observation – Family History of |
| FORUM POST | http://forums.ohdsi.org/t/how-to-represent-family-history/3386 |
| SOLUTION | We want to recommend that all family history get the OBSERVATION_CONCEPT_ID = 4210989 - Family history with explicit context and then if there is an associated condition it should get put into the VALUE_AS_CONCEPT_ID. For example, if I get this ICD9 V17.5-Family history of asthma, the Vocab would map it to 4210989 but there would also be a separate non-standard relationship to asthma. Any time I have a code mapped to 4210989 then I will do a separate query to get to its associated condition. |
| NEXT STEPS | Add as a convention under the OBSERVATION page. There is no connection from the disease to the "family history of". Check that all relationships exist. If they do not, then talk to SNOMED. Next step is to add SNOMED extension |
| TYPE | NOTES |
|---|---|
| ITEM | What should someone do if duplicate drugs are reported on the same day? |
| FORUM POST | http://forums.ohdsi.org/t/duplicate-drugs-themis-wg3/4101 |
| SOLUTION | If a patient has multiple records on the same day for the same drug or procedures the ETL should not dedupe them unless there is probable reason to believe the item is a true data duplicate. |
| NEXT STEPS | Work with @clairblacketer and CDM WG to have this added to the DRUG_EXPOSURE part of the WIKI under convensions. https://github.com/OHDSI/CommonDataModel/wiki/DRUG_EXPOSURE |
| TYPE | NOTES |
|---|---|
| ITEM | Where should we store DRG codes? |
| FORUM POST | http://forums.ohdsi.org/t/most-appropriate-omop-table-to-house-drg-information/1591/8 |
| SOLUTION | DRGs should be stored in the COST table using the DRG_CONCEPT_ID and DRUG_SOURCE_VALUE columns. |
| NEXT STEPS | Vocabulary team Add the APR-DRG into Concept and change domain_id to 'Cost'. Add the above note to the CDM Wiki FAQ. |
| TYPE | NOTES |
|---|---|
| ITEM | One of the items that came out of the OHDSI Symposium Themis F2F was what to do with DATETIME columns when the raw data has no time. What do you do for start times when all you have is day data? What do you do for end times when all you have is day data? |
| FORUM POST | http://forums.ohdsi.org/t/default-time-themis-wg3/4337 |
| SOLUTION | Choose default time of 00:00:00 if time is unknown. If you do have time and receive a time of 00:00:00 just shift 1 second to 00:00:01 |
| NEXT STEPS | Work with @clairblacketer to have posted on the Data Model Conventions page under the CDM Wiki under convensions. https://github.com/OHDSI/CommonDataModel/wiki/Data-Model-Conventions |
| TYPE | NOTES |
|---|---|
| ITEM | How do we handle providers with multiple specialties? |
| FORUM POST | http://forums.ohdsi.org/t/new-comprehensive-hierarchy-for-providers-visits-and-place-of-service-specialty-care-site/5633 |
| SOLUTION | Currently there is a convention: A single Provider cannot be listed twice (be duplicated) in the table. If a Provider has more than one Specialty, the main or most often exerted specialty should be recorded. |
| NEXT STEPS | Understand from @cgreich how this should be working given what is now in the Vocabulary. Supposedly there is a hierarchy now. |
| TYPE | NOTES |
|---|---|
| ITEM | How do we handle events after death? |
| FORUM POST | TBD |
| SOLUTION | Currently there is a convention very similar to this: Death Convention 2. "...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. .." However this doesn't specifically address what you do with records that come after a believable death. |
| NEXT STEPS |
|
| TYPE | NOTES |
|---|---|
| ITEM | What should happen to the quantity when the record is moved over to the OMOP CDM if the quantity from the source is either not provided or set to 0? |
| FORUM POST | - |
| SOLUTION | Default quantities of ‘0’ to ‘1’, if there is a record in the source then we can assume that this happened at least once. |
| NEXT STEPS | Update the CDM Wiki on DEVICE_EXPOSURE.quantity column Description. Post issue to ACHILLES GitHub requesting this rule be added |
| TYPE | NOTES |
|---|---|
| ITEM | Example: Doctor comes to hospital. Bill shows his office address but place of service is hospital. Billing address different from actual site where patient was. Owner: Ron Stewart Proposal: Handled in visit-detail 5.3 table. OHDSI/CommonDataModel#153 Clair: Location history table can handle multiple addresses for same location ID. Provider in multiple care sites are assigned different provider IDs. ADDRESSED. Cs 03 AND 04: Require deeper nuanced discussion on how to handle, but not a priority now. Bring up in a discussion when Ron is present. Tom: Well discussed, make a priority. Follow up with Ron |
| FORUM POST | http://forums.ohdsi.org/t/multiple-addresses-per-provider-provider-address-differs-from-care-site/5653 |
| SOLUTION | The CDM allows us to capture location of visits, so knowing where a patient was treated is quantified in the CDM. If a provider has multiple addresses the ETL should just choose one as it is unknown what the analytical use case for storing multiple addresses per provider. The question of how to handle a situation where the billing address differs from where the patient received care is already handled in the CDM. The VISIT_OCCURRENCE table has a separate PROVIDER_ID and CARE_SITE_ID for expressly this purpose. This is already handled with Convention 8 on the VISIT_OCCURRENCE page (https://github.com/OHDSI/CommonDataModel/wiki/VISIT_OCCURRENCE). |
| NEXT STEPS | Update Convention #3 under PROVIDER. A single Provider cannot be listed twice (be duplicated) in the table. In situations where a provider has multiple addresses the ETL should choose the best one. If a Provider has more than one Specialty, the main or most often exerted specialty should be recorded. Update Conventions #8 under VISIT_OCCURRENCE: One visit may involve multiple care sites, in which case the ETL must specify how a single CARE_SITE_ID is selected or leave the CARE_SITE_ID field null. When the address of the provider and site of care differ you can use the CARE_SITE_ID to capture location of care and PROVIDER_ID to capture provider office. |
| Type | Notes |
|---|---|
| Item | Trial Enrollment information in OBSERVATION table |
| Forum Post | http://forums.ohdsi.org/t/omop-cdm-and-clinical-trials/2109 |
SOLUTION
To represent clinical study/trial data in CDM use the following specifications (OBSERVATION table).
NEXT STEPS: implement conventions outlined above
| Type | Notes |
|---|---|
| Item | Glean month if birth absent e.g. from Observation Period starting same year |
| Forum Post | http://forums.ohdsi.org/t/eliminating-persons-themis-wg3-topic-2/3974 |
| Solution | 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 we will drop that person. |
| Next Steps | To add this as a convention under the PERSON wiki page. |
| TYPE | NOTES |
|---|---|
| ITEM | Do we allow different payer plan periods to overlap? |
| FORUM POST | http://forums.ohdsi.org/t/overlapping-payer-plan-periods/4528 |
| SOLUTION | Payer plan periods are allowed to overlap with other payer plan periods for a patient. |
| NEXT STEPS | Update PAYER_PLAN_PERIOD wiki conventions |
Today OMOP's death table contains information about a person's death_date and a cause of death. Discussion in http://forums.ohdsi.org/t/condition-occurrence-death-diagnoses/2609/52 figures that there may be a need for storing several causes of death per person. This means a need to have multiple records. It's clear that just storing multiple records in the death table using its current structure is not the best idea: that would bring redundancy and possible ambigiosy, because of multiple death dates per a person. That's why it is reasonable to move the death date, since it's a one time thing per person, in the person table, and leave the death table for just storing the causes of death. But if we go forward, we can see that resulting death table basically stores all info presented in a condition_occurrence table, and what is more, logically, cause of death is a condition. That's why second step of the proposal is to replace the death table by storing causes of death in condition_occurrence table.
| TYPE | NOTES |
|---|---|
| ITEM | What do you do when an NPI represents a set of physicians? |
| FORUM POST | TBD |
| SOLUTION | |
| NEXT STEPS | Add a convention to PROVIDER: It is okay to bring across an NPI that represents a set of physicians into the PROVIDER table. This should not create multiple rows for each physician in the group, rather one row representing the group. The physicians have their own NPI number which can also be stored. |
| TYPE | NOTES |
|---|---|
| ITEM | Currently there is a PROVIDER convention 2: "Many sources do not make a distinction between individual and institutional providers. The PROVIDER table contains the individual providers." But this needs to be clearer defined for institutions (especially since GENDER is required). |
| FORUM POST | http://forums.ohdsi.org/t/non-individuals-in-the-provider-table-themis/5720 |
| SOLUTION | Update conventions on the provider table. |
| NEXT STEPS | Update the Convention 2 PROVIDER Many sources do not make a distinction between individual medical groups and institutional providers. The PROVIDER table contains the individual providers.Add the following convention In cases where a provider has unknown gender or may be a individual medical group set GENDER_CONCEPT_ID = 0. |
| TYPE | NOTES |
|---|---|
| ITEM | How should we handle duplicate records Devices and Procedures? |
| FORUM POST | http://forums.ohdsi.org/t/themis-focus-group-1-decisons-updates/3821/2?u=ericavoss |
| SOLUTION | When these fields are the same, the ETL must determine whether to sum them up into 1 record or keep them as multiple separate records. Things to consider are: - Same Device/Procedure - Same Modifier for Procedures - Same Day - Same Visit/Visit Detail - Same Provider - Same Time - Same Cost ID |
| NEXT STEPS | Updated the PROCEDURE_OCCURRENCE portion of the WIKI under conventions. |
| TYPE | NOTES |
|---|---|
| ITEM | What should be done with negative integers for MEASUREMENTS? |
| FORUM POST | http://forums.ohdsi.org/t/negative-values-in-lab-test-records/4012 |
| SOLUTION | Only allow values for negative measurements (see list below). If you have negative values for positive measurements, then set it to NULL. Negative Measurements 1925-7-Base excess in Arterial blood by calculation 1927-3-Base excess in Venous blood by calculation 8632-2 - QRS-Axis 11555-0 - Base excess in Blood by calculation 1926-5 - Base excess in Capillary blood by calculation 28638-5 - Base excess in Arterial cord blood by calculation 28639-3 - Base excess in Venous cord blood by calculation |
| NEXT STEPS | 1. Work to develop an exception list (e.g. 1925-7-Base excess in Arterial blood by calculation, RANGE: mmol.L:[-2,+2], https://s.details.loinc.org/LOINC/1925-7.html), 2. Update ACHILLES (@vojtechhuser) to do a warning on non-exempt tests that are negative. 3. Work with CDM WG to document both the exception list and above text in the VALUE_AS_NUMBER column. https://github.com/OHDSI/CommonDataModel/wiki/MEASUREMENT |
| TYPE | NOTES |
|---|---|
| ITEM | Provider specialty not well captured in the Vocabulary. |
| FORUM POST | http://forums.ohdsi.org/t/provider-specialty-code-set-clean-up/3888 http://forums.ohdsi.org/t/care-sites-and-specialty-specialty-code-clean-up/4538/4 http://forums.ohdsi.org/t/new-comprehensive-hierarchy-for-providers-visits-and-place-of-service-specialty-care-site/5633 |
| SOLUTION | Incorporate NUCC, ABMS, HES Specialty, and Specialty-CMS. The order of preference should be OMOP->Specialty->Place of Service->NUCC->ABMS->HES Specialty->UB04 |
| NEXT STEPS | Ultimately the Vocabulary team will work on. Double check this has been implemented in the Vocabulary. Maybe we need to remove duplicates. |
| TYPE | NOTES |
|---|---|
| ITEM | How to handle geographical or year-based multiplier tables? |
| FORUM POST | http://forums.ohdsi.org/t/geographical-year-based-multiplier/4571 |
| SOLUTION | Currently, the CDM does not handle this information. |
| NEXT STEPS | A proposal has to be submitted to the CDM Working Group for storing this information. |
| TYPE | NOTES |
|---|---|
| ITEM | How should local source codes be managed? Should I assign my own CONCEPT_IDs? How have others handled this? |
| FORUM POST | http://forums.ohdsi.org/t/themis-question-what-do-people-put-in-the-source-value-fields/4092/ |
| SOLUTION | There are three approaches to handle source codes that are not in the OMOP Vocabulary (in order of complexity): 1. Leveraging the SOURCE_TO_CONCEPT_MAP: In the OMOP Vocabulary there is an empty table called the SOURCE_TO_CONCEPT_MAP. It is a simple table structure that allows you to establish mapping(s) for each source code with a standard concept in the OMOP Vocabulary (TARGET_CONCEPT_ID). This work can be facilitated by the OHDSI tool USAGI which does text similarity between your source code descriptions and the OMOP Vocabulary and exports mappings in a SOURCE_TO_CONCEPT_MAP table structure. Example SOURCE_TO_CONCEPT_MAP files can be found here. These generated SOURCE_TO_CONCEPT_MAP files are then loaded into the OMOP Vocabulary's empty SOURCE_TO_CONCEPT_MAP prior to processing the native data into the CDM so that the CDM builder can use them in a build. 2. Adding CONCEPT.CONCEPT_IDs: When an source code is not supported by the OMOP Vocabulary, one can create a new records in the CONCEPT table, however the CONCEPT_IDs should start >2000000000 so that it is easy to tell between the OMOP Vocabulary concepts and the site specific concepts. Once those concepts exist CONCEPT_RELATIONSHIPS can be generated to assign them to a standard terminologies, USAGI can facilitate this process as well. 3. Work with ODYSSEUS Data Services to add to OMOP Vocabulary: The OMOP Vocabulary is an evolving thing and new vocabularies can be added, however working with the ODYSSEUS team is the best way to manage performing this task. |
| NEXT STEPS | Add this description with the CDM WG to the FAQ section. |
Even though not really established as a standard across all computer languages used in OHDSI, we do tend to use camel case for the repo names. So could we change THEMIS into Themis?
| TYPE | NOTES |
|---|---|
| ITEM | The OBSERVATION_PERIOD table contains records which uniquely define the spans of time for which a Person is at-risk to have clinical events recorded within the source systems, even if no events, in fact, are recorded (healthy patient with no healthcare interactions). |
| FORUM POST | (OLD THREAD) http://forums.ohdsi.org/t/observation-period-flavors-first-themis-focus-group-2-now-discussed-everywhere/3850/18 (CURRENT THREAD) http://forums.ohdsi.org/t/data-outside-of-observation-period/4557 |
| SOLUTION | 1. Events CAN fall out of observation period. 2. Payer plan period should be used to capture coverage (including partial e.g. Medicare part D) and can overlap with the observation period. 3. Every patient must have at least one observation period. |
| RECOMMENDATIONS | 1. not use time outside of an observation period for identifying people. 2. to ensure quality do not use events outside of an observation period for an analysis. 3. if patients do not meet criteria for observation period (e.g. have partial Medicare D coverage), create an alternative CDM that allows for them to fall in OBSERVABLE_TIME. |
| NEXT STEPS | Update CDM Wiki for OBSERVATION_PERIOD to discussion in the conventions. |
| Type | Notes |
|---|---|
| Item | Masking of person’s age based on privacy regulations |
| Forum Post | |
| Solution | Depends on the business, may need to mask these ages, if over 110-115 y.o --> drop Apply business rule. Save rules in metadata table. Always meet HIPAA standards. |
| Next Steps | Accepted by the THEMIS F2F meeting. |
| TYPE | NOTES |
|---|---|
| ITEM | |
| FORUM POST | http://forums.ohdsi.org/t/visit-vs-place-of-service/4006 br> http://forums.ohdsi.org/t/new-comprehensive-hierarchy-for-providers-visits-and-place-of-service-specialty-care-site/5633 |
| SOLUTION | |
| NEXT STEPS | Christian to discuss at next THEMIS call |
| TYPE | NOTES |
|---|---|
| ITEM | How should we handle multiple deaths on different days? |
| FORUM POST | http://forums.ohdsi.org/t/multiple-deaths-on-different-days/4552 |
| SOLUTION | 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. |
| NEXT STEPS | Update the CDM Wiki on DEATH conventions. |
| Type | Notes |
|---|---|
| Item | Primary provider unknown for a person. |
| Forum Post | http://forums.ohdsi.org/t/unknown-persons-primary-provider/4549 |
| Solution | When the primary provider is unknown for a person then leave the PROVIDER_ID blank. |
| Next Steps | In the CDM Wiki, under the PERSON page, under conventions add this text. |
| TYPE | NOTES |
|---|---|
| ITEM | Should you keep DRUG_EXPOSURES with negative days supply? |
| FORUM POST | http://forums.ohdsi.org/t/drug-exposure-end-date-for-negative-days-supply/3845/ |
| SOLUTION | When the native data suggests a drug exposure has a days supply less than 0, drop the record as unknown if a person has received the drug or not. |
| NEXT STEPS | Add this statement under the DRUG_EXPOSURES.CONVENSIONS section of the WIKI https://github.com/OHDSI/CommonDataModel/wiki/DRUG_EXPOSURE#conventions |
| TYPE | NOTES |
|---|---|
| ITEM | How should we handle quantities of ‘0’ in Devices and Procedures? |
| FORUM POST | http://forums.ohdsi.org/t/quantities-of-0-for-devices-and-procedures/4614 |
| SOLUTION | Default quantities of ‘0’ to ‘1’. If there is a record in the source then we can assume this occurred at least once. |
| NEXT STEPS | Update the PROCEDURE_OCCURRENCE and DEVICE WIKI pages under conventions. |
I don't think we mention anywhere on the WIKI that there is only supposed to be one PERSON record per person.
| Type | Notes |
|---|---|
| Item | Gender Identification vs. Biological Sex |
| Forum Post | http://forums.ohdsi.org/t/should-transgenders-be-excluded-from-the-cdm/2750 |
| Solution | The PERSON.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). |
| Next Steps | Add this under conversions under PERSON wiki. |
see SOLUTION in a related issue here: #4
| TYPE | NOTES |
|---|---|
| ITEM | Standardization of Measurements and Units |
| FORUM POST | http://forums.ohdsi.org/t/themis-subgroup-measurement-procedure/3675 |
| SOLUTION | see below |
| NEXT STEPS | modify convention for MEASUREMENT |
SOLUTION: modify current conventions slightly.
| TYPE | NOTES |
|---|---|
| ITEM | How should we handle multiple deaths on the same day? |
| FORUM POST | http://forums.ohdsi.org/t/multiple-cause-of-death/4551 |
| SOLUTION | 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. |
| NEXT STEPS | Update the CDM Wiki on DEATH.cause_concept_id column description. |
I have previously proposed to record a change in location on an observation table, but the proposal is not progressing.
This page discusses the update of the location table, but discusses the column of the location table rather than the discussion of the record of the location change.
I think that if the history of location is recorded in the observation table, it can generate more good evidence.
What do you think about recording the history of location changes in the Observation table?
| Type | Notes |
|---|---|
| Item | Person without no transaction records besides observation_period/payer plan period. Keep if no other record in other data (Typically claims data) |
| Forum Post | http://forums.ohdsi.org/t/eliminating-persons-themis-wg3-topic-2/3974 |
| Solution | Keep Person Record. (useful for claims data: enrollees vs. active patients) |
| Next Steps | Accepted by the THEMIS F2F meeting. |
| TYPE | NOTES |
|---|---|
| ITEM | How do we handle multiple genders? |
| FORUM POST | http://forums.ohdsi.org/t/should-transgenders-be-excluded-from-the-cdm/2750/13 |
| SOLUTION | If there are multiple genders for an individual and you cannot determine if it was because of a sex change, then take the use the latest value |
| NEXT STEPS | Update the CDM Wiki on PERSON.gender_concept_id column Description. |
| TYPE | NOTES |
|---|---|
| ITEM | How and where do we capture granular and generic payer info? |
| FORUM POST | 1. http://forums.ohdsi.org/t/how-to-represent-visit-payer-information-in-the-model/369/7 2. http://forums.ohdsi.org/t/provider-table-standardize-the-way-providers-are-identified/4324/3 3. OHDSI/CommonDataModel#120 |
| SOLUTION | Store payer information (e.g. Medicare, Private etc.) in payer_plan_period.payer_concept_id and store plan information (e.g. PPO, HMO etc.) in payer_plan_period.plan_concept_id. |
| NEXT STEPS | Finalize guidelines, create a vocabulary for the concepts including hierarchy (http://forums.ohdsi.org/t/provider-table-standardize-the-way-providers-are-identified/4324/3). You need a group of people to add granular payers and then map them to parent payers. It is going to take someone from the vocabulary work group and someone that understands payers. This is not a version 6 issue, as the fields specified are also in version 5.3.1. It’s an “ad hoc” group issue. |
| TYPE | NOTES |
|---|---|
| ITEM | When should CONCEPT_ID be NULL and when should it be 0? |
| FORUM POST | http://forums.ohdsi.org/t/concept-id-to-null-or-not-to-null-themis-wg3/3965/46 |
| SOLUTION | Foreign key into the Standardized Vocabularies (i.e. the standard_concept attribute for the corresponding term is true), which serves as the primary basis for all standardized analytics. For example, condition_concept_id = 31967 contains reference value for SNOMED concept of 'Nausea'. Set the value to 0 'No matching concept' when a mapping to a standard concept cannot be found (except for MEASUREMENT/OBSERVATION.VALUE_AS_CONCEPT_ID, MEASUREMENT/OBSERVATION.UNIT_CONCEPT_ID, MEASUREMENT.OPERATOR_CONCEPT_ID which can be NULL if data does not contain a value). |
| NEXT STEPS | 1) Submit recommendation to the CDM WG to make all CONCEPT_IDs NOT NULL columns (except for MEASUREMENT/OBSERVATION.VALUE_AS_CONCEPT_ID, MEASUREMENT/OBSERVATION.UNIT_CONCEPT_ID, MEASUREMENT.OPERATOR_CONCEPT_ID which can be NULL if data does not contain a value). 2) Update language in the WIKI under CONCEPT_ID https://github.com/OHDSI/CommonDataModel/wiki/Data-Model-Conventions |
| Type | Notes |
|---|---|
| Item | Person with Multiple Ethnicities |
| Forum Post | |
| Solution | Pick latest or add to observation table |
| Next Steps | Accepted by the THEMIS F2F meeting. |
| TYPE | NOTES |
|---|---|
| ITEM | How to handle missing visit end dates? Can we leave it blank? |
| FORUM POST | http://forums.ohdsi.org/t/themis-2-how-do-you-handle-missing-visit-end-dates/4308 |
| SOLUTION | Visit_end_date is mandatory. Use the best information to infer a visit end date. If end dates are not provided, possible ways to derive them include: 1) Outpatient Visit: end_date=start_date 2) Emergency Room Visit: end_date=start_date 3) Inpatient Visit: usually there is information about discharge. If not you should be able to derive from the sudden decline of activity, or from the absence of inpatient procedures/drugs. But the latter would be not obvious. 4) Long Term Care Visits: particularly for claims data, if end dates are not provided assume the visit is for the duration of month that it occurs. 5) For inpatient visits ongoing at the date of ETL, put date of processing the data as mandatory visit_end_date and VISIT_TYPE_CONCEPT_ID with 32220-"Still patient" to identify the visit as incomplete. |
| NEXT STEPS | Add this as a convention under VISIT_OCCURRENCE Add the following note to 6.5: "Visit_end_date is mandatory. If there is no definite information, the following heuristic can be used: equate end date to start date, use discharge date or another way to pick the best option" |
| TYPE | NOTES |
|---|---|
| ITEM | How to handle granular vs total cost from claims data? |
| FORUM POST | http://forums.ohdsi.org/t/proposal-for-cost-table-adjustment/1842/21 OHDSI/CommonDataModel#81 |
| SOLUTION | Use cost_type_concept_ids. Class = “summary” will denote “total cost” and class = “detail” will denote granular costs. |
| NEXT STEPS | update CDM Wiki for COST table |
| Type | Notes |
|---|---|
| Item | Person with Multiple Races, Multiple Ethnicities, and Multiple Genders |
| Forum Post | http://forums.ohdsi.org/t/multiple-race-solution/2012 |
| Solution | When a person has multiple races, multiple ethnicities, or multiple genders it is recommended to choose the latest race/ethnicity/gender found for the patient record, unless a more appropriate approach exists for your data. If you would like to keep other designations of race, ethnicity, or gender do so in the OBSERVATION table. |
| Next Steps | Add under conventions on the PERSON wiki page. THIS MISSED RELEASE V1.0.0 WILL GO IN FOR THE NEXT RELEASE. |
| TYPE | NOTES |
|---|---|
| ITEM | What should be done with patient reported drugs or conditions? |
| FORUM POST | http://forums.ohdsi.org/t/patient-reported-drugs-and-conditions/3152 |
| SOLUTION | Patient reported data recommendation should land in the appropriate domain table (e.g. if a patient reports they had lymphoma it should land in the CONDITION_OCCURRENCE table. These data should be strongly typed so that it easily known which records are patient reported. Type concepts include 44814721-Patient reported 44818706-Patient reported device 44818704-Patient reported value 45905770-Patient Self-Reported Condition 44787730-Patient Self-Reported Medication 44786633 – numeric HRA values 44786634 – categorical HRA values |
| NEXT STEPS | Ask the CDM WG to add this to the FAQ https://github.com/OHDSI/CommonDataModel/wiki/Frequently-Asked-Questions |
| TYPE | NOTES |
|---|---|
| ITEM | Should we include the patients with a year of birth after a database end date? |
| FORUM POST | http://forums.ohdsi.org/t/eliminating-persons-themis-wg3-topic-2/3974/3 |
| SOLUTION | Do not bring in any patients who have a year of birth after the database end date. |
| NEXT STEPS | Update the CDM Wiki on PERSON.year_of_birth column Description. |
FORUM: http://forums.ohdsi.org/t/improved-data-quality-checking-for-measurement/5421
SOLUTION:
NEXT STEPS: modify conventions for MEASUREMENT table
Observed units per lab test: https://github.com/OHDSI/StudyProtocolSandbox/blob/master/themis/extras/results2019/S3-units-with-tests.csv
(for example see data for LOINC,8302-2 - height - cm (6 datasets), inches (2 datasets))
Data driven concensus KB for the second point:
https://github.com/OHDSI/StudyProtocolSandbox/blob/master/themis/extras/results2019/S7-preferred_units-ABC.csv
This issue will document the progress on it - or people to make comments.
ThemisUnits knowledge base will be used.
Proposal is to implement it as R logic (not in SQL). (VH volunteers to do that).
If SQL has to be used - I am making a call for volunteer SQL developer willing to help.
ITEM: see title
FORUM POST: see below
SOLUTION:
only convention for mother, father is the main scope of this themis proposal. First two conventions. One additional convention tries to guide (to as specifically) other biological relationships.
use concept 4277283 to represent personA is biological mother of personB (in column relationship_concept_id). Use concept 4321888 to represent personC is biological father of personB. Prioritize mother or father relationship (if known) and try to avoid only saying biological parent. Only if parent gender is not known, use 'biological parent' (concept 4029630). Use of biological parent (and not mother or father) triggers a heel data quality notification).
If person A has a recorded biological relationship to person person B (e.g., mother, father, parent), always represent the reverse relationship as well (daughter, son, child). Prioritize biological son (4014096) /biological daughter (4308126) based on sex at birth. Only if child gender is not know, use biological child (4326600). Lack of reverse relationship triggers data quality error. Use of less preferred 'biological child' concept triggers data quality notification.
If you have other biological relationship in source data, use concepts that are descendants of concept_id 4054070 (relative). This convention does not prevent representing other non-biological relationships between persons. The goal of this convention is to restrict the value set of concepts for "encouraged" biological relationships. (heel notification not possible here; no way to distinguish it is biological statement)
see concept_ids discussion below. In your comment, indicate concepts you like the most
NEXT STEPS: add conventions in SOLUTION
HEEL: DQ notification if parent concept id is used (not mother or father)
Current specs do not prescribe specific vocabulary concept to use when linking persons in FACT_RELATIONSHIP
Goal: recommend specific concept for column relationship_concept_id.
Use natural father and natural mother from this parent concept of natural parent
http://athena.ohdsi.org/search-terms/terms/4029630
(reverse relationship is natural child)
http://athena.ohdsi.org/search-terms/terms/4326600
links to forum
http://forums.ohdsi.org/t/voijtechs-question-conventions-for-iological-relationships-in-fact-relationship-table/158
http://forums.ohdsi.org/t/mother-father-and-baby-link/1044
The gap in specs is here
https://github.com/OHDSI/CommonDataModel/wiki/FACT_RELATIONSHIP#conventions
I want to write a Data Quality notification in Achilles but for that it needs to tighter specified.
How do we handle patients changing names over time, can we store all permutations of the names?
Identified during the AllOfUs F2F
| TYPE | NOTES |
|---|---|
| ITEM | Are there conditions/procedures/drugs or other items that should be masked/hidden in the CDM? |
| FORUM POST | http://forums.ohdsi.org/t/masking-of-data-about-a-person/4373 |
| SOLUTION | The masking of information related to a person is dependent on the organization's privacy policies and may vary by data asset. |
| NEXT STEPS | Work with CDM WG to add this statement to FAQs. QUESTION Are there conditions/procedures/drugs or other domains that should be masked/hidden in the CDM? ANSWER The masking of information related to a person is dependent on the organization's privacy policies and may vary by data asset. https://github.com/OHDSI/CommonDataModel/wiki/Frequently-Asked-Questions |
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.
