https://w3id.org/omop/ontology/source_value
For Observation: This field houses the verbatim value from the source data representing the Observation that occurred. For example, this could be an ICD10 or Read code.
This code is mapped to a Standard Concept in the Standardized Vocabularies and the original code is stored here for reference. - For Note: The source value mapped to the NOTE_CLASS_CONCEPT_ID. - For Device Exposure: This field houses the verbatim value from the source data representing the device exposure that occurred. For example, this could be an NDC or Gemscript code.
This code is mapped to a Standard Device Concept in the Standardized Vocabularies and the original code is stored here for reference. - For Visit Detail: This field houses the verbatim value from the source data representing the kind of visit detail that took place (inpatient, outpatient, emergency, etc.)
If there is information about the kind of visit detail in the source data that value should be stored here. If a visit is an amalgamation of visits from the source then use a hierarchy to choose the VISIT_DETAIL_SOURCE_VALUE, such as IP -> ER-> OP. This should line up with the logic chosen to determine how visits are created. - For Location: Put the verbatim value for the location here, as it shows up in the source. - For Cost: The source value for the cost as it appears in the source data - For Visit Occurrence: This field houses the verbatim value from the source data representing the kind of visit that took place (inpatient, outpatient, emergency, etc.)
If there is information about the kind of visit in the source data that value should be stored here. If a visit is an amalgamation of visits from the source then use a hierarchy to choose the visit source value, such as IP -> ER-> OP. This should line up with the logic chosen to determine how visits are created. - For Measurement: This field houses the verbatim value from the source data representing the Measurement that occurred. For example, this could be an ICD10 or Read code.
This code is mapped to a Standard Measurement Concept in the Standardized Vocabularies and the original code is stored here for reference. - For Condition Occurrence: This field houses the verbatim value from the source data representing the condition that occurred. For example, this could be an ICD10 or Read code.
This code is mapped to a Standard Condition Concept in the Standardized Vocabularies and the original code is stored here for reference. - For Care Site: The identifier of the care_site as it appears in the source data. This could be an identifier separate from the name of the care_site. - For Drug Exposure: This field houses the verbatim value from the source data representing the drug exposure that occurred. For example, this could be an NDC or Gemscript code.
This code is mapped to a Standard Drug Concept in the Standardized Vocabularies and the original code is stored here for reference. - For Person: Use this field to link back to persons in the source data. This is typically used for error checking of ETL logic.
Some use cases require the ability to link back to persons in the source data. This field allows for the storing of the person value as it appears in the source. This field is not required but strongly recommended. - For Provider: Use this field to link back to providers in the source data. This is typically used for error checking of ETL logic.
Some use cases require the ability to link back to providers in the source data. This field allows for the storing of the provider identifier as it appears in the source. - For Procedure Occurrence: This field houses the verbatim value from the source data representing the procedure that occurred. For example, this could be an CPT4 or OPCS4 code.
Use this value to look up the source concept id and then map the source concept id to a standard concept id.
DOMAIN | PROPERTY | RANGE |
---|---|---|
Blank node (see implementation) | Source value | string |
@prefix omop: <https://w3id.org/omop/ontology/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
omop:source_value a owl:DatatypeProperty,
owl:FunctionalProperty ;
rdfs:label "Source value"^^xsd:string ;
rdfs:comment "For Care Site: The identifier of the care_site as it appears in the source data. This could be an identifier separate from the name of the care_site."@en,
"""For Condition Occurrence: This field houses the verbatim value from the source data representing the condition that occurred. For example, this could be an ICD10 or Read code.
This code is mapped to a Standard Condition Concept in the Standardized Vocabularies and the original code is stored here for reference."""@en,
"For Cost: The source value for the cost as it appears in the source data"@en,
"""For Device Exposure: This field houses the verbatim value from the source data representing the device exposure that occurred. For example, this could be an NDC or Gemscript code.
This code is mapped to a Standard Device Concept in the Standardized Vocabularies and the original code is stored here for reference."""@en,
"""For Drug Exposure: This field houses the verbatim value from the source data representing the drug exposure that occurred. For example, this could be an NDC or Gemscript code.
This code is mapped to a Standard Drug Concept in the Standardized Vocabularies and the original code is stored here for reference."""@en,
"For Location: Put the verbatim value for the location here, as it shows up in the source."@en,
"""For Measurement: This field houses the verbatim value from the source data representing the Measurement that occurred. For example, this could be an ICD10 or Read code.
This code is mapped to a Standard Measurement Concept in the Standardized Vocabularies and the original code is stored here for reference."""@en,
"For Note: The source value mapped to the NOTE_CLASS_CONCEPT_ID."@en,
"""For Observation: This field houses the verbatim value from the source data representing the Observation that occurred. For example, this could be an ICD10 or Read code.
This code is mapped to a Standard Concept in the Standardized Vocabularies and the original code is stored here for reference."""@en,
"""For Person: Use this field to link back to persons in the source data. This is typically used for error checking of ETL logic.
Some use cases require the ability to link back to persons in the source data. This field allows for the storing of the person value as it appears in the source. This field is not required but strongly recommended."""@en,
"""For Procedure Occurrence: This field houses the verbatim value from the source data representing the procedure that occurred. For example, this could be an CPT4 or OPCS4 code.
Use this value to look up the source concept id and then map the source concept id to a standard concept id."""@en,
"""For Provider: Use this field to link back to providers in the source data. This is typically used for error checking of ETL logic.
Some use cases require the ability to link back to providers in the source data. This field allows for the storing of the provider identifier as it appears in the source."""@en,
"""For Visit Detail: This field houses the verbatim value from the source data representing the kind of visit detail that took place (inpatient, outpatient, emergency, etc.)
If there is information about the kind of visit detail in the source data that value should be stored here. If a visit is an amalgamation of visits from the source then use a hierarchy to choose the VISIT_DETAIL_SOURCE_VALUE, such as IP -> ER-> OP. This should line up with the logic chosen to determine how visits are created."""@en,
"""For Visit Occurrence: This field houses the verbatim value from the source data representing the kind of visit that took place (inpatient, outpatient, emergency, etc.)
If there is information about the kind of visit in the source data that value should be stored here. If a visit is an amalgamation of visits from the source then use a hierarchy to choose the visit source value, such as IP -> ER-> OP. This should line up with the logic chosen to determine how visits are created."""@en ;
rdfs:domain [ a owl:Class ;
owl:unionOf ( omop:CareSite omop:ProcedureOccurrence omop:BaseVisit omop:BasePerson omop:Specimen omop:ConditionOccurrence omop:Cost omop:Location omop:Exposure omop:Measurement omop:Note omop:Observation ) ] ;
rdfs:range xsd:string ;
omop:omop_cdm_name "care_site.care_site_source_value#271 AS str"^^xsd:string,
"condition_occurrence.condition_source_value#74 AS str"^^xsd:string,
"cost.cost_source_value#314 AS str"^^xsd:string,
"device_exposure.device_source_value#127 AS str"^^xsd:string,
"drug_exposure.drug_source_value#96 AS str"^^xsd:string,
"location.location_source_value#258 AS str"^^xsd:string,
"measurement.measurement_source_value#145 AS str"^^xsd:string,
"note.note_source_value#192 AS str"^^xsd:string,
"observation.observation_source_value#163 AS str"^^xsd:string,
"person.person_source_value#13 AS str"^^xsd:string,
"procedure_occurrence.procedure_source_value#111 AS str"^^xsd:string,
"provider.provider_source_value#281 AS str"^^xsd:string,
"specimen.specimen_source_value#218 AS str"^^xsd:string,
"visit_detail.visit_detail_source_value#52 AS str"^^xsd:string,
"visit_occurrence.visit_source_value#35 AS str"^^xsd:string .