DOCS — INTEGRATIONS · WEB SEARCH

Web Search

OpenMed does not search the web unless you turn it on — on every provider, including OpenAI and ChatGPT OAuth. This page explains why, what enabling it sends where, and how to configure it.

Why it is off by default

A search query built from a case tends to contain clinical detail. Sending that query to a hosted search API makes that vendor a third-party data processor for your patient data. That is a decision an operator should make deliberately, with knowledge of which vendor and under which agreement — not one inherited from a default.

There is a second reason, specific to clinical work. OpenAI's Responses API can run a provider-side search where the model searches and returns prose. Those results never reach OpenMed as inspectable sources, so a claim drawn from them cannot be traced back to a page you can open and check. OpenMed's evidence rules require citations to be verifiable, so OpenMed does not request provider-side search. When search is enabled, it runs client-side and every result becomes a source record with a URL you can inspect.

What still works with search off

Search being off does not mean OpenMed is cut off from evidence:

• PubMed, MedlinePlus and RxNorm lookups work normally and do not use a third-party search vendor.
• fetch_web_page retrieves a specific URL you or the agent already has.
• The literature and guideline workflows are unaffected.

What is unavailable is open-ended discovery — "find me recent papers on X" where no URL is known yet.

Enabling it

Two things are required: the feature flag, and a backend key. A key on its own does nothing, so that adding a key for another purpose can never silently start sending clinical text to a vendor.

export OPENMED_WEB_SEARCH=1
export SERPER_API_KEY="..."

Supported backends:

Backend	Key	Sign-up
Serper	SERPER_API_KEY	https://serper.dev
Tavily	TAVILY_API_KEY	https://tavily.com
Brave Search	BRAVE_SEARCH_API_KEY	https://brave.com/search/api/

With more than one key present, OpenMed picks the first configured backend. To pin one explicitly:

export OPENMED_WEB_SEARCH_BACKEND=tavily

Keys can also live in ~/.openmed/service_secrets.json rather than the environment:

{
  "web_search": {
    "serper_api_key": "..."
  }
}

Keys are sent as request headers, never as query parameters, so they do not end up in proxy logs. They are never embedded in the binary and never included in any diagnostic output.

Checking the state

openmed env

reports whether search is enabled and which backend is active. Inside the TUI, /config shows the same. When search is off and the model is asked to search, it receives an explanation naming the flag, the backend options and this page — so it can tell you what to do rather than claiming it simply cannot search.

What gets sent

When enabled, the search query goes to the backend you configured. The query is composed by the model from the conversation, so assume it can contain clinical detail. The rest of the case is not sent.

Search results come back as titles, URLs and snippets. Snippets are the search engine's summaries, not page content — OpenMed will fetch a page with fetch_web_page before citing anything from it.

PHI and third-party search

If you handle PHI under HIPAA or equivalent, a search vendor is a sub-processor. Confirm your agreement covers it before enabling search on sessions that touch patient data, or keep search off and rely on the PubMed and guideline tools, which do not use one.

Turning it off

unset OPENMED_WEB_SEARCH

The tool stays registered and reverts to explaining that search is disabled.