OHDSI Home | Forums | Wiki | Github

Representing Registry Content and Evidence in OMOP

Implementers
#1

Hi all,

We are working on a registry project where many of the Registry data elements are “made up” (think, “Favorite ice cream flavor”). We are then pulling data from the EHR that helps answer the registry question (think, SNOMED 3241314 “Addiction to Chocolate”).

So my question is, how would you set this up? Current working idea:

  1. Create local Observation concepts for the registry questions and write the results of each question to the Observation table with value as string (eg “Chocolate”)

  2. Write a condition_occurrence for the EHR finding (eg occurrence of “Addicted to Chocolate” on date xyz)

  3. Create a FACT_RELATIONSHIP connecting the two (eg has_evidence)

Does this sound like the right way to go?

Thanks!

Jon

#2

@jon_duke:

Just wrote a lengthy exposé about this subject. Bottom line:

  • It doesn’t matter much, because your registry seems local, and therefore not analyzable in a network session.
  • So, I’d just write Observation concepts for the question, and either answer concepts for the answers if they are controlled, or value_as_as_string if open ended.
  • I would map the useful question/answer pairs to proper concepts and record them there
  • Don’t worry about linking, people trust what you are ETLing.
#3

Thank you @Christian_Reich for the quick response. I just read your expose and am still processing a bit but I overall agree with your your assessment of my Ice Cream scenario.

One complicating aspect is that some of the registry questions can have multiple answers. Eg What are the patient’s symptoms (check all that apply)?

Certainly this could be broken down into multiple questions such as do they have coughing, do they have rhinitis, do they have dyspnea, etc. But to respect the original design of the registry, I lean towards generating multiple links to relate the singular question to all its component evidentiary conditions. And the value of the answer itself… Um, long string? Set of concept ids?

Sorry if I am missing something obvious.

#4

@jon_duke:

Well, since it is your private survey you can do pretty much what you want, since nobody else is ever going to analyze it. As long as you have the concepts Cough, Rhinitis and Dyspnea in the CONDITION table.

#5

Agreed these questions will not be part of a network study.

But even given local use, I was just was wondering if others had experience or approaches that had worked well when creating local registries.

#6

Hello, @jon_duke, seems like you have a great field of work

I will summarize a little what Christian said and add a few cents:

  1. For the ‘Ice Cream scenario’ seems reasonable to create local Observation concepts and write answers as strings or as concepts, both are fine.
  2. For some clinical cases, like ‘Do you have a cough?’ - ‘Yes’ I would recommend mapping this question-answer combination (you can create a specific precoordinated concept for it) to Standard ‘cough’.
  3. I think point 2 works fine with multiple-choice questions too. You can create a concept for each question-answer combination and map it to Standard. Or just map answers to standard conditions, which looks more reasonable. No need to use long strings.
  4. Regarding date and time, it always depends on the question and given context. In some registries, historical context is not stated in the question, but you can figure it out from metadata. You can also calculate the dates from the person’s age. Ex: Question: ‘Age when last ate meat’ Answer: ‘44 years’. And from the person table you know that patient is 46 now, so you can find precise historical concepts with following patterns History of clinical finding within n years/months/weeks, History of clinical finding longer than n years/months/weeks. They are extremely useful in registries’ mapping.
  5. You may also find our UKB experience interesting, we discussed it here, and our discussions resulted in this release and further discussions here.

Hope you will find something useful.
Registries are very interesting to work with :slight_smile:

#7

Thank you so much @zhuk for those additional insights and ideas. I am reassured that we can largely represent the original registry questions while having the answers represented by standard codes.

I will review the the other materials you referenced and let you know if I have any additional questions.

Most appreciated!

Jon

t