OHDSI Home | Forums | Wiki | Github

Genomic Data in the CDM

CDM Builders
#35

Just came across this:

#36

Sorry for the late release because of API validation.
Releases common data model extensions and APIs created by AMC.
The link is as follows.
Genomic Common data model: https://github.com/yrpark/GenomicCommonDataModel
API: https://github.com/yrpark/GenomicWebAPI
I was not registered as a collaborator on OHDSI Github, so I first posted it on the public Github.

Please feel free to send us any comments or improvements on the Genomic CDM and API.

#37

I’d like to join!

#38

a more precise link would be: https://github.com/yrpark/GenomicCommonDataModel/blob/cc274d0de0419050843c1478a3c9fb2ca44d5854/PostgreSQL/OMOP%20CDM%20ddl%20-%20PostgreSQL.sql#L702

#39

I am interested in this work, Please sign me up.

#40

Hi Clair, I’d like to join.
Thanks.

Concept ids for proteomics, lipidomics and other x-omics measurements
#41

Hi folks,
I am Eran from Boston and have been in the immunology and cancer drug discovery space for the past 12 years. I am not a bioinformatician and know very little about relational data bases, though I promise to learn. What I can bring to the table is the cancer researcher perspective and experience. I’d like to thank @Christian_Reich for inviting me to this free global community. Many thanks to all those partaking in the Genomics WG dialogue: Your posts were VERY helpful for me to educate myself and understand what are the main issues and the decisions to be made in these early days. So here is my two cents.

Type of Genetic data
1. Base alterations detected by WGS, WES and real-time PCR:

  • Straightforward description of a variant with a single base up to a
    few bases alteration (change, addition, deletion). Cf. ‘Measurement
    table’ in slide #7 of presentation 2 by David Fasel.
  • Need to decide how to handle long insertions, deletions, inversions
    as well as multi-variant genes (e.g. Ig, MHC). I think this can be
    done consistently.
  • Unlike other disease cancer is different because it’s mostly about
    somatic mutations. In this case it’s important to know the date of
    the biopsy from which genetic information was derived. Chronological alignment with treatment allows queries regarding interplay between therapy, mutation and outcome.
  • Nomenclature: Consistent, systematic, broad and accommodating
    expansion.

2. Gene amplification detected by CGH arrays, NGS, qPCR, FISH, WGS:

  • Concept: Gene name, ID, chromosome start/end
  • Measure: Copy number
  • Value: e.g. 4, ≥6

3. Cytogenetics/ Karyotype, chromosomal aberrations:

4. Gene expression arrays:

  • Compared with mutations and gene amplification these are not hard
    data.
  • Quality of data is affected by samples storage, handling and
    processing.
  • Data obtained using different platforms need to be normalized.
  • Large amounts of data and also tissue specific and may change with
    time.

5. DNA methylation analysis using arrays or bisulfite with NGS:

  • Quality of data might be affected by samples storage and handling.
  • Data obtained using different platforms need to be normalized.

Implementation
A. Build stepwise:

  • Start with ‘Base alterations’ then move to gene amplifications. Hard
    data, high value.
  • Inclusion of expression and methylation analysis could be discussed
    later.

B. Scope- which genetic data to store:
The question is intimately linked to the discussion of flexibility and operationality. One way to ensure efficient querying is to limit observations to variant with clinical interpretation. Another opinion voiced by Kyu Pyo Kim is that all variants should be stored, because variant are not always classified consistently and the scientific knowledge base is expanding. Ergo, additional clinically relevant variants will be discovered.
Let’s not limit OHDSI vision and include all variants. This way OHDSI could become a robust platform for discovery of new prognostic and predictive (i.e. patient stratification) biomarkers. If OHDSI exerts broad impact on human health and spur basic research into the biology of new biomarkers, wouldn’t it be something that we all celebrate?!
It follows that we need to think hard and creatively about the data base architecture/ organization that would support the ‘include all genetic variants’ goal without compromising functionality. As suggested we’ll also have to decide which annotations to include. If push comes to shove and despite best efforts the size of the data base interferes with functionality, we could limit the genetic data base to exome variants (plus promoter regions).

C. Structure of the data base:
As I said bio-computing and data bases are not my cup of tea and I am still educating myself about OMOP CDM. Please be forgiving if my input is flawed. The comparison of the several options in slide 6 of presentation 2 is insightful. Also Kyu Pyo Kim experimenting with a “rigid” and “simple enough” model that keeps the important information and handles large amount of data is instructive.

  • If we are to embrace all genetic variants we need to carefully
    control what information elements are included per variant. I like
    the notion of the essential components as suggested by Kyu Pyo Kim
    and shown in David Fasel’s slide 7 of presentation 2.
  • Annotations: To counteract data burden I tend to support a minimalist
    approach, which includes only data items that are required for
    friendly, effective and efficient querying. The first seven rows of
    the observation table in slide 7 of presentation 2 are an example. It’s up to the community to decide whether other attributes are required for effective querying- ‘population_freq’ (?), ‘interpretation’ (?). All other information could be included in external files if wished so. We should be open to the possibility of discarding certain information if it is deem unnecessary now and in the future.
  • I understand that there are several ways to organize genetic
    information depending on the model: Placing variants in measurement
    domain and annotation information in an observation table or in a
    genetic data table with a single row per variant. These were a few ideas.

