IMPORTANT DISCLAIMER: This article reflects the author’s interpretation of applicable federal regulations and HHS guidance as of September 2026. The article is provided for educational purposes only to assist coders and auditors in understanding the regulatory environment in which they work. This is not legal advice, and it does not constitute an attorney-client relationship. The interpretation and application of healthcare compliance law to specific facts, circumstances, and organizational practices requires individualized legal analysis by qualified counsel admitted in your jurisdiction. Before adopting any policy, implementing any practice, making any compliance determination, or submitting patient information to any vendor or tool based on the interpretations presented in this article, consult with your organization’s legal counsel or qualified healthcare compliance counsel to ensure that the proposed course of action complies with applicable law and is appropriate for your specific circumstances. HHS regulations continue to evolve, and regulatory interpretation remains subject to change through rulemaking, guidance updates, and enforcement actions. This article’s statement of the law is current as of the publication date but should not be relied upon without confirmation that the cited regulations and guidance remain current and unchanged.
The core principle governing how coders and auditors handle patient information is straightforward: protected health information may not be disclosed except where the Privacy Rule permits, regardless of the form in which the disclosure occurs. Whether information is emailed to a consultant, entered into a vendor software platform, or typed into an artificial intelligence tool, the same legal standard applies. The difference for your work is that these tools accelerate the volume and speed at which information moves, making the handling of that information more visible to compliance review and more likely to be audited after the fact. This article addresses the standards that apply when you communicate patient information in the context of coding, auditing, and documentation review, with particular attention to where artificial intelligence changes the analysis and where it does not.
The Privacy Rule as the Governing Standard
Protected health information is defined by HIPAA at 45 CFR 164.500 and includes any information in a medical record or payment record that can be used to identify an individual. The Privacy Rule at 45 CFR 164.502(a) states plainly that protected health information may not be used or disclosed except as permitted or required by the Privacy Rule. This standard does not contain exceptions for training, for efficiency, for external review, or because disclosure might be helpful to improving patient care. The permission must exist, or the disclosure is not compliant.
For coders and auditors, this means that when you submit patient information to a vendor, an AI tool, or an external consultant for documentation review, coding verification, or audit support, you are making a disclosure of PHI. The standard does not ask what the tool does with the information after it receives it. The standard asks whether the organization making the disclosure had authority to disclose that information to that recipient for that purpose. The presence or absence of a Business Associate Agreement (described below) determines that authority.
What Actually Constitutes PHI: Identifiers Plus Health Information
A critical threshold question for coders and auditors is whether information you are considering for submission actually qualifies as PHI. The answer depends on whether the information combines two elements: an identifier AND health information.
The Regulatory Requirement
The Privacy Rule protects “protected health information,” which is defined as “individually identifiable health information” held or transmitted by a covered entity or business associate. This definition requires both elements:
- Individually identifiable — means the information relates to an identified individual or can reasonably identify the individual
- Health information — information about the individual’s health condition, health care, or payment for health care
HHS Office for Civil Rights has emphasized this dual requirement. In its 2024 Updated Guidance on Use of Online Tracking Technologies, OCR stated:
“To constitute PHI, OCR has emphasized that the information must be related to an individual’s past, present, or future health, health care, or payment for health care.“
Source: HHS Office for Civil Rights, “Use of Online Tracking Technologies by HIPAA Covered Entities” (Updated March 2024)
Claim Numbers, Account Numbers, and Identifiers Standing Alone
This distinction matters directly for your work. Identifiers standing alone—including claim numbers, account numbers, medical record numbers, and similar identifiers—are not necessarily PHI.
HHS Office for Civil Rights has stated:
“Identifying information alone, such as personal names, residential addresses, or phone numbers, would not necessarily be designated as PHI.“
Source: HHS Office for Civil Rights, Guidance Regarding Methods for De-identification of Protected Health Information
Applied to coding and auditing: A claim number submitted to a vendor or tool without accompanying diagnosis codes, dates of service, procedure codes, or other health information is not PHI under this analysis. However, the same claim number combined with a diagnosis code, treatment date, or procedure code becomes PHI because it is now “individually identifiable health information.”
The Reverse Is Also True
Just as identifiers alone are not PHI, health information standing alone without identifiers is also not PHI. Diagnosis codes without any identifier linking them to an individual do not qualify as PHI. The Privacy Rule requires both elements.
Why This Matters for Your Compliance Decisions
If you are submitting information to a vendor, AI tool, or external consultant, you can use this framework to determine whether a Business Associate Agreement is required:
- Claim number only = Not PHI; no Business Associate Agreement required (but verify with counsel in your jurisdiction)
- Diagnosis code only = Not PHI; no Business Associate Agreement required
- Claim number + diagnosis code = PHI; Business Associate Agreement required
- Claim number + procedure codes + treatment dates = Clearly PHI; Business Associate Agreement required
Important Caveats
Before applying this analysis to your organization’s specific practices, understand the following qualifications:
Context and Re-identification Risk. Even though a claim number alone is technically not PHI, you must assess whether it could be re-identified when combined with other reasonably available information. If your claim numbering system is sequential or follows a predictable pattern, the number plus a discharge date or procedure code could identify someone in a small population. The Safe Harbor de-identification standard requires that the covered entity have “no actual knowledge” that remaining information could re-identify an individual. If you know the claim number can be re-identified in combination with other information, it becomes PHI in your hands. This is an interpretation and application question that requires counsel review for your specific situation.
State Law Variation. Your state may have its own definition of what constitutes protected health information. Some state laws are stricter than HIPAA and may classify identifiers or health information differently. Before relying on the federal standard to avoid compliance safeguards, confirm with counsel that your state law does not impose additional restrictions.
Designated Record Set Treatment. If a claim number is part of your organization’s “medical records” or “billing records” maintained as a designated record set under 45 CFR 164.501, it may be treated as part of a collection of information that includes PHI, even if the number standing alone is not. This may trigger additional obligations such as patient access rights under 45 CFR 164.524 and amendment rights under 45 CFR 164.526.
Recommendation. Before submitting any information—even if you believe it does not constitute PHI—consult with your organization’s legal counsel regarding: (1) whether your jurisdiction has state laws that define PHI differently than HIPAA; (2) whether the information carries any reasonable re-identification risk in your specific context; (3) whether the information is being submitted as part of a designated record set; and (4) how your organization’s security policies should treat such information in your systems. The safer compliance approach is often to treat anything that might combine with other available information to re-identify someone as potentially PHI, even if it does not technically meet the definition in isolation. This reflects the regulatory burden, which falls on your organization to demonstrate that information is not PHI, not on the other party to prove that it is.
Minimum Necessary: The Discipline That Prevents Unnecessary Disclosure
Even where a disclosure is otherwise permitted, the minimum necessary standard applies to most uses and disclosures. This standard is established at 45 CFR 164.502(b) and 45 CFR 164.514(d) and requires covered entities to limit uses, disclosures, and requests of PHI to only the amount reasonably needed to accomplish the intended purpose.
The practical application of this standard for coders is direct. When you submit a case to an external coding consultant or to an AI-assisted coding tool for documentation review, the entire patient record is rarely necessary. A question about the precise code for a particular operative procedure does not require the patient’s demographic information, account number, insurance information, billing history, or any information unrelated to that specific clinical question. Similarly, an audit of coding accuracy in a particular service line or specialty does not require extraction of complete charts; focused record samples that include only the clinical information necessary to evaluate the coding decision are sufficient.
The minimum necessary standard requires documentation of your policy about how much information is included in each type of request or submission. If an external coder regularly receives entire charts rather than focused case information, and the organization has not documented that this volume is necessary for the disclosed purpose, the organization has not satisfied the minimum necessary requirement. This is particularly important when the recipient is an AI tool, because the tool may retain copies of everything submitted and may use it for purposes beyond the scope of your authorization. Your organization’s legal counsel should review what constitutes “minimum necessary” in the context of your specific coding and audit workflows.
De-Identification as the Path to Unrestricted Information Use
When information has been properly de-identified under the standards at 45 CFR 164.514(a) through (c), it is no longer protected health information, and the Privacy Rule places no restrictions on its use or disclosure. Information that is no longer PHI may be submitted to AI tools, external consultants, published in educational materials, or used for any other purpose without Business Associate Agreements, authorization forms, or compliance review. The threshold question is therefore whether the information you are working with has actually been de-identified.
HHS recognizes two rigorous methods of de-identification, plus a third option for specific authorized purposes. The interpretation and application of these standards to your organization’s specific data practices should be reviewed by qualified legal counsel, particularly when de-identified information will be used for research, training, or external publication.
Safe Harbor De-Identification
The Safe Harbor method is defined at 45 CFR 164.514(b)(2) and is the more commonly used approach. Under Safe Harbor, information is de-identified if a covered entity removes all eighteen identifiers listed in the regulation. The identifiers that must be removed are:
- Names of the individual, relatives, employers, and household members
- Geographic subdivisions smaller than a state, except that a three-digit ZIP code prefix is permitted under a narrow exception described in the regulation
- All elements of dates directly related to the individual (birth date, admission date, discharge date, death date, and all other dates) except the year, unless dates are necessary for the research and the risks of re-identification are documented and minimized
- Ages in years or months for individuals age 90 or older, and age over 90
- Telephone and fax numbers
- Email addresses
- Social Security numbers
- Medical record numbers
- Health insurance beneficiary numbers
- Account numbers
- Certification or license numbers
- Vehicle and license plate identifiers and serial numbers
- Device identifiers and serial numbers
- Universal resource locators (URLs)
- Internet protocol (IP) addresses
- Biometric information, including fingerprints and voice recordings
- Full face photographs and any comparable image
- Any other unique identifying number, characteristic, or code, except a re-identification code that permits re-identification only by persons authorized to create or use the code
This list is expansive, and the Safe Harbor standard also requires that the covered entity have no actual knowledge that the remaining information could identify the individual. The effect of the third requirement—dates—is particularly relevant for coders. A date of service combined with a distinctive procedure and a specific facility frequently constitutes enough information to identify a single patient without any name present. Safe Harbor treatment of dates therefore either requires removal of the date entirely (retaining only the year) or, for materials used in research, demonstration of how the risks of re-identification have been assessed and minimized.
Critically, Safe Harbor de-identification is a one-time determination made when the information is prepared. Once the eighteen identifiers have been removed and the covered entity certifies that it has no actual knowledge that the remaining information could identify the individual, that information is de-identified and the Privacy Rule no longer applies to subsequent uses. Coders and auditors should understand that visual redaction—such as highlighting or obscuring text with a black bar—does not constitute removal under this standard. Removing underlying text, so that the identifier is not present in the document at all, is what the regulation contemplates.
Expert Determination De-Identification
Expert Determination is the second method of de-identification recognized at 45 CFR 164.514(b)(1). This method requires a person with appropriate knowledge and experience in applying statistical and scientific principles to determine that the risk of re-identification is very small. The expert applies those principles, documents the methods used and the results of the analysis, and certifies that the risk is acceptable. The documentation of the expert’s work is what compliance reviewers will examine, so this method is particularly important for coders and auditors to understand as organizations become more sophisticated in using AI for training, pattern recognition, and performance improvement.
HHS guidance emphasizes that the expert’s documentation is the compliance artifact. If an organization has committed to using expert determination, the expert’s report becomes part of the compliance program’s documentation and must be retained for six years. Unlike Safe Harbor, which requires removal of specific identifiers, expert determination permits flexibility. For example, geographic detail or dates might be retained if the expert’s statistical analysis determines that the combination of remaining data presents only a very small re-identification risk. However, the justification for retaining those elements must be documented by the expert, and the analysis must reflect knowledge of statistical methods and the specific dataset. Before using Expert Determination as a basis for de-identification, consult with counsel regarding whether your organization has access to appropriately qualified experts and whether the documentation created will meet regulatory expectations in a compliance investigation or audit.
Limited Data Sets and Data Use Agreements
A third option, often overlooked, permits retention of dates and certain geographic detail through a limited data set agreement. This method is addressed at 45 CFR 164.514(e) and permits covered entities to disclose information with dates and three-digit ZIP codes (or larger geographic units) for purposes of research, public health, and health care operations, provided that a written data use agreement restricts how the recipient may use and re-disclose that information. The data use agreement is the compliance mechanism and must be in place before the disclosure occurs. For coders and auditors, this method is relevant when sample records are being used for internal performance improvement, benchmarking, or outcome analysis, provided the business associate or internal team signs a data use agreement that restricts their use of the information. Counsel should review any data use agreement before it is executed to ensure that it addresses your organization’s intended uses and includes appropriate restriction language.
The Business Associate Agreement as the Permission Structure
A vendor that creates, receives, maintains, or transmits protected health information on behalf of a covered entity is a business associate, as defined at 45 CFR 160.103. A written business associate agreement satisfying the requirements of 45 CFR 164.504(e) must be in place before any protected health information is disclosed to that vendor. The agreement must address how the business associate will use and disclose the information, what safeguards the business associate will implement, and what obligations the business associate assumes with respect to breach notification, access rights, amendment rights, and other Privacy and Security Rule provisions.
The critical point for coders is this: the existence of a Business Associate Agreement does not give a covered entity unlimited authority to disclose information. The agreement establishes the relationship and the permitted purposes, but the minimum necessary standard still applies, and the uses permitted by the agreement must be consistent with the organization’s representation to the patient about how information will be used.
Business Associate status is a function of the contract between the vendor and the covered entity, not the brand of the product. The same vendor may offer a consumer tier with no business associate agreement and an enterprise health care tier with one. Before submitting any PHI to a vendor platform, coders should confirm with their compliance officer that an executed Business Associate Agreement is in place. If the vendor offers no Business Associate Agreement, the information submitted cannot be PHI. This is the reason that organizations often ask external coders to work from de-identified materials or materials that have been prepared for disclosure through a limited data set agreement.
Your organization should not submit any patient information to any vendor or tool without first confirming with legal counsel that appropriate agreements are in place and that the intended use complies with the terms of those agreements.
Subcontractors and Downstream Disclosure
The Business Associate Agreement obligation extends to subcontractors. If a business associate uses a subcontractor that handles PHI, that subcontractor is itself a business associate and requires its own written agreement with the covered entity or with the business associate on the covered entity’s behalf. This is particularly relevant when coding or auditing software relies on model hosting, cloud infrastructure, or downstream processing. If a coding software vendor stores patient information in cloud infrastructure operated by a different company, that cloud operator is a business associate. If an AI model is trained using patient information by a third-party vendor, that third-party vendor is a business associate.
The Business Associate Agreement requirement does not disappear because a tool uses artificial intelligence. The chain of responsibility must extend from the covered entity through every vendor and subcontractor that touches the information. Before using any AI tool or cloud-based platform that will process patient information, your organization should confirm with counsel that all subcontractors in the chain have been identified and that appropriate agreements are in place.
Documentation Retention and Audit Trail Requirements
The Security Rule at 45 CFR 164.316 requires covered entities and business associates to retain documentation of compliance efforts for six years from the date the documentation was created or revised. This is not a guideline; it is a regulatory obligation, and OCR investigators will request these documents in response to breach investigations, audits, or complaints.
For coders and auditors, the audit trail obligation means that when you use an AI tool to code records or when you review AI-assisted coding output, a record of that action and that work must be maintained. The specific documentation required includes:
- Records of which cases were submitted to which tools or vendors, including the date and the business associate
- Evidence of what information was submitted (de-identified, limited data set, or full PHI under a Business Associate Agreement)
- Documentation of any vendor agreement, Business Associate Agreement, or data use agreement under which the disclosure was made
- Records of validation testing performed on any AI tool, including the results of that testing and any documented errors or limitations
- Policies and training materials addressing the use of the tool
- Audit samples of output from the tool, including cases where the tool’s recommendation was followed and cases where it was overridden
- Incident reports if the tool generated an incorrect code or if information was disclosed to the tool without proper authorization
An organization that has used an AI tool to assign codes or review documentation but has no documentation of validation testing, no evidence of business associate agreements, no audit samples, and no written policy about how the tool is to be used is not in a defensible position if the tool’s performance is later questioned. Your organization’s compliance officer and legal counsel should establish clear protocols for what documentation is created, retained, and made available for regulatory inspection.
Artificial Intelligence and Section 1557 Nondiscrimination Requirements
On January 10, 2025, the HHS Office for Civil Rights issued a guidance letter clarifying how Section 1557 of the Affordable Care Act applies to artificial intelligence and other emerging technologies used in patient care. This guidance is directly relevant to coders and auditors because it establishes specific obligations when AI tools are used to make decisions affecting patient care or health outcomes.
Section 1557 at 42 USC 18116 prohibits discrimination on the basis of race, color, national origin, sex, age, or disability in health programs and activities that receive Federal financial assistance. The final rule implementing Section 1557 was published on May 6, 2024 (89 FR 37610) and is codified at 45 CFR Part 92. The nondiscrimination requirement that applies specifically to patient care decision support tools is set forth at 45 CFR 92.210.
The regulation at 45 CFR 92.210(a) states: “A covered entity must not discriminate on the basis of race, color, national origin, sex, age, or disability in its health programs or activities through the use of patient care decision support tools.” This obligation applies to both automated tools (such as AI algorithms and machine learning models) and non-automated tools (such as manual clinical flowcharts and triage protocols). The regulation applies the longstanding principles of civil rights law to the use of technology, making clear that these protections do not cease when the technology changes.
Identifying and Mitigating Discrimination Risk
The OCR guidance describes two affirmative obligations for covered entities using patient care decision support tools, with an effective date of May 1, 2025.
First, covered entities must make reasonable efforts to identify whether any patient care decision support tool they use contains input variables that measure race, color, national origin, sex, age, or disability. The guidance indicates that “reasonable efforts” may include reviewing published articles about tools known to have discriminatory risk (citing examples including the race-adjusted eGFR equation used in kidney function assessment, pulse oximeters that have higher error rates in patients with darker skin tones, and crisis standards of care flowcharts that may screen out individuals with disabilities), researching peer-reviewed literature, obtaining vendor information about input variables, and developing internal policies requiring staff to document the inputs used in decision support tools.
OCR will evaluate whether a covered entity’s efforts to identify risk were reasonable by considering factors including the entity’s size and resources, the available information at the time the tool was adopted, whether the entity used the tool as the developer intended, and whether the entity has a formal process for evaluating tools.
Second, after identifying that a tool poses a discrimination risk, the covered entity must make reasonable efforts to mitigate that risk. Mitigation efforts may include implementing written policies and procedures for how the tool is used in decision-making, maintaining an internal registry of tools that pose discrimination risk, ensuring human review of decisions made by tools, training staff, and disclosing to patients the use of tools identified as posing a discrimination risk.
Application to Coding and Audit
For coders and auditors, the Section 1557 requirement translates into specific obligations regarding AI-assisted coding tools. If an organization uses an AI tool to assign codes or review documentation, the organization must:
- Determine whether the tool’s underlying algorithm uses any input variables that measure race, ethnicity, age, sex, or disability as factors in generating its output
- Document the results of that review
- If the tool does use such variables, assess whether the tool’s output varies in a way that could result in differential treatment based on those protected characteristics
- Implement controls to identify and override potentially discriminatory output
- Train coders on how to recognize and respond to discriminatory decisions
- Maintain an audit trail of instances where human coders overrode the tool’s recommendation due to concerns about accuracy or potential discrimination
This obligation does not require that covered entities stop using AI tools. Rather, it requires that entities understand the tools they use, identify potential sources of discrimination, and implement reasonable controls to mitigate that risk. OCR enforcement authority under Section 1557 becomes effective May 1, 2025, so covered entities should have these processes in place before that date. The interpretation of what constitutes “reasonable efforts” to identify and mitigate discrimination risk, and whether your organization’s current practices satisfy that standard, should be reviewed by counsel before May 1, 2025.
Coding Accuracy and the False Claims Act
The use of artificial intelligence in coding does not shift responsibility for claim accuracy to the vendor or to the tool. The provider or supplier submitting a claim certifies that the claim is accurate and truthful. Liability under the False Claims Act at 31 USC 3729 attaches to the submission of a claim knowing it is false or with deliberate ignorance or reckless disregard for the truth.
For coders, this means that using an AI tool to assign codes does not replace the coder’s obligation to verify that the code assigned is appropriate given the clinical documentation. Systematic reliance on a tool that has not been validated, or continued use after error patterns have been identified, can constitute deliberate ignorance or reckless disregard. Organizations should ensure that:
- The AI tool has been validated through documented testing and the validation results are retained
- Error patterns identified during audit are documented and addressed
- Coders are trained on how to evaluate the tool’s output and when to override it
- A regular audit sampling process is in place to assess the tool’s performance in the actual clinical environment
- Records of each audit, including the audit methodology, sample size, error frequency, and corrective actions, are retained for six years
If an audit identifies that an AI coding tool is systematically assigning codes that do not match the clinical documentation, the organization’s continued use of the tool without documented mitigation constitutes reckless disregard for accuracy, and liability exposure follows. Your organization should consult with counsel regarding what level of validation testing and ongoing audit oversight is appropriate for any AI-assisted coding tool you implement, and how to document that the tool is being used responsibly.
Operational Compliance Practices for Coders and Auditors
The legal framework translates into a practical checklist for your work:
Before Submitting Any Patient Information to a Tool or Vendor:
- Confirm with your compliance officer that a current, executed Business Associate Agreement or data use agreement is in place
- Understand exactly what information will be submitted, and confirm that the submitted information is limited to what is necessary for the specific purpose
- Determine whether the information is de-identified, part of a limited data set under agreement, or full PHI under a Business Associate Agreement
- If the information is being submitted to an AI tool, understand what the tool will do with the information after your use is complete (will it be retained, used for model improvement, or deleted immediately)
- Confirm that the vendor’s contract terms do not conflict with the Business Associate Agreement
- Before implementing any new process, confirm with legal counsel that the proposed information flow complies with applicable law and organizational policy.
When Using AI Tools for Coding or Documentation Review:
- Maintain a record of which cases were submitted, the date submitted, and whether validation testing had been completed before use
- Document any validation testing performed on the tool, including testing methodology and results
- Maintain samples of cases where the tool’s output was accepted and cases where it was overridden, including the reason for the override
- Train yourself and other users on the tool’s limitations, the circumstances under which override is appropriate, and any known discrimination risks
- If you identify error patterns or discrimination concerns, report these to compliance immediately and document the report
Documentation Retention:
- Retain all Business Associate Agreements and data use agreements
- Retain all validation testing results
- Retain all policies and training materials related to AI tools
- Retain all audit samples and audit reports
- Retain all incident reports related to tool performance or authorization concerns
- Retain all of the above for a minimum of six years from the date created or revised
- Establish a process with your compliance officer to ensure that all documentation necessary to demonstrate compliance is created, retained, and retrievable in the event of a regulatory investigation or compliance audit.
The Documentation Standard as the Governing Principle
Across every regulation and authority discussed, the organization’s compliance position is established by what it can produce. An organization may have made reasonable compliance decisions without recording them, but that organization is in a materially weaker position than one that has documented the analysis behind each decision. The existence of the documentation is what an OCR investigator will request, what an auditor will examine, and what will determine whether the compliance decision is upheld.
For coders and auditors, the practical application is this: when you submit patient information to a tool or external party, the compliance analysis is not complete until the authorization for that disclosure has been recorded, the limitation of information to minimum necessary has been documented, any validation testing has been retained, and the transaction has been incorporated into an audit trail that can be produced if questioned.
The technology has changed the volume and speed at which patient information moves through your organization. The standard governing how that movement is handled has not changed—and the expectation that documentation of compliance will be available is now more important than ever.
Citations
45 CFR 160.103 (definition of business associate)
45 CFR 164.500 et seq. (HIPAA Privacy Rule)
45 CFR 164.501 (definitions, including “individually identifiable health information”)
45 CFR 164.502(a) (use and disclosure standard)
45 CFR 164.502(b) (minimum necessary)
45 CFR 164.514(a)-(c) (de-identification standards and Safe Harbor)
45 CFR 164.514(b)(2) (eighteen identifiers)
45 CFR 164.514(e) (limited data sets)
45 CFR 164.504(e) (business associate agreement requirements)
45 CFR 164.316 (documentation retention – six years)
45 CFR Part 92 (Section 1557 nondiscrimination requirements)
45 CFR 92.210 (patient care decision support tools)
89 FR 37610 (Section 1557 final rule, May 6, 2024)
31 USC 3729 (False Claims Act)
42 USC 18116 (Section 1557 of the Affordable Care Act)
HHS Office for Civil Rights, “Ensuring Nondiscrimination Through the Use of Artificial Intelligence and Other Emerging Technologies” (January 10, 2025)
HHS Office for Civil Rights, “Use of Online Tracking Technologies by HIPAA Covered Entities” (Updated March 2024)
HHS Office for Civil Rights, “Guidance Regarding Methods for De-identification of Protected Health Information”
FINAL DISCLAIMER
This article reflects the author’s interpretation of applicable federal regulations and HHS guidance as of September 2026. The article is provided for educational purposes only to assist coders and auditors in understanding the regulatory environment in which they work. This is not legal advice, and it does not constitute an attorney-client relationship. The interpretation and application of healthcare compliance law to specific facts, circumstances, and organizational practices requires individualized legal analysis by qualified counsel admitted in your jurisdiction. Before adopting any policy, implementing any practice, making any compliance determination, or submitting patient information to any vendor or tool based on the interpretations presented in this article, consult with your organization’s legal counsel or qualified healthcare compliance counsel to ensure that the proposed course of action complies with applicable law and is appropriate for your specific circumstances. HHS regulations continue to evolve, and regulatory interpretation remains subject to change through rulemaking, guidance updates, and enforcement actions. This article’s statement of the law is current as of the publication date but should not be relied upon without confirmation that the cited regulations and guidance remain current and unchanged.