We have found that some data have clinical interpretation related to that data. This interpretation is a free text and related to the measure. We want to store this interpretation in the CDM. My first thought was to use note (or even observation) to store the clinical interpretation and then relate it with a fact_relationship to the measurement, but I’m not sure if there is a suitable “interpretation” code in OMOP or a suitable relationship that can be put into fact_relationship that represents the “interprets” meaning
More doubts, probably more general:
Is Note intended only for full textual documents? (I’m assuming this by the requisite of using Loinc CDO) Could it be used to store the different sections of a document or a given comment regarding another measure?
Would using 0 as note_class_concept_id and fully relying on note_source_value be ok?
If it is discouraged to use Note for the different parts of a clinical document, what are the alternatives? Using Observation.value_as_string limits the contents to 60 characters, and you lose the ability to use the note_nlp table
Sure thing! Take for example Blood Pressure openEHR archetype (an ‘archetype’ is how openEHR calls their clinical information models)
The interpretation is described as a “single word, phrase or brief description that represents the clinical meaning and significance of the blood pressure measurement.”. In this case is specifically defined as the interpretation of a BP, but the interpretation is something that repeats in several archetypes. Same happens with “Comment” a data element available in numerous archetypes. So as you see there are measures (some of which already have SNOMED codes associated) and textual parts that give a clinical interpretation or comment these measures.
Yes, the definitions of the concepts in the OMOP CDM belongs to the Standardized Vocabularies. The ETL has to make sure to pick the right concept, but then the source has no more say. So, drop the field.
Of course you can always add your own custom field for convenience and add there whatever you want. But that wouldn’t be standard, and none of the tools will pick it up.
Thing is, this clinical interpretation could be coded or susceptible of being included in a NLP process.
If the clinical interpretation is coded then probably is Ok to create a condition occurrence from it. If not maybe even an Observation registry, having for example ‘has interpretation’ as observation_concept_id, and the corresponding transformed code in the value_as_concept_id.
If it’s not coded, the idea was to prepare it so it could be coded in the future by putting it on a note (and use the note_nlp table, etc.).
In the above example, “hypertension” could be a clinical interpretation, and we would want to use NLP over that field if it’s not coded, as could be very interesting for research purposes
I’m looking at valid codes for notes that fit the purpose and I’ve found Summary note. No explicit interpretation notes sadly
Still not sure why you want this information. What is the use case? What analytic is driven by it? How is a standardized representation useful (you can have your private one whichever way you want)? See my point?
In the OMOP CDM, we are representing facts about a patient, not about concepts we use to describe them. That is not clinical data, that is reference data. So, my question is: Is there any such fact in this field? If not, there is no place in the OMOP CDM.
We are pretty adamant about that distinction. Many people succumb to the so-called “attic use case”: I have data, where can I possibly store it, and what field can I abuse to squish it in? Because “I might need it”. That’s like your attic at home: You are putting things in because you might need it, and it never comes out till you move house.
1 Like
This is a blood pressure panel with the clinical interpretation of the data (e.g. hypertension, normal blood pressure, etc.). In some systems/hospitals this will be coded, which has no real problem, as it will end in a condition_occurrence (or on the domain the transformed code ends e.g. hypertension).
The panel definition is such that this diagnosis/clinical interpretation is not required to be coded right from the start, so a place where to temporally store these interpretation/diagnostic texts should be perfect to do NLP later on (and get the diagnoses from them).
In addition to either of these, a fact_relationship could be added (although no “condition to measurement” code exists as a relationship)
Finally, this kind of panel with the pattern measurements with associated clinical finding/diagnosis repeats in several openEHR archetypes, that’s why I was looking for a more generic approach. In general the clinical interpretation/diagnosis/condition occurrences are each in their corresponding “panel”, so the way of populating the condition_occurrence table is taking these and translate them to omop codes (regardless they are coded in source or not)
You can think about the openEHR archetypes as equivalent to CDA Implementation Guides talking about ClinicalDocuments or Sections, although they are not coded with LOINC CDO at all.
Yes, you can do that. But it will be only meaningful within your data instance. Nobody engaged in network research and sending you queries crafted outside will even know this exists, leave alone make use. So, definitely good for convenience purposes for you guys.
1 Like
Well. we are talking mainly about Note, Note_nlp, and fact_relationship so I was assuming no ohdsi tools or partners were going to use it 
In the end all this is for having more condition_occurrences available not to stop in the notes.