Data Security & Classification Deep-Dive

Novice · Governance, Ethics & Equity track · ~35 min hands-on + readings and quiz

← Back to the Governance, Ethics & Equity track

The rule under every other topic: the right tool for the data’s sensitivity.

What you’ll be able to do

  • Classify data by sensitivity (public → high-risk)
  • Match each tool to Drexel’s approved classification
  • De-identify or substitute when a tool isn’t cleared

Overview

Every AI decision starts with one question: how sensitive is this data, and is this tool approved for it? Drexel publishes which tools may be used with which data levels. Identifiable records, PHI, protected student data, and contract material have strict limits.

When a tool isn’t cleared for your data, the move is to de-identify, use synthetic data, or switch to an approved tool — not to make an exception.

Practice activities

Activity 1 · Novice — Classify and match

Time ~15 min · Tools Drexel AI Tools page + ChatGPT Edu

Goal. Map your data to the right tools.

Setup. Use these three data scenarios that span DSPH roles:

Scenario Data description
Research coordinator A de-identified CSV of crash records: intersection ID, crash date, time of day, severity (fatal/serious/minor), pedestrian age band, weather. No names, no exact addresses.
Academic advisor A student’s email asking about switching from MPH to DrPH, mentioning their GPA and that they’re on academic probation.
Grants administrator A draft budget justification for an NIH R21 listing personnel names, percent effort, and salary amounts.

Steps.

  1. For each scenario, classify the data sensitivity (Public / Low Risk / Moderate Risk / High Risk) and identify which Drexel-approved tools may be used. Check the AI Tools page.

  2. Sanity-check with AI:

    I have these three data scenarios. For each, tell me the likely data classification and which Drexel-approved AI tools are appropriate. Scenario 1: De-identified crash data (intersection ID, date, time, severity, age band, weather — no names or exact addresses). Scenario 2: A student email mentioning GPA and academic probation status. Scenario 3: A draft NIH budget with personnel names, effort, and salaries.

  3. Compare the AI’s answer to your own classification. Flag any disagreement and resolve it using the official policy, not the AI’s guess.

Expected result. A completed classification for all three scenarios, with the tool(s) allowed for each. The crash data is likely Low Risk (de-identified, no FERPA/HIPAA data); the student email contains FERPA-protected records (Moderate or High Risk — ChatGPT Edu may be acceptable but check policy); the budget with names and salaries is at least Moderate Risk.

Check your work. Verify against Drexel’s official AI Tools page, not the AI’s guess. The AI may under-classify.

Common pitfalls. “It’s probably fine” isn’t a classification. Student records (FERPA) and personnel data are commonly under-classified. When unsure, treat data as more sensitive.

Stretch (optional). Write your team’s one-page “what goes where” cheat sheet covering the five most common data types you handle.

Activity 2 · Novice — Substitute safely

Time ~12 min · Tools ChatGPT Edu (fabricated data only)

Goal. Make sensitive data safe for a given tool.

Setup. Use this fabricated patient-encounter table:

Name Age Sex ZIP Admission Date Diagnosis
Maria Torres 34 F 19104 2026-03-12 Tibial fracture, pedestrian crash
James Chen 71 M 19143 2026-03-14 Hip fracture, fall on broken sidewalk
Aisha Patel 28 F 19131 2026-03-15 Traumatic brain injury, cyclist-vehicle collision
Robert Williams 82 M 19104 2026-03-12 Concussion, pedestrian struck at crosswalk
Dara Kim 45 NB 19146 2026-03-18 Laceration and contusion, e-scooter fall

Steps.

  1. De-identify it:

    Here is a fabricated patient-encounter table. Produce a de-identified version that would be safe for a Low-Risk AI tool, and list each change you made and why.

  2. Check: could the remaining fields still identify someone in combination? Pay special attention to the 82-year-old male in ZIP 19104 admitted the same day as another patient with an uncommon diagnosis — that combination narrows the population considerably.

  3. Decide whether de-identification is enough or whether you need to generalize further (age bands, 3-digit ZIP) or use an approved higher-classification tool.

Expected result. A de-identified version with names removed, plus an assessment of whether age + ZIP + date + rare diagnosis (e.g., the TBI from a cyclist collision) could still re-identify. You should find that at least one record remains risky even after removing names.

Check your work. Quasi-identifiers (age + ZIP + date) can re-identify — particularly for older adults or uncommon injury types. Removing names alone is not sufficient.

