CHDA common mistakes
CHDA · Understand the traps and how to avoid them.
On terminology items, the candidate labels any report that mentions future time periods as "predictive analytics," or labels a dashboard of last quarter's admissions as "prescriptive" because it includes a recommendation column.
Candidates memorize the four analytics types as a list of words rather than as a test of the question each type answers, so 'time' or 'recommendation-shaped' language becomes the trigger instead of the analytical intent.
What to do instead
Drill a one-line decision test for each type: descriptive = what happened; diagnostic = why it happened; predictive = what is likely to happen; prescriptive = what action should be taken and its expected effect. Classify by the question being answered, not by the tool, the chart, or the time horizon of the data.
The candidate calls every rate a 'ratio' and every ratio a 'rate,' or describes a 30-day readmission measure as a ratio because the denominator is not the whole population.
Proportion, rate, ratio, and percentage get used interchangeably in everyday work, so the formal distinctions are never reinforced and term-level items feel like hair-splitting.
What to do instead
Use one bright-line test: is the numerator a subset of the denominator (proportion), does the denominator include a time or exposure component (rate), or are the two quantities disjoint counts (ratio)? Apply the test to each named measure before answering, and write the numerator and denominator out explicitly.
Given a scenario ('our readmission numbers look bad, build me something'), the candidate immediately selects an analysis technique or a deliverable format and never restates the business question, the decision the output will support, or the success criteria.
Working analysts are trained to start where the data is available, and scenario stems are long enough that the question reads like a request for a method rather than a request for a clarified requirement.
What to do instead
Apply a fixed pre-analysis checklist to every scenario: who is the decision-maker, what decision changes, what is the operational definition of the measure, what population and time window, and how will success be judged. Answer only after all five are identifiable from the stem, and note any that must be confirmed with the requester.
The candidate builds a calculation on a field based on its name, e.g., treating the 'discharge date' field as the end of the encounter, counting an ICD-10-PCS code as a diagnosis, or using 'admit date' when the measure specifies 'service date.'
Column names in extracts are familiar-looking, and under time pressure reading the data dictionary feels like overhead when the meaning seems obvious.
What to do instead
For every field used in the final calculation, confirm three things from the data dictionary or lineage: the business definition, the allowable values/format, and the source system it originated from. If the stem gives no definition and the choice would change the answer, flag the ambiguity rather than assuming.
The candidate treats a successful extract as a validated dataset - no reconciliation of record counts or totals to the source system report, no range or referential-integrity checks, no examination of null and default values before analysis.
Query tools return clean-looking rows, so 'it loaded without error' is mistaken for 'the data are correct,' and validation is treated as a downstream step rather than part of acquisition.
What to do instead
Run and record a standard battery before any analysis: row counts versus source, control totals on key measures, completeness on required fields, value-range and code-set conformance, referential integrity across joins, and duplicate checks. Treat any unexplained variance as a blocker, not a footnote.
The candidate computes a system-level or period-level rate by averaging the unit-level or monthly percentages, giving a small unit the same weight as a large one.
Averaging a column of already-computed percentages is the fastest path in a spreadsheet, and the resulting figure looks plausible, so the aggregation error is invisible without a re-derivation.
What to do instead
Always re-aggregate from the raw numerator and denominator sums, never from the summary percentages, and weight by volume. As a check, compare the pooled result to the unweighted average; when they diverge sharply, look for a compositional (Simpson's paradox) effect before reporting.
The candidate reacts to a single month's value that sits above the historical mean as evidence the intervention worked, or compares two periods without any statement of whether the difference exceeds normal variation.
Trend narratives in the workplace are usually built from line charts and month-over-month comparisons, so control limits, run rules, and expected variation are not part of the candidate's default reasoning.
What to do instead
Before interpreting any time series, establish the expected variation: use a control chart with appropriate limits for the data type, apply run rules (e.g., shifts, trends) rather than single-point comparisons, and distinguish common-cause from special-cause variation in the written interpretation.
The candidate states that a p-value of 0.04 means there is a 4% chance the null hypothesis is true, or concludes a difference is operationally important solely because p < 0.05 on a very large sample.
The p-value definition is widely misstated in casual professional conversation, and the large administrative datasets in this field make trivially small differences statistically significant.
What to do instead
Memorize the correct phrasing: the p-value is the probability of data at least this extreme assuming the null is true; the conclusion is 'reject' or 'fail to reject.' Pair every significance statement with an effect size and confidence interval, and judge importance against a pre-specified practical threshold.
The candidate's final summary leads with methodology and raw tables, gives a point estimate with no confidence interval or stated limitations, and offers a recommendation with no mention of the assumptions the result depends on.
The deliverable is treated as a demonstration of analytical rigor rather than a communication product for a decision-maker, and limitations feel like admissions of weakness.
What to do instead
Use a fixed report structure: business question, key finding stated in one sentence with the effect size, confidence and caveats, what the data cannot tell you, and the recommended next action. Put the finding first and move method detail to an appendix; state at least one limitation tied to a specific data or design constraint.
The candidate treats removal of names and medical record numbers as sufficient de-identification, or agrees to share a limited data set with an external partner without confirming a data use agreement is in place.
Privacy knowledge is often reduced to 'strip the obvious identifiers,' and the distinction between Safe Harbor, Expert Determination, and a limited data set is easy to blur when the scenario focuses on the analysis task.
What to do instead
Check the scenario against the Safe Harbor list of the 18 identifier categories (including dates more granular than year, ZIP codes beyond the initial three digits, and any unique identifying codes) or note that Expert Determination is required. For a limited data set, confirm the data use agreement exists and that only the permitted identifiers are included, consistent with minimum necessary.