Birth dates tokenized
Never merely shifted
- Category C handled as a replacement, not an offset
Home / Case studies / Risk adjustment
Case study · HCC coding engine, validation run
HCC chart de-identification: zero PHI leaks on ten real charts, and what that does and does not prove
Short answer: before the ASP AI Engine reads a chart for HCCs, the chart is de-identified on the local machine under Safe Harbor and re-scanned for leaks. Ten real charts: 0 surviving identifiers, regression gate 39 passing, 0 failing. An engineering result, not a client outcome; we have none to report.
45 CFR 164.514(b)(2) · 18 categories10 real charts · 0 leaksFail closed · unverified scrub stops the runNo client outcome claimed
Focus
De-identification
Audience
Compliance
Framework
HIPAA Safe Harbor
Metric
0 leaks
Archetype
10 real charts
Length
6 min
0leaks
Identifier leaks found by the per-chart scan across 10 real charts ASP-RCM engagement records
18categories
HIPAA Safe Harbor identifier categories the scrub targets, 45 CFR 164.514(b)(2) [1]
39/ 0
Regression-gate checks passing / failing on the current build ASP-RCM engagement records
45to 49 s
Per digital chart in a bulk run; scanned charts take longer ASP-RCM engagement records
Three kinds of claim, and which this page makes
The ASP AI Engine hands a coder an evidence-linked list of documented HCC conditions. The fail-closed PHI boundary is described elsewhere on this site; this page adds the measurements. No panel has run through this engine with a measured RAF, recapture or audit result; the companion page on the engine audit and the coder in the loop says the same.
| Claim | Made on this page? | Basis |
|---|---|---|
| The scrub removed the targeted identifiers on the validation charts | Yes | Per-chart leak scan, 10 charts, 0 findings |
| The build has not regressed on the de-identification tests | Yes | Regression gate 39 checks passing, 0 failing |
| The engine codes HCCs accurately on a client panel | No | No client panel data exists; coder signs off every chart |
| A health plan improved its RAF with this engine | No | No such result exists |
Safe Harbor, applied locally
45 CFR 164.514(b) allows expert determination or Safe Harbor, which removes 18 identifier categories [1]. The engine applies the Safe Harbor list on the local copy before any model call. Three design choices matter more than the list.
- 1ChartPDF or scanStays on the local machine
- 2ScrubSafe Harbor sweepAll 18 categories; birth dates tokenized
- 3Leak scanfail closedOutput re-scanned; an unverified scrub stops the run
- 4Model readsde-identified text onlyNo real identifier reaches a model call
- 5Coder decidesevidence-linked HCC listAccept, reject or query each condition
Stable per-chart date shift
Sequence survives
- Every other date shifted by one offset per chart
- A re-run produces identical output
Scrub everywhere, allow-list eponyms
Fragments included
- A value found anywhere is scrubbed everywhere, including name fragments
- Achilles or Baker are not mistaken for people
45 CFR 164.514(b)(2)(i)(A) to (R), what the scrub removes
| Letter | Identifier category removed | Letter | Identifier category removed |
|---|---|---|---|
| A | Names | J | Account numbers |
| B | Geographic subdivisions smaller than a state (3-digit zip only if the unit holds over 20,000 people) | K | Certificate or license numbers |
| C | All elements of dates except year (birth, admission, discharge, death); ages over 89 | L | Vehicle identifiers and serial numbers, including license plates |
| D | Telephone numbers | M | Device identifiers and serial numbers |
| E | Fax numbers | N | Web URLs |
| F | Email addresses | O | IP addresses |
| G | Social Security numbers | P | Biometric identifiers, including finger and voice prints |
| H | Medical record numbers | Q | Full-face photographs and comparable images |
| I | Health plan beneficiary numbers | R | Any other unique identifying number, characteristic or code |
Ten real charts, measured
Two leak classes were found and closed during the build: a date offset resolving to zero, and a name wrapped across two lines leaving the given name unscrubbed. Both fixes are in the gate; neither reached a model call.
Charts clean on the per-chart leak scan0 surviving identifiers, 0 name fragments ASP-RCM engagement records
Regression checks passing0 failing on the current build
Identifiers survivingDOB, phone, zip, name, record-id token classes
| Token class | What the scan looks for in the output | Result on the 10-chart run |
|---|---|---|
| Date of birth | Any surviving DOB string or unreplaced placeholder | 0 found |
| Phone | Any surviving telephone pattern | 0 found |
| Zip code | Any surviving 5- or 9-digit postal code | 0 found |
| Name | Any fragment of a name found anywhere in the source | 0 found |
| Record identifier | Any surviving MRN, account or encounter number | 0 found |
| Shifted dates | Reported separately: shifted, not removed, by design | Excluded from the leak count |
Seconds per chart, measured
Seconds per chart
Page cap raised from 20 to 5,000 so long inpatient records are read in full ASP-RCM engagement records.
Scanned chart, 18 to 23 pagesbefore parallel chunking
170 to 200 sbaseline
Scanned chart, 18 to 23 pagesafter parallel chunking
about 110 s45% faster
Digital chartbulk run
45 to 49 s75% faster than the scanned baseline
050100150200 s
BeforeAfter chunkingDigital
Status at October 27, 2026
- ONo client outcomeNo RAF, recapture, annual wellness visit or audit result from a real panel exists for this engine. We will publish one when measured on a client's own data.
- OInternal scan, not an independent auditThe leak scan tests our own output. An expert determination under 45 CFR 164.514(b)(1) has not been performed [1].
- OShifted dates are pseudonymized, not removedDates other than birth dates survive as shifted values by design: Safe Harbor on identifiers, not on dates. The coder sees the sequence; the model sees no real date.
- OCoding accuracy is a separate questionRun-to-run RAF variance on the same chart is documented on the companion page; the coder, not the engine, signs the code.
Takeaway
Zero leaks on ten charts is a statement about the scrubber. It says nothing about coding accuracy, and we have no client outcome to add to it.
Frequently asked questions
What does zero leaks actually mean here?
After each chart is de-identified, a second pass re-scans the output for the identifier classes it was supposed to remove: dates of birth, phone numbers, zip codes, names and record identifiers. On the ten-chart run that scan found zero surviving identifiers on every chart; it is a scan of our own output, not an independent audit.
Which de-identification standard does the engine follow?
The Safe Harbor method at 45 CFR 164.514(b)(2), which lists 18 identifier categories to remove. Dates other than birth dates are shifted by a stable per-chart offset rather than deleted, which keeps clinical sequence intact for the coder; the leak scan therefore measures identifiers excluding those shifted dates.
Has this engine produced a RAF or recapture result for a health plan or practice?
No. There is no client panel, RAF lift, suspect-closure or audit result from this engine on record, and this page does not claim one. The published figures are de-identification, regression and throughput measurements from internal validation.
Why does a coder still sign off every chart?
Because de-identification protects the patient, not the accuracy of the code. In internal runs the same chart has produced different RAF values from one run to the next, and a double-counting defect was found and fixed during the build. The engine proposes and a credentialed coder decides, as the companion engine-audit case study covers.
Checked October 27, 2026. Rules change; confirm against the source before relying on them. Client figures are archetype aggregates from ASP-RCM engagement records; no client is named.
CapabilityHCC risk adjustment AI: V28 mapping and MEAT evidenceServiceRisk adjustment coding servicesCapabilityV28 HCC coding AICase studyAI secondary diagnosis capture without PHI: the fail-closed boundaryCase studyHCC engine audit: why a coder stays in the loopCase studyASC orthopedic AI coding pilot, auditor scoredWhite paperHCC 2027 unlinked chart review exclusion playbookBlogHCC suspecting: prospective versus retrospective
See the de-identification boundary on your own charts
We will run a sample of your charts through the local scrub and show you the leak scan, the shifted dates and the coder review queue before any model reads a word.