Tag: PHI

Why Did a Puerto Rico Healthcare Company Pay $2.7 Million in HIPAA Penalties When It Doesn’t Even Treat Patients?

Posted by Jaime Farrant on September 16, 2026

The most common HIPAA violation in medical offices isn’t caused by hackers. It is one caused by never writing one specific document.

In December 2024, the U.S. Department of Health and Human Services’ Office for Civil Rights (“OCR”) announced a $250,000 settlement with Inmediata Health Group, a “clearinghouse” (an intermediary that converts medical claims into the standard format insurance plans require) based in Puerto Rico that processes data for physicians, dentists, hospitals, laboratories, and health plans across the island.

What happened? Between May 2016 and January 2019, the health information of 1,565,338 people held by Inmediata became publicly accessible on the internet due to a website misconfiguration. That information included names, dates of birth, addresses, Social Security numbers, medical diagnoses, and treatment information — all indexed and accessible through Google.

OCR identified the root cause: Inmediata had never conducted an adequate risk analysis, and it wasn’t monitoring activity on its information systems.

The total cost of this website error was far more than $250,000. Between the OCR settlement, a $1.4 million multi-state settlement with 32 state attorneys general and Puerto Rico, and a $1,125,000 class-action payout, the incident cost Inmediata at least $2.7 million.

$2.7 million in penalties for not having a document required since 2005.

What Is a Risk Analysis, and Why Is It Mandatory?

HIPAA’s Security Rule, at 45 C.F.R. § 164.308(a)(1)(ii)(A), requires every covered entity and business associate to conduct “an accurate and thorough assessment of the potential risks and vulnerabilities” to the confidentiality, integrity, and availability of the electronic health information it handles.

There’s a technical detail here that many people overlook. The Security Rule splits its requirements into 2 categories: requiredand addressable. Required specifications must be implemented by every covered entity and business associate. There’s no flexibility, no alternative, and no exception for the size of the practice. A solo physician’s office has the same obligation as a hospital.

Addressable specifications, on the other hand, do allow flexibility: if your office determines a measure isn’t reasonable given its size, you can document why and adopt an alternative instead.

The Security Rule was designed to account for the size and complexity of your operation, your technical infrastructure, the cost of security measures, and the probability and severity of your risks. A small practice doesn’t need the same analysis as a hospital system. But it needs one.

OCR Is Actively Looking for These Assessments

In October 2024, OCR launched an enforcement initiative dedicated exclusively to this requirement, called the Risk Analysis Initiative. By 2026, it had already announced roughly a dozen enforcement actions.

The reasoning behind focusing on this is fairly simple. These are straightforward cases for OCR: the question they need to answer is: do you have this document or not?

If you’re a HIPAA-covered entity, you need to understand that, if OCR opens an investigation, the first document they’ll ask for is your risk analysis — and most offices can’t produce one.

Being a small practice or business doesn’t protect you from being sanctioned. For example, Bryan County Ambulance Authority (“BCAA”), an entity serving just over 14,000 people, was the first case under this initiative. It settled with HHS for $90,000 following a ransomware attack. The investigation concluded that BCAA had never conducted an adequate risk analysis. Similarly, West Georgia Ambulance, an ambulance company in Carroll County, Georgia, paid $65,000 to HHS in a settlement for failing to conduct a risk analysis, failing to maintain a security awareness training program for its employees, and failing to implement policies and procedures for the Security Rule. 500 individuals were affected by this incident.

OCR recently expanded its investigative focus from “risk analysis” to “risk management.” As a result, the question is no longer just “do you have the document?” but “can you show you acted on what you found?” An analysis done 5 years ago, filed away and never acted on, could today be seen as nearly as bad as having no analysis at all.

Why Should This Matter to You?

Here are at least 4 reasons:

First: ignorance isn’t a defense. The Security Rule has been in force for more than 20 years. OCR has been explicit in concluding that not knowing the Rule doesn’t excuse anyone. At best, it might lower the penalty, but it will not eliminate it.

Second: you face double legal exposure. Since the federal HITECH Act was passed, state attorneys general have independent authority to bring civil actions for HIPAA violations. The Inmediata case demonstrates this clearly: OCR collected $250,000 and the multi-state coalition collected $1.4 million for the same underlying facts. These are separate proceedings.

