OHDSI / CommonDataModel

Definition and DDLs for the OMOP Common Data Model (CDM)
https://ohdsi.github.io/CommonDataModel
870 stars 446 forks source link

Oncology Treatment Proposal #163

Closed mgurley closed 5 years ago

mgurley commented 6 years ago

Oncology Treatments

Radiation Therapy Treatment Welter

This treatment spawns 72 entries using 11 CPT codes in the PROCEDURE_OCCURRENCE table covering the radiation therapy treatment lifecycle: radiation therapy management, radiation therapy simulation, radiation therapy planning and radiation therapy delivery:

Drug Therapy Treatment Welter

This treatment spawns 22 entries using 5 CPT codes in the PROCEDURE_OCCURRENCE table and 50 entries using 13 RxNorm codes in DRUG_EXPOSURE table.

TREATMENT Concept

In the oncology community there is a widely shared TREATMENT concept: tumor registries, practice guidelines, clinical trials databases and oncology analytic platforms all employ the concept of a TREATMENT. The TREATMENT concept aggregates lower-level clinical events into a higher-level abstraction. But we still want this higher-level abstraction TREATMENT concept to connect to lower-level clinical events.

Can we have both the benefit of a higher-level oncology TREATMENT abstraction and connection to lower-level clinical events? Can we find a place for pre-made oncology TREATMENT abstractions connected to lower-level clinical events? Conversely, can we derive higher-level oncology TREATMENTs from lower-level clinical events ? Finally, can we attach unconnected available pre-made oncology TREATMENT abstractions to lower-level clinical events?

Making room for a TREATMENT concept in the OMOP CDM will afford a number of benefits:

Proposal

Add support for a TREATMENT domain within the OMOP CDM.

We will out outline two possible implementation options. Option A and Option B.

Tables (Option A)

TREATMENT Table The TREATMENT table contains records aggregating lower-level clinical events (DRUG_EXPOSURE and PROCEDURE_OCCURRENCE) into a higher-level abstraction representing an extended diagnostic or therapeutic intervention for specific patient condition(s). A TREATMENT can be delivered at regular intervals, cycles or fractions. The temporal grouping of clinical events into cycles will only be instantiated if it is available within a source system. TREATMENT cycles will not be algorithmically derived. Pre-made higher-level TREATMENT abstractions present in a source systems will be directly inserted. Alternatively, when not available within any source system, TREATMENT abstractions will be algorithmically derived from lower-level clinical events.

Field Required Type Description
treatment_id yes integer A unique identifier for each Treatment.
person_id yes integer A foreign key identifier to the Person who is undergoing Treatment. The demographic details of that Person are stored in the PERSON table.
treatment_concept_id yes integer A foreign key that refers to a standard Treatment Concept identifier in the Standardized Vocabularies.
treatment_start_date yes date The start date for the Treatment. If not available within a source system the date is constructed from the individual instances of Standardized Clinical Data tables (Procedure Occurrence and Drug Exposure) comprising the Treatment’s Treatment Concept. It is the start date of the very first chronologically recorded clinical event within a defined window of days after an index date.
treatment_end_date yes date The end date for the Treatment. If not available within the source system the date is constructed from the individual instances of Standardized Clinical Data tables (Procedure Occurrence and Drug Exposure) comprising the Treatment’s Treatment Concept. It is the end date of the final recorded instance of the Treatment within a defined window of days after an index date.
treatment_parent_id no integer A foreign key that refers to a parent Treatment entry representing an entire treatment if the treatment spans multiple cycles.
treatment_cycle_number no integer An ordinal count of cycles for a Treatment that spans multiple cycles
treatment_type_concept_id yes integer A foreign key that refers to a standard Treatment Type Concept identifier in the Standardized Vocabularies reflecting the source data from which the Treatment was recorded, the level of standardization, and the type of occurrence.
treatment_intent_concept_id no integer A foreign key that refers to a standard Treatment Intent Concept identifier in the Standardized Vocabularies reflecting the interventional intent of the Treatment.
treatment_source_value no varchar(50) The source code for the Treatment as it appears in the source data. This code is mapped to a standard procedure Concept in the Standardized Vocabularies and the original code is, stored here for reference.
treatment_source_concept_id no integer A foreign key to a Treatment Concept that refers to the code used in the source.
treatment_status_concept_id no integer A foreign key that refers to a standard Treatment Status Concept identifier in the Standardized Vocabularies reflecting the status the Treatment.

Conventions

