P3d V5.3 Vs 5.4

[Catherin Bergan]

Belowis the specification document for the OMOP Common Data Model,v5.3 (previously v5.3.1). Each table is represented with a high-leveldescription and ETL conventions that should be followed. This iscontinued with a discussion of each field in each table, any conventionsrelated to the field, and constraints that should be followed (likeprimary key, foreign key, etc). All tables should be instantiated in aCDM instance but do not need to be populated. Similarly, fields that arenot required should exist in the CDM table but do not need to bepopulated. Should you have questions please feel free to visit the forums or the github issuepage.

Special Note This documentation previouslyreferenced v5.3.1. During the OHDSI/CommonDataModel Hack-A-Thon thatoccurred on August 18, 2021 the decision was made to align documentationwith the minor releases. Hot fixes and minor.minor release can be foundthrough the searching of tags.

All Persons in a database needs one record in this table, unless theyfail data quality requirements specified in the ETL. Persons with noEvents should have a record nonetheless. If more than one data sourcecontributes Events to the database, Persons must be reconciled, ifpossible, across the sources to create one single record per Person. Thecontent of the BIRTH_DATETIME must be equivalent to the content ofBIRTH_DAY, BIRTH_MONTH and BIRTH_YEAR.

For detailed conventionsfor how to populate this table, please refer to the THEMISrepository.

This table contains records which define spans of time during whichtwo conditions are expected to hold: (i) Clinical Events that happenedto the Person are recorded in the Event tables, and (ii) absence ofrecords indicate such Events did not occur during this span of time.

For each Person, one or more OBSERVATION_PERIOD records may bepresent, but they will not overlap or be back to back to each other.Events may exist outside all of the time spans of the OBSERVATION_PERIODrecords for a patient, however, absence of an Event outside these timespans cannot be construed as evidence of absence of an Event. Incidenceor prevalence rates should only be calculated for the time of activeOBSERVATION_PERIOD records. When constructing cohorts, outside Eventscan be used for inclusion criteria definition, but without any guaranteefor the performance of these criteria. Also, OBSERVATION_PERIOD recordscan be as short as a single day, greatly disturbing the denominator ofany rate calculation as part of cohort characterizations. To avoid that,apply minimal observation time as a requirement for any cohortdefinition.

Each Person needs to have at least one OBSERVATION_PERIOD record,which should represent time intervals with a high capture rate ofClinical Events. Some source data have very similar concepts, such asenrollment periods in insurance claims data. In other source data suchas most EHR systems these time spans need to be inferred under a set ofassumptions. It is the discretion of the ETL developer to define theseassumptions. In many ETL solutions the start date of the firstoccurrence or the first high quality occurrence of a Clinical Event(Condition, Drug, Procedure, Device, Measurement, Visit) is defined asthe start of the OBSERVATION_PERIOD record, and the end date of the lastoccurrence of last high quality occurrence of a Clinical Event, or theend of the database period becomes the end of the OBSERVATOIN_PERIOD foreach Person. If a Person only has a single Clinical Event theOBSERVATION_PERIOD record can be as short as one day. Depending on thesedefinitions it is possible that Clinical Events fall outside the timespans defined by OBSERVATION_PERIOD records. Family history or historyof Clinical Events generally are not used to generate OBSERVATION_PERIODrecords around the time they are referring to. Any two overlapping oradjacent OBSERVATION_PERIOD records have to be merged into one.

The configuration defining the Visit are described by Concepts in theVisit Domain, which form a hierarchical structure, but rolling up togenerally familiar Visits adopted in most healthcare systemsworldwide:

Visits can be derived easily if the source data contain codingsystems for Place of Service or Procedures, like CPT codes for wellvisits. In those cases, the codes can be looked up and mapped to aStandard Visit Concept. Otherwise, Visit Concepts have to be identifiedin the ETL process. This table will contain concepts in the Visitdomain. These concepts are arranged in a hierarchical structure tofacilitate cohort definitions by rolling up to generally familiar Visitsadopted in most healthcare systems worldwide. Visits can be adjacent toeach other, i.e. the end date of one can be identical with the startdate of the other. As a consequence, more than one-day Visits or theirdescendants can be recorded for the same day. Multi-day visits must notoverlap, i.e. share days other than start and end days. It is often thecase that some logic should be written for how to define visits and howto assign Visit_Concept_Id. For example, in US claims outpatient visitsthat appear to occur within the time period of an inpatient visit can berolled into one with the same Visit_Occurrence_Id. In EHR data inpatientvisits that are within one day of each other may be strung together tocreate one visit. It will all depend on the source data and howencounter records should be translated to visit occurrences. Providerscan be associated with a Visit through the PROVIDER_ID field, orindirectly through PROCEDURE_OCCURRENCE records linked both to the VISITand PROVIDER tables.