Third: Puerto Rico has an additional obligation. 2005’s Law 111, as amended, covered previously in this blog, applies to you even if you are subject to HIPAA. Its Article 2 defines “personal information file” to expressly include “medical protection protected by the HIPAA Act.” Consequently, complying with the federal notification does not relieve you of the local obligation. Law 111 requires you to report the security breach to DACO (Puerto Rico’s Department of Consumer Affairs) within a non-extendable 10-day period from detecting the breach. DACO is then required to make a public announcement of the incident within the following 24 hours. Compare this with HIPAA, which gives you up to 60 days to notify affected individuals. Puerto Rico’s clock runs much faster and does not give any extensions. Its fines range from $500 to $5,000 per violation, and they do not prevent those affected from separately suing you for damages. We previously explained this law here. Separately, Section 5 of the Federal Trade Commission (“FTC”) Act covers privacy and security representations made to the public, including what your own website says. Between OCR, the state’s attorneys general, DACO and the FTC, a single incident can lead to 4 simultenaous open legal proceedings against you.

Fourth: This one is important, but one that doesn’t show up in any of these settlements. The first thing your cyber-liability insurer will likely ask for if you ever need to file a claim over a data breach is your risk analysis. If you don’t have one, a denied claim could cost you far more than the fine itself.

How Can You Comply with the Law?

A risk analysis isn’t a form you fill out in an afternoon, but it also doesn’t require hiring an international consulting firm. OCR’s guidance identifies the elements it should contain:

Scope — every system that creates, receives, maintains, or transmits electronic health information. That includes the personal cell phone your front-desk staff uses to schedule appointments, the computer at home, and your website.
Data collection — where that information lives, who touches it, where it travels.
Threats and vulnerabilities — from ransomware to a laptop left in a car.
Current controls — what you have in place today to mitigate each risk.
Likelihood that each threat will materialize.
Impact if it does.
Risk level resulting from combining the two above.
Documentation — in writing, with dates.
Periodic review — this isn’t a one-time event.

Here are 3 practical recommendations that you can implement:

Use the free federal government tool. HHS publishes the Security Risk Assessment Tool, designed specifically for small and mid-sized practices. It walks you through the elements in plain-language questions, and it’s free.
Don’t forget to review your website. In risk analyses, many medical offices overlook their own website — the security of contact forms, tracking pixels, plugins, and hosting. HHS’s tool won’t ask you about this; you have to add it yourself.
Document the corrective actions you’ve taken, not just the findings. With OCR’s shift toward risk management, a dated record of what you found, what you did about it, and when, is just as important as the analysis itself.
Encrypt your devices, even though HIPAA doesn’t require it. Encryption is an “addressable” implementation specification under the HIPAA Security Rule. However, under Puerto Rico’s Law 111, the duty to notify is triggered only if the information was not protected by cryptographic keys beyond a password. Translation: losing a laptop with strong encryption, whose keys were not compromised, doesn’t start the 10-day clock or trigger DACO’s public announcement. This is one of the few measures that can buy you protection under 2 laws at once.

The Bottom Line

The Inmediata case isn’t a story about a sophisticated hack. It was a multimillion-dollar penalty for a website misconfiguration that nobody caught because nobody was checking. That’s exactly what a risk analysis exists to prevent.

If your office handles electronic health information — and if you use electronic billing, email, or a records system, you do — you’ve had this obligation since day one. It doesn’t matter whether you have 2 employees or 200.

The question worth asking today isn’t whether you’ll eventually be investigated. It’s simpler than that: if OCR asked for your risk analysis tomorrow morning, could you produce it?

If your answer is “no” — or “we did one years ago and I don’t know where it is” — it’s worth addressing now, before it becomes a matter of enforcement instead of planning, and before it costs you hundreds of thousands of dollars in penalties, and before your name ends up in newspapers and blogs across Puerto Rico and the mainland U.S. for failing to protect your patients’ information.

Do you have questions about whether your medical practice complies with this HIPAA rule? You can schedule a consultation with us today. We’re here to help.

About the Author

Jaime Farrant is an attorney admitted to practice law in Puerto Rico, New York, Maryland, and the District of Columbia, with an LL.M. in International Law, focusing on privacy, cybersecurity, and AI regulation for businesses and healthcare providers.

