We Scanned 3,000 Healthcare Repos. Here’s What We Found.

Healthcare software is failing compliance at the code level. Not in theory. Not in edge cases. Across the board.

We built a scanner that reads healthcare source code the way a compliance auditor would, by mapping code patterns to specific HIPAA sections, GDPR articles, SOC 2 criteria, and India’s DPDPA requirements. Then we pointed it at 3,000 public healthcare repositories spanning 11 programming languages.

The results are now published in the Healthcare Code Compliance Security Index (2026 Edition). Here are five of the most notable findings.

1. India’s Vaccination Platform Logs Aadhaar Numbers to Stdout

India’s DIVOC platform powered the national COVID vaccination certificate system. The code serializes the entire certificate request. This includes the citizen’s Aadhaar number, name, date of birth, gender, phone number, and home address. The entire payload is written to application logs for every single certificate created.

A separate analytics consumer prints every Kafka vaccination message to stdout unconditionally. There is no feature flag, no log level gate, and no way to disable it without modifying the source code.

The Kubernetes deployment configs in the repository contain production CoWIN URLs (cowin.gov.in), confirming this code was deployed to India’s national vaccination infrastructure. No log sanitization, masking, or redaction is configured anywhere in the codebase.

We reported this to CERT-In on March 23, 2026.

2. The VA Deliberately Disables TLS and Suppresses the Security Warning

The US Department of Veterans Affairs notification-api handles SMS, email, and push notifications for 9+ million veterans, deployed to AWS GovCloud.

One Lambda function forwards incoming veteran SMS messages with verify=False, disabling TLS certificate verification. The code includes an explicit # nosec annotation, a Bandit security scanner suppression comment, proving the development team was aware this was a security issue and deliberately suppressed the warning.

All affected Lambda functions deploy to production via GitHub Actions across dev, staging, perf, and prod environments.

3. OpenEMR Writes Patient SSNs to Plaintext CSV Files

OpenEMR is the most widely deployed open-source EMR with over 100,000 installations. The billing export feature writes patient Social Security Numbers, names, dates of birth, addresses, and phone numbers to a plaintext CSV file via fwrite() with zero encryption.

There is no encryption option. There is no audit trail on the export. The file is written to the server filesystem in the clear.

4. Patient Data Flows Into AI Models Without De-identification

Metriport, a funded healthcare API company, sends patient medical record data to an AI model via Amazon Bedrock for generating AI briefs. No de-identification or tokenization is visible before the API call.

This is part of a broader pattern. Across the 3,000 repositories we scanned, our MLPHI-001 rule detected 657 confirmed instances of patient data flowing into AI/ML pipelines without de-identification. This includes CSV exports, model training data, and inference calls.

5. NHS England’s Research Platform Queries 58 Million Patient Records with TLS Disabled

OpenSAFELY is a secure analytics platform for NHS England electronic health records. The cohort-extractor tool queries patient data from approximately 58 million NHS patients.

The code unconditionally disables TLS certificate verification for its EMIS database connection. Security warnings are globally suppressed. And TODO comments in the code confirm the developers know it should be fixed:

# TODO remove this when certificate verification reinstated

The TODO is still there.

The Systemic Pattern

These five findings come from five different countries, five different types of organizations, and five different categories of violation. But they share one root cause: nobody checked the code for compliance.

Security scanners find vulnerabilities. Compliance audits check policies. Neither examines whether application code actually implements the safeguards that regulations require.

Compliance failure does not correlate with funding, team size, or institutional credibility. It correlates with whether anyone checked the code.

What You Should Do

If your organization develops or deploys healthcare software:

1. Audit your XML parsing configurations. XXE was the most common critical finding across Google, CDC, CMS, and the most widely used FHIR libraries.
2. Check your data exports. Billing exports, CSV downloads, and reporting features frequently write PHI to plaintext files.
3. Review your AI/ML pipelines. De-identification must occur before data enters training or analytics pipelines.
4. Search your logs for PHI. Application logs are frequently accessible to operations teams and third-party services not covered by BAAs.
5. Distinguish between security scanning and compliance scanning. A clean Snyk or Semgrep scan does not mean your application is HIPAA-compliant.

These are five examples from a much larger dataset. The full report documents verified findings across 15+ named repositories, including Google, CDC, CMS, the US Department of Veterans Affairs, Mirth Connect (NextGen Healthcare), IBM, India’s ABDM and DIVOC, the UK’s NHS, and widely deployed open-source EMR platforms. Additional findings across healthcare repositories in the US, UK, EU, India, and sub-Saharan Africa are currently undergoing validation and will be published in subsequent editions of the Index.

All affected organizations were notified through responsible disclosure channels prior to publication.