The VISIT_DETAIL table is an optional table used to representsdetails of each record in the parent VISIT_OCCURRENCE table. A goodexample of this would be the movement between units in a hospital duringan inpatient stay or claim lines associated with a one insurance claim.For every record in the VISIT_OCCURRENCE table there may be 0 or morerecords in the VISIT_DETAIL table with a 1:n relationship where n may be0. The VISIT_DETAIL table is structurally very similar toVISIT_OCCURRENCE table and belongs to the visit domain.

The configuration defining the Visit Detail is described by Conceptsin the Visit Domain, which form a hierarchical structure. The VisitDetail record will have an associated to the Visit Occurrence record intwo ways:

1. The Visit Detail record will have theVISIT_OCCURRENCE_ID it is associated to 2. The VISIT_DETAIL_CONCEPT_IDwill be a descendant of the VISIT_CONCEPT_ID for the Visit.

It is not mandatory that the VISIT_DETAIL table be filled in, but ifyou find that the logic to create VISIT_OCCURRENCE records includes theroll-up of multiple smaller records to create one picture of a Visitthen it is a good idea to use VISIT_DETAIL. In EHR data, for example, aPerson may be in the hospital but instead of one over-arching Visittheir encounters are recorded as times they interacted with a healthcare provider. A Person in the hospital interacts with multipleproviders multiple times a day so the encounters must be strung togetherusing some heuristic (defined by the ETL) to identify the entire Visit.In this case the encounters would be considered Visit Details and theentire Visit would be the Visit Occurrence. In this example it is alsopossible to use the Vocabulary to distinguish Visit Details from a VisitOccurrence by setting the VISIT_CONCEPT_ID to 9201 and theVISIT_DETAIL_CONCEPT_IDs either to 9201 or its children to indicatewhere the patient was in the hospital at the time of care.

This table contains records of Events of a Person suggesting thepresence of a disease or medical condition stated as a diagnosis, asign, or a symptom, which is either observed by a Provider or reportedby the patient.

This table captures records about the exposure to a Drug ingested orotherwise introduced into the body. A Drug is a biochemical substanceformulated in such a way that when administered to a Person it willexert a certain biochemical effect on the metabolism. Drugs includeprescription and over-the-counter medicines, vaccines, andlarge-molecule biologic therapies. Radiological devices ingested orapplied locally do not count as Drugs.

The purpose of records in this table is to indicate an exposure to acertain drug as best as possible. In this context a drug is defined asan active ingredient. Drug Exposures are defined by Concepts from theDrug domain, which form a complex hierarchy. As a result, oneDRUG_SOURCE_CONCEPT_ID may map to multiple standard concept ids if it isa combination product. Records in this table represent prescriptionswritten, prescriptions dispensed, and drugs administered by a providerto name a few. The DRUG_TYPE_CONCEPT_ID can be used to find and filteron these types. This table includes additional information about thedrug products, the quantity given, and route of administration.

Information about quantity and dose is provided in a variety ofdifferent ways and it is important for the ETL to provide as muchinformation as possible from the data. Depending on the provenance ofthe data fields may be captured differently i.e. quantity for drugsadministered may have a separate meaning from quantity for prescriptionsdispensed. If a patient has multiple records on the same day for thesame drug or procedures the ETL should not de-dupe them unless there isprobable reason to believe the item is a true data duplicate. Take noteon how to handle refills for prescriptions written.

For detailedconventions on how to populate this table, please refer to the THEMISrepository.

Lab tests are not a procedure, if something is observed with anexpected resulting amount and unit then it should be a measurement.Phlebotomy is a procedure but so trivial that it tends to be rarelycaptured. It can be assumed that there is a phlebotomy procedureassociated with many lab tests, therefore it is unnecessary to add themas separate procedures. If the user finds the same procedure overconcurrent days, it is assumed those records are part of a procedurelasting more than a day. This logic is in lieu of theprocedure_end_date, which will be added in a future version of theCDM.

3a8082e126