TREATMENT_MODIFIER Table The TREATMENT_MODIFIER table contains records that attribute properties to a treatment. These properties should further refine the description of the treatment. Most often these modifiers will point to a TREATMENT table entry but also possibly a PROCEDURE_OCCURRENCE table entry or a DRUG_EXPOSURE table entry. Some examples: attribution of a known Drug Regimen concept to a Drug Therapy treatment; number of fractions, anatomical target, total dose in cGy for Radiation Therapy treatment.

Field Required Type Description
treatment_modifier_id Yes integer A unique identifier for each Treatment Modifier.
treatment_modifier_event_id Yes integer A foreign key identifier to the event (e.g. Treatment, Treatment Cycle, Drug, Procedure etc) record that is being modified.
treatment_modifier_domain_id Yes integer The concept representing the domain of the treatment modifier event, from which the corresponding table can be inferred that contains the entity for which the treatment modifier information is recorded.
person_id Yes integer A foreign key identifier to the Person about whom the Treatment Modifier was recorded. The demographic details of that Person are stored in the PERSON table.
treatmeant_modifier_concept_id Yes integer A foreign key to the standard Treatmenft Modifier concept identifier in the Standardized Vocabularies.
treatment_modifier_date Yes date The date of the Treatment Modifier.
treatment_modifier_datetime No datetime The date and time of the Treatment Modifier. Some database systems don't have a datatype of time. To accomodate all temporal analyses, datatype datetime can be used (combining treatment_modifier_date and treatment_modifier_time)
treatment_modifier_type_concept_id Yes integer A foreign key to the predefined Concept in the Standardized Vocabularies reflecting the provenance from where the Treatment Modifier record was recorded.
operator_concept_id No integer A foreign key identifier to the predefined Concept in the Standardized Vocabularies reflecting the mathematical operator that is applied to the value_as_number. Operators are <, <=, =, >=, >.
value_as_number No float A Treatment Modifier result where the result is expressed as a numeric value.
value_as_concept_id No integer A foreign key to a Treatment Modifier result represented as a Concept from the Standardized Vocabularies (e.g., positive/negative, present/absent, low/high, etc.).
unit_concept_id No integer A foreign key to a Standard Concept ID of Treatment Modier Units in the Standardized Vocabularies.
provider_id No integer A foreign key to the provider in the PROVIDER table who was responsible for initiating or obtaining the Treatment Modifier.
treatment_modifier_source_value No varchar(50) The Treatment Modifier name as it appears in the source data. This code is mapped to a Standard Concept in the Standardized Vocabularies and the original code is stored here for reference.
treatment_modifier_source_concept_id No integer A foreign key to a Concept in the Standard Vocabularies that refers to the code used in the source.
unit_source_value No varchar(50) The source code for the unit as it appears in the source data. This code is mapped to a standard unit concept in the Standardized Vocabularies and the original code is stored here for reference.
value_source_value No varchar(50) The source value associated with the content of the value_as_number or value_as_concept_id as stored in the source data.

Conventions

DRUG_EXPOSURE Table Amendments required to the DRUG_EXPOSURE table are as follows:

Field Required Type Description
treatment_id yes integer A unique identifier for each Treatment.

Conventions

PROCEDURE_OCCURRENCE Table Amendments required to the PROCEDURE_OCCURRENCE table are as follows:

Field Required Type Description
treatment_id yes integer A unique identifier for each Treatment.

Conventions

Tables (Option B)

TREATMENT Table The TREATMENT table contains records aggregating lower-level clinical events (DRUG_EXPOSURE and PROCEDURE_OCCURRENCE) into a higher-level abstraction representing an extended diagnostic or therapeutic intervention for a specified patient condition. Pre-made higher-level TREATMENT abstractions present in a source systems will be directly inserted. Alternatively, when not available within any source system, TREATMENT abstractions will be algorithmically derived from lower-level clinical events.

