Non-queryable concepts

[lrasmus]

We have situations where we have a concept that is purely organizational, but doesn't have a direct tie to underlying data (or really doesn't make sense to query on). For example, a concept of "Has Results" with values (child concepts) of "Yes", "No", "Unknown".

Someone dragging over "Has Results" into a query panel doesn't really make sense. It can be configured in various ways to be used in a query, but ideally in this scenario someone wouldn't be able to drop that on a query panel.

This could be a configuration attribute for concepts, called "Is Queryable", which would be set to "true" by default for all concepts.

Would others find this useful?

[ndobb]

Hey @lrasmus this is a good question. Just to understand this better, in other words, the concept hierarchy currently looks like:

• Has Results
  • Yes
  • No
  • Unknown

Is that correct? I know the IsQueryable-style solution is how i2b2 does it, but I've always been somewhat ambivalent about that kind of approach, as non-queryable concepts seem (to me at least) to be a lost opportunity to present the user with more information, given a slightly different presentation & hierarchy.

But perhaps I'm just on my soapbox and need to understand the particular use case a bit better. Could you elaborate more on the type of data and how you imagine users querying?

Also, if necessary as a (kinda lame, I know) workaround in the meantime, you could do something like having Has Results

• Use a by-design zero-row return like SQL: 1=0
• Have ShowPatientCount set to false, so the concept is never grayed out and doesn't show any 'green person' patient count next to it.
• Optionally add Subtext like Not queryable, or something.

[lrasmus]

@ndobb - thanks so much for your feedback! You are spot on in the recap of what I was describing. It's also very helpful to hear your perspective/philosophy on this. I had suspected that might be why a feature like that wasn't already available.

For another example, we were looking at certain laboratory tests to detect an organism. Let's say "Influenza A" as an example. There could be different results: e.g., Positive, Negative, Error. We were starting to organize it like this:

• Influenza A
  • Positive
  • Negative
  • Error

When doing some initial sessions with users, they expressed that they thought dragging over "Influenza A" would mean "sample tested positive for Influenza A", not "Test for Influenza A was performed on the sample". It was an interesting perspective I admit I did not consider at first (which is why we talk with our users!).

Another example would be more organizational "concepts". For example, the higher-level concepts above Influenza A would be:

• Sample Results
  • Pathogens Tested
    • Influenza A
    • ... and more

Querying for "Sample Results" or "Pathogens Tested" again, just didn't really make sense. I can make a query work as they do mean "pathogens were tested". I was more concerned about how to make it clear to a user what they were getting if they dragged it over. Leaf's ability to provide the full text to describe what is being queried is a huge benefit in addressing this. I think that if the user reads the full text of the concept brought over, they would realize "hey, this isn't what I want". I was thinking that by having these organizational concepts be a non-queryable concept, it would save the user the time of having to make that determination. Counter-point to that argument is that by not allowing it to be dropped, we may confuse the user more as they could wonder "why isn't this concept dropping?"

Your workarounds are all very reasonable as a way to address this in Leaf without making any modifications. I think I need to go back to ask some users what their expectation is with different configurations as you've suggested.

Thanks!