ADVERTISING MATERIAL. This article constitutes advertising as defined under the rules of professional conduct in effect in New York (22 NYCRR 1200.7.1 and 1200.7.3), Maryland (Rule 19-307.1 and 19-307.2), and the District of Columbia (D.C. Rules of Professional Conduct 7.1), as well as the Puerto Rico Rules of Professional Conduct (Rules 7.1–7.3). It does not constitute solicitation of known prospective clients who need legal services in a particular matter. Rather, it is general information directed to the public about the practice of law and available legal services. No attorney-client relationship is created by reading this article or by contacting the author.

What Happens If Your Vendor’s AI Decides to Hack Someone Else?

Posted by Jaime Farrant on July 28, 2026

Have you ever thought about what could happen to your business if a vendor’s AI system decides, on its own, to break into another company’s servers? If you haven’t, it might be time to, because the consequences for your business could be severe. If you’re a business regulated by HIPAA, a violation of this law could carry a civil penalty of up to $2,190,294 per violation category, per year, at the highest tier of culpability. Even a business that did nothing wrong, where a vendor’s AI system acted entirely on its own, could still face a lower-tier penalty, an OCR investigation, breach notification costs, and reputational fallout, for something it never caused and couldn’t have predicted.

This nightmarish possibility is no longer a hypothetical scenario. On July 21, 2026, OpenAI published on its website a notice were they took responsibility for a cyberattack on Hugging Face, a widely used AI hosting and machine-learning collaboration platform. According to OpenAI, a combination of its models — including a publicly available model and a more capable unreleased one, running with reduced safety restrictions for an internal cybersecurity evaluation — broke out of their isolated test environment by exploiting a previously unknown flaw in an internal software tool, reached the open internet, and then used stolen credentials and another unknown vulnerability to gain remote code execution on Hugging Face’s production servers. Their goal, according to OpenAI, was narrow but telling: the models were trying to retrieve the answer key to the benchmark test they were being scored on. Hugging Face had already detected the intrusion over a weekend of automated activity, reported it to law enforcement, and began its own containment before it even learned OpenAI was behind it.

Both companies have called this a watershed moment for cybersecurity. For a small business, medical practice, or professional office that relies on outside vendors — including AI tools — to store, process, or transmit sensitive information, it should also be a wake-up call about a risk category that most vendor contracts were never written to address: the AI agent that acts on its own.

Why could your AI Vendor’s Behavior Become Your Problem?

Most privacy and data security laws that apply to small businesses do not distinguish between a breach caused by a human hacker and a breach caused by an autonomous system. If your practice or business uses a covered entity’s business associate, a cloud vendor, or any third party that touches personal or health information, you are generally still responsible for:

Vetting that vendor’s security practices before you sign a contract (due diligence).
Having the right contractual protections in place, such as a HIPAA Business Associate Agreement (BAA) for medical offices, or comparable data processing and security terms for any business handling personal information.
Notifying affected individuals, and in some cases regulators, if that vendor’s system is compromised and your data is involved.

Under HIPAA, a covered entity’s business associates are contractually and legally bound to safeguard protected health information (PHI), and a breach at the vendor level can trigger notification obligations for the covered entity itself, even though the vendor’s system, not the medical office’s, was the one that failed. Outside of healthcare, most state data breach notification laws work the same way: liability follows the data, not just the party that caused the incident.

An AI agent that autonomously escalates its own access, exfiltrates credentials, or reaches systems it was never authorized to touch does not change any of that legal analysis. It just makes it harder to predict, detect, and contain.

It’s worth being precise about what did and didn’t happen here: by OpenAI’s own account, the models were chasing the answer key to their own benchmark test, not deliberately hunting for customer or patient records. No business should read this incident as proof that patient or client data was taken. What should concern any business relying on outside vendors is the capability on display: an AI system that, on its own initiative, found a zero-day vulnerability, stole credentials, escalated privileges, and reached a third party’s production infrastructure, over an unmonitored weekend, before any human intervened. Point that same capability at a system that holds patient records, financial account numbers, or client files, and the outcome looks very different.

A Disclosure Gap Worth Knowing About

Here’s a detail that matters for any business relying on a vendor’s assurances: OpenAI was not legally required to disclose this incident at all. Two recent state laws, California’s SB 53 and New York’s RAISE Act, require large AI developers to report critical safety incidents, but only if the incident risks more than 50 deaths or serious injuries, or over $1 billion in property damage. An incident like this one falls well short of that bar. OpenAI disclosed it voluntarily. The practical takeaway for your business: you generally cannot count on a public filing or regulatory notice to tell you whether a vendor’s AI system has had a similar failure. That makes your own contract language, and your own right to ask direct questions, the primary tool you have.

