OHDSI Home | Forums | Wiki | Github

Medical image data in OMOP

Implementers
#1

In one of out projects, we will be storing a lot of data related to medical images. I’m having a hard time figuring out where and if this data fits into the OMOP schema. Specifically, we will need:

  1. a record representing the image capture event
  2. a record representing the image itself
  3. all the structured, unstructured and note data associated with the image

For #1, the closest match I could think of was device_exposure. Then I was thinking #2 would be an observation. Then #3 would include notes, measurements and observations all associated with #2 using the fact_relationship table. Any problems with that plan or any ideas for doing it better?

Also, related to that question - Is it ever appropriate to extend your implementation of the OMOP model with custom tables if you feel that some of your data doesn’t really fit? Or is that considered bad practice?

Thanks

#2

I am planning on doing very similar things with pathology exams. And imaging exams. My inclination for #1 would be procedure_occurrence (this would seem to be what standard procedure vocabularies dictate). #2 a custom table. #3 observation or measurement via fact_relationship to the procedure_occurrence. I would put the note interpreting the imaging exam or pathology exam in the note table. And maybe tying together the procedure_occurrence and the note via a shared reference to a visit_occurrence. Not sure if it is considered bad practice to extend the OMOP model with custom tables but this is what I am doing. Would love to hear other folks’ thoughts.

#3

A few issues: 1: the standard ohdsi tools won’t be able to read it (they don’t know they exist). 2: Any research question you answer won’t be runnable (unmodified) on another CDM in the network. 3. If you put those new tables in the same schema as the cdm, you risk having naming collisions later.

1 is pretty unavoidable. For 2, if you provide build scripts with your analysis to build the custom tables based on the core CDM tables, then someone could run the anlaysis on a different cdm, but there could be other considerations that make this impossible. For 3, keeping your custom tables in their own schema will prevent those naming collisions from happening. Don’t think of this as ‘extending the cdm tables’, but rather just adding auxiliary tables to support your one-off needs. You should absolutely avoid changing the table definitions of the cdm tables (such as making an INT field a varchar or renaming a column).

-Chris

1 Like
#4

Yes, I concur about leaving the core CDM tables untouched/unmodified. Because I find it simpler, I create my local non-CDM tables within the same schema but just namespace them by prepending them with my project’s name.

#5

Friends:

Why don’t you submit an extension proposal to the CDM WG? That’s what it is there for. You already got a ton of such proposals going.

Wrt to the content:

  1. Would be the MEASUREMENT table .However, the problem of that is the expectation that each Measurement record results in a single result (think HbA1C). If that doesn’t cut it you could think of an IMAGING table. But I would not put it into the PROCEDURE table, even thought it wouldn’t hurt: a procedure is a diagnostic or therapeutic activity on the human body (or mind). To stand in front of an x-ray machine is a procedure by that definition, but so is phlebotomy. I don’t think we need those.
  2. You want to put the DICOM into a database?
  3. What are they? We’d have to come up with a sleek model.

Leave the FACT_RELATIONSHIP table out of it. :slight_smile:

#6

  1. Yes, we want to store the location of the DICOM image in PACS. Though there’s probably no need for this to go in OMOP as it is only internally relevant.

  2. I will sit down with the docs and try to find out more about what data they plan to store.

I will look into submitting an extension proposal as well. My current feeling is that an image has a lot of the same characteristics as a SPECIMEN. It’s a product collected and stored from a patient, and then any number of measurements can be performed on it directly. I know measurements can be associated with a SPECIMEN using the FACT_RELATIONSHIP table. I think something similar would work well for images.

t