We Scanned 6 Popular Open-Source Healthcare Systems — Found 79 Security Risks Affecting Patient Data

Introduction

Healthcare software handles some of the most sensitive data in existence — patient diagnoses, medications, medical records, billing information. The HIPAA Security Rule (45 CFR § 164.312) mandates specific technical safeguards to protect this data: encryption at rest, transmission security, access controls, audit logging, session management, and more.

But how well do the open-source healthcare applications that thousands of hospitals and clinics rely on actually implement these safeguards?

We used Scrutora's automated HIPAA compliance scanner to analyze 6 popular open-source healthcare applications across 4 programming languages. Our scanner performs AST-based static analysis against 10 HIPAA Security Rule safeguards, detecting potential risks with specific file paths, line numbers, and framework-aware remediation guidance.

The results were sobering: 79 potential security risks across all 6 projects. 16 critical findings requiring immediate attention. Not a single project achieved an A grade.

Methodology

Each project was scanned using Scrutora's automated HIPAA compliance scanner, which performs AST-based static analysis using tree-sitter parsers. The scanner checks for 10 HIPAA Security Rule safeguards:

1. Access Control (§164.312(a)(1)) — Authorization checks on PHI access
2. Transmission Security (§164.312(e)(1)) — Encryption of PHI in transit
3. Encryption at Rest (§164.312(a)(2)(iv)) — Encrypted storage of PHI
4. Audit Controls (§164.312(b)) — Logging of PHI access and modifications
5. Session Management (§164.312(a)(2)(iii)) — Automatic logoff and timeouts
6. Password Management (§164.308(a)(5)(ii)(D)) — Password strength policies
7. Key Management (§164.312(a)(2)(iv)) — Encryption key lifecycle
8. Log Management (§164.530(j)) — PHI excluded from application logs
9. Weak Cryptography (§164.312(a)(2)(iv)) — Modern encryption algorithms
10. Backup & Recovery (§164.308(a)(7)(ii)(A)) — Data backup integrity

Vendor dependencies, build artifacts, minified bundles, and test files were excluded from scanning to ensure findings reflect actual application code written by the project's developers.

Projects Scanned

Key Findings

1. Deprecated Encryption Algorithm Protecting Access Controls

We identified DES (Data Encryption Standard) usage in Danphe EMR's Role-Based Access Control module (DanpheRBAC.cs). DES has been officially deprecated since 2005 and is considered insecure by NIST. When used to protect access control mechanisms, this may weaken the cryptographic protections guarding who can access patient records.

Recommended fix: Replace DES with AES-256-GCM. In C#: use AesGcm or Aes.Create() with CBC mode and a random IV.

2. Patient Data Potentially Transmitted Over Plain HTTP

Both Danphe EMR and OpenMRS contain hardcoded HTTP URLs in their application code. Danphe EMR references an SMS API (api.sparrowsms.com) via plain HTTP in both its Admission and Pharmacy controllers — meaning patient appointment details, pharmacy notifications, and admission alerts could potentially be transmitted without encryption.

3. Patient Objects Serialized Into Application Logs

Across multiple projects, we found patient, medical, and health objects being serialized directly into application logs using toString() and JSON.stringify(). This pattern was identified in SudoEMR (patient actions logging), OpenMRS (HL7 message handlers), Danphe EMR (clinical diagnosis and pharmacy controllers), and HospitalRun (medication details).

4. PHI Endpoints Without Apparent Access Controls

Multiple projects expose methods that access patient data without visible authorization checks at the code level. In SudoEMR, methods like getPatient(), getPatientList(), and getPatientAppointments() have no authentication middleware. In OpenMRS, methods like getCommaSeparatedPatientIds() and getMemberIds() on the Cohort class lack @PreAuthorize annotations. In Danphe EMR, accounting controllers accessing billing PHI have no [Authorize] attribute.

5. Extended Session Durations Far Beyond NIST Guidelines

Danphe EMR configures JWT token expiration at 1,440 minutes (24 hours) and session idle timeout at 480 minutes (8 hours). NIST SP 800-66 recommends session timeouts of 15 minutes or less for systems handling ePHI. The HospitalRun Server also lacks explicit session timeout configuration.

