What Two Recent Healthcare Breach Notices Teach Software Teams

Healthcare organisations in the US send breach notices to patients and members almost every week. Most people read the first paragraph, check whether their Social Security number was involved and move on. If you build or run healthcare software, the rest of the letter is worth reading. It describes what happened, and that often points to safeguards worth building into your own software.

This post looks at two recent notices: one from a claims processor and one from a mental health provider. They describe two very different incidents. We summarise what each organisation said in its own letter, then turn both into a checklist for teams that build healthcare software.

Facts checked on 8 November 2026 against the organisations' own notice letters, filed with the Massachusetts Office of Consumer Affairs and Business Regulation and linked at the end. We describe these incidents only as the organisations themselves describe them, and we have no other information about them. If anything here is inaccurate, contact us and we will correct it.

The two notices at a glance

Sutherland Healthcare Solutions: someone else doing an employee's job

Sutherland provides business process services, including claims processing for health insurers. Its letter says it "became aware of access to claims-related information by an unauthorized individual who acted on behalf of a Sutherland employee" at various times between 29 July 2024 and 10 July 2026. Sutherland says it ended the employee's access, investigated together with the insurers, and identified the people and data involved on or about 24 August 2026.

The letter is clear that this was not a typical attack. Sutherland says it has found no evidence of actual or attempted misuse, and that "by all appearances" the person "was not engaged in malicious activity and accessed only relevant information in the normal course of performing the tasks that the actual employee was supposed to do". Sutherland says it is cooperating with law enforcement and adding technical and administrative measures.

So in this case, the issue is not hacking. The person using an account was not the person the account belonged to. Most systems can't tell the difference.

Osceola Mental Health: information copied from its systems

Osceola Mental Health, which operates as Park Place Behavioral Healthcare, says it became aware of unusual activity on its computer systems on 23 July 2026. It secured its systems, brought in a cybersecurity firm, and completed the forensic investigation on 19 August. The investigation found that some information stored on its systems had been copied by an unauthorised party. Osceola finalised the list of people to notify on 17 September and dated its letters 23 September 2026.

The letter lists what Osceola did next: it reset all user account credentials, installed endpoint detection and response software, tightened the security of remote access, and restored operations. Those steps are a useful list in their own right, and we come back to them below.

Two lessons for software teams

1. Your software trusts the login, not the person

Sutherland's letter describes someone doing an employee's work through that employee's access. Remote and outsourced work makes this possible in many organisations. A person passes on their login, or someone works under another person's account, and the system can't tell. Every action is logged under the wrong name, so the audit trail stops being reliable.

Software can make this harder:

• Multi-factor authentication tied to a device or app the employee controls. A shared password alone is no longer enough.
• Re-checking identity at sensitive moments. For example, ask again before bulk exports or when a session starts on a new device or in a new location.
• Device and session visibility. Show admins which devices and locations each account uses, and alert on new ones.
• Personal accounts only. No shared logins, and contractors get their own accounts with their own limits.

2. Data copied from your systems can't be taken back

Osceola's letter describes information being copied from its systems. Once data has left, the only thing you control is how much of it there was. Copies, old exports and files kept "just in case" all add to the amount that can be copied.

The steps in Osceola's letter are also a good starting point for prevention: unique credentials that can be reset quickly, monitoring on every machine (endpoint detection and response), and secure remote access. These are much cheaper to set up before an incident than after one.

A checklist for teams that build healthcare software

1. Log every view, not only changes. Record who opened which patient or claim record, when and from where. In an investigation you need to know who looked at what.
2. Alert on unusual access. Start with simple rules: far more records than an account usually opens, access at unusual hours, logins from new countries or devices. Send alerts to someone who will check them.
3. Use multi-factor authentication and personal logins for everyone, including contractors and vendor staff. No shared accounts, so that the audit log shows who really did what.
4. Give each role only the data it needs. Many roles don't need a full Social Security number. Mask it by default.
5. Control exports. Limit who can download bulk data, log every export, and make exported files expire.
6. Encrypt stored files and delete old ones. Set retention rules for uploads, exports and backups.
7. Check your vendors. Ask business associates how they verify who is using their accounts, how they log access and how quickly they will tell you about an incident. Write it into the business associate agreement.
8. Write the breach response plan now. Decide who investigates, who decides whether an incident counts as a breach, who writes the notices and how you will find the people affected. Under HIPAA, notices to individuals are due without unreasonable delay and no later than 60 days after a breach is discovered, which goes quickly when you start from nothing.

The bigger picture

Large breaches remain common. HHS received 397 reports of breaches affecting 500 or more people in the first half of 2026, 5.9% fewer than in the first half of 2025, according to HIPAA Journal.

A proposed update to the HIPAA Security Rule would make practices such as encryption, network segmentation and regular compliance audits mandatory. According to the federal regulatory agenda, final action is now expected in July 2027. More than 100 hospital and provider groups have asked HHS to withdraw it, so the final version may differ. The current Security Rule applies in the meantime.

How Develenza can help

We build healthcare software with audit logs, role-based access and export controls from the start, and we review existing systems for the gaps described above. If you want a second opinion on your platform, contact us for a security review, or start your project if you are planning new healthcare software and want these safeguards from day one.

Security also depends on keeping the software underneath up to date. If your platform runs on PHP or Laravel, see PHP2Shell: Critical PHP Flaws Put Unpatched Websites at Risk and Laravel 13.40 Security Fix: Is Your Laravel App Up to Date?.

Sources

• Sutherland Healthcare Solutions: notice letter dated 2 November 2026 (Massachusetts filing 2026-1918)
• Osceola Mental Health d/b/a Park Place Behavioral Healthcare: notice letter dated 23 September 2026 (Massachusetts filing 2026-1613)
• eCFR: 45 CFR 164.404, notification to individuals
• Feldesman: OCR delays final action on proposed HIPAA Security Rule
• Medcurity: 2026 HIPAA Security Rule update
• HIPAA Journal: H1 2026 healthcare data breach report