1 of 30

OMOP Standardized Vocabularies. Part 1

Polina Talapova, MD, PhD

OMOP CDM Consultant

Tufts Clinical and Translational Science Institute (CTSI)

1

Health Informatics Elective

Discovering Digital Health Standards

4 August 2023

2 of 30

Content

Overview
Building the Standardized Vocabularies
Access to the Standardized Vocabularies
Source of Vocabularies: Adopt Versus Build
Vocabulary Building-Blocks
Vocabulary Lifecycle

In the next presentation:

Relationships
Hierarchy
Comparing Domain-Centric and Use-Case-Centric Logic in Mappings
Homework :)

2

3 of 30

Overview: Digital Health Data Standards

Data Format Standards: HL7 (FHIR, CDA, CCDA), DICOM, OMOP CDM
Terminology Standards: OMOP Vocabulary, SNOMED CT, LOINC, ICDs
Data Exchange Standards: HL7 FHIR, DICOM, IHE, SOAP, REST

3

4 of 30

Overview: OMOP

The Observational Medical Outcomes Partnership (OMOP) is a multi-stakeholder consortium initiated to develop and promote a common data model for observational studies.
OMOP CDM is a widely adopted standardized data model which transforms data from disparate healthcare systems into a common format (data structure and standard vocabularies).
The OMOP CDM is maintained by the Observational Health Data Sciences and Informatics (OHDSI) network.
OMOP Standardized Vocabularies (OMOP Vocabulary) is a set of standardized vocabularies to capture health-related concepts.

4

5 of 30

Overview: OMOP

5

6 of 30

Overview: OMOP Standardized Vocabularies

Open unified repository of terminologies, ontologies and coding systems used in digital health
Foundational part of OHDSI research network and OMOP CDM
Enables standardization of each element of a study
Addresses challenges in interpreting diverse clinical event descriptions
Shares principles, components, rules, and conventions
Needs community support for continuous improvement

6

7 of 30

Overview: OMOP Standardized Vocabularies

7

https://ohdsi.github.io/CommonDataModel/cdm54.html#Vocabulary_Tables

They are the interconnected tables within a relational database

8 of 30

Building the Standardized Vocabularies

All vocabularies consolidated into a common format

Vocabulary Development Process

GitHub Vocabulary-v5.0

Key vocabularies are maintained by OHDSI Vocabulary Team

Community contribution encouraged for reporting mistakes and improvement

Feedback channels:

OHDSI Forums

OHDSI GitHub Issue page

8

9 of 30

Access to the Standardized Vocabularies

Go to ATHENA https://athena.ohdsi.org/search-terms/start
ATHENA offers search for easy navigation through the Vocabularies
Define what you need and download the latest version of the vocabularies as a zip file and load it into your local database
Proprietary vocabularies require a license for access
The OHDSI Vocabulary Team can assist in obtaining the necessary license

9

10 of 30

Download Vocabularies with Python

10

Sequence	Step in Code	Library	Element
1	Establishing a connection with a PostgreSQL database.	sqlalchemy	create_engine
2	Creating a base class for declarative class definitions and setting up a metadata object with a specified schema	sqlalchemy	MetaData, declarative_base
3	Opening and reading SQL files (DDL, constraints), generating a list of CSV files in a directory	pathlib	Path
4	Reading a table from a database, reading CSV files.	pandas	read_sql_table, read_csv
5	Defining a generic TypeVar and Iterable for handling a sequence of DataFrames	typing	TypeVar, Iterable
6	Setting CSV reading options	csv	QUOTE_NONE
7	Inserting data into tables	pandas	to_sql
8	Accessing command-line arguments to get the directory of CSV files.	sys	argv

11 of 30

Source of Vocabularies: Adopt Versus Build

OHDSI prefers adopting existing vocabularies over de-novo construction. Reasons:

Utilization in observational data within the community
Complexity and long-term input required for vocabulary construction and maintenance

If needed, the community produces and maintain supplemental vocabularies:

