PDI Verified Adversarially validated · Audit ledger public · Cycle 6

What it means when your clinical platform says it's secure.

PDI Verified is not a self-assessment. It is the result of an adversarial validation cycle — automated attack simulation across 12 security and clinical preservation domains — with the full outcome record published publicly so anyone can read it.

What the validation actually tests

Each cycle of PDI Verify runs a structured adversarial battery against the live codebase. The battery simulates the attacks that matter most for a platform handling clinical data under physician control — not generic security checklists, but attack classes built around the specific trust model PDI Med claims to implement.

The tests ask: if PDI Med's claims were false, how would that manifest? If the vault were accessible without the physician's key — what would that look like in code? If patient information reached the AI model — where would it cross the boundary? Each attack class answers one of these questions. The full outcome is published below.

A1 · Vault Encryption
Can the vault be decrypted without your key?

Tests whether server-side access or a database dump can produce readable patient data. AES-256-GCM encryption, physician-held keys.

A2 · Physician Privacy
Can physician behavior be profiled from aggregate data?

Tests whether patterns in de-identified federated data can re-identify which physician treated which patient types.

A3 · Note Security
Can a clinical note compromise the system?

Tests prompt injection, SQL injection, and database manipulation via clinical note content. All notes are treated as data, not instructions.

A4 · Login Security
Can authentication be bypassed?

Tests NPI-only bypass, credential stuffing patterns, session token manipulation, and unauthenticated API access to PHI-adjacent routes.

A5 · Access Controls
Can internal access reconstruct physician data?

Tests whether admin-level access, support paths, or database inspection can produce individually identifiable physician practice patterns.

A6 · Data Sovereignty
Can PDI Med be compelled to produce your data?

Tests what PDI Med actually holds under subpoena. Because vault contents are encrypted under physician-held keys, there is nothing producible. Tests verify this architecture holds.

A7 · Data Retention
Does patient information persist in logs?

Tests whether clinical context appears in application logs, error traces, temporary files, or caches after a session ends.

A8 · Support Path Security
Can support access expose patient data?

Tests whether help requests, debug routes, or support sessions create paths to de-encrypt vault contents or surface clinical data.

A9 · Software Supply Chain
Can a dependency introduce a vulnerability?

Tests third-party package integrity, dependency pinning, and whether a compromised upstream package could exfiltrate vault data.

A10 · De-identification
Does patient information reach the AI model?

Tests all 11 adversarial PHI format variants (PP-01 to PP-11): name abbreviation series, prose emails, nonstandard phone separators, legal name bridges, relative names with clinical facts, BRCA accession splits, and more.

A11 · Clinical Preservation
Does clinical data survive the privacy process intact?

Tests that gestational ages, diagnoses, procedures, measurements, and eponymous clinical terms pass through the de-identification pipeline unchanged. The pipeline removes who — not what.

A12 · Assurance Integrity
Is this summary connected to real test results?

Tests whether the assurance layer can be gamed, manually authored, or disconnected from actual validation. The certificate hash chain makes post-generation modification detectable.

Latest validation cycle

Cycle 6 — PDI Verified (Conditional)
10 security and clinical preservation tests completed. No new findings were identified. 2 privacy-sensitive components were re-validated before deployment. 4 tests require live system access and are scheduled for the next validation window.

"Conditional" means some test cases require live system-level access that cannot be fully automated — for example, confirming that a real database dump is unreadable without a physician key requires a controlled live environment, not just a code scan. Those cases are scheduled for the next cycle window. All automatable tests passed.

Public audit ledger
The full cycle record is publicly accessible. Each entry contains the certificate ID, outcome, what was tested, what changed, and whether any findings were identified. The record is hash-chained — every entry references the SHA-256 hash of the previous one, making retroactive modification detectable by anyone who holds a prior entry.

Latest certificate: PDI-CERT-0006-5085D167
Cycle date: 2026-06-02
Overall outcome: CONDITIONAL
View full audit ledger (JSON) →

What PDI Verified is not

PDI Verified is not a certification body stamp. There is no third party that issued this badge. The validation is designed and run by PDI Med against its own codebase, with the full methodology and results published publicly so any party can evaluate the claims independently.

The value is in the specificity and the public record — not the badge itself. A physician reading this page can see exactly what was tested, what the result was, and can verify the hash chain of the ledger independently. A badge without that is marketing. A badge with that is evidence.

The multi-layer de-identification architecture with mandatory physician verification, tokenization-rehydration pipeline, and hash-chained audit ledger described here are the subject of a provisional patent application.
Methodology Publication

PDI Verify: An Adversarial Audit Methodology for AI-Assisted Clinical Software — Extended with Dual-Axis Clinical Context Preservation and Physician Assurance Layer

Bristow, D.  ·  Zenodo, June 4, 2026  ·  v1.0.2

Introduces the dual-axis certification standard (A10 + A11): A10 tests whether PHI is removed from the pipeline; A11 tests whether clinical meaning survived the privacy process. Neither condition alone constitutes adequate certification for clinical AI. Also introduces the A12 Assurance Integrity attack class and the tokenization-rehydration architecture.

DOI: 10.5281/zenodo.20549147