Field Required Type Description
treatment_id yes integer A unique identifier for each Treatment.
person_id yes integer A foreign key identifier to the Person who is undergoing Treatment. The demographic details of that Person are stored in the PERSON table.
treatment_concept_id yes integer A foreign key that refers to a standard Treatment Concept identifier in the Standardized Vocabularies.
treatment_start_date yes date The start date for the Treatment. If not available within a source system the date is constructed from the individual instances of Standardized Clinical Data tables (Procedure Occurrence and Drug Exposure) comprising the Treatment’s Treatment Concept. It is the start date of the very first chronologically recorded clinical event within a defined window of days after an index date.
treatment_end_date yes date The end date for the Treatment. If not available within the source system the date is constructed from the individual instances of Standardized Clinical Data tables (Procedure Occurrence and Drug Exposure) comprising the Treatment’s Treatment Concept. It is the end date of the final recorded instance of the Treatment within a defined window of days after an index date.
treatment_type_concept_id yes integer A foreign key that refers to a standard Treatment Type Concept identifier in the Standardized Vocabularies reflecting the source data from which the Treatment was recorded, the level of standardization, and the type of occurrence.
treatment_intent_concept_id no integer A foreign key that refers to a standard Treatment Intent Concept identifier in the Standardized Vocabularies reflecting the interventional intent of the Treatment.
treatment_source_value no varchar(50) The source code for the Treatment as it appears in the source data. This code is mapped to a standard procedure Concept in the Standardized Vocabularies and the original code is, stored here for reference.
treatment_source_concept_id no integer A foreign key to a Treatment Concept that refers to the code used in the source.
treatment_status_concept_id no integer A foreign key that refers to a standard Treatment Status Concept identifier in the Standardized Vocabularies reflecting the status the Treatment.

Conventions

TREATMENT_MODIFIER Table The TREATMENT_MODIFIER table contains records that attribute properties to a treatment. These properties should further refine the description of the treatment. Most often these modifiers will point to a TREATMENT table entry but also possibly a TREATMENT_CYCLE table entry, a PROCEDURE_OCCURRENCE table entry or a DRUG_EXPOSURE table entry. Some examples: attribution of a known Drug Regimen concept to a Drug Therapy treatment; number of fractions, anatomical target, total dose in cGy for Radiation Therapy treatment.

Field Required Type Description
treatment_modifier_id Yes integer A unique identifier for each Treatment Modifier.
treatment_modifier_event_id Yes integer A foreign key identifier to the event (e.g. Treatment, Treatment Cycle, Drug, Procedure etc) record that is being modified.
treatment_modifier_domain_id Yes integer The concept representing the domain of the treatment modifier event, from which the corresponding table can be inferred that contains the entity for which the treatment modifier information is recorded.
person_id Yes integer A foreign key identifier to the Person about whom the Treatment Modifier was recorded. The demographic details of that Person are stored in the PERSON table.
treatmeant_modifier_concept_id Yes integer A foreign key to the standard Treatmenft Modifier concept identifier in the Standardized Vocabularies.
treatment_modifier_date Yes date The date of the Treatment Modifier.
treatment_modifier_datetime No datetime The date and time of the Treatment Modifier. Some database systems don't have a datatype of time. To accomodate all temporal analyses, datatype datetime can be used (combining treatment_modifier_date and treatment_modifier_time)
treatment_modifier_type_concept_id Yes integer A foreign key to the predefined Concept in the Standardized Vocabularies reflecting the provenance from where the Treatment Modifier record was recorded.
operator_concept_id No integer A foreign key identifier to the predefined Concept in the Standardized Vocabularies reflecting the mathematical operator that is applied to the value_as_number. Operators are <, <=, =, >=, >.
value_as_number No float A Treatment Modifier result where the result is expressed as a numeric value.
value_as_concept_id No integer A foreign key to a Treatment Modifier result represented as a Concept from the Standardized Vocabularies (e.g., positive/negative, present/absent, low/high, etc.).
unit_concept_id No integer A foreign key to a Standard Concept ID of Treatment Modier Units in the Standardized Vocabularies.
provider_id No integer A foreign key to the provider in the PROVIDER table who was responsible for initiating or obtaining the Treatment Modifier.
treatment_modifier_source_value No varchar(50) The Treatment Modifier name as it appears in the source data. This code is mapped to a Standard Concept in the Standardized Vocabularies and the original code is stored here for reference.
treatment_modifier_source_concept_id No integer A foreign key to a Concept in the Standard Vocabularies that refers to the code used in the source.
unit_source_value No varchar(50) The source code for the unit as it appears in the source data. This code is mapped to a standard unit concept in the Standardized Vocabularies and the original code is stored here for reference.
value_source_value No varchar(50) The source value associated with the content of the value_as_number or value_as_concept_id as stored in the source data.

Conventions

TREATMENT_CYCLE Table

A TREATMENT can be delivered at regular intervals, fractions or cycles. This temporal grouping of clinical events will only be instantiated if it is available within a source system. A TREATMENT_CYCLE will not be algorithmically derived.

