Repository navigation
Medical Imaging Extension Conventions
📖If you are new to the MI-CDM or OMOP medical imaging, we strongly recommend reading the Book of OHDSI chapter on Medical Imaging first.
The flowchart below provides a step-by-step guide for implementing the MI-CDM. Follow the workflow and answer each question to determine the appropriate implementation path for your institution.
For additional details and recommendations, refer to the corresponding numbered sections referenced in the flowchart.
Have a question? Post questions or issues to forums.ohdsi.org with the tag #imaging and we will get right back to you!
Note that results from radiology or other imaging reports are organized through the OMOP NLP_note table. (see FAQ) Conversely, DICOM Structured Report (SR) objects would be included in the methodology below.
Please refer to the Common Data Model Workgroup to initialize the OMOP CDM: https://github.com/OHDSI/CommonDataModel.
CREATE TABLE dbo.image_occurrence(
image_occurrence_id integer NOT NULL,
person_id integer NOT NULL,
procedure_occurrence_id integer NOT NULL,
visit_occurrence_id integer,
anatomic_site_concept_id integer,
wadors_uri varchar(10000),
local_path varchar(10000),
image_occurrence_date date NOT NULL,
image_study_uid varchar(10000) NOT NULL,
image_series_uid varchar(10000) NOT NULL,
modality_concept_id integer NOT NULL
);
CREATE TABLE dbo.image_feature(
image_feature_id integer NOT NULL,
person_id integer NOT NULL,
image_occurrence_id integer NOT NULL,
image_feature_event_field_concept_id integer,
image_feature_event_id integer,
image_feature_concept_id integer NOT NULL,
image_feature_type_concept_id integer NOT NULL,
image_finding_concept_id integer,
image_finding_id integer,
anatomic_site_concept_id integer,
alg_system varchar(10000),
alg_datetime timestamp
);
3: Add DICOM vocabulary as OMOP concepts <Standard concepts v. custom concepts - where are we now regarding vocab integration? - Jen>
Implementation approaches vary across institutions. The primary goal is to extract DICOM header metadata without disrupting clinical operations. Before extraction, assess the expected storage and computational requirements, particularly when working with large imaging archives.
Although DICOM image files can be large, the MI-CDM imaging extension requires only DICOM metadata and not the pixel data itself. Therefore, extracting headers separately from image pixels can substantially reduce storage and processing demands.
Another critical consideration is establishing a reliable linkage between DICOM data and the corresponding procedure or procedure order in the clinical data warehouse. Plan the de-identification workflow carefully, as de-identifying DICOM files before linkage may remove the identifiers required to connect imaging data with clinical records in the research database.
More details regarding accessing DICOM headers are here. <Author: Blake to write: code/process/architecture; also include - How would you keep current? - Performance throttling needed for migration off of Production PACS systems. Throughput concerns the overall system. )
DICOM metadata contains both standard (public) attributes and manufacturer-specific private attributes. The MI-CDM DICOM Concepts vocabulary currently includes standard DICOM attributes and values defined by the DICOM standard. Private attributes are not included because their definitions vary across manufacturers and implementations.
If your institution or research community relies on private attributes, we recommend creating custom concepts and mappings to incorporate them into your local implementation. Examples may include manufacturer-specific acquisition parameters, reconstruction settings, or other metadata not represented in the DICOM standard.
The proposed attribute list is intended to capture metadata that are commonly used for observational research, imaging phenotyping, cohort discovery, and data quality assessment. Because DICOM files contain thousands of potential attributes, loading every available attribute may increase storage and processing requirements without providing meaningful research value.
We encourage implementers to review the proposed attribute list and identify any frequently requested attributes that are missing. Feedback from the community will help refine future versions of the vocabulary and recommended attribute sets. Current proposed attribute lists are available for MR, CT, and mammography (MG) imaging modalities.
More details regarding proposed high value DICOM attributes are here.
The MI-CDM ETL process integrates DICOM imaging metadata with an existing OMOP CDM while preserving connections between the imaging data and their clinical context. DICOM metadata are extracted from imaging files or another structured source, linked to the corresponding OMOP PERSON and PROCEDURE_OCCURRENCE records, and transformed into MI-CDM. Core series-level information, including imaging date, modality, anatomical site, Study and Series Instance UIDs, and file location, is stored in IMAGE_OCCURRENCE. Additional DICOM attributes, such as acquisition parameters, are represented in the OMOP MEASUREMENT table using DICOM concepts and linked back to the source IMAGE_OCCURRENCE record to maintain provenance.
More details regarding DICOM Acquisition Attribute ETL Conventions are here.
When image-derived findings or quantitative features are available, they are represented using the IMAGE_FEATURE and MEASUREMENT tables. Examples include outputs from image analysis algorithms, artificial intelligence models, segmentation results, radiomics features, and DICOM Structured Reports (SR). IMAGE_FEATURE describes the imaging finding, its visual characteristics, anatomical location, and provenance, while quantitative or coded results are stored in MEASUREMENT. These records remain linked to the source imaging series, enabling imaging metadata and derived features to be queried alongside standardized clinical data within OMOP. The following conventions provide guidance for preparing the required tables and vocabularies and for loading imaging-derived results into MI-CDM.
Features extracted from radiology reports are not considered image-derived features. Instead, they should be represented using the OMOP NOTE and NOTE_NLP tables and linked to the corresponding Image_occurrence record when appropriate.
Before loading image-derived features, the source imaging series should already be represented in the Image_occurrence table. This linkage is essential for maintaining provenance and documenting the origin of each derived feature.
By linking records in Image_feature to Image_occurrence, researchers can determine which image was used to generate a feature, measurement, or algorithm result. This provenance information supports reproducibility, validation, and downstream analysis.
Image-derived features should be represented using standardized concepts from existing OMOP vocabularies. Standardized concepts improve interoperability, enable consistent analysis across institutions, and support federated research.
Depending on the feature, appropriate vocabularies may include LOINC, SNOMED CT, DICOM, or other OMOP-supported terminologies. Future versions of MI-CDM are expected to incorporate concepts from the Radiology Lexicon (RadLex) to better support radiology-specific findings and imaging phenotypes.
If a suitable standardized concept is not available, define a custom concept as described in Section 11.
This section is coming soon. Image features (e.g., tumor volume or spiculation) are represented by other ontologies, most notably RSNA/ACR RadLex. In research, agentic AI algorithms will be able to add image features to these OMOP MI CDM tables. In clinical practice, we will get to the point where confirmed image features will also be able to be added to the OMOP MI CDM tables, with different provenance, obviously.
- considerations for specific anatomical sites - considerations for radiomics standards/vocabularyMore details regarding ETL Conventions for Image Features is here.
When a required imaging feature, finding, or algorithm output cannot be represented using an existing standardized concept, implementers may create custom concepts following OMOP CDM conventions.
OHDSI recommends assigning custom concept identifiers within the 2-billion range to avoid conflicts with concepts distributed through the standard OMOP vocabularies. Custom concepts should be clearly documented and maintained locally to support reproducibility and future vocabulary harmonization efforts.
Have a question? Post questions or issues to forums.ohdsi.org with the tag #imaging and we will get right back to you!