anchor.diff:  OBSERVATION_PERIOD,person_id,Yes,integer,The Person ID of the PERSON record for which the Observation Period is recorded.,,No,Yes,PERSON,PERSON_ID,,,
   OBSERVATION_PERIOD,observation_period_start_date,Yes,date,Use this date to determine the start date of the Observation Period.,"It is often the case that the idea of Observation Periods does not exist in source data. In those cases, the observation_period_start_date can be inferred as the earliest Event date available for the Person. In insurance claim data, the Observation Period can be considered as the time period the Person is enrolled with a payer. If a Person switches plans but stays with the same payer, and therefore capturing of data continues, that change would be captured in [PAYER_PLAN_PERIOD](https://ohdsi.github.io/CommonDataModel/cdm531.html#payer_plan_period).",No,No,,,,,
   OBSERVATION_PERIOD,observation_period_end_date,Yes,date,Use this date to determine the end date of the period for which we can assume that all events for a Person are recorded.,"It is often the case that the idea of Observation Periods does not exist in source data. In those cases, the observation_period_end_date can be inferred as the last Event date available for the Person. In insurance claim data, the Observation Period can be considered as the time period the Person is enrolled with a payer.",No,No,,,,,
  -OBSERVATION_PERIOD,period_type_concept_id,Yes,integer,"This field can be used to determine the provenance of the Observation Period as in whether the period was determined from an insurance enrollment file, EHR healthcare encounters, or other sources.",Choose the observation_period_type_concept_id that best represents how the period was determined. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=).,No,Yes,CONCEPT,CONCEPT_ID,Type Concept,,
  +OBSERVATION_PERIOD,period_type_concept_id,Yes,integer,"This field can be used to determine the provenance of the Observation Period as in whether the period was determined from an insurance enrollment file, EHR healthcare encounters, or other sources.",Choose the observation_period_type_concept_id that best represents how the period was determined. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). A more detailed explanation of each Type Concept can be found on the [vocabulary wiki](https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT). ,No,Yes,CONCEPT,CONCEPT_ID,Type Concept,,
   VISIT_OCCURRENCE,visit_occurrence_id,Yes,integer,Use this to identify unique interactions between a person and the health care system. This identifier links across the other CDM event tables to associate events with a visit.,This should be populated by creating a unique identifier for each unique interaction between a person and the healthcare system where the person receives a medical good or service over a span of time.,Yes,No,,,,,
   VISIT_OCCURRENCE,person_id,Yes,integer,,,No,Yes,PERSON,PERSON_ID,,,
   VISIT_OCCURRENCE,visit_concept_id,Yes,integer,"This field contains a concept id representing the kind of visit, like inpatient or outpatient. All concepts in this field should be standard and belong to the Visit domain.","Populate this field based on the kind of visit that took place for the person. For example this could be ""Inpatient Visit"", ""Outpatient Visit"", ""Ambulatory Visit"", etc. This table will contain standard concepts in the Visit domain. These concepts are arranged in a hierarchical structure to facilitate cohort definitions by rolling up to generally familiar Visits adopted in most healthcare systems worldwide. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Visit,,
  
