What’s the most common approach for relating note/note_nlp rows to the extracted condition, procedure, etc.?
One would assume that fact_relationship could deal with that, but allowed codes seem to be lackluster.
Some tables have _event_id fields, but they are not widespread to all the model tables
Hi Diego!
These tables are not finally shaped - read here.
Recording a note in the note table doesn’t necessarily mean you extract the concepts. But even if you do, why would you need a record-level connection? You can flag such Conditions, Observations, etc. with a proper type_concept_id and include or exclude them from your study.
Note_event_id won’t help because in the majority of cases, you extract many concepts from a single note, but this field doesn’t allow one-to-many connections.
Note_nlp is better in a way that each record represents a single term, so you could have one-to-one connections, but the “_event_id” field is missing, right? You could also store the derived concepts right in the note_nlp_concept_id/note_nlp_source_concept_id fields or deliver them to the proper tables and use the fact_relationships. Here’s a discussion about it.
Unless we have clear and ratified conventions, folks may come up with their own ideas, implement them, validate them in the studies, and contribute back to OHDSI. This is how it usually works.
1 Like
I am in the “store NLP-extracted events in the event tables” camp. I missed it at the time, but I like the NOTE_NLP Proposal @Daniel_Smith linked to in the thread you linked to:
which proposes to use NOTE_NLP to link events to notes from which they were extracted.
@mgurley what became of that proposal?
2 Likes
I think we are definitely on your camp 
I’ll pass the proposal to my colleagues so we can evaluate its feasibility on our use case