From 2ea53b22bdfa01c643c58158404353b6cae2e0f1 Mon Sep 17 00:00:00 2001 From: parisni Date: Sun, 10 Sep 2017 00:11:54 +0200 Subject: [PATCH] repair broken md tables --- .../CONDITION_OCCURRENCE.md | 41 +++++++++++++++ .../StandardizedDerivedElements/NOTE_NLP.md | 50 +++++++++++++++++++ 2 files changed, 91 insertions(+) create mode 100644 Documentation/CommonDataModel_Wiki_Files/StandardizedDerivedElements/CONDITION_OCCURRENCE.md create mode 100644 Documentation/CommonDataModel_Wiki_Files/StandardizedDerivedElements/NOTE_NLP.md diff --git a/Documentation/CommonDataModel_Wiki_Files/StandardizedDerivedElements/CONDITION_OCCURRENCE.md b/Documentation/CommonDataModel_Wiki_Files/StandardizedDerivedElements/CONDITION_OCCURRENCE.md new file mode 100644 index 0000000..0b20827 --- /dev/null +++ b/Documentation/CommonDataModel_Wiki_Files/StandardizedDerivedElements/CONDITION_OCCURRENCE.md @@ -0,0 +1,41 @@ +Conditions are records of a Person suggesting the presence of a disease or medical condition stated as a diagnosis, a sign or a symptom, which is either observed by a Provider or reported by the patient. Conditions are recorded in different sources and levels of standardization, for example: + + * Medical claims data include diagnoses coded in ICD-9-CM that are submitted as part of a reimbursement claim for health services and + * EHRs may capture Person Conditions in the form of diagnosis codes or symptoms. + +Field|Required|Type|Description +:--------------------------------|:--------|:------------|:------------------------------------------------------------ +| condition_occurrence_id | Yes | integer | A unique identifier for each Condition Occurrence event. | +| person_id | Yes | integer | A foreign key identifier to the Person who is experiencing the condition. The demographic details of that Person are stored in the PERSON table. | +| condition_concept_id | Yes | integer | A foreign key that refers to a Standard Condition Concept identifier in the Standardized Vocabularies. | +| condition_start_date | Yes | date | The date when the instance of the Condition is recorded. | +| condition_start_datetime | No | datetime | The date and time when the instance of the Condition is recorded. | +| condition_end_date | No | date | The date when the instance of the Condition is considered to have ended. | +| condition_end_datetime | No | date | The date when the instance of the Condition is considered to have ended. | +| condition_type_concept_id | Yes | integer | A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the source data from which the condition was recorded, the level of standardization, and the type of occurrence. | +| stop_reason | No | varchar(20) | The reason that the condition was no longer present, as indicated in the source data. | +| provider_id | No | integer | A foreign key to the Provider in the PROVIDER table who was responsible for capturing (diagnosing) the Condition. | +| visit_occurrence_id | No | integer | A foreign key to the visit in the VISIT_OCCURRENCE table during which the Condition was determined (diagnosed). | +| visit_detail_id | No | integer | A foreign key to the visit in the VISIT_DETAIL table during which the Condition was determined (diagnosed). | +| condition_source_value | No | varchar(50) | The source code for the condition as it appears in the source data. This code is mapped to a standard condition concept in the Standardized Vocabularies and the original code is stored here for reference. | +| condition_source_concept_id | No | integer | A foreign key to a Condition Concept that refers to the code used in the source. | +| condition_status_source_value | No | varchar(50) | The source code for the condition status as it appears in the source data. | +| condition_status_concept_id | No | integer | A foreign key to the predefined concept in the standard vocabulary reflecting the condition status | + +### Conventions + + * Valid Condition Concepts belong to the "Condition" domain. + * Condition records are typically inferred from diagnostic codes recorded in the source data. Such code system, like ICD-9-CM, ICD-10-CM, Read etc., provide a comprehensive coverage of conditions. However, if the diagnostic code in the source does not define a condition, but rather an observation or a procedure, then such information is not stored in the CONDITION_OCCURRENCE table, but in the respective tables instead. + * Source Condition identifiers are mapped to Standard Concepts for Conditions in the Standardized Vocabularies. When the source code cannot be translated into a Standard Concept, a CONDITION_OCCURRENCE entry is stored with only the corresponding source_concept_id and source_value, while the condition_concept_id is set to 0. + * Family history and past diagnoses ("history of") are not recorded in the CONDITION_OCCURRENCE table. Instead, they are listed in the OBSERVATION table. + * Codes written in the process of establishing the diagnosis, such as "question of" of and "rule out", are not represented here. Instead, they are listed in the OBSERVATION table, if they are used for analyses. + * A Condition Occurrence Type is assigned based on the data source and type of condition attribute, for example: + * ICD-9-CM Primary Diagnosis from inpatient and outpatient Claims + * ICD-9-CM Secondary Diagnoses from inpatient and outpatient Claims + * Diagnoses or problems recorded in an EHR. + * The Stop Reason indicates why a Condition is no longer valid with respect to the purpose within the source data. Typical values include "Discharged", "Resolved", etc. Note that a Stop Reason does not necessarily imply that the condition is no longer occurring. + * Condition source codes are typically ICD-9-CM, Read or ICD-10 diagnosis codes from medical claims or discharge status/visit diagnosis codes from EHRs. + * Presently, there is no designated vocabulary, domain, or class that represents condition status. The following concepts from SNOMED are recommended: + * Admitting diagnosis: 4203942 + * Final diagnosis: 4230359 � should also be used for �Discharge diagnosis� + * Preliminary diagnosis: 4033240 diff --git a/Documentation/CommonDataModel_Wiki_Files/StandardizedDerivedElements/NOTE_NLP.md b/Documentation/CommonDataModel_Wiki_Files/StandardizedDerivedElements/NOTE_NLP.md new file mode 100644 index 0000000..14f269a --- /dev/null +++ b/Documentation/CommonDataModel_Wiki_Files/StandardizedDerivedElements/NOTE_NLP.md @@ -0,0 +1,50 @@ +The NOTE_NLP table will encode all output of NLP on clinical notes. Each row represents a single extracted term from a note. + +Field | Required | Type | Description +:------------------------------- | :-------- | :------------ | :--------------------------------------------------- +|note_nlp_id | Yes | Big Integer | A unique identifier for each term extracted from a note.| +|note_id | Yes | integer | A foreign key to the Note table note the term was extracted from.| +|section_concept_id | No | integer | A foreign key to the predefined Concept in the Standardized Vocabularies representing the section of the extracted term.| +|snippet | No | varchar(250) | A small window of text surrounding the term.| +|offset | No | varchar(50) | Character offset of the extracted term in the input note.| +|lexical_variant | Yes | varchar(250) | Raw text extracted from the NLP tool.| +|note_nlp_concept_id | No | integer | A foreign key to the predefined Concept in the Standardized Vocabularies reflecting the normalized concept for the extracted term. Domain of the term is represented as part of the Concept table.| +|note_nlp_source_concept_id | no | integer | A foreign key to a Concept that refers to the code in the source vocabulary used by the NLP system| +|nlp_system | No | varchar(250) | Name and version of the NLP system that extracted the term.Useful for data provenance.| +|nlp_date | Yes | date | The date of the note processing.Useful for data provenance.| +|nlp_date_time | No | datetime | The date and time of the note processing. Useful for data provenance.| +|term_exists | No | varchar(1) | A summary modifier that signifies presence or absence of the term for a given patient. Useful for quick querying. *| +|term_temporal | No | varchar(50) | An optional time modifier associated with the extracted term. (for now “past” or “present” only). Standardize it later.| +|term_modifiers | No | varchar(2000) | A compact description of all the modifiers of the specific term extracted by the NLP system. (e.g. “son has rash” ? “negated=no,subject=family, certainty=undef,conditional=false,general=false”).| + +### Conventions + +**Term_exists** +Term_exists is defined as a flag that indicates if the patient actually has or had the condition. Any of the following modifiers would make Term_exists false: + +* Negation = true +* Subject = [anything other than the patient] +* Conditional = true +* Rule_out = true +* Uncertain = very low certainty or any lower certainties + +A complete lack of modifiers would make Term_exists true. + +For the modifiers that are there, they would have to have these values: + +* Negation = false +* Subject = patient +* Conditional = false +* Rule_out = false +* Uncertain = true or high or moderate or even low (could argue about low) + +**Term_temporal** +Term_temporal is to indicate if a condition is “present” or just in the “past”. + +The following would be past: + +* History = true +* Concept_date = anything before the time of the report + +**Term_modifiers** +Term_modifiers will concatenate all modifiers for different types of entities (conditions, drugs, labs etc) into one string. Lab values will be saved as one of the modifiers. A list of allowable modifiers (e.g., signature for medications) and their possible values will be standardized later.