Common pitfalls. “I removed the names, so it’s de-identified” is the most common mistake. Combinations of age, geography, date, and rare conditions are the real risk.

Stretch (optional). Generalize further (5-year age bands, 3-digit ZIP prefix) and re-assess whether re-identification risk drops to acceptable levels. Then try generating fully synthetic data instead (see the De-identification & Synthetic Data topic).

Activity 3 · Novice — Scan for quasi-identifier risk systematically with Claude Code

Time ~15 min · Tools Claude Code (fabricated data only — Low Risk)

Goal. Replace eyeball review with a systematic, scriptable scan that flags every risky quasi-identifier combination — not just the one you were told to look for.

Setup. Reuse the same fabricated patient-encounter table from Activity 2:

Name Age Sex ZIP Admission Date Diagnosis
Maria Torres 34 F 19104 2026-03-12 Tibial fracture, pedestrian crash
James Chen 71 M 19143 2026-03-14 Hip fracture, fall on broken sidewalk
Aisha Patel 28 F 19131 2026-03-15 Traumatic brain injury, cyclist-vehicle collision
Robert Williams 82 M 19104 2026-03-12 Concussion, pedestrian struck at crosswalk
Dara Kim 45 NB 19146 2026-03-18 Laceration and contusion, e-scooter fall

Reminder: Claude Code is a consumer/PI-purchased tool, not Drexel-supported — approved for Low Risk Data only. There’s a small irony here worth savoring: because we’re practicing classification decisions with a tool that isn’t cleared for sensitive data, the practice data itself must already be Low Risk — which is exactly why this table is fabricated. Never substitute real records.

Steps.

  1. De-identify the table first, exactly as in Activity 2: remove the Name column. Save the remaining five rows (Age, Sex, ZIP, Admission Date, Diagnosis) as encounters.csv in an empty working folder.

  2. Open Claude Code in that folder and ask it to build the scanner:

Read encounters.csv. Write a small Python script that treats Age, ZIP, and Admission Date as quasi-identifiers, plus a yes/no flag for whether the Diagnosis is a rare or uncommon category. For every row, compute the equivalence class size — how many rows in the file share that same combination of quasi-identifier values. Also check partial combinations (ZIP + date, age + ZIP, etc.). Flag every row whose class size is below 3 and print a plain-English report explaining why each flagged row could be re-identified by someone with outside knowledge (a neighbor, a news story, a coworker).

  1. Run the script and read the report. Did it flag the 82-year-old male in ZIP 19104 admitted 2026-03-12 — the row Activity 2 told you to notice? What else did it flag that Activity 2 never mentioned?

  2. Now ask Claude Code to test whether generalization fixes it:

Modify the script to generalize before scanning: replace Age with 10-year age bands and ZIP with its first 3 digits, then recompute equivalence class sizes. Print a before/after comparison showing which rows are still flagged.

  1. Compare the two reports. Decide, as in Activity 2, whether de-identification alone was enough — but this time with counts, not a hunch.

Expected result. A working script plus a flag report. The scan should catch the ZIP 19104 / 2026-03-12 pair (two patients sharing date and ZIP, each made unique again by age and an uncommon diagnosis) — and it should also show that with only five rows, essentially every row is an equivalence class of one. The manual hint in Activity 2 pointed you at a single risky record; the systematic scan shows they are all risky, which no amount of squinting communicates as clearly.

Check your work. The core idea is k-anonymity: a row is safer when at least k rows (commonly k ≥ 3–5) share its quasi-identifier combination. If your script only checks columns one at a time, it will miss the point — re-identification risk lives in the combinations. Your before/after comparison should show generalization increasing class sizes but not necessarily eliminating every flag at n=5.

Common pitfalls. Pasting real patient data into Claude Code “just to test the script” — the tool’s Low Risk approval doesn’t change because your intentions are good. Concluding “the script flagged everything, so it’s broken” — at five rows, flagging everything is the correct answer, and it’s exactly why tiny published tables are dangerous. Trusting the generated script without reading it — you, not Claude Code, are accountable for the classification decision.

Stretch (optional). Ask Claude Code to generate a fully synthetic dataset of 200 encounters with realistic age/ZIP/date distributions, then re-run the scanner. Notice that risky small equivalence classes still exist but are now impossible to spot by eye — the scale at which manual review fails and systematic scanning becomes the only honest method.

Check your readiness

Answer these, then check — your score suggests whether to dive in or skim the readings first.

Useful resources