https://w3id.org/omop/ontology/CdmSource
The CDM_SOURCE table contains detail about the source database and the process used to transform the data into the OMOP Common Data Model.
Instances of Cdm source can have the following properties:
| PROPERTY | TYPE | DESCRIPTION | RANGE |
|---|---|---|---|
| From class Cdm source | |||
| Abbreviation | owl:DatatypeProperty | For Cdm Source: The abbreviation of the CDM instance. | string |
| Cdm etl reference | owl:DatatypeProperty | For Cdm Source: Version of the ETL script used. e.g. link to the Git release | string |
| Cdm holder | owl:DatatypeProperty | For Cdm Source: The holder of the CDM instance. | string |
| Cdm release date | owl:DatatypeProperty | For Cdm Source: The date the ETL script was completed. Typically this is after the source_release_date. | date |
| Cdm version | owl:DatatypeProperty | For Cdm Source: Version of the OMOP CDM used as string. e.g. v5.4 | string |
| Source description | owl:DatatypeProperty | For Cdm Source: The description of the CDM instance. | string |
| Source documentation reference | owl:DatatypeProperty | For Cdm Source: Refers to a publication or web resource describing the source data, e.g. a data dictionary. | string |
| Source release date | owl:DatatypeProperty | For Cdm Source: The date the data was extracted from the source system. In some systems that is the same as the date the ETL was run. Typically the latest even date in the source is on the source_release_date. | date |
| Vocabulary version | owl:DatatypeProperty | For Cdm Source: Version of the OMOP standardised vocabularies loaded You can find the version of your Vocabulary using the query: `SELECT vocabulary_version from vocabulary where vocabulary_id = 'None'` | string |
| Has cdm version concept | owl:FunctionalProperty | For Cdm Source: The Concept Id representing the version of the CDM. You can find all concepts that represent the CDM versions using the query: `SELECT * FROM CONCEPT WHERE VOCABULARY_ID = 'CDM' AND CONCEPT_CLASS = 'CDM'` | Concept |
| From class OMOP CDM thing | |||
| Id | owl:DatatypeProperty | For Cohort Definition: This is the identifier given to the cohort, usually by the ATLAS application - For Procedure Occurrence: The unique key given to a procedure record for a person. Refer to the ETL for how duplicate procedures during the same visit were handled. Each instance of a procedure occurrence in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same procedure within the same visit. It is valid to keep these duplicates and assign them individual, unique, PROCEDURE_OCCURRENCE_IDs, though it is up to the ETL how they should be handled. - For Vocabulary: A unique identifier for each Vocabulary, such as ICD9CM, SNOMED, Visit. - For Device Exposure: The unique key given to records a person's exposure to a foreign physical object or instrument. Each instance of an exposure to a foreign object or device present in the source data should be assigned this unique key. - For Condition Occurrence: The unique key given to a condition record for a person. Refer to the ETL for how duplicate conditions during the same visit were handled. Each instance of a condition present in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same condition within the same visit. It is valid to keep these duplicates and assign them individual, unique, CONDITION_OCCURRENCE_IDs, though it is up to the ETL how they should be handled. - For Note Nlp: A unique identifier for the NLP record. - For Payer Plan Period: A unique identifier for each unique combination of a Person, Payer, Plan, and Period of time. - For Visit Detail: 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 detail. 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. - For Visit Occurrence: 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. - For Concept Class: A unique key for each class. - For Measurement: The unique key given to a Measurement record for a Person. Refer to the ETL for how duplicate Measurements during the same Visit were handled. Each instance of a measurement present in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same measurement within the same visit. It is valid to keep these duplicates and assign them individual, unique, MEASUREMENT_IDs, though it is up to the ETL how they should be handled. - For Observation: The unique key given to an Observation record for a Person. Refer to the ETL for how duplicate Observations during the same Visit were handled. Each instance of an observation present in the source data should be assigned this unique key. - For Concept: A unique identifier for each Concept across all domains. - For Specimen: Unique identifier for each specimen. - For Domain: A unique key for each domain. - For Provider: It is assumed that every provider with a different unique identifier is in fact a different person and should be treated independently. This identifier can be the original id from the source data provided it is an integer, otherwise it can be an autogenerated number. - For Observation Period: A Person can have multiple discrete Observation Periods which are identified by the Observation_Period_Id. Assign a unique observation_period_id to each discrete Observation Period for a Person. - For Note: A unique identifier for each note. - For Location: The unique key given to a unique Location. Each instance of a Location in the source data should be assigned this unique key. - For Metadata: The unique key given to a Metadata record. Attribute value is auto-generated - For Relationship: The type of relationship captured by the relationship record. - For Care Site: Assign an ID to each combination of a location and nature of the site - the latter could be the Place of Service, name or another characteristic in your source data. - For Person: It is assumed that every person with a different unique identifier is in fact a different person and should be treated independently. Any person linkage that needs to occur to uniquely identify Persons ought to be done prior to writing this table. This identifier can be the original id from the source data provided if it is an integer, otherwise it can be an autogenerated number. - For Drug Exposure: The unique key given to records of drug dispensings or administrations for a person. Refer to the ETL for how duplicate drugs during the same visit were handled. Each instance of a drug dispensing or administration present in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same drug within the same visit. It is valid to keep these duplicates and assign them individual, unique, DRUG_EXPOSURE_IDs, though it is up to the ETL how they should be handled. | owl:Thing |
| From class Thing | |||
| OMOP CDM name | owl:AnnotationProperty | owl:Thing | |
@prefix omop: <https://w3id.org/omop/ontology/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
omop:CdmSource a owl:Class ;
rdfs:label "Cdm source"^^xsd:string ;
rdfs:comment "The CDM_SOURCE table contains detail about the source database and the process used to transform the data into the OMOP Common Data Model."@en ;
rdfs:subClassOf [ a owl:Restriction ;
owl:onProperty omop:cdm_holder ;
owl:someValuesFrom xsd:string ],
[ a owl:Restriction ;
owl:onProperty omop:abbreviation ;
owl:someValuesFrom xsd:string ],
[ a owl:Restriction ;
owl:allValuesFrom xsd:string ;
owl:onProperty omop:source_documentation_reference ],
[ a owl:Restriction ;
owl:allValuesFrom omop:Concept ;
owl:onProperty omop:has_cdm_version_concept ],
[ a owl:Restriction ;
owl:allValuesFrom xsd:string ;
owl:onProperty omop:abbreviation ],
[ a owl:Restriction ;
owl:onProperty omop:name ;
owl:someValuesFrom xsd:string ],
[ a owl:Restriction ;
owl:onProperty omop:source_release_date ;
owl:someValuesFrom xsd:date ],
[ a owl:Restriction ;
owl:onProperty omop:vocabulary_version ;
owl:someValuesFrom xsd:string ],
[ a owl:Restriction ;
owl:onProperty omop:cdm_release_date ;
owl:someValuesFrom xsd:date ],
[ a owl:Restriction ;
owl:allValuesFrom xsd:date ;
owl:onProperty omop:cdm_release_date ],
[ a owl:Restriction ;
owl:allValuesFrom xsd:string ;
owl:onProperty omop:vocabulary_version ],
[ a owl:Restriction ;
owl:allValuesFrom xsd:string ;
owl:onProperty omop:source_description ],
[ a owl:Restriction ;
owl:allValuesFrom xsd:string ;
owl:onProperty omop:cdm_etl_reference ],
[ a owl:Restriction ;
owl:onProperty omop:has_cdm_version_concept ;
owl:someValuesFrom omop:Concept ],
[ a owl:Restriction ;
owl:allValuesFrom xsd:string ;
owl:onProperty omop:cdm_holder ],
[ a owl:Restriction ;
owl:allValuesFrom xsd:string ;
owl:onProperty omop:name ],
[ a owl:Restriction ;
owl:allValuesFrom xsd:date ;
owl:onProperty omop:source_release_date ],
[ a owl:Restriction ;
owl:allValuesFrom xsd:string ;
owl:onProperty omop:cdm_version ],
omop:OmopCDMThing ;
omop:omop_cdm_name "cdm_source"^^xsd:string .