The HIPAA Minimum Necessary Standard: History, Enforcement, and What AI Actually Changes
The HIPAA minimum necessary standard has been around since 2002. It still shows up in OCR complaint data, and healthcare organizations still struggle to apply it consistently. In AI-assisted healthcare, it's become one of the harder compliance questions to get right.
The minimum necessary standard: where it came from, where enforcement has landed, and what it means when your covered entity feeds patient records into an AI system.
Where It Came From
The Health Insurance Portability and Accountability Act became law in August 1996. Congress built in a backstop: if it didn't pass comprehensive privacy legislation within three years, HHS would have to do it through rulemaking. Congress didn't act. So HHS did.
The proposed Privacy Rule dropped in November 1999, a sprawling set of regulations governing how covered entities could use and disclose individually identifiable health information. The minimum necessary standard was part of the original proposal, drawn from confidentiality principles already in use across the healthcare industry. The core principle wasn't novel: don't share more patient information than you need to accomplish the purpose at hand. What changed was that it became federal law.
The final rule published December 28, 2000. Then came the modifications. HHS received thousands of public comments, and a consistent message came back from healthcare providers: the rule as written was going to create problems in care settings. Physicians worried about friction in every clinical consultation. Hospitals worried about the cost of applying a minimization analysis to every information exchange in a treatment environment.
The August 2002 modifications addressed this directly.1 The most important clarification, from a practical standpoint: the minimum necessary standard does not apply to disclosures to or requests by a health care provider for treatment purposes. If PHI is moving between providers for treatment, minimum necessary analysis is generally off the table. HHS recognized that care delivery depends on information flow, and building a compliance checkpoint into every clinical communication would do more harm than good.
The rest of the standard took shape as a flexible policy obligation.2 Covered entities must develop internal procedures identifying who needs what PHI for what purposes, implement standing protocols for routine requests, and conduct case-by-case review only for non-routine ones. The standard is "reasonable efforts": not an absolute minimum, not a data-element-by-data-element audit, and not a case-by-case review of every transaction.
HITECH and the 2013 Omnibus Rule
The Health Information Technology for Economic and Clinical Health Act of 2009 and the 2013 Omnibus Rule materially expanded HIPAA's enforcement perimeter.3 Business associates became directly liable for certain HIPAA obligations, including limits on uses and disclosures not authorized by their BAA or required by law. For AI vendors acting as BAs, this matters: minimum necessary now functions not only as a contract obligation but as part of the regulatory framework governing permitted PHI use. That said, BA direct liability attaches to specific provisions, not the full Privacy Rule in the same way it applies to covered entities.
The 2021 NPRM: HHS Acknowledges Operational Friction
In January 2021, HHS published the first significant proposed revision to the Privacy Rule in nearly twenty years.4 The NPRM (Modifications to the HIPAA Privacy Rule to Support, and Remove Barriers to, Coordinated Care and Individual Engagement) proposed an express exception to minimum necessary for disclosures to or requests by health plans or covered providers for individual-level care coordination and case management. The proposal was expressly tied to HHS's recognition that uncertainty around the standard may inhibit information sharing for those functions.
That proposal is narrower than a wholesale confession that minimum necessary had failed across the board. It targeted care coordination and case management, particularly where that activity is classified as health care operations rather than provider-to-provider treatment. But it is still meaningful: HHS was acknowledging that the existing framework created friction in a defined category of legitimate information sharing, and that a specific exception was needed to remove it.
The NPRM has not been finalized, so the proposed exception is not currently part of the Privacy Rule.
Where Enforcement Has Landed
OCR's cumulative complaint data currently lists use or disclosure of more than the minimum necessary PHI as the fifth most often alleged HIPAA compliance issue in complaints.5 That is not a fringe issue; it puts minimum necessary in the same tier as impermissible uses and disclosures generally, lack of safeguards, lack of patient access, and lack of administrative security safeguards.
As of October 31, 2024, OCR had received over 374,321 HIPAA complaints, resolved 99% of them, and settled or imposed civil money penalties in 152 cases, totaling $144,878,972.5 OCR does not publish minimum-necessary-specific resolution rates, so the available aggregate data supports a narrower point: most HIPAA complaints do not become public monetary enforcement actions.
The risk profile is specific. In public OCR enforcement materials, minimum necessary themes typically appear alongside adjacent theories: impermissible disclosure, authorization scope, access authorization, monitoring, or Security Rule safeguards, rather than as a standalone enforcement theory. For risk planning, minimum necessary is better treated as a potential compounding issue than as the most likely standalone enforcement trigger.
Adjacent Enforcement Patterns
Three cases illustrate how minimum necessary shows up in practice:
• Holy Redeemer Family Medicine ($35,581, 2024).6 A practice sent a patient's full medical record to a prospective employer when the patient had only authorized disclosure of one specific test result. The fact pattern looks like a minimum necessary issue. But OCR's resolution agreement framed the violation as an impermissible disclosure without valid authorization under 45 C.F.R. § 164.502(a), not as a standalone minimum necessary case. It is useful as a cautionary illustration of authorization-scope discipline, but it is not proof that OCR is actively enforcing minimum necessary as an independent enforcement theory.
• BayCare Health System ($800,000, 2025).7 A malicious insider breach at a Tampa hospital led OCR to find failures to authorize access to ePHI consistent with Privacy Rule requirements, risk management deficiencies, and failure to review system activity. OCR's release included language about workforce users having only the access necessary to perform their jobs (which carries minimum necessary undertones), but the case is better characterized as a Security Rule access authorization and monitoring failure.
• Anthem Inc. ($16,000,000, 2018).8 The largest HIPAA settlement in history resolved violations following a cyberattack affecting nearly 79 million records. The case illustrates the enterprise-level risk of overbroad workforce access and weak access controls. It is better understood as a Privacy and Security Rules case, not a clean minimum necessary enforcement action, and should not be cited as proof of standalone minimum necessary enforcement without a source tying the conduct specifically to 45 C.F.R. §§ 164.502(b) or 164.514(d).
AI Arrangements: The New Hard Question
Applied to AI, the minimum necessary standard produces questions without clean answers. The rule predates large language models ingesting patient records at scale, and applying it to AI arrangements requires working through issues that the 2002 framework was never designed to address.
The dominant narrative around HIPAA and AI focuses on BAA requirements, data security, and breach liability. Minimum necessary introduces different issues: ones that force analysis of what the AI system is actually doing with PHI, whether the purpose is bounded, and how the standard's exemptions map onto clinical AI workflows.
What OCR Has Not Said
Note: OCR has not issued comprehensive guidance explaining how the minimum necessary standard applies to AI inference, model training, fine-tuning, product improvement, or cross-client learning. That means organizations should avoid treating any single AI/HIPAA answer as categorical. The defensible approach is to document the permitted purpose, vendor status, PHI scope, data flow, training restrictions, and de-identification analysis before PHI is made available to an AI system.
That gap in guidance matters practically: organizations are left making their own minimum necessary determinations for AI arrangements with limited regulatory clarity and significant uncertainty about what "reasonable efforts" means in this context. The analysis below reflects how the existing framework applies to AI. It is not OCR doctrine.
Start Here: The Threshold Taxonomy
Before asking whether the data is 'minimum necessary,' ask what the arrangement actually is:
• What is the permitted purpose? Treatment, payment, health care operations, research, authorization-based use, de-identification, or independent vendor product development? Each has a different legal framework and different minimum necessary implications.
• What is the vendor's status? Business associate performing services on behalf of the covered entity, subcontractor BA, or an entity that should not be receiving PHI at all?
• What is the data actually used for? Inference only, local model tuning, general model training, vendor product improvement, or cross-client benchmarking? These land differently under HIPAA.
• Is the data PHI? De-identified data under 45 C.F.R. § 164.514(a)-(b) is not PHI. If the covered entity de-identifies before providing data to the AI system, minimum necessary does not govern that data at all.
Only once you've characterized the arrangement does minimum necessary analysis produce a defensible answer.
Does Minimum Necessary Apply?
Yes, unless an exemption applies. New technology complicates the analysis without changing the underlying framework.
The standard requires reasonable efforts to limit PHI to what's necessary for the intended purpose.2 For an AI arrangement, you need to know what the intended purpose actually is, which in many deployments is less obvious than it sounds. The same underlying PHI may be used simultaneously for inference (completing a defined task), model improvement (making the system better over time), and vendor product development (building a better general tool). Those are different purposes, and minimum necessary applies to each separately.
Inference and Training: Two Different Analyses
Inference is when an AI system processes PHI to produce an output: a clinical note, a diagnostic suggestion, a risk score, a scheduling recommendation. The purpose is bounded by the defined task. The minimum necessary question here is tied to that task: scope the data to what the system actually uses to produce its output. A clinical AI tool that needs medication lists and recent lab values to flag a drug interaction does not need billing history or unrelated historical records. This analysis is tractable.
Training is harder. The purpose may be broader, the claimed data need may be less bounded, and the benefit may accrue partly to the vendor or to other customers. A covered entity is in a stronger position when: training is limited to a defined function performed for that covered entity; it is expressly permitted in the BAA; it is technically and contractually segregated from other uses; and the trained model or its improvements are not reused for independent vendor commercialization or cross-client benefit. The farther the arrangement moves toward general-purpose product development using identifiable PHI, the weaker the HIPAA justification becomes.
One framing to avoid: 'more data produces better models, therefore we need all of it.' AI vendors may argue for broader datasets on the theory that broader training or tuning improves performance. HIPAA does not accept model-performance optimization as a substitute for defining the permitted purpose and limiting PHI accordingly.
When Minimum Necessary Does Not Apply
The exemptions still apply in AI contexts, and they cover a significant portion of clinical AI activity. Two cautions apply: 'doesn't apply' means this particular standard is not the gating requirement, not that there is no HIPAA issue. And the treatment exception for vendors requires more care than it might seem.
Treatment.1 The minimum necessary standard does not apply to disclosures to or requests by a health care provider for treatment purposes. For provider-to-provider treatment disclosures, the exception remains strong even if AI supports the clinical workflow: a diagnostic AI tool assisting a treating physician, an ambient documentation system recording a clinical encounter, a sepsis model used by the treating team. But the exception should not be stretched past its regulatory limit. If PHI is disclosed to an AI vendor, retained for model improvement, used for product development, or combined across customers, the analysis cannot stop at 'treatment.' The organization still has to address vendor status, BAA scope, permitted purpose, downstream use restrictions, and Security Rule controls. The treatment exception removes the minimum necessary question for a qualifying treatment disclosure; it does not bless the full vendor arrangement.
De-identification. De-identified data under 45 C.F.R. § 164.514 is not PHI. Minimum necessary does not govern non-PHI. If a covered entity de-identifies before providing data for model training, the HIPAA minimum necessary framework does not apply. This is the cleanest path for AI training use cases.
Valid authorization. Minimum necessary does not apply to uses or disclosures made under a valid HIPAA authorization, but the use or disclosure must stay within the authorization's scope. Authorization removes the minimum necessary question; it does not permit disclosure of PHI that wasn't covered by the authorization.
Reasonable reliance on the BA. When a covered entity discloses PHI to a BA for a specified function, it may reasonably rely on the BA's representation that the information is the minimum necessary for the stated purpose. This simplifies operations, but it requires the stated purpose to independently justify the disclosure.
Is It a Violation? And Does It Actually Matter?
Whether a given AI arrangement violates minimum necessary is often genuinely uncertain. Applying 'reasonable efforts' to novel technology produces a range of defensible outcomes. A covered entity with documented policies scoping PHI access to what the AI vendor's stated function requires, combined with reasonable reliance on the BA's representations, is in a defensible position even if a future reviewer might have used a narrower dataset.
The AI risk that actually matters is broader than minimum necessary. Purpose limitation, downstream disclosure, and Security Rule compliance all sit alongside it: is the AI vendor using your PHI to improve a product that benefits competitors, or using your patients' data beyond the service you're paying for? What happens to learned model representations if the vendor is acquired or changes its terms? AI systems holding ePHI would be subject to substantially strengthened cybersecurity expectations if the Security Rule NPRM is finalized in its current or similar form. That rule is not AI-specific, but it would apply to any system that creates, receives, maintains, or transmits ePHI.
Minimum necessary still earns its keep in the AI context as a contracting discipline. Drafting a BAA that specifies exactly what data the AI vendor receives, for what purpose, and with what restrictions on further use forces the conversations you need to be having about purpose limitation anyway. Getting minimum necessary right in an AI BAA tends to produce the answers to those broader questions as a byproduct.
Getting minimum necessary right in AI arrangements forces the right questions. It separates what an AI vendor actually needs from what's simply convenient to give them.
The Persistent Confusion Problem
In 2016 testimony before the NCVHS Subcommittee, AHIMA reported survey results from its members showing substantial uncertainty about how organizations defined and operationalized minimum necessary: 38% were unsure whether their organization had adopted a definition, another 21% were still developing one, and one-third had no policies at all.9
AHIMA's board president testified that this confusion created serious practical risks, and called on HHS to develop a clearer definition with objective criteria rather than leaving each organization to define the standard for itself. The comprehensive guidance never materialized. What organizations have is the original 2002 OCR guidance document, a set of FAQs, and a body of enforcement cases that illustrate the edges of the rule without defining its center.
The practical result: covered entities and their AI vendors are making minimum necessary determinations with limited regulatory guidance and significant uncertainty about what 'reasonable efforts' means for their specific context. For AI arrangements, where the circumstances are novel and the regulatory framework is being stretched well past its original design, that uncertainty is amplified. OCR has not issued comprehensive guidance on minimum necessary and AI. The 2024 Section 1557 final rule addressed nondiscrimination in AI tools; the 2025 Security Rule NPRM addressed cybersecurity controls for ePHI. Neither addressed the threshold question of how to apply minimum necessary analysis to AI data flows. The gap between the legal standard and current practice continues to grow as AI adoption accelerates.
What This Means in Practice
Check the exemptions first. Before applying minimum necessary analysis, confirm that none of the exceptions apply. Treatment, valid authorization, required-by-law, and HIPAA transaction compliance are all exit ramps. A significant portion of clinical AI activity qualifies for the treatment exception, and many compliance conversations skip the exemption analysis entirely, applying minimum necessary where none is required.
Run the threshold taxonomy. For any AI arrangement, answer the four characterization questions: what is the permitted purpose, what is the vendor's regulatory status, what is the data actually used for, and is it PHI? The answers determine which framework governs.
Reasonable efforts is a documentation game as much as a substantive one. A covered entity with documented policies defining what data its AI vendors receive, why, and for what purpose has a far stronger position than one without, even if the actual data flows look similar. Document the justification. If the vendor's function requires access to full records, say so explicitly.
Get specific in your BAAs. Standard BAA language wasn't designed for arrangements where PHI will be used for model training, inference at scale, or product improvement. You need explicit contractual restrictions on purpose: the vendor can use this data to provide this service and nothing else, backed by audit rights and termination triggers if those restrictions are violated.
Take de-identification seriously as a real option. For model training in particular, ask whether de-identified or synthetic data could produce a functional model at the required quality before committing to a PHI-based training arrangement. If it can, the minimum necessary question (and most of the HIPAA framework) disappears for that use.
Create five evidence artifacts for any AI arrangement involving PHI:
• An AI use-case intake record documenting the business purpose and legal basis for the disclosure;
• A PHI data map showing exactly what categories flow to the AI system;
• A minimum necessary rationale justifying the scope of that data;
• A BAA or service exhibit with explicit permitted use and prohibited training or product-improvement language; and
• A de-identification or synthetic-data feasibility note explaining why PHI was necessary if de-identification was not used.
These artifacts serve minimum necessary compliance, but they also serve the purpose limitation, Security Rule, and governance conversations simultaneously. That is the point: getting minimum necessary right in AI arrangements forces most of the conversations you need to be having anyway.
Where This Leaves Us
The minimum necessary standard is twenty-four years old and has not been fundamentally revised in that time. The healthcare landscape it governs has changed substantially: electronic health records, interoperability mandates, value-based care models, and now AI systems that can ingest large patient datasets quickly. The rule was designed for a world where data minimization meant not faxing more pages than necessary.
The core principle (don't share more patient information than the purpose requires) has held up. The 'reasonable efforts' standard, implemented through policies and procedures, can accommodate new technologies without legislative revision.
The guidance hasn't kept pace. Organizations are trying to apply a 2002 framework to 2026 technology with limited regulatory clarity. HHS acknowledged in the 2021 NPRM that the standard had created friction in defined care coordination contexts. That rulemaking stalled. The guidance gap persists.
For now, the work is in the details: clear policies, appropriately scoped BAAs, documented justifications, and honest conversations about what AI systems actually need versus what is simply convenient to provide. In a space where the regulatory framework is lagging the technology, When OCR is already looking at an AI arrangement, minimum necessary may not be the lead allegation. But weak scoping, vague BAAs, and undocumented data flows can easily become part of the problem.
Sources
1. OCR HIPAA Privacy, Minimum Necessary [45 C.F.R. §§ 164.502(b), 164.514(d)], Dec. 3, 2002 (rev. Apr. 4, 2003), available at hhs.gov (OCR Minimum Necessary Guidance). See also 45 C.F.R. § 164.502(b)(2)(i) (treatment exception).
2. OCR Minimum Necessary Guidance, supra note 1; see also OCR FAQs on Minimum Necessary, FAQ 207, 208, 213, available at hhs.gov/hipaa/for-professionals/faq/minimum-necessary/.
3. Health Information Technology for Economic and Clinical Health Act (HITECH), Pub. L. No. 111-5, § 13401, 123 Stat. 226 (2009); Modifications to the HIPAA Privacy, Security, Enforcement, and Breach Notification Rules Under HITECH (Omnibus Rule), 78 Fed. Reg. 5566 (Jan. 25, 2013) (codified at 45 C.F.R. pts. 160, 164).
4. Proposed Modifications to the HIPAA Privacy Rule To Support, and Remove Barriers to, Coordinated Care and Individual Engagement, 86 Fed. Reg. 6446, 6527 (Jan. 21, 2021).
5. OCR, Enforcement Highlights (as of Oct. 31, 2024), available at hhs.gov/hipaa/for-professionals/compliance-enforcement/data/enforcement-highlights/. Statistics: 374,321 complaints received; 370,578 resolved (99%); 152 settlements or CMPs totaling $144,878,972.
6. HHS Office for Civil Rights, Resolution Agreement and Corrective Action Plan: Holy Redeemer Family Medicine (2024), available at hhs.gov/hipaa/for-professionals/compliance-enforcement/agreements/holy-redeemer-hospital-ra-cap/.
7. HHS Office for Civil Rights, Press Release: HHS Reaches HIPAA Settlement with BayCare Health System Over Security Rule Violations (2025), available at hhs.gov/press-room/hhs-ocr-hipaa-agreement-baycare.html.
8. HHS Office for Civil Rights, Resolution Agreement: Anthem, Inc. (2018), available at hhs.gov/hipaa/for-professionals/compliance-enforcement/agreements/.
9. AHIMA, Testimony of Melissa Martin Before the NCVHS Subcommittee on Privacy, Confidentiality, and Security Regarding the HIPAA Minimum Necessary Standard (2016); summarized at HIPAA Journal, "Call Issued for Further Guidance on HIPAA Minimum Necessary Standard," available at hipaajournal.com/ahima-hipaa-minimum-necessary-standard-3481/.
10. HHS Office for Civil Rights, Notice of Proposed Rulemaking: HIPAA Security Rule (Dec. 27, 2024), 90 Fed. Reg. 898 (Jan. 6, 2025), available at hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/.