Storing note data from radiology, coronary angiography, and pathology report

[SCYou (Seng Chan You)]

I converted coronary angiography report into note table of OMOP-CDM ver 5.0.2.
I want to convert all reports from radiology and pathology into CDM, too.

But I’m wonder how I can set relationship between these notes with primary procedure or measurements or specimens.
(How can I know where the coronary angiography report comes from, when the patient has multiple coronary angiography in the same day? Current note table has visit_occurrence_id, so I can tag it. But I don’t find any room for procedure_id or measurement_id)

Is there any established logic for this issue? Or should we extend the note table further?

[Dymshyts (Dmytry Dymshyts)]

You can use fact_relationship table
https://github.com/OHDSI/CommonDataModel/wiki/FACT_RELATIONSHIP
where
domain_concept_id_1 = ‘Note’
fact_id_1 = Note.visit_occurrence_id
domain_concept_id_2 = ‘Measurement’ (if measurement)
fact_id_2 = Measurement.Measurement_concept_id
relationship_concept_id = ??? “Note of”

We don’t have this relationship currently.
@Christian_Reich, we need to think about new relationships adding process

[SCYou (Seng Chan You)]

Thank you, @Dymshyts
Your comment really helpful!

But I think we should think about extending note table for these relationships, too!

[Dymshyts (Dmytry Dymshyts)]

I agree, @SCYou.

It’s an obvious, when Note describes some other event (Procedure, Measurement, Condition or Drug exposure even),
so analogues of domain_concept_id_2 and fact_id_2 fields should be added

[Christian_Reich]

@SCYou, @Dymshyts:

Please submit to the CDM WG as a proposal for changing the NOTE table. It might be relegated to THEMIS as a FACT_RELATIONSHIP convention.

[mgurley (Michael Gurley)]

@SCYou @Dymshyts @Christian_Reich

I think we should move to making relationships more explicit. FACT_RELATIONSHIP is opaque. Perhaps follow the lead of how the COST table references other tables with a polymorphic pairing:

cost_event_id
cost_domain_id

note_event_id
note_domain_id

Having the NOTE table be able to to explicitly reference PROCEDURE_OCCURENCE is, I believe, especially important.

[SCYou (Seng Chan You)]

We can add reference system just as COST table does now. Thank you for very good comment, @mgurley !

@Christian_Reich Yes, I or we should submit a proposal for changing NOTE table to CDM WG.

[Dymshyts (Dmytry Dymshyts)]

Just wondering if any decision was made already or some WG-discussion started?

[SCYou (Seng Chan You)]

@Dymshyts, I don’t think so. I’m thinking of making proposal to add reference system just as COST table in Note table.
Do you have any other plan?

[MPhilofsky (Melanie Philofsky)]

Having the NOTE table be able to to explicitly reference PROCEDURE_OCCURENCE is, I believe, especially important.

I agree! We have EHR data and a LOT of “note” data that is present in most domains (procedures, specimens, measurements, observations, oncology, genomic, etc.). @Christian_Reich’s favorite table, Fact_Relationship, is one way to relate data in the Note table to other OMOP tables, but as @Dymshyts stated, the relationship_concept_ids aren’t representative of the relationships.

[Christian_Reich]

Looks like we need to overhaul the NOTE table.

[PriyaDesai (Priyamvada Desai)]

Should there be a place in the note table where you can also capture image accessing ids corresponding to a radiology report? We think it would be really useful to be able to pull out the notes associated with specific accession_ids and vice-versa.
@MPhilofsky @Christian_Reich @Paul_Nagy @SCYou @Dymshyts

[jmethot (John Methot)]

Please see this proposal by @rtmill on formalizing/extending the relationship concepts used in FACT_RELATIONSHIP to represent this type of relationship. There are many use cases like this.

Fact relationships: Searching for an extensible approach

Disclaimer: This post advocates for increased use of the FACT_RELATIONSHIP table and may not be suitable for all viewers. Problem: There is a growing list of disparate use cases that require persisting relationships between clinical events to which the existing foreign keys are insufficient. I view the overall goal simply as establishing a common convention. Not everyone will have this relational information explicitly in their data but for those that have use cases and wish to preserve it in …

[MPhilofsky (Melanie Philofsky)]

@PriyaDesai,

Are you asking about connecting two Note records to each other? If yes, John’s response above is the correct route.

However, if you’re asking about connecting the radiology report Note record to the actual image? Then the best way to link would be to add another column to your Note table to link to the outside image since the OMOP CDM doesn’t store the actual image. Since these data are not in the CDM, they won’t ever be used by others and this column won’t be part of the formal CDM. I presented a poster describing how/when to add additional columns to the CDM.

[jmethot (John Methot)]

Sorry, my reference to the FACT_RELATIONSHIP proposal was not aimed at the comment about image accession numbers. It was directed at the comment about connecting notes to procedures, measurements, observations, etc. As in “observation derived from (NLP on) note”.

[SCYou (Seng Chan You)]

In the Medical Imaging WG, we recommend to capture the radiology report in the DICOM, as DICOM SR (structured reporting).
Nonetheless, you can link the note table and other table (eg, procedure) by using note_event_id and note_event_field_concept_id: https://github.com/OHDSI/CommonDataModel/issues/172