Suggestion:
Treat each variant as a concept with its own ID. It would include the essential components (c.f. first bullet) and a link to the annotation.

  • Each variants is generic- a biopsy may have a certain genetic variant
    or not regardless of the genetic method used for detection.
  • Purpose and main advantage: To speed up queries.
  • The genetic observation table would consist of a list of IDs of all
    variants discovered. If a mutation in a certain gene is absent, it
    won’t be on the list. This answers the requirement by Seng Chan You.
  • Variants observed are linked (foreign key, right?) to the source
    specimen.
  • This requires strict quality check (filtering?) before entries are
    accepted into OHDSI CDM because there are no shades of gray- a
    variant is either present or not.
  • Method information (WGS, WES, rt-PCR) and other information
    pertaining to run such as quality could be included in an external
    file.
  • Vocabulary is expected to increase by 10^6 (more?) terms.
  • Option for hierarchical organization of mutations if found useful. As
    example is by chromosome# and position: 1-30,000,000;
    30,000,001-60,000,000; 60,000,001-90,000,000 etc.

So this is it for now.
@clairblacketer

1 Like
#42

I’d be interested in joining

#43

Not sure if this forum is still accepting new members. I have just joined OHDSI, and would like to be part of the CDM Genomics WG.

#44

@datnoor1:

All Working Groups, like any community activities in OHDSI are always open as a matter of principle. So, welcome to the family. You are in. :smile:

#45

Thank to help of @clairblacketer, we’ve made wiki page for genomic CDM WG.
In the wiki page, the pilot model for genomic CDM was posted and some issues or comments were also posted.

We’ve converted genomic data of NGS to this model from one hospital(Ajou university). We are trying to converted TCGA open dataset into this mode, too.

I develop a machine learning algorithm which combining clinical features from existing CDM and genomic features from G-CDM by using FeatureExtraction and PatientLevelPrediction package. The code will be soon released, too.

We’re now working on summarizing what we’ve discussed in this thread. Until now, we’ve just suggested the prototype for the great challenge to unify genomic data around the world.
We need your thorough reviews. I do appreciate everyone for their passionate participation and comments.

#46

I’d also be interested in participating here. Thanks.

1 Like
#47

I’d be interested in joining too!

#48

Is the Genomic CDM Subgroup still moving forward? We have interest at Northwestern in implementing the Genomic proposal extension.

#49

It takes time for us to develop standardized ontology system for functional and structural meanings of genetic variants.
We’re now trying to validate G-CDM by comparing Ajou university’s lung cancer mutation data and TCGA’s lung cancer mutation data. We’re building a kind of genetic analytic pipeline, based on OHDSI ecosystem so that researchers can easily analyze the genetic profiles between cohorts produced by ATLAS.

I apologize for my laziness. We’ll propose new version (not much changed from former version. We’ve focused on ontology system for representing variants) and the demo of our experiments within one or two weeks. I want to start G-CDM WG meeting again after that.

@mgurley , I am so interested to hear that! Please let me know if you need anything about this!

#50

An updated version of G-CDM was released in Google Drive.

There are Specification and Sample Data of G-CDM. You can also see TCGA (The Cancer Genome Atlas) Sample Data and how it can be transform to G-CDM (ETL specification).

In this version, we applied standardized ontology system for representing structural and functional meanings of genetic variants. Because of a discrepancy in vocabulary for variant between databases, it needed to mapping each data source value to concept name and id.

Using hierarchical ontology system of “Sequence Ontology”, different expression of variant type in each database unified to common vocabulary.

I would like to present and discuss with you in Genomic-CDM Working Group and Teleconference.

4 Likes
#51

Hi all,
thanks a lot for your effort to extend OMOP to adopt different data sources. Is this working group still active? It would be really interesting to evaluate further extensions to the OMOP CDM to accommodate genomics datasets.

#52

Sure!
We are working on developing the genomic-CDM (G-CDM) as an extension model of OMOP-CDM.
There was an Oncology+Genomic working group face to face meeting in in 2018 OHDSI Symposium (Bethesda).
Here is our Google drive link. You can see a specification and presentation materials about G-CDM which is on developing.
We are on tunning the schedule for the online meeting for the next steps.
Thank you for your interest!

1 Like
#53

Just went through Drive documents. I admit it is an ambitious goal to put genomic data to structured database model not only because of the data size, but also because of the non-standardized notation used for genomic data. However, there is still a strong need for a good database format for that.

We have just calculated pharmacogenomics recommendations for 44,000 biobank participants (https://www.nature.com/articles/s41436-018-0337-5) and I only wanted to highlight that information about genotype PHASING (are the genotypes of 2 SNPs phased) and IMPUTATION (was the genotype imputed, what was the value probability) are also very important pieces of information when you are dealing with genomic data.

1 Like
#54

Thank you for your information about “Phasing” and “Imputation” for dealing sequencing data.
I’ll review that issue and let G-CDM adopt those concepts in adequate position and method!
Thanks again :wink:

t