Field Required Type Description
treatment_cycle_id yes integer A unique identifier for each Treatment Cycle.
treatment_id yes integer A foreign key identifier to the Treatment that the Treatment Cycle belongs to and subdivides.
person_id yes integer A foreign key identifier to the Person who is undergoing Treatment. The demographic details of that Person are stored in the PERSON table.
treatment_cycle_start_date yes date The start date for the Treatment Cycle.
treatment_cycle_end_date yes date The end date for the Treatment Cycle.
treatment_cycle_number yes integer An ordinal count of cycles for a Treatment that spans multiple cycles

TREATMENT_EVENT Table

Connect qualifying DRUG_EXPOSURE or PROCEDURE_OCCURRENCE to the appropriate TREATMENT entry by populating the TREATMENT_EVENT table.

Field Required Type Description
treatment_event_id yes integer A unique identifier for each Treatment Event.
treatment_event_event_id yes integer A foreign key identifier to the event (Drug Exposure or Procedure Occurrence) record for which cost data are recorded.
treatment_event_domain_id yes integer The concept representing the domain of the treatment event, from which the corresponding table can be inferred that contains the entity connected to the Treatment and Treatment Cycle.
treatment_id yes integer A foreign key identifier to the Treatment that the Treatment Event belongs to.
treatment_cycle_id no integer A foreign key identifier to the Treatment Cycle that the Treatment Event belongs to. If no Treatment Cycle information is present within the source system, his field will be NULL.
person_id yes integer A foreign key identifier to the Person who is undergoing Treatment. The demographic details of that Person are stored in the PERSON table.

Vocabulary

TREATMENT table columns demanding new concepts are as follows:

The Treatment Concept domain is partially based on the NCI CRN ‘Cancer Therapy Look-up Tables’.) https://crn.cancer.gov/resources/codes.html. Entries will be made in the CONCEPT_RELATIONSHIP table using the existing ‘"Maps to" and "Mapped from" relationships based on the NCI CRN ‘Cancer Therapy Look-up Tables’ that link National Drug Codes (NDCs), procedure codes (CPT4, ICD-9, HCPC) and diagnosis codes (ICD-9) to Treatment Concepts.

The Treatment Type vocabulary:

The Treatment Intent vocabulary:

The Treatment Status vocabulary:

TREATMENT_MODIFIER table columns demanding new concepts are as follows:

The Treatment Modifier domain:

The Treatment Modifier Value domain:

The Drug Regimen Value domain is based on National Tariff Chemotherapy Regimens List. See here: https://hscic.kahootz.com/gf2.ti/f/762498/27839109.1/XLSX/-/NatTarChemoRegList1718.xlsx And here: https://hscic.kahootz.com/gf2.ti/f/762498/27838501.1/PDF/-/ChemRegClinCodingStandGuidApl2017.pdf. Entries will be made in the CONCEPT_RELATIONSHIP table using the existing ‘"Maps to" and "Mapped from" relationships to RxNorm ingredients based on the ingredient participation detailed in the National Tariff Chemotherapy Regimens List.

Algorithms

Option A Algorithms

Option B Algorithms

Algorithm Inspiration
Based on an algorithm in paper “Algorithm to Identify Systemic Cancer Therapy Treatment Using Structured Electronic Data”: http://ascopubs.org/doi/pdf/10.1200/CCI.17.00002. Attempts to characterize first-course systemic therapy and all subsequent course systemic therapy. Uses ‘Cancer Therapy Look-up Tables’ maintained by the NCI Cancer Research Network (CRN) listing National Drug Codes (NDCs), procedure codes (CPT4, ICD-9, HCPC) and diagnosis codes (ICD-9) to filter clinical events in a Health Care Systems Research Network (HCSRN) virtual data warehouse (VDW). https://crn.cancer.gov/resources/codes.html

Open Issues

ColinOrr2008 commented 6 years ago

Good proposal. As per my forum message on tracking patient treatments I have a similar requirement to store treatment level data related to various cancer treatment methods. And as the proposal suggests there a bunch of data that relates to the overall course of treatment that has no natural location within OMOP today that is easily / efficiently accessible. Option A of the proposal is the most appropriate approach from the perspective of my use cases anyway. My use cases at present all relate to cancer treatment but the approach suggested can be used for any chronic condition where there is a course of treatment. I image that CNS conditions would benefit from such a construct.