Type Concepts for administrative purpose
RxNorm Extension - to cover drugs used on market outside the United States in study)
OMOP Extension - to broaden the list of standard concepts across various domains

11

12 of 30

Vocabulary Building-Blocks (1)

12

Name	Definition
Concepts	Elements that define medical entities or observations
Concept IDs	Unique identifiers assigned to Concepts across the OMOP CDM
Concept Names	User-friendly names associated with Concepts
Domains	Categorization of Concepts in specific areas (Drug, Condition, Measurement, Procedure, Device, etc.)
Vocabularies	Collections of Concepts categorized by a source
Concept Classes	Grouping of Concepts based on shared attributes and/or domain sub-categories (ATC 5th, Clinical Finding, Observable Entity, Lab Test)
Standardness	Identifies whether a concept is of non-standard, standard or classification type
Concept codes	Unique identifiers representing Concepts within a source data or terminology
Validity	Shows whether a concept or its relationship is active or deprecated or updated

13 of 30

Vocabulary Building-Blocks (2)

13

https://athena.ohdsi.org/search-terms/terms/313217

14 of 30

Vocabulary Building-Blocks (3)

14

Category	Thoughts
Concepts	Everything can be a concept
Concept IDs	There is no concept ID duplicates in OMOP Standardized Vocabularies
Concept Names	Names of concepts can be not so friendly as stated, sometime they have hidden senses which can be revealed only when looking at the synonyms list
Domains	Some concepts have controversial domains
Vocabularies	Vocabularies contain standard and non-standard concepts in different extent
Concept Classes	Some concepts have controversial classes
Standardness	In ideal world, each non-standard concept has its standard equivalent
Concept codes	Concept codes can intersect with each other if not considering vocabulary
Validity	Some deprecated concepts or their relationships may not have replacement mapping

15 of 30

Concepts

All clinical events in OMOP CDM are expressed as concepts, representing the semantic notion of each event.
Concepts serve as fundamental building blocks for data records, leading to highly normalized tables
CONCEPT table stores these concepts.
OMOP CDM encompasses concepts relevant to the patient's healthcare experience (conditions, procedures, drug exposures, etc.).
Administrative information of the healthcare system is also included (visits, care sites, etc.).

15

16 of 30

Concept Names

Names are imported from the source vocabulary.
Each concept has one preferable name, always in English.
Names in other languages are stored in the CONCEPT_SYNONYM table.
If the source vocabulary has multiple names for a concept, the most expressive one is selected, and others are stored in the CONCEPT_SYNONYM table under the same CONCEPT_ID key.

16

17 of 30

Standard Concept

The standard_concept field is an integral part of the OMOP Vocabulary to define concept status (Standard/Classification/Non-standard).
It resides within the CONCEPT table and contains such values as ‘S’, ‘C’, NULL respectively
Every record in event tables should ideally be mapped to a standard concept.

17

18 of 30

Domains

Each concept is assigned a domain in the DOMAIN_ID field.
Domain IDs are short case-sensitive unique alphanumeric identifiers representing the concept's semantic domain.
Examples of domain identifiers include "Condition," "Drug," "Procedure," "Visit," "Device," "Specimen," etc.
Domains group and direct the recording of clinical events or event attributes to specific CDM tables and fields.
Ambiguous or pre-coordinated concepts can belong to a combination of domains.
Standard Concepts are always assigned a singular domain.

18

19 of 30

Measurement Domain

Contains records of structured measurements represented by numerical or categorical values.
Terms related to measurements are obtained through standardized testing or examination of a person or person's sample.
Types of Measurements:

Laboratory tests/procedures
Vital signs
Pathology reports with quantitative findings
Assessment instruments such as staging, scales, and scores (but not all of them)
Observable entities with information about a quality or property to be observed (but not all of them)
Some Clinical Findings with qualitative results of testing

19

20 of 30

Procedure Domain

Contains records of activities or processes ordered by/carried out by a healthcare provider on the patient with a diagnostic or therapeutic purpose.
Examples of procedures: surgical interventions, diagnostic tests and imaging, therapeutic procedures
Measurement vs. Procedure

