OHDSI Home | Forums | Wiki | Github

Recommendations for questionnaires / surveys

CDM Builders
#1

NOTE: I’m using the term survey and questionnaire interchangeably in the conversation below.

Not to beat a dead horse, but I’ve been reading about CDM v6 and questionnaires / surveys on these forums. We’re trying to “future proof”, to a certain extent, and would like to follow best practices ahead of time rather than fixing everything later.

LOINC seems to store each survey, question, and answer as a separate concept, and uses the concept_relationship table to link them. Panel contains and Has Answer are relationships used.

To use a concrete example, here are the links for the LOINC Kansas City Cardiomyopathy Questionnaire (KCCQ):

  • survey itself: Athena
  • one of the questions, “Bothered by fatigue over the past 2 weeks” : Athena
  • one of the answers, “Extremely bothersome”, Athena

We’re thinking of modeling our surveys, questions, and answers similarly.

We’ve also been reading a lot of info on the forums, Github, web, etc. about how surveys are done in CDM.

There’s some inconsistencies (is the table called survey or survey_conduct?), but that’s a minor issue from my perspective, as we can rename a table really easily. We’re more interested in recommendations on how to store questionnaire questions and answers.

A few questions:

  1. Some people seem to recommend just using your own custom schema until v6 is finalized.
  2. Since Survey Data in CDM · Issue #90 · OHDSI/CommonDataModel · GitHub has been merged, is it safe to assume that the general schema will remain the same, and can be safely used for internal purposes? We’d prefer doing this, instead of reinventing the wheel.
  3. Are the relationships that LOINC uses, (i.e., Has Answer, Panel contains) canon? Should we continue doing this?
  4. Should responses to surveys go in the response table, measurement, observation, or condition? Or a combination of them? Or it depends on the question answered??
  5. We want to perform statistical operations such as histograms and averages for survey responses. For example, “Degree of difficulty experienced due to your hip while descending stairs in the last week [HOOS]” has a range from None, Mild, Moderate, Severe, Extreme. We’d map these to 0 - 4 to get an average. What’s the best way to map these categories to numbers? concept_relationship with a custom relationship?

Anyway, any recommendations would be greatly appreciated, thank you!

1 Like
#2

Thanks @The-Alchemist. Sounds like it’s time to make some gold out of dirt. For all folks involved in surveys and questionnaires to sit down and get this sorted. You may want to apply a top-down approach using USE CASES.

Looks like you have one already! Keep it coming. Make a list. It will guide you to make the right decisions.

Let me try answering a few, and rephrase or pose others:

  1. You are free to create a new standard. While it is not yet in the CDM, it can be an Expansion to it, gathering experience.
  2. I would not assume anything is settled. You guys have to come together and do that.
  3. Ditto.
  4. Ditto. You may even want to consider a new table. SURVEY_CONDUCT isn’t for the content, it is for metadata so the data can be queried the right way.
  5. This is an analytic. It needs no modelling or mapping. Unless you think you want to standardize all answers that are degrees of something to a numerical value - then make that part of your Expansion.

You also need to ask yourselves:

  1. Which surveys are we going to standardize and put into the vocabulary? What are the rules for that? What are the mechanisms for that?
  2. Are we going to have standard answers? In other words, are we going to have one “Yes”, or 500 “Yesses”, one for each question that can be answered that way?
  3. Surveys are EAV, which means they have questions and answers, or variables/attributes and values. Except for the rather undefined OBSERVATION table, and the very narrowly defined MEASUREMENT table, in the OMOP CDM we have pre-coordinated facts (“Extreme difficulty descending stairs in the last week”). That is how all our tools and methods work, and there really is no need to keeping them separate. So, what are you going to do about that? Are you going to pre-coordinate question/answers, map them and put them into the actual clinical entity tables, so they can be picked up?

Happy to help.

1 Like
#3

For those familiar with REDCAP, here is an exported list of supported “standard” Questionnaires/Surveys.
ie-re: Use Cases - It’s a bigger problem than I realized.

Comprehensive Clinical Surveys DB.xls (1.5 MB)

#4

AllOfUs has surveys and one can also look at all the representation choices they have made. For example on Q7: Only one Yes and they used LOINC code for that. (but in vocab, there are also examples of not doing it (see conceptID 1332792)

Some parts of my paper here are relevant for that: Table - PMC

See this file
https://github.com/lhncbc/CRI/raw/master/AoU/CDE/Registered_Tier/S2_AOU_CRF_values.xlsx

image
image1406×931 115 KB

Here is their approach:

  1. their study design tried to re-use existing questions but they extended where truly needed (PPI vocabulary) (no research should skip this smart stage 1 and try to re-use non-copyrighted questions as much as possible and AoU did it really well)
  2. if element was fully captured by existing vocabulary, they used it, if not they created vocabulary entries for that
  3. they were able to store everything using existing core OMOP tables but they put necessary infrastructure into the terminology layer - e.g., CRF name and CRF sections were represented in vocabulary. See Athena for example

Here are the relationships in the PPI vocab (has PPI parent code)
(is the CRF level and it has children for each section)

image
image1482×719 56.5 KB

sections of CRF here

image
image1827×961 66.7 KB

questions in section Mood

image
image1774×886 76.7 KB

1 Like
t