From a129d3daba4961071897b7156f0ad75e05b08b8f Mon Sep 17 00:00:00 2001 From: IPerception Date: Mon, 7 Sep 2026 21:43:39 -0400 Subject: [PATCH 1/2] fix: warn that Limited Data Set does not scrub an 835 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 Claude-Session: https://claude.ai/code/session_01AfabdBfKu77QsNYVZkc3nn --- docs/835-validation.md | 14 +++++++++++--- web/EDIWorkbench.html | 14 +++++++++++++- web/tests/render.mjs | 24 +++++++++++++++++++++++- 3 files changed, 47 insertions(+), 5 deletions(-) diff --git a/docs/835-validation.md b/docs/835-validation.md index 5259645..fec721b 100644 --- a/docs/835-validation.md +++ b/docs/835-validation.md @@ -153,9 +153,17 @@ code change, audited the same way: the rule's identifier-bearing loops are opens no loop at all under this feature — see "the governing rule" above — so `scrubLoop` never reaches one of these NM1s, and `PERSON_LOOPS` itself never names an 835 loop id to begin with. An 835 handed through Limited Data -Set comes back byte-identical to what went in, which is worth stating loudly -in the app's own UI copy: silence here would hand a user a file they believe -is scrubbed. +Set comes back byte-identical to what went in, and silence about that would +hand a user a file they believe is scrubbed. + +So the app says it twice, at the point of use rather than only in the guide: +a caution inside the Limited Data Set card (`#deidRemit`, shown by +`syncRunButton` whenever `has835` is true of the loaded file), and a message +naming the reason after a run that changes nothing. The button is deliberately +left **enabled** for an 835 — disabling it would read as "not yet", where the +truth is "never, by design". `render.mjs` section [5] pins all of it, including +that the caution clears again when an 837 is loaded over an 835, and that the +output really is byte-identical rather than merely reported as such. ## Sources, and what could not be used diff --git a/web/EDIWorkbench.html b/web/EDIWorkbench.html index fc6105a..046f534 100644 --- a/web/EDIWorkbench.html +++ b/web/EDIWorkbench.html @@ -1831,6 +1831,9 @@

EDI*WORKBENCH

Dates are shifted per patient rather than removed, and city, state and ZIP are kept — that is what a HIPAA Limited Data Set permits, and it is what keeps the file usable as test data. Providers are left real: an NPI is not patient information.

The result is still PHI. A Limited Data Set is not de-identified data under HIPAA — it stays protected, and sharing it still needs a data use agreement. Only Safe Harbor or an expert determination produces data that leaves HIPAA behind, and neither is what this does.

The mapping is random for every run and is never saved, so this is one-way — the output cannot be turned back into the original.

+ +