Warn that Limited Data Set does not scrub an 835, and fix the suite counts - #9
Merged
Merged
Conversation
The rule is a no-op on a remittance advice: an 835's patient identifiers sit directly inside loop 2100 (NM1*QC, NM1*IL), outside the PERSON_LOOPS the rule targets, so the file comes back byte-identical. That was stated only in the guide panel, so at the point of use the app was silent -- a user could run it, download an unchanged file, and believe it was scrubbed. Say it where the action is instead: a caution in the Limited Data Set card, shown by syncRunButton whenever has835 is true of the loaded file, and a post-run message naming the reason rather than the generic "no patient loops found", which reads as "already clean" on an 835. The button stays enabled. Disabling it would read as "not yet", where the truth is "never, by design". Covered in render.mjs rather than the static lint, because the failure mode is stale state: the caution not clearing when an 837 is loaded over an 835 is the same bug pointed the other way. The test also asserts the output really is byte-identical, so that claim is pinned by a test and not only by prose. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AfabdBfKu77QsNYVZkc3nn
The runner reports nine suites. The README said eight, and PERFORMANCE.md said four and named an outdated subset of them -- both predate the tree, claims, validate, deid and render suites landing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AfabdBfKu77QsNYVZkc3nn
IPerception
added a commit
that referenced
this pull request
Sep 8, 2026
The rail footer is the single place the version is written; release.mjs derives the tag and the asset filename from it. v1.1.0 predates the 835 Limited Data Set warning (#9), so a holder of that download has the silent no-op. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AfabdBfKu77QsNYVZkc3nn
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 835 gap
docs/835-validation.mdalready recorded that an 835 handed through LimitedData Set comes back byte-identical — its patient identifiers sit directly
inside loop 2100 (
NM1*QC,NM1*IL), outside thePERSON_LOOPSthe ruletargets, so
scrubLoopnever reaches one. The doc called that "worth statingloudly in the app's own UI copy: silence here would hand a user a file they
believe is scrubbed."
It was stated in the guide panel only. At the point of use the app said nothing:
load an 835, click Create Limited Data Set, download an unchanged file, and
nothing on screen distinguishes that from a successful scrub.
What changed:
#deidRemit), shown bysyncRunButton()wheneverhas835()is true of the loaded file. It names thereason rather than just the outcome.
the generic "No patient loops found — nothing to strip", which reads as
already clean.
truth is "never, by design".
docs/835-validation.mdnow records that this is said, and where.Doc drift
README.mdsaid eight browser suites; the runner reports nine.web/PERFORMANCE.mdsaid four, and named an outdated subset — both predatethe
tree,claims,validate,deidandrendersuites landing.Verification
Covered in
render.mjs(section [5]) rather than the static lint, because thefailure mode is stale state — the caution not clearing when an 837 is loaded
over an 835 is the same bug pointed the other way. The test also asserts the
output is genuinely byte-identical to the input, so that claim is now pinned by
a test and not only by prose.
Not yet exercised in a real browser — the DOM shim can't report how the caution
reads in the card or whether the 2.2s toast is long enough.
🤖 Generated with Claude Code