UX for *_type_concept_id different from *_concept_id

gowthamrao commented 6 years ago

Expected/Desired behavior

Have a uniform and easy to understand/maintain interface for selecting concept_id Consistent user experience for _concept_id, _source_concept_id, and *_type_concept_id

Actual behavior

Different UX for selecting _type_concept_id, compared to _concept_id and *_source_concept_id

http://www.ohdsi.org/web/atlas/#/cohortdefinition/1713730

Followed by a pop-up

or, import

Enhancement request

Change UX for _type_concept_id to be the same as _concept_id and _source_concept_id. Allow the use of concept_set expression - import concept sets Easier to learn, easier to maintain. Why have two sets of code libraries for similar functionalities? Current UX for _type_concept_id feels 'clunky'

chrisknoll commented 6 years ago

Hey, @gowthamrao, The UX for the *_type_concept_id is a literal concept ID list, while the source concept and {domain}_concept_id is based off of a concept set. So these are quite different things.

The reason for the difference: the source concepts and domain concepts are usually driven by some kind of concept hierarchy query + exclusion rules. For this, we use concept set expressions. This makes sense for creating code lists for drugs, procedures, and conditions. The other places where you use a straight concept is for specifying gender, or the visit type (inpatient, er, outpatient), etc, and these places it's more straightforward to just chose your concepts you want directly, since you don't use concept_ancestor, exclusions, or any of that stuff.

Maybe there's an idea about how to read in a concept set from the repository and add the included concepts to the array of concepts in the *_type_concept ids? You run the risk of accidentally selecting a concept set that has thousands of concepts and adding those concepts to your 'gender' concept list...

gowthamrao commented 6 years ago

Thank @chrisknoll

The UX for the *_type_concept_id is a literal concept ID list, while the source concept and {domain}_concept_id is based off of a concept set. So these are quite different things.

Based on my current understanding, the difference between concept_id list and concept_set seems very little, if at all. A list of concept_id maybe a concept_set, even if there are no excludes, descendants or mapped. Example http://www.ohdsi.org/web/atlas/#/conceptset/1713731/details

The above list of type-concepts is still a concept set expression. Yes, it is straightforward and we dont need to use concept_ancestor, exlcusions etc for this list -- but it makes it exponetially easier for the user. Plus, we can expose the same consistent API end-points. We dont have to maintain another (clunky) UX for the _type_concept's.

risk of accidentally selecting a concept set that has thousands of concepts and adding those concepts to your 'gender' concept list

I dont think this is a significant risk. During the cohort build process, the end-user has to verify the specifications. Plus - if you import a concept_set into the cohort builder from concept-set library, you can always crosscheck and see how many concepts will be used.

Overall - this would simplify the UX I think, make it easier for end-user learning, and will expose the same consistent endpoints for concepts.

gowthamrao commented 6 years ago

After much discussion with @chrisknoll

The underlying circe-be java object for gender, _type_concept_id requires an array of concept_id. Example:

"Gender": [
            {
              "CONCEPT_CODE": "F",
              "CONCEPT_ID": 8532,
              "CONCEPT_NAME": "FEMALE",
              "DOMAIN_ID": "Gender",
              "VOCABULARY_ID": "Gender"
            }

and

          "ConditionType": [
            {
              "CONCEPT_CODE": "OMOP generated",
              "CONCEPT_ID": 38000183,
              "CONCEPT_NAME": "Inpatient detail - primary",
              "DOMAIN_ID": "Type Concept",
              "VOCABULARY_ID": "Condition Type"
            }
          ]

and is different from concept-set's

"ConceptSets": [
    {
      "id": 0,
      "name": "Diabetes",
      "expression": {
        "items": [
          {
            "concept": {
              "CONCEPT_CLASS_ID": "Clinical Finding",
              "CONCEPT_CODE": "73211009",
              "CONCEPT_ID": 201820,
              "CONCEPT_NAME": "Diabetes mellitus",
              "DOMAIN_ID": "Condition",
              "INVALID_REASON": "V",
              "INVALID_REASON_CAPTION": "Valid",
              "STANDARD_CONCEPT": "S",
              "STANDARD_CONCEPT_CAPTION": "Standard",
              "VOCABULARY_ID": "SNOMED"
            },
            "includeDescendants": true
          }

Option to explore to improve the UX is to resolve a concept-set expression into an array of concept-id's that will be stored as a backward compatible object.

pbr6cornell commented 5 years ago

I support using one consistent vocabulary search/selection experience across ATLAS 3.0, including when you are making conceptsets or just picking some concepts for something like gender or type concepts. We can consider if we want to make everything 'conceptset' based just to have one consistent modality as well, which on the surface seems logical to me.

OHDSI / Atlas