Remove 89 ICD-9 codes filed under ICD-10 fields - #61
Merged
Conversation
Every ICD-10-CM code begins with a letter, so a digit-led value in an ICD-10 field is an ICD-9 code stored under the wrong vocabulary. 61 such values were in ARI_ICD10 across 53 diseases, with 14 matching rows in each mapping export. Letter-led values were left alone, including the range I00-I02 on Rheumatic fever, which is a different defect. Four diseases are left with no ICD-10 code at all because everything they held was ICD-9: ARI:0001032, ARI:0001033, ARI:0001119, ARI:0001201. Those cells now read as no term recorded, which is the honest state. Ten of the fourteen mapping rows were negative judgments rather than confirmations. Dropping them removes a record, but a rejection of a code that cannot be represented in the target vocabulary carries nothing forward, and nine of the ten already had no stored id to guard. This also clears three unrelated errors that happened to be ICD-9 all the way down: ARI:0001012 -> icd10cm:720.0 was recorded as both confirmed and flagged wrong, and was the one id still stored after #60 despite being flagged. #57 retired ICD-9 from the source list, the report script and the diagram, but it merged into feature/metadata-manager_v2/ARI rather than main, so none of that is on this branch. Porting it is still open. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This was referenced Aug 16, 2026
#52 landed 11 new mapping rows in each export while this branch was open, conflicting with the rows it deletes. Rather than hand-resolve the hunks, both mapping files were taken wholesale from main and the ICD-9 filter re-run over them, so the result is derived from current data rather than patched around it. #52 introduced no new ICD-9 codes: the ontology merged cleanly and a re-run removed nothing further from it. The diff against main is still exactly 89 deletions. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This was referenced Aug 16, 2026
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
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.
ontologies/ari_t1d.owland both mapping exports. 89 deletions, no additions.The rule
Every ICD-10-CM code begins with a letter. A digit-led value in an ICD-10 field is therefore an ICD-9-CM code stored under the wrong vocabulary —
446.1,720.0and390-392.99are ICD-9;M30.3,M45andE10are not.ontologies/ari_t1d.owl—ARI_ICD10values across 53 diseasesmappings/ari.sssom.tsvrowsmappings/ari.equivalencies.tsvrowsLetter-led values were left alone, including the range
I00-I02on Rheumatic fever — that is a separate defect (a range where a single code belongs) and is still reported by the validator.Judgement calls worth a look
Four diseases now have no ICD-10 code at all, because everything they held was ICD-9:
ARI:0001032,ARI:0001033,ARI:0001119,ARI:0001201. Those cells now read as no term recorded, which is the honest state, but it is a visible drop in apparent coverage.Ten of the fourteen mapping rows were negative judgments, not confirmations — a curator had already reviewed the code and rejected it. Dropping them removes a record. The reasoning for doing so anyway: a rejection of a code that cannot be represented in the target vocabulary carries nothing forward, and nine of the ten already had no stored id to guard. Affected:
ARI:0001012,0001014,0001061,0001062,0001063,0001065,0001068,0001073,0001074,0001107.Three unrelated errors fall out of this
ARI:0001012 -> icd10cm:720.0was recorded as both confirmed and flagged wrong, and was the one id still stored on its disease after #60 despite being flagged. Both rows and the stored value are ICD-9, so all three go together. Two of the six drifts between the two exports (362.50/362.5and720.0/720) go with them.Note on #57
#57 retired ICD-9 from
data/3-meta-database-sources/meta-databases.csv,notebook/ari-grounding/make_match_reports.pyandconnecting_ontologies.drawio— but it merged intofeature/metadata-manager_v2/ARI, notmain. None of it is on this branch, somainstill advertises ICD9/ICD9CM as sources and still groups ICD-9 into the report's ICD column. This PR covers the data only; porting #57 tomainis still outstanding.Verification
Validated with the checker from #63. Whole-repository errors 193 → 94; every
icd9-under-icd10finding cleared, along withcontradictionandflagged-still-stored. The ontology diff is 61 pure deletions, allARI_ICD10annotation lines, zero additions, and the file still parses as XML.Advances #23 ("Validate all diseases with database xrefs"); the other subtasks are untouched, so it is referenced rather than closed.
🤖 Generated with Claude Code