Minimum necessary is the Privacy Rule's proportionality principle: for uses and disclosures of Protected Health Information (PHI) other than treatment, you should access or share only the PHI actually needed for the task at hand. It is codified at 45 CFR §164.502(b). Treatment is the notable carve-out — clinicians need the full picture to care for a patient — but almost everything else (operations, analytics, support, administrative disclosures) is held to the "only as much as you need" standard.
For a product team, this abstract principle becomes very concrete engineering. It translates into role-based access control so a billing clerk does not see clinical notes they have no reason to read, scoped API tokens that expose only the fields a given integration requires, redacted or summarized views for support staff, and data-minimizing defaults in exports, reports, and analytics pipelines. Each of these is minimum necessary expressed as a design decision rather than a policy paragraph.
It is also a powerful design heuristic that pays off well beyond compliance: every field you choose not to collect, and every system you prevent from seeing PHI, is a field and a system that cannot leak in a breach. Designing for minimum necessary shrinks your attack surface and your incident blast radius at the same time. The common pitfall is the opposite reflex — collecting and broadcasting "just in case," giving internal tools, analytics, and support dashboards blanket access to full records. That convenience quietly maximizes risk, and it is exactly the pattern regulators and post-incident reviews flag, so make least-privilege the default and justify every broadening of access explicitly.
