Add Type-2 NPI Luhn test cases to us_npi_recognizer tests - #2237
Open
jbisaccia-9 wants to merge 3 commits into
Open
jbisaccia-9 wants to merge 3 commits into
jbisaccia-9 wants to merge 3 commits into
Conversation
The parametrized case labeled "Valid NPI starting with 2 (Type 2 = organization)" actually used 1003000126, an NPI starting with 1 (Type 1 = individual) — the recognizer's Type-2 (organization) branch had no dedicated Luhn coverage. Adds: - 2123456784: a genuine Type-2 NPI (starts with 2) that passes the "80840"-prefixed Luhn check per the CMS NPI spec. - 2123456783: the same body with a Luhn-failing check digit, to confirm the recognizer rejects it. Both values were verified against the recognizer's own __npi_luhn_checksum implementation before being added.
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The change is test-only, aligns with the recognizer’s implemented Luhn validation logic, and adds targeted coverage for an otherwise untested Type-2 path.
Pull request overview
Improves the reliability of the US NPI recognizer’s checksum validation tests by adding dedicated Type-2 (organization) NPI cases and correcting an inaccurate comment, ensuring the Type-2 Luhn path is explicitly exercised.
Changes:
- Corrected the comment for an existing Type-1 (individual) NPI test vector.
- Added a valid Type-2 NPI (starts with
2) which passes the recognizer’s Luhn-with-80840-prefix validation. - Added an invalid Type-2 NPI with a bad check digit to confirm it is filtered out.
File summaries
| File | Description |
|---|---|
| presidio-analyzer/tests/test_us_npi_recognizer.py | Adds explicit Type-2 (organization) Luhn pass/fail test vectors and fixes the mislabeled Type-1 comment. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
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.
The parametrized case labeled "Valid NPI starting with 2 (Type 2 = organization)"
in tests/test_us_npi_recognizer.py actually used
1003000126, an NPI startingwith
1(Type 1 = individual). The recognizer's Type-2 (organization) branch hadno dedicated Luhn test coverage.
Per the CMS NPI spec, the check digit is a standard Luhn check computed over the
10-digit NPI prefixed with "80840". I verified the following against the
recognizer's own
__npi_luhn_checksumimplementation:2123456784— Type 2 (starts with 2), passes Luhn → should be recognized2123456783— same 9-digit body, invalid check digit, fails Luhn → should befiltered out
This PR adds both cases and fixes the comment on the pre-existing case to
correctly say "Type 1".
No source changes — test-only.