positive.code: EPISODE,episode_parent_id,No,bigint,Use this field to find the Episode that subsumes the given Episode record. This is used in the case that an Episode are nested into each other.,"If there are multiple nested levels to how Episodes are represented, the EPISODE_PARENT_ID can be used to record this relationship. ",No,No,,,,,
  EPISODE,episode_number,No,integer,"For sequences of episodes, this is used to indicate the order the episodes occurred. For example, lines of treatment could be indicated here. ",Please see [article] for the details of how to count episodes.,No,No,,,,,
  EPISODE,episode_object_concept_id,Yes,integer,"A Standard Concept representing the disease phase, outcome, or other abstraction of which the episode consists.  For example, if the EPISODE_CONCEPT_ID is [treatment regimen](https://athena.ohdsi.org/search-terms/terms/32531) then the EPISODE_OBJECT_CONCEPT_ID should contain the chemotherapy regimen concept, like [Afatinib monotherapy](https://athena.ohdsi.org/search-terms/terms/35804392). ",Episode entries from the 'Disease Episode' concept class should have an episode_object_concept_id that comes from the Condition domain.  Episode entries from the 'Treatment Episode' concept class should have an episode_object_concept_id that scome from the 'Procedure' domain or 'Regimen' concept class.,No,Yes,CONCEPT,CONCEPT_ID,"Procedure, Regimen",,
  EPISODE,episode_type_concept_id,Yes,integer,"This field can be used to determine the provenance of the Episode record, as in whether the episode was from an EHR system, insurance claim, registry, or other sources.",Choose the EPISODE_TYPE_CONCEPT_ID that best represents the provenance of the record. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=).,No,Yes,CONCEPT,CONCEPT_ID,Type Concept,,
  EPISODE,episode_source_value,No,varchar(50),The source code for the Episdoe 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.,,No,No,,,,,
  EPISODE,episode_source_concept_id,No,integer,A foreign key to a Episode Concept that refers to the code used in the source.,Given that the Episodes are user-defined it is unlikely that there will be a Source Concept available. If that is the case then set this field to zero. ,No,Yes,CONCEPT,CONCEPT_ID,,,
  EPISODE_EVENT,episode_id,Yes,bigint,Use this field to link the EPISODE_EVENT record to its EPISODE.,Put the EPISODE_ID that subsumes the EPISODE_EVENT record here.,No,Yes,EPISODE,EPISODE_ID,,,
  
negative.code: CONDITION_OCCURRENCE,condition_start_datetime,No,datetime,,If a source does not specify datetime the convention is to set the time to midnight (00:00:0000),No,No,,,,,
  CONDITION_OCCURRENCE,condition_end_date,No,date,Use this date to determine the end date of the condition,"Most often data sources do not have the idea of a start date for a condition. Rather, if a source only has one date associated with a condition record it is acceptable to use that date for both the CONDITION_START_DATE and the CONDITION_END_DATE.",No,No,,,,,
  CONDITION_OCCURRENCE,condition_end_datetime,No,datetime,,If a source does not specify datetime the convention is to set the time to midnight (00:00:0000),No,No,,,,,
  CONDITION_OCCURRENCE,condition_type_concept_id,Yes,integer,"This field can be used to determine the provenance of the Condition record, as in whether the condition was from an EHR system, insurance claim, registry, or other sources.",Choose the CONDITION_TYPE_CONCEPT_ID that best represents the provenance of the record. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). A more detailed explanation of each Type Concept can be found on the [vocabulary wiki](https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT). ,No,Yes,CONCEPT,CONCEPT_ID,Type Concept,,
  CONDITION_OCCURRENCE,condition_status_concept_id,No,integer,"This concept represents the point during the visit the diagnosis was given (admitting diagnosis, final diagnosis), whether the diagnosis was determined due to laboratory findings, if the diagnosis was exclusionary, or if it was a preliminary diagnosis, among others. ","Choose the Concept in the Condition Status domain that best represents the point during the visit when the diagnosis was given. These can include admitting diagnosis, principal diagnosis, and secondary diagnosis. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Condition+Status&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Condition Status,,
  CONDITION_OCCURRENCE,stop_reason,No,varchar(20),The Stop Reason indicates why a Condition is no longer valid with respect to the purpose within the source data. Note that a Stop Reason does not necessarily imply that the condition is no longer occurring.,This information is often not populated in source data and it is a valid etl choice to leave it blank if the information does not exist.,No,No,,,,,
  CONDITION_OCCURRENCE,provider_id,No,integer,"The provider associated with condition record, e.g. the provider who made the diagnosis or the provider who recorded the symptom.","The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record, for example the admitting vs attending physician on an EHR record.",No,Yes,PROVIDER,PROVIDER_ID,,,
  