Privacy & Security¶

OpenMed is built for environments where operators need to see what the system is doing, where data is stored, and which external services are in the loop. This page describes the product as it exists today, not an idealized future control plane.

Runtime boundary¶

OpenMed itself runs locally. The TUI, session files, plans, cards, workflow artifacts, and local file operations all happen on your machine.

That does not mean every clinical capability is fully offline. Many medical functions depend on remote service boundaries:

The model provider (openmed login / OPENAI_API_KEY)
OpenMed's native medical service plane for extraction, PII, de-identification, terminology, education, HCC, and RAF tooling
User-added remote MCP endpoints

OpenMed does not assume every task belongs on the same remote boundary. General agent reasoning uses the configured model provider, while extraction, PII, de-identification, terminology, HCC, and RAF paths can run on dedicated protected medical-service planes. This split is designed to improve control, throughput, and cost efficiency for sensitive or high-volume clinical processing. The actual privacy and compliance posture still depends on where those services are hosted and governed.

Approval And Review Model¶

OpenMed does not stop for a modal approval before every tool call.

What happens today:

Deterministic workflows use a separate draft/finalize lifecycle, where final writes require a valid approval_token
Approval dialogs for approval-gated tools such as edit_file are currently wired on the OpenAI SDK path
Read/search/extraction tools can run without a modal approval step, but their execution is still surfaced in the TUI with plans, tool-call messages, and results

If you need a stricter approval policy than that, the current docs should not imply you already have it.

PHI Modes¶

OpenMed exposes three PHI modes in the CLI and TUI:

Mode	Current meaning
`full`	General-purpose clinical workflow context
`deid`	Indicates a de-identification-first posture where the workflow/path supports it
`strict`	Indicates a conservative handling posture for highly sensitive runs

Important caveat:

The current PHI mode setting is visible in the UI and persisted in session state, but it should not be treated as a universal enforcement layer by itself. Actual data handling depends on:

Which tool path or workflow you invoke
Whether that path explicitly calls deidentify_text or another de-identification step
Which remote boundaries are in use for model, native medical-service, or MCP access

In other words: treat PHI mode as operator-visible workflow context, not as a standalone compliance guarantee.

Local Storage¶

OpenMed writes local state to files such as:

~/.openmed/sessions/ for persisted TUI sessions
/tmp/openmed/artifacts/ and /tmp/openmed/cases/ by default for workflow outputs
~/.config/openmed/ for config, MCP metadata, profiles, and user skills
~/.openmed/auth.json for OAuth credentials
~/.openmed/audit.json and ~/.openmed/traces/ only when optional audit traces are enabled or HF audit writes fall back locally

Optional Audit Trail¶

Audit traces are opt-in and off by default. When enabled, they write directly from the user's machine to the configured private destination:

private Hugging Face Dataset repo
private Hugging Face Storage Bucket
local-only trace directory

OpenMed does not send audit traces to OpenMed-owned infrastructure. Once audit is enabled, the default audit payload mode is payload, which stores the full private transcript and tool payloads in the configured destination. Use preview, fingerprint, or none when you need a smaller or less revealing trace.

phi_payload is separate from PHI mode:

PHI mode describes the operator posture for the run
phi_payload controls what the audit trace stores

Use openmed audit status and /audit to see the active audit posture. See Audit Trail for setup and trace contents.

Token Storage¶

openmed login stores credentials locally:

openmed login writes ~/.openmed/auth.json
Project-local ./auth.json is deprecated and ignored

The current implementation writes a normal local JSON file and sets restrictive file permissions where supported by the operating system. Teams with stricter requirements should still rely on OS-level access controls.

Network Access¶

OpenMed can access the network for:

Model traffic — prompts/responses with the configured LLM provider
OAuth and auth validation — browser login flow plus token validation/status checks when invoked
Native medical services — extraction, PII, de-identification, terminology, education, HCC, and RAF tooling
Optional audit writes — private HF dataset or bucket writes only if openmed audit enable has been configured
Remote MCP servers — only if you configure them
Self-update — release checks/downloads when you run openmed update
Connectivity checks — commands such as openmed mcp doctor

Outside those paths, the local runtime remains local.

See Native Medical Services for the deployment patterns behind those service planes.

No Telemetry¶

OpenMed Agent itself does not include in-product analytics, usage tracking, or background crash reporting. Public marketing and documentation pages may use lightweight site analytics to understand aggregate visitor traffic.

That statement does not cover third-party services you intentionally configure. Once you point OpenMed at a model provider, customer-managed native medical-service plane, or remote MCP server, the privacy and retention posture of that service becomes part of your real deployment boundary.

Practical Guidance¶

If you need the most defensible deployment story today:

Keep sessions and artifacts on managed local storage
Treat ~/.openmed/auth.json as the single OAuth credential file and protect the user account that owns it
For customer-managed deployments, run native medical services on infrastructure you control or have vetted contractually
Treat PHI mode as operator context, and verify the exact tool/data path for any sensitive workflow
Use draft/finalize workflows so reviewers can inspect outputs before final writes