The disclosure ledger and patient restrictions (SP2)

Featurekamo-shared-library
Spegnimento
25 agosto 2026 alle ore 14:45 UTC
Autore
Kamo
Impegno
8e2c8d9

DisclosureLedger is separate from phi_access_log on purpose. The access log records every READ, and most reads are a clinician opening a chart; deriving an accounting from it hands the patient a document listing thousands of internal views, which is both wrong and alarming. §164.528 accounts for DISCLOSURES — PHI leaving the covered entity — not internal use. The two also cover different periods and different purposes, which is why purposeOfUse is stamped at access time and carried here rather than inferred later. hipaaAccountable is stored rather than derived from the purpose on read, because the rule has exceptions the purpose alone does not capture — a disclosure the patient authorized is accounted differently from one made under a treatment exception — and recomputing it later means re-deriving those exceptions from data that no longer exists. PatientRestriction carries the §164.522 obligation a covered entity may NOT refuse: a patient who pays out of pocket in full can require that the service not be disclosed to their plan. That is the one usually implemented wrong, because hiding the encounter on a screen does not comply. It has to stay out of CLAIM SUBMISSION and out of ELIGIBILITY ENQUIRIES, since both tell the plan the service happened. A system that hides it in the chart and bills it anyway has disclosed exactly what the patient paid to prevent, and they find out from their explanation of benefits. So suppressFromClaims is its own flag checked by the billing path, not inferred from a display rule — display rules get relaxed for usability and a billing suppression must not travel with them. suppressFromEligibility is separate again, because a 270 asking a plan about a service signals the service is contemplated; suppressing the claim alone leaks the same fact more quietly. Both tables close rows rather than deleting them. A lifted restriction still explains why a service went unbilled for six months, and the ledger is append-only because an accounting that can be edited is not an accounting. Temporal boundaries are exclusive at the end instant and the tests pin both directions, including that an incomplete row denies rather than throwing — this predicate sits on the billing path. 1653 tests green.

Tutte le modifiche

Come quello che vedi la spedizione?

Ognuno di questi aggiornamenti atterra automaticamente nello spazio di lavoro. Inizia gratis e guardalo crescere settimana dopo settimana.

Inizia gratis per sempreVisualizza il prezzo