PDI-Med Architecture

This document answers one question precisely: what happens when a physician uses PDI-Med? Not promises, not implications, not future integrations—only the architecture as built.

Protected Health Information is not sent to PDI-Med servers as a default operating condition. This is a system design boundary, not a trust-based promise or legal workaround. Every feature is built outward from this constraint.

• Step 1 — Physician Interaction (Identified Domain). The physician may paste raw clinical text—including identifiers—without friction or scolding. This occurs entirely within the physician-controlled environment.
• Step 2 — Local Processing & De-Identification. Local processes detect PHI patterns, remove/generalize identifiers, normalize content, and suppress rare combos. The behavior is quiet, deterministic, and conservative.
• Step 3 — De-Identified Output Only Leaves. Only de-identified text or structured abstractions can be transmitted for inference or synthesis. PHI transmission is treated as a security incident, not a feature.
• Step 4 — AI Synthesis (Non-Prescriptive). Outputs are descriptive: summaries, differential framing, guideline context, follow-up considerations, documentation support, and uncertainty articulation. No orders or standards of care.
• Step 5 — Synthetic Case Generation (Optional). If the physician elects, a PHI-free Synthetic Case is created for recall, pattern recognition, and aggregation. It is non-reversible and not a patient record.
• Step 6 — Federated Intelligence (Aggregate Only). Synthetic Cases can contribute to cohort-level insight: trends, distributions, and grey-zone patterns. Outputs are non-punitive, non-ranking, and non-identifying.

What PDI-Med never does: store PHI as normal operation, require PHI for support, rank physicians, grade performance, report to employers or payors, enforce consensus behavior, or issue prescriptive mandates.

• What PDI-Med can see: de-identified text, synthetic cases, aggregate patterns, and non-clinical usage metadata.
• What PDI-Med cannot see: patient identities, raw charts, names/MRNs/DOBs, re-identification keys, vault contents.

Privacy is an engineering constraint: if a feature requires PHI server-side, it is not built; if monetization requires leakage, it is rejected; if growth pressures conflict with trust, trust wins.

• Only the physician can unlock the vault.
• PDI-Med cannot decrypt vault contents or reconstruct patients.
• PDI-Med cannot impersonate the physician.
• Keys are never stored in a form that grants PDI-Med access to PHI.
• Recovery mechanisms exist without custody.

Once data is de-identified, converted to Synthetic Cases, and aggregated into Federated Intelligence, it becomes part of a collective clinical commons. Selective removal of individual contributions is avoided because it corrupts aggregate validity. This is disclosed transparently.

PDI-Med is a cognitive support system, longitudinal memory extension, grey-zone sandbox, and physician-owned learning layer. It helps clinicians think clearly, see patterns, reduce blind spots, close loops, and practice with integrity under uncertainty.

It is not an AI doctor, guideline enforcer, quality scoring engine, utilization tool, or compliance monitor. It shows what happened, how often, under what conditions, with what follow-ups, and with what uncertainty. It does not say “you should” or “you must.”

Innovation safeguard: PDI-Med protects legitimate outliers, thoughtful deviations, experimental reasoning, and minority insight. Consensus gravity is treated as a risk, not a virtue.

This architecture exists to give physicians a private cognitive workspace—not another overseer.