Purpose
Why this posture exists
Security here is threat-model-driven, not a checklist. It is designed for hostile environments, human error, and institutional skepticism. Privacy is enforced by architecture, not promises.
Mindset
Security philosophy
- Users make mistakes; browsers can be compromised; malicious actors exist.
- Trust is enforced by design: minimize sensitive data, collect only what can be protected, prefer not to store at all.
- The safest data is data we never see.
Separation
Domain separation (primary safeguard)
- Identified Domain: may contain PHI; controlled by the physician; not transmitted by default.
- De-Identified Domain: contains scrubbed/synthetic data; may be stored and processed; cannot be re-identified by PDI Med.
This separation is foundational and non-optional.
Zero-knowledge
Zero-knowledge intent
- Vaults are physician-controlled; keys are not known to PDI Med.
- PDI Med cannot decrypt vault contents or reconstruct patients.
- Recovery relies on identity verification and remapping, not access to prior secrets.
- Zero-knowledge is the design intent and operating posture, not an absolute guarantee that transcends device integrity or credential compromise. PDI Med does not retain plaintext keys or patient data under any operating condition.
Evidence
Evidence spans and retroactive proof
Evidence spans are the de-identified, structured records of clinical reasoning that PDI Med stores — not the raw clinical notes that preceded them. They document what was known, what was uncertain, and what was ordered, without retaining the source PHI.
- Evidence spans are physician-owned artifacts stored under physician-controlled keys.
- They serve as retroactive proof that reasoning occurred — not as PHI surrogates or re-identification vectors.
- PDI Med does not have access to evidence spans stored in the Vault; only de-identified derivatives may exist on PDI Med infrastructure.
Threats
Threat modeling assumptions
- Insider misuse, credential theft, data exfiltration attempts.
- Aggregation abuse and “curious” reverse engineering.
- Institutional pressure to expand scope beyond physician-first and privacy absolutes.
Features that expand attack surface without proportional benefit are rejected.
Privacy
Collective intelligence safeguards
- Minimum cohort sizes enforced.
- Rare combinations suppressed.
- Drill-down depth limited; no single-user extraction.
- No comparative physician ranking.
Outputs are intentionally blunt at the edges to preserve safety.
Logging
Logging and monitoring
- PDI Med logs system health, security events, and abuse signals.
- PDI Med does not log PHI, raw clinical text, or patient identifiers.
- Logs exist to defend the platform, not to surveil users.
Response
Incident response
- Access may be temporarily restricted to contain suspected incidents.
- Investigation prioritizes containment; vault remapping may be required.
- Aggregate integrity is preserved; transparency preferred over concealment.
Browser
Browser-based reality
- Hospital machines and policies vary; environments may be hostile.
- Platform remains lightweight, non-persistent by default, resilient to session termination.
- No privileged software install required.
Will not
What PDI Med will not do
- Store PHI “temporarily.”
- Ask users to email data.
- Troubleshoot using patient data.
- Backdoor encryption.
- Trade privacy for convenience.
- Use board preparation session data for credentialing, performance scoring, or employer disclosure.
- Provide employers, payors, or institutional partners access to individual physician-level data of any kind.
Summary
Summary for security teams
PDI Med minimizes risk by not collecting what it cannot protect, strictly separating domains, designing for failure, and treating privacy as an architectural invariant — not a policy promise. Evidence spans prove reasoning without exposing patients. Zero-knowledge is the operating posture, not an absolute guarantee. What PDI Med cannot see, it cannot expose. This is structural restraint, not compliance theater.