The TREATMENT domain in conjunction with the TREATMENT_MODIFIER would support all of the my requirements. I have a whole series of “modifiers” that I need to capture at a treatment level such as “whether it was completed or not” or specific side effects and their date of occurrence. These “modifiers” could also easily be considered OBSERVATIONS and I believe in my case all of the data that would be collected as part of a TREATMENT could just as easily be stored in the OBSERVATION table. In which case the OBSERVATION table should also have a TREATMENT_ID column added in to relate them to a specific treatment.

The proposal of adding a TREATMENT ID to the DRUG_EXPOSURE and PROCEDURE_OCCURRENCE table to link these events to a specific treatment I suggest should also be extended to the VISIT_OCCURRENCE table. This would allow for any events related to a patient visit whether they are related to a specific procedure, drug exposure or otherwise to be linked back to a treatment where the visit is part of a specific treatment.

Just a few thoughts…..

shawndo commented 6 years ago

Is there any reason this cannot be used for non-cancer treatments that have some or all of the same requirements/challenges? Seems it has been designed without cancer specificity enough to accommodate others. ?

mgurley commented 6 years ago

@ColinOrr2008 @shawndo

Thanks for the feedback.

@ColinOrr2008

vojtechhuser commented 6 years ago

I am confused by Option A statements on derivation. see blue text (start and end) image

vojtechhuser commented 6 years ago

If we ingest into OMOP Vocab NCI CRN ‘Cancer Therapy Look-up Tables, we should think of non-US contries. The knowledge base is in "non-standard" CPT codes.

see these examples from here https://crn.cancer.gov/resources/Radiation%20Therapy%20Codes_Procedures.csv

image

If we formulate smart constructs in OMOP Vocab, we should not do it off copyrighted CPT4 codes.

mgurley commented 6 years ago

@vojtechhuser Regarding your comment: "I am confused by Option A statements on derivation. see blue text (start and end)"

One of the main issues this proposal is trying accomodate is the varying levels of grouping/abstraction of lower-level clinical events available within various source systems. Sometimes:

gowthamrao commented 6 years ago

Add support for a TREATMENT concept

I think we mean, TREATMENT domain. i.e. just like we have Visit domain, condition domain.

A TREATMENT can be delivered at regular intervals, cycles or fractions. The temporal grouping of clinical events into cycles will only be instantiated if it is available within a source system. TREATMENT cycles will not be algorithmically derived. Pre-made higher-level TREATMENT abstractions present in a source systems will be directly inserted. Alternatively, when not available within any source system, TREATMENT abstractions will be algorithmically derived from lower-level clinical events.

Could you please clarify - 'treatment cycles will not be algorithmically derived' vs. 'Treatment abstractions will be algorithmically derived'

Treatment table

Can the person have different treatment_id's with the same or overlapping treatment start date and treatment end date? (I think the answer is yes). Could you please give some examples?

treatment_cycle_number an ordinal enumeration of treatment cycles. Each representation of a treatment cycle should refer to the parent Treatment by the parent id column.

can you please elaborate this field with an example. E.g. if this is the third chemoRx cycle of a planned treatment of 6 cycles, what value would be in treatment_cycle_number. I think it is proposed to be increment count - e.g. in this case, it would treatment_cycle_number = 3? What is a 'parent Treatment' in this case - maybe the treatment that encompasses all six chemoRx cycles? How can the analyst know for example -- 6 chemoRx were planned, and only 3 were done so far?

table contains records aggregating lower-level clinical events Treatment_modifier.treatment_modifier_domain_id Treatment_modifier.treatment_modifier_event_id

To identify if the table is procedure_occurrence, condition_occurrence, visit_occurrence etc., I think it is best if we support this proposal (use table_concept_id instead of ambiguous domain_concept_id )

TREATMENT_MODIFER

This table seems like a detail of the TREATMENT table. For every record in the TREATMENT table there may 0 or more records in TREATMENT_MODIFIER table? Can the attributes in the TREATMENTMODIFIER table be considered measurements? It has value, unit_

mgurley commented 6 years ago

@vojtechhuser

If we formulate smart constructs in OMOP Vocab, we should not do it off copyrighted CPT4 codes.

We need to find a mapping from vocabulary codes used to represent oncology treatment low-level clinical events to a high-level typing of oncology treatments. This is what NCI CRN ‘Cancer Therapy Look-up Tables' provides. For radiation therapy, it maps 'CPT4', 'HCPC' and 'ICD9' codes. This was based on the actual codes present in the VDW instance upon which it was developed. Since CPT4 is not a standard procedure vocabulary within OMOP (because of licensing), our ingestion of the 'NCI CRN ‘Cancer Therapy Look-up Tables' would likely need to enrich the native mappings to include all standard procedure concepts mappable from CPT4.

