Skip to content

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 configured remote services:

  • The model provider (openmed login / OPENAI_API_KEY)
  • OPENMED_INFERENCE_URL for extraction and PII tooling
  • OPENMED_MED_CODES_API_URL for PubMed, terminology, RxNorm, MedlinePlus, and HCC 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 endpoints. 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 endpoints you configured for model, inference, med-codes, 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
  • ./auth.json or ~/.openmed/auth.json for OAuth credentials, depending on how you logged in

Token Storage

openmed login stores credentials locally:

  • openmed login writes ./auth.json by default
  • openmed login --global writes ~/.openmed/auth.json

The current implementation writes normal local JSON files. It does not add extra permission hardening beyond the behavior of your local filesystem, so teams with stricter requirements should choose the storage location deliberately and 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 — OPENMED_INFERENCE_URL and OPENMED_MED_CODES_API_URL
  • 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 endpoints.

No Telemetry

OpenMed does not include analytics, usage tracking, or background crash reporting.

That statement does not cover third-party services you intentionally configure. Once you point OpenMed at a model provider, hosted inference endpoint, med-codes endpoint, 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:

  1. Keep sessions and artifacts on managed local storage
  2. Use openmed login --global only when a shared home-level auth location is actually desired
  3. Point native service endpoints at infrastructure you control or have vetted contractually
  4. Treat PHI mode as operator context, and verify the exact tool/data path for any sensitive workflow
  5. Use draft/finalize workflows so reviewers can inspect outputs before final writes