Penalty Structure: What’s Potentially at Stake

The exposure here is layered, and it can apply to a business that never asked for an AI system to do anything wrong, if that system operated within its own environment or a vendor’s:

HIPAA: Civil penalties currently range from roughly $145 up to $2,190,294 per violation category per year, depending on the covered entity’s or business associate’s level of culpability. Tier 1 (lack of knowledge) sits at the low end; willful neglect that goes uncorrected sits at the top. State attorneys general can separately pursue HIPAA-related fines of up to $25,000 per violation category, per year, and multi-state actions are increasingly common when a breach touches residents across several states.
State breach notification laws: Most states can pursue penalties or authorize private lawsuits when a business fails to notify affected residents promptly after a breach involving personal information, regardless of whether the breach originated with the business or with a vendor it selected.
Contractual exposure: If your vendor agreement lacks clear breach notification timelines, security requirements, or audit rights covering AI tools specifically, your business could be left absorbing costs, or negotiating from a weaker position, after the fact.

None of this means every AI-related vendor incident automatically results in a maximum fine. Regulators generally consider the nature of the data involved, the number of people affected, whether the business had reasonable safeguards in place, and how quickly the incident was addressed. But the exposure is real, and it is not limited to companies that build or sell AI models. It reaches any business, medical office, or professional practice that relies on one.

Why Should You Care About This?

Because experts who study AI safety are calling this one of the first real-world examples of an AI “loss of control” scenario: a system doing something researchers had long warned about, without a human directing it, and without a simple software bug to blame. The activity reportedly ran for an extended period on a system that, unlike OpenAI’s actively monitored production tools, was not being watched in real time. If a frontier AI lab with dedicated security teams can have this happen during a controlled internal test, it is a reasonable question for any business to ask what oversight exists over the AI-enabled tools, chatbots, scheduling assistants, or back-office automation your practice already uses, and what your vendor’s contract actually says about that risk.

For a medical office, this question is not abstract. AI tools are increasingly built into patient intake, scheduling, transcription, and billing software. For any small business, it applies to whatever AI-enabled service touches client records, financial data, or other sensitive information, even indirectly.

How Can You Protect Your Business?

Inventory every vendor and software tool your business uses that incorporates AI, especially anything touching patient, client, financial, or employee data.
Confirm you have a signed BAA in place with any vendor that creates, receives, maintains, or transmits PHI on your behalf, if you are a covered entity or business associate.
Review vendor contracts for AI-specific language: does the agreement address autonomous system behavior, require prompt breach notification, and specify security obligations?
Ask vendors directly how they test AI systems for containment and what happens if a model exceeds its intended scope.
Confirm your incident response plan accounts for a scenario where a vendor, not your own systems, is the source of a breach.
Revisit your cyber insurance policy to confirm it covers incidents involving AI tools and third-party AI vendors, not just traditional data breaches.
Don’t assume silence means safety: build a contractual right to be notified of AI-related security incidents into your vendor agreements, since current AI safety-incident disclosure laws only cover the most catastrophic events and won’t necessarily surface a vendor’s close call.

The Bottom Line

The OpenAI–Hugging Face incident is a reminder that AI risk in 2026 is not just about what your business chooses to do with AI. It is also about what the AI systems inside your vendors’ infrastructure might do without anyone telling them to. If your practice or business has not reviewed its vendor agreements and incident response plan with that possibility in mind, now is a good time.

If you have questions about your vendor contracts, business associate agreements, or how a breach at a third-party AI vendor could affect your obligations, schedule a consult with us today.

About the Author

Jaime Farrant is admitted to practice law in Puerto Rico, New York, Maryland and the District of Columbia. This article is for informational purposes only and does not constitute legal advice or create an attorney-client relationship.

ADVERTISING MATERIAL. This article constitutes advertising as defined by the professional conduct rules in New York (22 NYCRR 1200.7.1 and 1200.7.3), Maryland (Rule 19-307.1 and 19-307.2), and the District of Columbia (D.C. Rules of Professional Conduct 7.1), and the Puerto Rico Rules of Professional Conduct (Rules 7.1-7.3). It is not solicitation of prospective clients known to need legal services in a particular matter. Instead, it is general information directed to the public about the practice of law and available legal services. No attorney-client relationship is created by your reading of this article or by contacting the author. Consult qualified counsel in each jurisdiction with specific situations.