On related note, The NCI has recently released a parallel effort called the 'Observational Research in Oncology Toolbox'. See here: https://seer.cancer.gov/oncologytoolbox/. This effort similarly maps vocabulary codes used to represent oncology treatment low-level clinical events to a high-level typing of oncology treatments. A very attractive feature of the 'Observational Research in Oncology Toolbox' is that its high-level typing of oncology treatments is based on and can be connected to tumor registry NAACCR/SEER treatment variables. So far the 'Observational Research in Oncology Toolbox' has only released a mapping for Oncology Drugs, but it is planning on releasing mappings for radiation therapy and surgical oncology. I will be replacing the 'NCI CRN ‘Cancer Therapy Look-up Tables' within the proposal with the 'Observational Research in Oncology Toolbox'. However, your advice about making sure the mappings do not rely on copyrighted non-standard codes will still hold true.

mgurley commented 6 years ago

@gowthamrao

I think we mean, TREATMENT domain. i.e. just like we have Visit domain, condition domain.

You are right. Changed it.

Could you please clarify - 'treatment cycles will not be algorithmically derived' vs. 'Treatment abstractions will be algorithmically derived'

See my response to @vojtechhuser first comment. But basically, in the best case neither Treatments nor Treatment Cycles will need to be algorithmically derived if they are present within your source system. However, if Treatments and Treatment Cycles are not present within your source system, I think it will only be possible to derive Treatments and not Treatment Cycles.

Can the person have different treatment_id's with the same or overlapping treatment start date and treatment end date? (I think the answer is yes). Could you please give some examples?

Yes, a person could have two Treatments with overlapping start and end dates. For example, my Radiation Therapy Beam IMRT treatment could overlap with my Drug Therapy Hormonal treatment.

can you please elaborate this field with an example. E.g. if this is the third chemoRx cycle of a planned treatment of 6 cycles, what value would be in treatment_cycle_number. I think it is proposed to be increment count - e.g. in this case, it would treatment_cycle_number = 3? What is a 'parent Treatment' in this case - maybe the treatment that encompasses all six chemoRx cycles? How can the analyst know for example -- 6 chemoRx were planned, and only 3 were done so far?

The treatment_cycle_number field is supposed to represent the actual number cycle that was executed. So not necessarily incrementing, if for some reason a cycle is skipped.
The treatment_parent_id (in Option A) is always the treatment that encompasses all six chemoRx cycles. (Option B makes this relationship more explicit, which is why I prefer it, the table structure being more isomorphic with reality). Right now the model does not allow for tracking planned versus executed cycles. To allow for this, perhaps we should add a treatment_cycle_status_concept_id field. What do you think?

To identify if the table is procedure_occurrence, condition_occurrence, visit_occurrence etc., I think it is best if we support this proposal (use table_concept_id instead of ambiguous domain_concept_id )

Sounds good. We should follow the emerging OMOP/OHDSI standards. I will change the proposal to adhere to the proposal you pointed to.

This table seems like a detail of the TREATMENT table. For every record in the TREATMENT table there may 0 or more records in TREATMENT_MODIFIER table? Can the attributes in the TREATMENTMODIFIER table be considered measurements? It has value, unit_

This response is a repeat of what I have said to @ColinOrr2008. We are proposing the TREATMENT_MODIFIER structure/domain instead of using references to OBSERVATION/MEASUREMENT via FACT_RELATIONSHIP or adding foreign keys to them in order move to more tightly-scoped EAV structures/domains. We are doing likewise in a separate Diagnosis Modifier proposal for the myriad oncology diagnosis modifiers: staging, grade, lymphatic invasion, biomarker results, etc. EAV is a necessary evil in healthcare. But there are ways to make it less evil. To quote @cgreich, MEASUREMENT and OBSERVATION are "garbage cans". We are just trying to organize our garbage cans. Like separating into compost, waste, paper, aluminum/plastic.

vojtechhuser commented 5 years ago

It would be nice to have same sample data and show all the issues in an example context.

cgreich commented 5 years ago

Agree 100%. Will have to create that.

mgurley commented 5 years ago

@vojtechhuser @cgreich

I will create some sample data. Sample data will make it concrete how source systems (EHR data and Tumor Registry data) with varying degrees of treatment abstractions natively can ETL into the model.

clairblacketer commented 5 years ago

closing as this is covered by #216