Measurement deals with quantities, sizes, weights, distances, or capacities of a substance compared to a designated standard.
A genuine Procedure does not specify a result

20

21 of 30

Observation Domain

Captures clinical facts about a person obtained in the context of examination, questioning or a procedure.
Any data that cannot be represented by any other domains, such as social and lifestyle facts, medical history, family history, etc. are recorded here.

21

22 of 30

Drug Domain

Captures records related to the utilization of a Drug when ingested or otherwise introduced into the body.
A Drug, in this context, refers to a biochemical substance formulated to exert a specific physiological or biochemical effect when administered to a person.
Drug concepts are used to record instances when a person takes or is exposed to a Drug for medical purposes.
Drug exposure records encompass various drug forms, such as oral medications, injections, topical applications, etc.
The administration routes may include oral, intravenous, intramuscular, and others.

22

23 of 30

Condition Domain

Comprises records of a person indicating the possible presence of a disease or medical condition, expressed as a diagnosis, sign, or symptom.
Conditions can be observed by a healthcare provider or reported by the patient, encompassing a range of states from mere symptom observation to fully established diagnoses.

23

24 of 30

Device Domain

Captures information about a person’s exposure to a foreign physical object or instrument which is used for diagnostic or therapeutic purposes through a mechanism beyond chemical action.
Devices include implantable objects (e.g. pacemakers, stents, artificial joints), medical equipment and supplies (e.g. bandages, crutches, syringes), other instruments used in medical procedures (e.g. sutures, defibrillators) and material used in clinical care (e.g. adhesives, body material, dental material, surgical material).

24

25 of 30

Domains and CDM Event Tables

25

Domain	Event table to populate
Measurement	Measurement
Observation	Observation
Procedure	Procedure_Occurrence
Condition	Condition_Occurrence
Drug	Drug_Exposure
Device	Device_Exposure

26 of 30

Uncertainties in Domain Assignment

The assignment of concepts to specific domains can sometimes be controversial due to a few reasons:

The interpretation of clinical data can vary between healthcare providers and researchers.
Health care data can be quite complex, and many concepts have applications across multiple domains.
As our understanding of medicine evolves, the classification of concepts can change.
The structure and semantics of source data may vary considerably.
Some concepts are broad and can span multiple domains.

26

27 of 30

Uncertainties in Domain Assignment

Examples:

Certain substances with therapeutic effects, often categorized as 'drugs,' can fall under the 'Device' or 'Observation' domains in some instances.
Some procedures, such as CPT4 or HCPCS codes, may sometimes be classified within the 'Measurement' domain.

What to Do:

If you believe that a concept has been inaccurately assigned to a domain, you have the option to make changes directly in your instance of the OMOP CDM.
Also you are encouraged to submit a domain change using Community Contribution Template #7. The process for submitting these changes is described here.

27

28 of 30

Concept Classes

Categorize concepts in a different way at the vocabulary level via the CONCEPT_CLASS_ID field
Some vocabularies classify their codes or concepts using case-sensitive unique alphanumeric codes
Vocabularies have concept classes that classify horizontal and/or vertical levels in their stratified hierarchies.

In the vertical model, concept class members can belong to any hierarchical level from the top to the bottom (SNOMED, MedDRA).
In the horizontal model, concept classes determine a specific hierarchical level (ICDs, ATC, MedDRA).
In mixed model, concept classes do both (CPT4, LOINC)

28

29 of 30

Concept Lifecycle: INVALID REASON

Vocabularies are dynamic and not permanently fixed
Concepts are added and deprecated over time
OMOP CDM supports longitudinal patient data, requiring concepts from the past and new ones
invalid_reason field provides context about the lifecycle of a concept, capturing the reason why a specific concept is no longer considered valid or active:

‘D’ (deprecated with no successor): the concept has been deprecated without replacement.
‘U’ (updated with successor): the concept has been replaced with a more recent or accurate one.
NULL: The concept is currently valid (not a blank string!)

29

30 of 30

Questions?

30