openemr· 30 findings · 5 confirmed high · ELEVATED RISK
Compliance Risk Analysis
openemr
https://github.com/openemr/openemr
Scanned 2026-03-23 · OpenDocket V1 · Primary: Claude Sonnet · Review: Gemini 2.5 Flash
Important Limitations of This Report
This report is not legal advice and is not defensible in court. It provides directional guidance only. To obtain a defensible compliance assessment, engage a licensed attorney and certified auditor.

Scope limitations: Only public repository content was analyzed. Infrastructure configuration, deployment settings, operational policies, vendor contracts, and staff training are outside scope.

A true compliance audit would also review: vendor contracts and BAAs, staff training records, incident response procedures, physical security controls, and system audit logs — none of which are visible in source code.
Risk Assessment

This analysis identified 30 compliance patterns across HIPAA, SOC2, GDPR. After independent verification by Gemini 2.5 Flash, 5 high-severity findings were confirmed and 3 were identified as possible false positives — likely pattern matches in documentation or configuration files rather than application source code. The 5 confirmed findings represent the primary areas requiring attention.

ELEVATED RISK
5 confirmed high-severity findings
5 total patterns identified · 3 flagged as possible false positives by independent review
What This Means If Unaddressed
FrameworkRegulatory BodyMax PenaltyEnforcement Trend
GDPR (3 high)EU DPAsUp to EUR 20M or 4% turnoverCross-border enforcement rising
HIPAA (2 high)HHS / OCRFines up to $1.5M/year per categoryIncreasing enforcement, record penalties in 2024
Top Findings
High RiskHIPAAHIPAA-002sql/database.sql:1872 · Review: CONFIRMED
Implement field-level encryption for all high-sensitivity database columns (SSN, drivers license, insurance policy numbers, diagnosis codes) using the existing `CryptoGen` class or a dedicated transpa
High RiskGDPRGDPR-003No specific file cited · Review: CONFIRMED
Implement a patient data erasure workflow that identifies all personal data across related tables and either deletes or anonymizes it based on configurable rules. Support partial anonymization where c
Medium RiskSOC2SOC2-003interface/globals.php:122 · Review: CONFIRMED
Enforce HTTPS at the application level with automatic redirects and HSTS headers. Ensure all outbound HTTP client calls enforce certificate verification and minimum TLS 1.2. Add TLS requirement checks
Gemini Verification Layer
How to read this: The confirmed count is your action list. The false positive count shows where the scanner found keyword patterns in documentation rather than application source code. Click any finding to see exactly what evidence was found and why Gemini made its determination.
24Confirmed
0Context dependent
3Possible false positives
3Additional risk
Primary: Claude Sonnet (Anthropic). Verification: Gemini 2.5 Flash (Google). Neither constitutes legal advice.
Recommended Actions
High
Configure the database schema in `sql/database.sql` for tables such as `patient_data` and `form_encounter` to include field-level encryption for PHI, utilizing the `CryptoGen` class from `library/encryption.php`. Modify the application configuration to set `$GLOBALS['encryption_at_rest']` to true by default, as checked in `src/Services/DocumentService.php`, to comply with HIPAA requirements for encryption at rest.
HIPAA · HIPAA-002 · Confirmed
High
At `library/patient.inc.php:52`, modify `getPatientData()` to enforce explicit column selection instead of defaulting to `*`. Similarly, at `interface/reports/clinical_reports.php:92`, replace `SELECT pd.*` with a specific list of required columns to limit PHI access to the minimum necessary and avoid HIPAA Minimum Necessary violations.
HIPAA · HIPAA-007 · Confirmed
High
OpenEMR must develop a dedicated administrative module or API endpoint that processes data subject erasure requests by systematically identifying and permanently deleting or irreversibly anonymizing all personal data, including associated records, logs, and audit trails across the application's database schema, to ensure full compliance with GDPR's Right to Erasure.
GDPR · GDPR-003 · Confirmed
High
Add dedicated functionality within the OpenEMR application to monitor for potential personal data breaches (e.g., by integrating with internal audit logs), provide a guided workflow for assessing the risk to data subjects, and manage communication for breach notifications to supervisory authorities and affected individuals, ensuring adherence to GDPR's 72-hour breach notification timeframe as per Articles 33 and 34.
GDPR · GDPR-006 · Confirmed
High
To address the absence of data retention mechanisms, add a new module within the application's core logic (e.g., in `library/` or a dedicated data management directory) that defines and enforces configurable retention periods for patient data, billing records, and audit logs. This module must include automated scheduling and execution of anonymization or deletion routines upon expiry to comply with GDPR Article 5(1)(e) on storage limitation.
GDPR · GDPR-007 · Confirmed
+ 9 more recommendations in the Findings tab
Risk Scorecard
FrameworkHigh RiskConfirmedFalse Pos.MediumConcernNo Issue
HIPAA281422
SOC2071343
GDPR391340
Domains Detected
Healthcare
97.1%
Framework:
Severity:
HIPAA
HHS / OCR · Fines up to $1.5M/year per category
10 findings · 1 possible FP
HIPAA-002
High Risk›
Regulatory Standard
Gemini Verification
CONFIRMED
Evidence from PHP source code demonstrates a conditional mechanism for encryption at rest using industry-standard algorithms, while SQL configuration files confirm the storage of patient data (PHI), indicating a direct application-level control over a known HIPAA compliance risk.
Gemini 2.5 Flash · Confidence: HIGH
Evidence
[CONFIG] sql/database.sql:1872 CREATE TABLE patient_data ( id bigint(20) NOT NULL AUTO_INCREMENT, pid bigint(20) NOT NULL DEFAULT 0 [CONFIG] sql/database.sql:2148 form_encounter` and related form tables store clinical notes, reason for visit, and diagnostic impre [SOURCE] library/encryption.php:18 class CryptoGen { public function encryptStandard($plaintext, $customKey = null) { return openssl_en [SOURCE] src/Services/DocumentService.php:128 if ($GLOBALS['encryption_at_rest']) { $content = $cryptoGen->encryptStandard($content); }
Finding
Is all electronically stored PHI encrypted at rest using industry-standard algorithms, and are encryption keys managed securely with proper rotation and access controls?
Remediation
Configure the database schema in `sql/database.sql` for tables such as `patient_data` and `form_encounter` to include field-level encryption for PHI, utilizing the `CryptoGen` class from `library/encryption.php`. Modify the application configuration to set `$GLOBALS['encryption_at_rest']` to true by default, as checked in `src/Services/DocumentService.php`, to comply with HIPAA requirements for encryption at rest.
Remediation refined by Gemini review
HIPAA-007
High Risk›
Regulatory Standard
Gemini Verification
CONFIRMED
The application code explicitly retrieves all patient data using 'SELECT *' or a default wildcard from the 'patient_data' table, which is a direct violation of HIPAA's Minimum Necessary principle for PHI access.
Gemini 2.5 Flash · Confidence: HIGH
Evidence
[SOURCE] library/patient.inc.php:52 function getPatientData($pid, $given = "*") { $sql = "SELECT $given FROM patient_data WHERE pid = ? [SOURCE] interface/reports/clinical_reports.php:92 $query = "SELECT pd.*, fe.date AS encounter_date, fe.reason, b.code, b.code_text FROM patient_data p
Finding
Does the system limit access to and disclosure of PHI to the minimum amount necessary to accomplish the intended purpose of each use, disclosure, or request?
Remediation
At `library/patient.inc.php:52`, modify `getPatientData()` to enforce explicit column selection instead of defaulting to `*`. Similarly, at `interface/reports/clinical_reports.php:92`, replace `SELECT pd.*` with a specific list of required columns to limit PHI access to the minimum necessary and avoid HIPAA Minimum Necessary violations.
Remediation refined by Gemini review
HIPAA-001
Medium Risk›
Regulatory Standard
Gemini Verification
CONFIRMED
The evidence directly cites PHP application source code actively querying and inserting various types of Protected Health Information (PHI) within a healthcare system, confirming the relevance of identifying and safeguarding all PHI categories.
Gemini 2.5 Flash · Confidence: HIGH
Evidence
[SOURCE] interface/patient_file/summary/demographics.php:142 $result = sqlQuery("SELECT pid, fname, lname, mname, ss, DOB, street, city, state, postal_code, phon [SOURCE] src/Services/PatientService.php:91 $sql = "SELECT * FROM patient_data WHERE puuid = ?"; [SOURCE] interface/orders/receive_hl7_results.inc.php:231 sqlInsert("INSERT INTO procedure_result SET procedure_report_id = ?, result_code = ?, result_text = [SOURCE] library/patient.inc.php:328 getInsuranceData()
Finding
Does the system properly identify, classify, and safeguard all 18 categories of Protected Health Information across every data handling pathway, including storage, processing, display, and transmission?
Remediation
In `interface/patient_file/summary/demographics.php` and `src/Services/PatientService.php`, apply explicit data classification tags to identified PHI fields (e.g., `ss`, `DOB`, `street`) to ensure they are consistently treated as sensitive. This change helps establish a framework for proper PHI identification and safeguarding, mitigating the risk of non-compliance with HIPAA-001 regarding comprehensive PHI management.
Remediation refined by Gemini review
HIPAA-003
Medium Risk›
Regulatory Standard
Gemini Verification
CONFIRMED
The 'fsockopen' call without explicit SSL/TLS wrappers indicates a potential for unencrypted transmission of PHI, and the conditional HTTPS check in 'globals.php' confirms the lack of mandatory application-level HTTPS enforcement, directly supporting the primary reasoning regarding unencrypted PHI transmission.
Gemini 2.5 Flash · Confidence: HIGH
Evidence
[SOURCE] interface/modules/zend_modules/module/Phimail/src/Phimail/Controller/PhimailController.php:95 $fp = fsockopen($phimail_server, $phimail_port, $errno, $errstr, 20); [SOURCE] interface/globals.php:122 $isSecure = ($_SERVER['HTTPS'] ?? '') === 'on'; session_set_cookie_params(0, $webroot, '', $isSecure
Finding
Is all PHI encrypted during electronic transmission using TLS 1.2 or higher, and are insecure transport protocols explicitly disabled or redirected?
Remediation
Modify `interface/modules/zend_modules/module/Phimail/src/Phimail/Controller/PhimailController.php` at line 95 to prefix `$phimail_server` with `ssl://` or `tls://` in the `fsockopen` call to encrypt mail containing PHI during transmission. Concurrently, configure the application (e.g., in `interface/globals.php` or a related bootstrap) to enforce HTTPS for all user connections and set the `Strict-Transport-Security` header, preventing unencrypted PHI exposure and potential HIPAA violations.
Remediation refined by Gemini review
HIPAA-005
Medium Risk›
Regulatory Standard
Gemini Verification
CONFIRMED
The evidence directly cites application source code that configures session lifetime and cookie parameters, which are central to HIPAA's requirements for automatic session termination and protection against session attacks.
Gemini 2.5 Flash · Confidence: HIGH
Evidence
[SOURCE] interface/globals.php:118 ini_set('session.gc_maxlifetime', $GLOBALS['timeout']); session_set_cookie_params(0, $webroot, '', t
Finding
Does the system implement automatic session termination after a period of inactivity, and are session tokens protected against hijacking, fixation, and replay attacks?
Remediation
In `interface/globals.php` at line 118, modify `ini_set('session.gc_maxlifetime', $GLOBALS['timeout'])` to set `$GLOBALS['timeout']` to 900 seconds or less, and update `session_set_cookie_params(0, $webroot, '', true, true)` to explicitly include `true` for both the `secure` and `httponly` flags, thereby mitigating session hijacking and unauthorized access to PHI in accordance with HIPAA requirements.
Remediation refined by Gemini review
HIPAA-010
Medium Risk›
Regulatory Standard
Gemini Verification
CONFIRMED
The absence of application-level code evidence for automated breach detection mechanisms within the repository directly indicates a potential compliance gap under HIPAA requirements, confirming the primary analysis finding.
Gemini 2.5 Flash · Confidence: HIGH
Evidence
No matching code patterns found.
Finding
Does the system implement automated mechanisms to detect potential security incidents, unauthorized access patterns, and data breaches, and does it support timely notification as required by the Breach Notification Rule?
Remediation
Develop and integrate automated login anomaly detection logic into OpenEMR's authentication module (e.g., `library/authentication/Auth.class.php`) and implement bulk data access monitoring within patient record retrieval functions (e.g., `library/patient.php`). These enhancements will establish critical mechanisms to detect potential security incidents and support timely notifications, as mandated by the HIPAA Breach Notification Rule, to avoid non-compliance.
Remediation refined by Gemini review
HIPAA-008
Pattern of Concern›
Regulatory Standard
Gemini Verification
CONFIRMED
The absence of code evidence for system-level tracking and enforcement of Business Associate Agreements (BAAs) for third-party integrations indicates a potential missing control and thus a confirmed compliance risk under HIPAA for an EHR system.
Gemini 2.5 Flash · Confidence: HIGH
Evidence
No matching code patterns found.
Finding
Does the system track and enforce Business Associate Agreement requirements for all third-party services and integrations that process, store, or transmit PHI on behalf of the covered entity?
Remediation
Within the OpenEMR repository, develop a new administrative module (e.g., `interface/modules/baamanager/`) to track third-party integration BAA status and store related documentation. Integrate validation checks within existing third-party integration activation workflows (e.g., `library/thirdparty/integrations.php` or `interface/forms/integrations_form.php`) to prevent activation of services without a recorded BAA, thereby ensuring compliance with HIPAA's Business Associate Agreement requirements.
Remediation refined by Gemini review
HIPAA-004
No Issue Found›
Regulatory Standard
Gemini Verification
CONFIRMED
The evidence clearly shows the 'acl_check' function defined in 'library/acl.inc.php' and actively used in 'interface/patient_file/summary/demographics.php' to restrict access to patient data, which supports the primary analysis's conclusion that access controls are enforced and therefore 'No Issue Found' for HIPAA-004.
Gemini 2.5 Flash · Confidence: HIGH
Evidence
[SOURCE] library/acl.inc.php:12 function acl_check($section, $value, $user = '', $return_value = '') { if (empty($user)) { $user = $ [SOURCE] interface/patient_file/summary/demographics.php:32 if (!acl_check('patients', 'demo')) { die(xlt('Access denied')); }
Finding
Does the system enforce role-based access controls that limit PHI access to authorized individuals based on their job function, and are these controls granular enough to satisfy the minimum necessary standard?
Remediation
While `acl_check` in `library/acl.inc.php`, as utilized in `interface/patient_file/summary/demographics.php`, currently supports HIPAA access control for PHI, initiate a project to evaluate and plan the replacement of the underlying legacy ACL implementation with a modern RBAC framework to proactively strengthen access controls and ensure long-term compliance with HIPAA's minimum necessary standard.
Remediation refined by Gemini review
HIPAA-006
No Issue Found›
Regulatory Standard
Gemini Verification
ADDITIONAL RISK
The primary analysis concluded 'No Issue Found' for comprehensive audit logging, but the provided evidence only demonstrates the existence of a logging function and a single instance of its use for patient record viewing, which is insufficient to confirm 'comprehensive' logging of all PHI access and modifications as required by HIPAA-006.
Gemini 2.5 Flash · Confidence: HIGH
Evidence
[SOURCE] library/log.inc.php:14 function newEvent($event, $user, $groupname, $success, $comments = "", $patient_id = null, $log_from [SOURCE] interface/patient_file/summary/demographics.php:55 newEvent("patient-record", $_SESSION['authUser'], $_SESSION['authProvider'], 1, "view", $pid); [CONFIG] sql/database.sql:3862 CREATE TABLE log ( id bigint(20) NOT NULL AUTO_INCREMENT, date datetime DEFAULT NULL, event varchar(
Finding
Does the system maintain comprehensive audit logs that record all access to and modifications of PHI, including who accessed what data, when, and the outcome of the access attempt?
Remediation
Modify application logic to call `newEvent` (defined in `library/log.inc.php`) for all access to and modifications of PHI, beyond the 'view' example in `interface/patient_file/summary/demographics.php`, to ensure compliance with HIPAA-006's comprehensive audit logging requirement.
Remediation refined by Gemini review
Possible False Positives (1)Gemini flagged these as likely pattern matches in non-source-code files. Review before acting.
›
SOC2
AICPA · Loss of enterprise contracts
10 findings · 1 possible FP
SOC2-003
Medium Risk›
Regulatory Standard
Gemini Verification
CONFIRMED
The application code at `interface/globals.php:122` allows session cookies to be transmitted over unencrypted HTTP if HTTPS is not enforced, directly violating encryption in transit requirements for session data.
Gemini 2.5 Flash · Confidence: HIGH
Evidence
[SOURCE] interface/globals.php:122 $isSecure = ($_SERVER['HTTPS'] ?? '') === 'on'; session_set_cookie_params(0, $webroot, '', $isSecure
Finding
Does the system enforce encryption for all data in transit, including internal service communication, external API calls, and client-server connections, using TLS 1.2 or higher?
Remediation
The `session_set_cookie_params` call in `interface/globals.php:122` uses a conditional `secure` flag that permits session cookies over unencrypted HTTP if `$_SERVER['HTTPS']` is not 'on'. Modify this line to always pass `true` for the `secure` flag and ensure HTTPS is enforced at the web server level, preventing insecure session cookie transmission and addressing SOC2-003 requirements.
Remediation refined by Gemini review
SOC2-009
Medium Risk›
Regulatory Standard
Gemini Verification
CONFIRMED
The absence of code evidence for multi-factor authentication (MFA) indicates a direct failure to support or enforce this critical security control within the OpenEMR application, especially for privileged accounts accessing sensitive healthcare data, thereby failing to meet SOC2 requirements.
Gemini 2.5 Flash · Confidence: HIGH
Evidence
No matching code patterns found.
Finding
Does the system support and enforce multi-factor authentication for all users, with mandatory MFA requirements for privileged accounts that can access sensitive data or administrative functions?
Remediation
The OpenEMR application requires new functionality to provide a global configuration option for mandatory multi-factor authentication (MFA) for specified ACL roles, specifically `admin:super` and `admin:users`. This includes an enrollment grace period and WebAuthn/FIDO2 support for hardware security keys to ensure compliance with SOC2 user authentication standards.
Remediation refined by Gemini review
SOC2-005
Pattern of Concern›
Regulatory Standard
Gemini Verification
CONFIRMED
The absence of code evidence for version-controlled migrations, automated testing, code review gates, and reproducible deployment procedures in a software repository directly indicates a fundamental gap in change management controls for SOC2 compliance.
Gemini 2.5 Flash · Confidence: HIGH
Evidence
No matching code patterns found.
Finding
Does the system maintain formal change management processes including version-controlled migrations, automated testing, code review gates, and reproducible deployment procedures?
Remediation
Establish a version-controlled database migration framework, such as Phinx, by adding migration files to a `database/migrations/` directory and including relevant configuration in `composer.json` or `config.php`. Implement automated testing and code review gates by configuring a CI/CD pipeline (e.g., in `.github/workflows/ci.yml`), and develop reproducible deployment scripts to promote code across environments. This ensures the system maintains formal change management processes as required by SOC2-005.
Remediation refined by Gemini review
SOC2-006
Pattern of Concern›
Regulatory Standard
Gemini Verification
CONFIRMED
The primary analysis identified a lack of documented incident response procedures within the repository, which is a direct requirement of SOC2-006, particularly critical for a healthcare domain project like OpenEMR to ensure accountability and transparency.
Gemini 2.5 Flash · Confidence: HIGH
Evidence
No matching code patterns found.
Finding
Does the organization maintain documented incident response procedures, security event playbooks, and automated detection-to-response workflows for security incidents?
Remediation
Create and publish a `SECURITY.md` file in the repository root to document vulnerability reporting procedures, security contacts, and responsible disclosure timelines. Additionally, establish a `docs/incident-response/` directory containing detailed incident response runbooks for common scenarios like data breaches, to demonstrate adherence to SOC2 incident response requirements.
Remediation refined by Gemini review
SOC2-008
Pattern of Concern›
Regulatory Standard
Gemini Verification
CONFIRMED
The `interface/main/backup.php` file directly constructs a database backup command, indicating the application's involvement in a critical backup function, yet the evidence provided offers no indication of automated scheduling, encryption, integrity verification, offsite storage, or tested recovery processes which are crucial SOC2 requirements.
Gemini 2.5 Flash · Confidence: HIGH
Evidence
[SOURCE] interface/main/backup.php:45 $cmd = escapeshellcmd($mysql_dump_cmd) . " --opt --quote-names " . escapeshellarg($sqlconf["dbase"])
Finding
Does the system implement automated backup procedures with encryption, integrity verification, offsite storage, and tested recovery processes to ensure system availability and data durability?
Remediation
Update the backup mechanism originating from `interface/main/backup.php` to include encryption and integrity verification for the generated database dump files. An external automated scheduler (e.g., cron) must also be configured to invoke this script, as the current implementation does not satisfy SOC2 requirements for automated, encrypted, and verifiable backups.
Remediation refined by Gemini review
SOC2-010
Pattern of Concern›
Regulatory Standard
Gemini Verification
CONFIRMED
The absence of documented security policies, vulnerability disclosure procedures, and operational guidance within the codebase and project documentation for OpenEMR is a direct non-compliance risk for SOC2, especially given its domain in healthcare.
Gemini 2.5 Flash · Confidence: HIGH
Evidence
No matching code patterns found.
Finding
Does the organization maintain and communicate documented security policies, vulnerability disclosure procedures, and security-related operational guidance within the codebase and project documentation?
Remediation
Add a `SECURITY.md` file to the repository's root, clearly outlining vulnerability reporting procedures, security contacts, responsible disclosure timelines, and supported product versions. Additionally, include a deployment security guide within the project's documentation covering essential aspects like TLS configuration, encryption at rest, MFA enforcement, session timeouts, and backup encryption. These additions are necessary to meet SOC2 requirements for documented security policies and operational guidance.
Remediation refined by Gemini review
SOC2-001
No Issue Found›
Regulatory Standard
Gemini Verification
CONFIRMED
The primary analysis correctly identified the use of a strong password hashing algorithm (BCRYPT with cost 12) within application source code, directly addressing the secure password storage component of the SOC2 authentication requirement, even if no issue was found.
Gemini 2.5 Flash · Confidence: HIGH
Evidence
[SOURCE] library/auth.inc.php:148 $hash = password_hash($password, PASSWORD_BCRYPT, ['cost' => 12]);` followed by `if (password_verify
Finding
Does the system implement strong authentication mechanisms including secure password storage, configurable complexity requirements, account lockout policies, and protection against credential-based attacks?
Remediation
While `password_hash($password, PASSWORD_BCRYPT, ['cost' => 12])` in `library/auth.inc.php:148` provides strong password storage, upgrading to `PASSWORD_ARGON2ID` with an appropriate cost factor in this file, where supported by PHP version, would further enhance resistance to GPU-based attacks, aligning with best practices for SOC2-001 authentication requirements. Additionally, the system's password policy settings should be clearly documented in deployment guides to meet SOC2 criteria for configurable complexity.
Remediation refined by Gemini review
SOC2-002
No Issue Found›
Regulatory Standard
Gemini Verification
ADDITIONAL RISK
The primary analysis incorrectly stated 'No Issue Found' because the explicit lack of code evidence for Role-Based Access Control in a critical healthcare system like OpenEMR represents a significant unverified risk to data security and regulatory compliance.
Gemini 2.5 Flash · Confidence: HIGH
Evidence
No matching code patterns found.
Finding
Does the system implement role-based access control with the principle of least privilege, ensuring users can only access resources and perform actions necessary for their job function?
Remediation
A thorough review of OpenEMR's source code is necessary to identify and confirm the presence and correct implementation of Role-Based Access Control, including adherence to the principle of least privilege. The current absence of code evidence for RBAC poses a significant risk of non-compliance with SOC2-002 and HIPAA, as unauthorized access to protected health information cannot be reliably prevented.
Remediation refined by Gemini review
SOC2-004
No Issue Found›
Regulatory Standard
Gemini Verification
ADDITIONAL RISK
The primary analysis understated the risk by concluding 'No Issue Found' despite reporting 'No code evidence was found' for comprehensive logging, monitoring, protection, and retention, which are critical SOC2 controls for a healthcare system.
Gemini 2.5 Flash · Confidence: HIGH
Evidence
No matching code patterns found.
Finding
Does the system implement comprehensive logging of security-relevant events with sufficient detail for forensic analysis, and are logs protected against tampering, monitored for anomalies, and retained for an appropriate period?
Remediation
"No code evidence was found" implies a critical gap in logging; the OpenEMR repository requires new code to generate security-relevant event logs with forensic detail and integrate them with an external log management system configured for tamper protection, anomaly monitoring, and defined retention. This change is necessary to satisfy SOC2-004 Logging and Monitoring requirements.
Remediation refined by Gemini review
Possible False Positives (1)Gemini flagged these as likely pattern matches in non-source-code files. Review before acting.
›
GDPR
EU DPAs · Up to EUR 20M or 4% turnover
10 findings · 1 possible FP
GDPR-003
High Risk›
Regulatory Standard
Gemini Verification
CONFIRMED
The primary analysis correctly identifies a critical GDPR high-risk area (Right to Erasure) where no code evidence was found to demonstrate its implementation in this healthcare repository, indicating a significant compliance gap.
Gemini 2.5 Flash · Confidence: HIGH
Evidence
No matching code patterns found.
Finding
Does the system provide a mechanism for data subjects to request and obtain erasure of their personal data ("right to be forgotten"), and can the system completely remove personal data from all storage locations including backups and derived datasets?
Remediation
OpenEMR must develop a dedicated administrative module or API endpoint that processes data subject erasure requests by systematically identifying and permanently deleting or irreversibly anonymizing all personal data, including associated records, logs, and audit trails across the application's database schema, to ensure full compliance with GDPR's Right to Erasure.
Remediation refined by Gemini review
GDPR-006
High Risk›
Regulatory Standard
Gemini Verification
CONFIRMED
The explicit absence of code evidence for automated breach detection, risk assessment workflows, and notification mechanisms for a high-risk GDPR requirement in a healthcare system strongly indicates a lack of necessary compliance functionality.
Gemini 2.5 Flash · Confidence: HIGH
Evidence
No matching code patterns found.
Finding
Does the system support the 72-hour breach notification requirement under GDPR, including automated detection of personal data breaches, assessment of risk to data subjects, and notification workflows for supervisory authorities and affected individuals?
Remediation
Add dedicated functionality within the OpenEMR application to monitor for potential personal data breaches (e.g., by integrating with internal audit logs), provide a guided workflow for assessing the risk to data subjects, and manage communication for breach notifications to supervisory authorities and affected individuals, ensuring adherence to GDPR's 72-hour breach notification timeframe as per Articles 33 and 34.
Remediation refined by Gemini review
GDPR-007
High Risk›
Regulatory Standard
Gemini Verification
CONFIRMED
The primary analysis found no code evidence for automated data retention policies or deletion/anonymization mechanisms, which is a confirmed high risk for a GDPR-compliant healthcare system handling personal data.
Gemini 2.5 Flash · Confidence: HIGH
Evidence
No matching code patterns found.
Finding
Does the system enforce data retention policies that limit personal data storage to the minimum period necessary for the stated purpose, and does it provide automated mechanisms for data deletion or anonymization when retention periods expire?
Remediation
To address the absence of data retention mechanisms, add a new module within the application's core logic (e.g., in `library/` or a dedicated data management directory) that defines and enforces configurable retention periods for patient data, billing records, and audit logs. This module must include automated scheduling and execution of anonymization or deletion routines upon expiry to comply with GDPR Article 5(1)(e) on storage limitation.
Remediation refined by Gemini review
GDPR-001
Medium Risk›
Regulatory Standard
Gemini Verification
CONFIRMED
The complete absence of code evidence for tracking and enforcing a lawful basis for processing special category health data under GDPR represents a confirmed, critical compliance gap in the application's design.
Gemini 2.5 Flash · Confidence: HIGH
Evidence
No matching code patterns found.
Finding
Does the system document and enforce a lawful basis for processing personal data under Article 6 of the GDPR, including specific provisions for processing special categories of health data under Article 9?
Remediation
Modify the `patient` data model within the database schema (e.g., `sql/create_tables.sql`) to include a `lawful_basis` field, explicitly documenting the legal grounds for processing. Integrate application-level controls (e.g., in `interface/patient_file/summary/demographics.php`) to enforce purpose limitation by tagging data processing activities, which is necessary to prevent violations of GDPR Articles 5, 6, and 9.
Remediation refined by Gemini review
GDPR-004
Medium Risk›
Regulatory Standard
Gemini Verification
CONFIRMED
The absence of code evidence for a mandatory GDPR data portability feature in a healthcare system like OpenEMR strongly indicates a lack of implementation, confirming a genuine compliance risk under GDPR Article 20.
Gemini 2.5 Flash · Confidence: HIGH
Evidence
No matching code patterns found.
Finding
Does the system allow data subjects to receive their personal data in a structured, commonly used, and machine-readable format, and can this data be transmitted directly to another controller upon request?
Remediation
OpenEMR requires new code development to implement a patient-facing data export module in the patient portal, enabling users to download all their personal data in structured, machine-readable formats (e.g., JSON, XML). Enhance existing CCD/CCDA export functionalities to include non-clinical personal data and a direct transmission capability, to comply with GDPR Article 20 and mitigate non-compliance risks.
Remediation refined by Gemini review
GDPR-008
Medium Risk›
Regulatory Standard
Gemini Verification
CONFIRMED
The absence of any code evidence for cross-border data transfer safeguards in an EHR system that handles personal data indicates a direct compliance risk, as the application itself does not provide mechanisms to ensure GDPR Chapter V requirements during data transfers.
Gemini 2.5 Flash · Confidence: HIGH
Evidence
No matching code patterns found.
Finding
Does the system implement safeguards for transferring personal data to countries outside the EEA, including adequacy assessments, Standard Contractual Clauses, or other approved transfer mechanisms under Chapter V of the GDPR?
Remediation
Add new configuration variables within `library/options.inc.php` to define permitted data residency regions and explicit cross-border transfer policies. Implement geographic validation logic within `interface/modules/api/api_routes.php` to block or warn against data transfers to non-adequate jurisdictions, thereby establishing critical safeguards required by GDPR Chapter V.
Remediation refined by Gemini review
GDPR-002
Pattern of Concern›
Regulatory Standard
Gemini Verification
CONFIRMED
The primary analysis finding 'No code evidence was found' for GDPR consent management in a healthcare system like OpenEMR indicates a critical absence of detectable compliance mechanisms, which is a direct and confirmed risk under GDPR Article 7.
Gemini 2.5 Flash · Confidence: HIGH
Evidence
No matching code patterns found.
Finding
Does the system implement GDPR-compliant consent management with granular consent collection, purpose-specific tracking, easy withdrawal mechanisms, and auditable consent records?
Remediation
Add core application logic and data models within OpenEMR's user-facing modules to capture granular, purpose-specific consent with timestamps and versioning, ensuring easy withdrawal mechanisms are integrated into patient preferences. This critical absence of detectable consent management components in the codebase poses a high risk of non-compliance with GDPR Article 7 requirements for valid consent, potentially leading to significant fines and reputational damage.
Remediation refined by Gemini review
GDPR-005
Pattern of Concern›
Regulatory Standard
Gemini Verification
CONFIRMED
The `getPatientData` function defaulting to `SELECT *` for sensitive patient data directly contradicts GDPR's data minimization and privacy by default principles by retrieving more data than necessary without an explicitly defined purpose for each request.
Gemini 2.5 Flash · Confidence: HIGH
Evidence
[SOURCE] library/patient.inc.php:52 function getPatientData($pid, $given = "*")` defaults to `SELECT *
Finding
Does the system implement data protection by design and by default, incorporating privacy-protective measures such as data minimization, pseudonymization, and purpose limitation into its core architecture?
Remediation
In `library/patient.inc.php`, modify the `getPatientData` function to remove the `SELECT *` default. Instead, require callers to explicitly declare the necessary fields for data retrieval, ensuring that only data relevant to the specific purpose is returned, which directly addresses GDPR's data minimization and privacy by default requirements.
Remediation refined by Gemini review
GDPR-010
Pattern of Concern›
Regulatory Standard
Gemini Verification
CONFIRMED
The absence of code evidence for displaying transparent privacy notices at data collection points, which is a core GDPR Article 13 and 14 requirement for a healthcare system, indicates a direct and confirmed compliance risk.
Gemini 2.5 Flash · Confidence: HIGH
Evidence
No matching code patterns found.
Finding
Does the system provide transparent privacy notices to data subjects at the point of data collection, informing them of processing purposes, lawful basis, data retention periods, their rights, and controller contact information as required by Articles 13 and 14?
Remediation
Modify existing patient registration forms (e.g., files like `interface/forms/patient/new_patient.php`) and patient portal signup pages (e.g., files like `portal/register.php`) to explicitly include or link to a GDPR-compliant privacy notice prior to data collection. This direct programmatic inclusion is essential to meet the transparency requirements of GDPR Articles 13 and 14.
Remediation refined by Gemini review
Possible False Positives (1)Gemini flagged these as likely pattern matches in non-source-code files. Review before acting.
›
What This Analysis Covers

OpenDocket scans source code patterns — specifically whether code handles regulated data in compliance-aware ways. It searches for evidence of encryption, access controls, consent mechanisms, audit logging, and other patterns that regulators look for.

What It Does Not Cover
  • Only public repository content is analyzed
  • Files in .gitignore are not scanned
  • Infrastructure, deployment, and cloud configuration are outside scope
  • Operational policies and procedures are outside scope
  • This analysis covers code at time of scan — changes after scan date are not reflected
Legal Limitations
  • This report is not defensible in court
  • It does not constitute legal advice
  • It does not satisfy regulatory audit requirements
  • To obtain a defensible compliance assessment, engage a licensed compliance attorney and certified auditor
  • OpenDocket provides directional guidance only
How Findings Are Generated
  • Primary analysis by Claude Sonnet (Anthropic)
  • Verification by Gemini 2.5 Flash (Google)
  • Question libraries are open source and community-maintained
  • All questions cite regulatory source text
  • Questions have not been validated by a licensed attorney
Why Two Models?

Claude Sonnet scans broadly — it finds every pattern that could indicate a compliance risk. This produces a comprehensive set of findings but includes noise from documentation files, config references, and test data.

Gemini 2.5 Flash then challenges each finding independently. It asks: is this evidence from actual application code? Would a regulator actually find this concerning? Is the severity appropriate?

The result is a tiered output:

  • CONFIRMED — Gemini agrees this is a real risk
  • CONTEXT DEPENDENT — Risk depends on deployment/infrastructure
  • POSSIBLE FALSE POSITIVE — Likely noise, review before acting

The confirmed count is the number you should act on. The total count shows the full scope of what was examined.

Evidence Tiers

Evidence is classified into three tiers based on file type:

  • [SOURCE] — Application source code (.ts, .py, .go, .rs, etc.) — strongest evidence
  • [CONFIG] — Configuration files (.yml, .json, .toml, Dockerfile) — moderate evidence
  • [DOCS] — Documentation (.md, .txt, .html) — context only, cannot produce High Risk findings

A finding is only classified as High Risk if supported by at least two source code files with matching evidence. Documentation references alone produce Pattern of Concern at most.

How to Use This Report
  • Share with your engineering lead for remediation planning
  • Share with your attorney as a starting point for compliance review
  • Re-scan after remediation to track progress
  • Do not present this as proof of compliance
Findings based on OpenDocket's open source question libraries. View and contribute