Repository navigation
Conversation
The condition occurrence treemap query concatenated level2_concept_name twice, so every concept path showed the HLT level twice and never the level1 (PT) name. Use level1_concept_name like the condition era report and the cohort results condition treemap do. Adds a test that runs the condition treemap query against the embedded Postgres database and checks the full concept path. Fixes OHDSI#2468
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #2468
cdmresults/sql/report/condition/treemap.sqlbuildsconcept_pathfromlevel4 || level3 || level2 || level2 || concept_name. Becauselevel2_concept_nameappears twice, every condition in the Data Sources > Condition Occurrence treemap gets the HLT name twice and loses the level1 (MedDRA PT) name entirely. The Condition Era report (conditionera/treemap.sql) and the cohort results condition treemap (cohortresults/sql/condition/sqlConditionTreemap.sql) both uselevel1_concept_namein that spot, andinit_concept_hierarchy.sqlfills level1 with the PT name for theConditiontreemap. No other treemap query has the duplicate.On @chrisknoll's question in the issue about whether the condition hierarchy skips level 1 on purpose: all three condition treemap queries read the same
treemap='Condition'rows ofconcept_hierarchy, and the condition era and cohort results ones already uselevel1_concept_name, so nothing in the hierarchy is set up to be skipped for this report. The path still has the same five segments, so the front end gets the same depth as before.Changes:
condition/treemap.sql: replace the secondlevel2_concept_namewithlevel1_concept_name.CDMResultsTreemapTest: createsachilles_resultsandconcept_hierarchyin a scratch schema on the embedded Postgres test database, runsCDMResultsAnalysisRunner.getTreemap(..., "condition", ...)and checks the fullSOC||HLGT||HLT||PT||conceptpath.Testing (JDK 8,
-Pwebapi-postgresql):CDMResultsTreemapTestfails:expected:<...tes mellitus (HLT)||[Type 2 diabetes mellitus (P]T)||...> but was:<...tes mellitus (HLT)||[Diabetes mellitus (HL]T)||...>mvn -DskipUnitTests=false -DskipITtests=true -Pwebapi-postgresql -Dtest=CDMResultsTreemapTest,CDMResultsAnalysisRunnerTest,CDMResultsCacheTest testgivesTests run: 15, Failures: 0, Errors: 0, Skipped: 0.Note: sources that already have a condition treemap in the Achilles cache will keep showing the old path until that cache entry is cleared or rebuilt.