6. Database Connections Without Explicit TLS Configuration

Danphe EMR's database connection strings do not include SSL/TLS parameters. While some database servers enable TLS by default or enforce it at the server level, the absence of explicit TLS parameters in the connection string means the application is not guaranteeing encrypted database communication.

7. No Audit Logging on Patient Data Modifications

HospitalRun Frontend performs multiple PHI write operations — saving patient records, updating medications, modifying allergies, deleting diagnoses — with no visible audit logging. When patient data is modified, there is no apparent record of who changed what, when, or why.

8. SHA-1 Used for Password-Related Operations

OpenMRS Core uses SHA-1 in its Security utility class for password-related hashing operations. SHA-1 has known collision vulnerabilities (demonstrated by the SHAttered attack in 2017) and is no longer recommended for cryptographic use. Modern standards recommend bcrypt, Argon2, or scrypt for password hashing.

Most Common Risk Patterns

Looking across all 6 projects, clear patterns emerge in where healthcare applications most commonly fall short of HIPAA Security Rule technical safeguards:

The most prevalent pattern across the healthcare open-source ecosystem is weak cryptography — deprecated algorithms like DES, MD5, and SHA-1 that have been considered insecure for years continue to appear in code paths that may protect patient data.

What This Means for Healthcare Engineering Teams

These findings are not academic. Danphe EMR is deployed in 60+ hospitals. OpenMRS serves millions of patients globally. HospitalRun is designed specifically for hospitals in developing countries where security infrastructure may be minimal.

If you're building a healthcare application — whether from scratch or on top of open-source foundations — these are the questions worth asking:

• Are your database connections encrypted? Check your connection strings for SSL/TLS parameters. Many frameworks default to unencrypted connections.
• Are you logging PHI? Search your codebase for console.log, logger.info, and toString() calls that might serialize patient objects. This is the most common and easiest-to-fix pattern we found. For a deep dive into detecting and fixing PHI in logs, see our developer guide on PHI in application logs.
• How long are your sessions valid? If your JWT tokens or session cookies last longer than 15 minutes without re-authentication, you're outside NIST guidelines.
• Do all PHI endpoints require authentication? Check every route that returns or modifies patient data. Missing a single [Authorize] attribute or auth middleware is a common oversight.
• Are you still using MD5, SHA-1, or DES? These algorithms are deprecated. Replace them with AES-256-GCM (symmetric), SHA-256 (hashing), and bcrypt or Argon2 (passwords).

Reproducibility & Transparency

We believe security research should be verifiable. To ensure transparency, all scans in this article were performed against publicly accessible repositories. The table below lists each project, its repository URL, and the branch scanned.

All scans were performed using Scrutora with default rule configuration (10 HIPAA Security Rule safeguards). Vendor dependencies, build artifacts, minified bundles, and test files were excluded.

You can reproduce these scans yourself using the free public scanner at scrutora.com — paste any public GitHub URL to get a compliance report in under 60 seconds.

Important Disclaimers

This analysis is based on automated static code analysis and has inherent limitations. Static analysis identifies code patterns that may indicate security risks. It cannot determine runtime behavior, infrastructure-level controls (such as database-level encryption, TLS termination at load balancers, or upstream authentication middleware), or administrative safeguards.

Findings should be interpreted as potential risk indicators requiring manual review, not as confirmed vulnerabilities or definitive compliance failures. Each finding includes a confidence level (Confirmed, Likely, or Needs Review) to help teams prioritize manual verification.

A clean scan does not guarantee HIPAA compliance, and the presence of findings does not necessarily mean a system is non-compliant. HIPAA compliance requires administrative safeguards, physical safeguards, and organizational requirements beyond what code scanning can evaluate.

We have the highest respect for the teams building these open-source healthcare tools. They are doing critical work, often with limited resources, to make healthcare technology accessible worldwide. Many of these projects explicitly state they are not intended for production use without additional security hardening. The purpose of this analysis is to help improve these tools and raise awareness of common security patterns — not to criticize the people behind them.