Developer GuideOpenAI-compatibleUpdated September 2026

Best Healthcare AI API: Why Build with EvidenceMD (2026)

EvidenceMD is the healthcare AI API to build on when your product needs clinical answers grounded in current guidelines and peer-reviewed literature, with citations users can check and reasoning they can audit. It is post-trained heavily on clinical conversation across medical specialties, it is the first medical API to return reasoning tokens, it answers in 30 languages, and it runs HIPAA compliant with zero retention of what you send. Point the OpenAI SDK at it and ship clinical decision support, prior authorization, utilization review, documentation, triage, and patient-facing features without first building a medical evidence pipeline of your own.

  • Post-trained on clinical conversation
  • Reasoning tokens, up to 64k
  • Peer-reviewed citations
  • 30 languages
  • HIPAA · zero retention
Drop-in: change two lines
client = OpenAI(
    base_url="https://evidencemd.ai/api/v1",   # 1. point here
    default_headers={"x-api-key": "YOUR_KEY"}, # 2. your key
)
client.chat.completions.create(model="evidencemd-deep", messages=[...])
# → clinical answer + reasoning tokens + peer-reviewed citations
Endpoint
/v1/chat/completions
Reasoning
up to 64k tokens
Languages
30
Retention
Zero
By the EvidenceMD Editorial TeamPublished September 17, 2026Updated September 17, 202612 min read
Quick Answer

EvidenceMD is the best healthcare AI API to build a clinical product on in 2026 because the clinical layer is inside the API rather than something you assemble around a general model. It is post-trained heavily on clinical conversation across medical specialties, retrieves evidence per request and cites it inline, and is the first medical API to return reasoning tokens — up to a 64,000-token reasoning budget on evidencemd-deep. It answers in 30 languages, runs HIPAA compliant with zero retention of what you send, and is OpenAI-compatible: point the OpenAI SDK at https://evidencemd.ai/api/v1 and ship clinical decision support, differential diagnosis, prior authorization, utilization review, clinical documentation, triage, and patient-facing features from one endpoint.

Key takeaways

  • EvidenceMD is a healthcare AI API with the clinical layer already inside it: evidence is retrieved per request, peer-reviewed citations come back inline, and the clinical reasoning is returned as tokens you can stream, show, or log.
  • It is the first medical API to expose reasoning tokens, and evidencemd-deep carries a 64,000-token reasoning budget for multi-comorbidity cases, utilization review, and appeal drafting.
  • It is post-trained heavily on clinical conversation across medical specialties and accepts a specialty parameter, so one integration serves a cardiology copilot and an oncology copilot without two prompt stacks.
  • One endpoint covers clinical decision support, differential diagnosis, prior authorization, utilization review, documentation, triage, patient-facing education in 30 languages, and clinical agents.
  • It is HIPAA compliant with zero retention of request and response content, no training on your data, AES-256-GCM at rest, TLS 1.2+ in transit, and a BAA executed before patient data flows.
  • Pricing is flat per request rather than per token — 4 credits ($0.20) for fast and pro, 5 credits ($0.25) for deep — so you can price your own product from request volume alone.

What does a healthcare AI API have to do for a clinical product?

Every team building in healthcare faces the same early decision. You can start from a general-purpose model and assemble the clinical layer yourself, or you can start from a model built for clinical work. Both are legitimate paths. The difference is where your engineering and clinical effort goes.

Assembling the clinical layer means sourcing medical evidence, keeping it current, teaching the model to cite it, engineering the context window so a long chart does not quietly degrade the answer, building clinical evaluation, and recruiting clinicians to review outputs before launch. Each of those is a real project. None of them is the product your users are waiting for, and all of them have to be redone the next time the underlying model changes.

EvidenceMD puts that clinical layer in the API itself. Evidence is retrieved at request time rather than recalled from a training cutoff. Citations arrive inline and as a structured sources array. The clinical reasoning comes back as tokens you can stream, display, or log. The model is post-trained heavily on clinical conversation across medical specialties, so a bare clinical question returns a usable clinical answer without a mega-prompt behind it. And the deployment posture — HIPAA compliant, zero retention, no training on your data, a BAA at onboarding — is the posture a health system procurement team will ask about on the first call.

Choose EvidenceMD when your users are clinicians, care teams, utilization reviewers, or patients, and the value of your product depends on clinical reasoning being sound, sourced, and reviewable. Choose a general model API when the workload is administrative and never touches clinical judgment — that is a real category, and we will not pretend otherwise.

Why choose EvidenceMD over OpenAI, Claude, Gemini or Grok?

Six things a general-purpose model API does not give a clinical product, and EvidenceMD does.

Post-trained on clinical conversation, across specialties

Clinical dialogue, specialty terminology, appropriate hedging, and follow-up behaviour are trained in rather than prompted, so a bare clinical question returns a usable clinical answer. That is not a stylistic preference: a 2026 Nature Communications study found supervised fine-tuning outperformed prompt engineering for diagnostic accuracy, and that general models fell short in dynamic diagnostic workflows and frequently committed clinical errors.

The first medical API to return reasoning tokens

Set include_thinking and the clinical reasoning streams back as part of the response — not a summary of it. Your product can show a reviewer the step that mattered, log the chain for audit, or gate an action on a specific finding. evidencemd-deep carries a 64,000-token reasoning budget for cases where the reasoning has to survive scrutiny.

Evidence retrieved per request, cited inline

Answers are grounded in literature and guidelines retrieved at request time rather than recalled from a training cutoff, and citations arrive inline plus as a structured sources array you can store. This is exactly where off-the-shelf models are weakest — a 2025 JAMA Network Open study of 21 large language models found they performed poorly at generating differential diagnoses and navigating uncertainty.

Context engineering already done for you

Long histories, pasted lab panels, imaging reports, medication lists, and payer criteria documents are assembled, prioritised, and reasoned over inside the API. You send the clinical context your product already holds instead of designing a retrieval pipeline, a chunking strategy, a re-ranker, and a token budget that degrades quietly as the chart grows.

Specialty-aware and multilingual from one endpoint

Pass specialty for a specialty-tuned answer and language for any of 30 supported languages. The clinical reasoning happens once and the rendering changes, so a patient-facing explanation stays consistent with what the care team sees rather than drifting through a separate translation vendor.

HIPAA compliant with zero retention, by default

Request and response content is not retained after the call, and it is never used to train, fine-tune, or evaluate a model. Only usage metadata — key, endpoint, status, latency, credits — is kept, and it contains no PHI. A Business Associate Agreement is executed as part of onboarding before patient data flows.

The EvidenceMD API, by the numbers
Reasoning-token budget on evidencemd-deep for complex multi-comorbidity analysis, utilization review and appeals
64kReasoning-token budget on evidencemd-deep for complex multi-comorbidity analysis, utilization review and appeals
Languages from one endpoint, so clinician-facing and patient-facing features share the same clinical reasoning pass
30Languages from one endpoint, so clinician-facing and patient-facing features share the same clinical reasoning pass
State-of-the-art result on the HealthBench Hard clinical benchmark in EvidenceMD internal evaluation
SOTAState-of-the-art result on the HealthBench Hard clinical benchmark in EvidenceMD internal evaluation
Retention of API request and response content, with no training on your prompts or outputs
ZeroRetention of API request and response content, with no training on your prompts or outputs

Benchmark figures come from EvidenceMD internal evaluation on clinical reasoning benchmarks, with the conditions stated in the write-up. See the benchmarks.

The short version: use a general API when one model has to serve general, administrative, and clinical tasks and you are ready to build grounding, citations, context engineering, and clinical evaluation yourself. Use EvidenceMD when the specification is “return an evidence-backed clinical answer, a differential, a medical-necessity justification, or a note — with citations and visible reasoning” and you want that working the same day.

What can you build with the EvidenceMD healthcare AI API?

Fourteen features teams ship on one endpoint, grouped by who the user is. Every one of them can show the evidence and the reasoning behind its output, which is usually what separates a clinical feature that gets adopted from one that gets switched off.

Clinical decision support and diagnosis

Features where a clinician is the user and the answer has to be defensible, not just fluent.

Clinical question answering at the point of care

evidencemd-pro · include_thinking · streaming

The most direct product to build is a clinical Q&A surface for physicians, advanced practice providers, pharmacists, and nurses. A hospitalist asks whether an anticoagulant needs dose adjustment at a given creatinine clearance. A primary care physician asks what the current screening interval is for a patient with a specific risk profile. A pharmacist asks about a suspected interaction. EvidenceMD answers from retrieved literature and guidelines rather than model memory, returns inline peer-reviewed citations, and streams the clinical chain-of-thought so the clinician can check the logic step by step instead of accepting a verdict.

See clinical reasoning

Clinical decision support inside the chart

evidencemd-pro · response_format json_object

Decision support that lives in an EHR cannot return prose. Ask for a JSON object and you get typed fields your interface maps to discrete elements — assessment, suggested next step, supporting sources — so the suggestion renders natively in the chart instead of as a chat bubble. Because each recommendation carries its citation, the clinician sees why a prompt fired, which is the difference between decision support clinicians act on and another alert they dismiss.

Best clinical decision support AI

Differential diagnosis and workup planning

evidencemd-deep · specialty · 64k reasoning tokens

Diagnostic reasoning is where a clinical model separates itself from a general assistant. Send the history, exam, labs, imaging findings, and medication list, and evidencemd-deep works through them across up to 64,000 reasoning tokens to return a ranked differential, the discriminating finding behind each possibility, the next diagnostic step, and the guideline that supports it. This is precisely the task where off-the-shelf models are weakest: a 2025 JAMA Network Open study of 21 large language models found they performed poorly at generating differential diagnoses and handling clinical uncertainty.

How differential diagnosis AI works

Medication safety and polypharmacy review

evidencemd-pro · JSON mode · citations

A long medication list is a reasoning problem, not a lookup problem. EvidenceMD reasons across interactions, renal and hepatic dose adjustment, anticholinergic burden, and deprescribing candidates in one pass, attaching a citation to each recommendation so a pharmacist can verify before acting. Pharmacy platforms, care management tools, and transitions-of-care products all build on the same call.

Prior authorization, utilization review and documentation

The administrative reasoning US healthcare actually runs on, against named payer criteria and CMS rules.

Prior authorization drafting and denial appeals

evidencemd-deep · specialty: Insurance · JSON mode

Prior authorization is administrative reasoning against a named criterion set, and it is the workflow US healthcare software teams most often need to automate. EvidenceMD reasons over payer criteria by name — InterQual, MCG, Aetna Clinical Policy Bulletins, Cigna coverage policies — and over CMS National and Local Coverage Determinations, so a drafted request engages the specific criterion the reviewer will apply. Under the CMS Interoperability and Prior Authorization final rule (CMS-0057-F), effective January 1, 2026, affected plans must state the specific reason for a denial, which makes point-by-point rebuttal drafting a concrete, buildable feature rather than a generic letter generator.

Prior auth and appeals reasoning

Utilization review and level-of-care determination

evidencemd-deep · include_thinking

Utilization review turns on whether the documentation supports the status being billed. EvidenceMD assesses an admission against the two-midnight rule, checks the Medicare Inpatient-Only list, and produces reviewer-ready justification for observation versus inpatient — with the reasoning exposed so a nurse reviewer or physician advisor can accept, adjust, or reject a specific step. The same call supports concurrent review, retrospective audit defence, and peer-to-peer call preparation for the treating physician.

Clinical documentation, coding support and CDI

evidencemd-pro · JSON mode

Documentation burden is the most reliably felt problem in medicine and the most common reason a team evaluates a healthcare AI API. EvidenceMD drafts H&Ps, progress notes, discharge summaries, handoffs, and referral letters where the assessment and plan carry reasoning and citations rather than transcription alone. The same clinical layer flags the specificity a note is missing before it becomes a denial, which is what makes clinical documentation integrity and coding support a natural extension of a scribe rather than a separate product.

See the EvidenceMD AI scribe

Patient-facing, triage and access

Where clinical accuracy and plain language have to hold at the same time, in 30 languages.

Patient-facing answers and plain-language education

evidencemd-fast · language · reading level

Clinicians spend a large share of their day translating decisions into language patients can act on. EvidenceMD generates discharge instructions, condition education, medication guides, and return precautions at a patient reading level in any of 30 languages, while keeping the underlying evidence trail intact for the care team to review. Patient materials still have to be clinically sound — return precautions after a procedure need clinical context, not just simple words — which is why a clinically post-trained model matters more here than a general one with a friendly tone.

Triage, symptom intake and red-flag escalation

evidencemd-fast → escalate to deep · streaming

Intake products need to know when a presentation is routine and when it is urgent. EvidenceMD evaluates reported symptoms, vitals, and intake answers against clinical escalation criteria and returns the specific finding that drove the urgency rating, so a nurse line or telehealth router acts on a reason rather than a score. A common pattern is to default to evidencemd-fast for latency and escalate anything with a red flag to evidencemd-deep for a fuller reasoning pass before a human reviews it.

Referral routing and pre-visit synthesis

evidencemd-pro · include_thinking

A patient arriving with years of notes, dozens of medications, and a scattered specialist history is an unstructured-data problem. EvidenceMD condenses that context into a pre-visit brief organized around the reason for the encounter — active problems, relevant medications, recent changes, open questions — and decides which specialty a referral belongs to and what workup should precede it, so the receiving clinic gets a complete packet instead of a bounce-back.

Platform, agents and research

EvidenceMD as the clinical reasoning step inside a larger system you already own.

Specialty copilots embedded in existing software

specialty parameter · one endpoint

Most healthcare software companies are not building a new destination for clinicians; they are adding intelligence to a product clinicians already open — a care management platform, a specialty practice system, a population health dashboard. Because EvidenceMD is post-trained across medical specialties and accepts a specialty parameter, one integration serves a cardiology copilot, an oncology copilot, and a nephrology copilot without maintaining three prompt stacks. A single sidebar assistant can answer a guideline question, summarize the chart on screen, and draft the next document.

Specialty coverage

Clinical agents and subagents in larger systems

OpenAPI spec · JSON mode · tool use

An increasing number of healthcare products are multi-step systems where a scheduling agent, a documentation agent, and a billing agent each need a clinical opinion at some point. Because the endpoint is OpenAI-compatible with JSON mode and a published OpenAPI specification, EvidenceMD registers as the clinical reasoning step of an existing agent framework without a custom adapter, and returns structured output the next step can consume directly.

View the OpenAPI spec

Evidence surveillance for research, pharma and medical affairs

evidencemd-deep · include_thinking

Because evidence is retrieved per request rather than recalled from a training cutoff, EvidenceMD suits tools that monitor a clinical question over time — for medical affairs, payer policy teams, HEOR, and trial feasibility. Every conclusion traces back to a retrieved source, and the reasoning path between sources is visible, which is what makes an output defensible in a regulated review rather than merely plausible.

Life sciences and pharma API guide

Clinical trial eligibility screening

evidencemd-deep · JSON mode

Match a patient summary against inclusion and exclusion criteria and get back which criteria are met, which fail, and — the field most screening tools omit — which the chart cannot answer yet. Returning the unresolved criteria separately is what lets a coordinator work a queue instead of re-reading every chart, and the reasoning attached to each verdict is what a monitor will ask to see.

How do you make your first clinical API call?

The endpoint is OpenAI-compatible, so an existing integration migrates with a base URL, a key, and a model name. Clinical parameters — specialty, language, include_thinking — pass through extra_body in the OpenAI SDK, and response_format is the native OpenAI parameter.

cURL · POST /api/v1/chat/completions · streamed reasoning
curl https://evidencemd.ai/api/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "x-api-key: YOUR_API_KEY" \
  -d '{
    "model": "evidencemd-deep",
    "specialty": "Cardiology",
    "messages": [
      {"role": "user", "content": "72M with dyspnoea, orthopnoea and bilateral crackles. Differential and next steps?"}
    ],
    "include_thinking": true,
    "stream": true
  }'
Python · OpenAI SDK · specialty + language
from openai import OpenAI

# Drop-in: the official OpenAI SDK, pointed at EvidenceMD.
client = OpenAI(
    base_url="https://evidencemd.ai/api/v1",
    api_key="unused",  # auth travels in the x-api-key header
    default_headers={"x-api-key": "YOUR_API_KEY"},
)

resp = client.chat.completions.create(
    model="evidencemd-pro",
    messages=[{"role": "user", "content": "Discharge instructions after a first DVT?"}],
    extra_body={
        "specialty": "Internal Medicine",
        "language": "Spanish",       # one of 30 supported languages
        "include_thinking": True,    # stream the clinical reasoning tokens
    },
)

# The message carries the answer plus inline peer-reviewed citations.
print(resp.choices[0].message.content)
JSON mode · typed output for a utilization-review queue
{
  "model": "evidencemd-deep",
  "specialty": "Insurance",
  "response_format": { "type": "json_object" },
  "messages": [
    { "role": "user",
      "content": "Does this documentation support inpatient status under the two-midnight rule? Draft the justification." }
  ]
}

// Response: a typed object your utilization-review queue renders directly.
// "answer" holds markdown with inline [n](url) citations; "sources" is storable.
{
  "answer": "Inpatient status is supported. The documented expectation of two
             midnights rests on ... [1](https://www.cms.gov/...)",
  "sources": [ { "n": 1, "title": "...", "url": "https://..." } ]
}

Streaming uses standard server-sent events terminated with [DONE], and responses carry the usual choices, message, and finish_reason fields, so existing client code, retries, and observability keep working. Full parameter reference in the developer documentation.

Does EvidenceMD match your requirements?

The table below is written as a checklist for your own evaluation rather than as a scoring exercise against other vendors: the common buyer requirement, what EvidenceMD provides against it, and the workflow where it decides the outcome.

Healthcare AI API buyer requirements mapped to EvidenceMD API capabilities and the workflows where each one matters most.
What you needWhat EvidenceMD providesWhere it matters most
Answers grounded in current medical evidenceLiterature and guidelines retrieved per request, not recalled from a training cutoffClinical Q&A, treatment planning, guideline currency checks
Citations a clinician can open and checkInline peer-reviewed citations plus a structured sources array you can storeAny clinician-facing feature where trust has to be earned
Visible reasoning, not a verdictReasoning tokens streamed via include_thinking; 64k budget on evidencemd-deepCase review, appeals, utilization review, audit trails
Diagnostic and treatment reasoningRanked differential with the discriminating finding, next diagnostic step and supporting guidelineAdmission workups, second opinion, telehealth
Handling of long, messy patient contextContext engineering inside the API across histories, labs, imaging reports and medication listsPre-visit briefs, patient summaries, agent pipelines
US payer and coverage reasoningInterQual, MCG, plan policy bulletins, NCDs and LCDs, two-midnight rule, Inpatient-Only listPrior authorization, appeals, utilization review, medical necessity
Clinical and patient documentationNotes, discharge summaries, handoffs, letters and plain-language patient materials with CDI supportAmbient scribing, discharge workflows, revenue cycle
Structured output an EHR can renderresponse_format json_object returning typed answer and sources fieldsEHR-embedded decision support, dashboards, queues
Specialty and language coverageSpecialty parameter across medical specialties and 30 response languagesSpecialty copilots, multilingual patient populations
A regulated deployment pathHIPAA compliant, zero retention, no training on your data, BAA executed at onboardingHealth system and payer sales cycles
Predictable unit economicsFlat per-request pricing with retrieval and citations included; failed calls refundedPricing your own product and forecasting a monthly bill
A migration that does not stall a roadmapOpenAI-compatible endpoint, SSE streaming, published OpenAPI specificationTeams already shipping on OpenAI, Claude, Gemini or Grok

Swipe the table horizontally to see more →

Is the API safe for HIPAA-regulated clinical workflows?

Compliance is where healthcare AI projects most often stall, so it is worth stating the posture precisely rather than in marketing language. A Business Associate Agreement is permission to handle protected health information — it is not, on its own, a promise to delete it. Ask every vendor about retention and training separately.

Zero retention on request and response content

Prompts and completions are not retained once the call completes. Usage metadata — which key called, the endpoint, status, latency and credits used — is kept for billing and support and contains no PHI. Design for this: EvidenceMD cannot reproduce last week's question or answer, so keep any clinical audit trail on your side.

No training, fine-tuning or evaluation on your data

Your API prompts and outputs are never used to improve an EvidenceMD model. No-training and zero retention are separate commitments and worth asking any vendor about individually; EvidenceMD makes both.

HIPAA compliant with a BAA at onboarding

A Business Associate Agreement is executed as part of onboarding for eligible plans, before any patient data flows through the API. Your finished product carries its own compliance obligations as the application clinicians and patients actually use.

Encrypted in transit and at rest

TLS 1.2 or higher in transit. AES-256-GCM plus Azure transparent data encryption at rest for datastores holding customer and clinical data.

Hosted on Microsoft Azure, East US 2

Application data is stored in East US 2 (Virginia, United States). SOC 2 Type II is in progress — EvidenceMD does not claim a completed report, and the current timeline is available on request.

Per-key access control and attribution

API keys are uniquely attributed, so usage, rate limits and revocation are scoped per key rather than per account — which is what lets you separate a staging environment, a design partner, and production traffic.

During development and evaluation, use synthetic or de-identified patient data so engineers can iterate freely before any protected information enters the workflow. Full detail, including the gated policy pack and the SOC 2 Type II timeline, is in the EvidenceMD trust centre and the enterprise API terms.

What does it cost, and who is it right for?

Billing is per request rather than per token, with evidence retrieval and citations included. That matters more in clinical work than elsewhere: answer length varies enormously, and reasoning models that bill thinking as output tokens only reveal the cost after the fact.

evidencemd-fast
4 credits · $0.20

High-volume triage, patient-facing answers and quick lookups where latency is the constraint. Cited answers, no thinking mode.

evidencemd-pro
4 credits · $0.20

The default for differentials, treatment planning and documentation. Comprehensive citations with reasoning tokens available.

evidencemd-deep
5 credits · $0.25

64k reasoning-token budget for complex multi-comorbidity cases, utilization review and appeal drafting.

A founding team gets 10 free credits at signup with no credit card, and paid top-ups begin at $10 for 200 credits — so a credible clinical prototype costs roughly what a couple of software seats would, well before you commit engineering quarters to a medical evidence pipeline. Requests that fail without producing an answer are refunded automatically to your balance, so you are billed for answers rather than attempts.

For a larger organisation, the same endpoint supports a programme of related features under one vendor relationship. An innovation group can pilot a documentation assistant, extend into patient education, and add a utilization-review layer without re-running vendor selection each time — because the clinical model, the compliance posture, and the billing model do not change between those features. Full plan detail is on the pricing page, and the per-request comparison against Claude Opus 5 and GPT-5.6 Sol is worked through in why EvidenceMD API.

Build responsibly

A healthcare AI API augments a qualified clinician's judgment; it does not replace it. Keep a human in the loop for anything that affects patient care, surface the citations and reasoning so users can verify rather than trust, and let the care organisation own its escalation protocols and who reviews what. EvidenceMD processes the clinical context your product sends — it does not independently retrieve charts, place orders, or take clinical actions, which keeps control of data and workflow inside your application and under your policies.

Frequently asked questions about choosing EvidenceMD

Why build a healthcare product on EvidenceMD instead of a general-purpose model?

Because with a general model you become the medical layer. Shipping a credible clinical feature on OpenAI, Claude, Gemini, or Grok means sourcing medical evidence, keeping it current, teaching the model to cite it, engineering the context window, building clinical evaluation, and recruiting clinicians to review outputs before launch. Each of those is a project, and none of them is the product your users are waiting for. EvidenceMD puts that layer inside the API: evidence is retrieved per request, citations come back inline, the reasoning is exposed, and the model is post-trained on clinical conversation across medical specialties. Choose EvidenceMD when your product's value depends on clinical reasoning being correct, sourced, and reviewable. Choose a general model when the workload is administrative and never touches clinical judgment.

What does it mean that EvidenceMD returns reasoning tokens?

It means the clinical thinking is a first-class part of the response rather than something inferred from the answer. EvidenceMD is the first medical API to return reasoning tokens: set include_thinking and the API streams the step-by-step clinical reasoning alongside the answer, so your product can show a reviewer how a conclusion was reached, log it for audit, or gate an action on a specific step. evidencemd-deep carries a 64,000-token reasoning budget for complex multi-comorbidity cases, utilization review, and appeal drafting where the reasoning has to withstand scrutiny. General reasoning models either hide their reasoning traces or summarize them, and no general model grounds those traces in retrieved clinical evidence.

What does EvidenceMD being post-trained on clinical conversation change in practice?

It changes how much prompt engineering you write and how the model behaves at the edges. Because clinical dialogue, specialty terminology, hedging, and follow-up behaviour are trained in rather than prompted, a bare clinical question returns a usable clinical answer — no mega-prompt, few-shot exemplars, refusal policy, or length policy to maintain. It also matters for accuracy: a 2026 Nature Communications study found supervised fine-tuning outperformed prompt engineering for diagnostic accuracy, and that general models fell short in dynamic diagnostic workflows and frequently committed clinical errors. EvidenceMD is post-trained across medical specialties and accepts a specialty parameter, so one integration can serve a cardiology copilot and an oncology copilot without maintaining two prompt stacks.

Does the EvidenceMD API retain the prompts and responses I send?

No. The API operates zero retention on request and response content: it is not kept once the call completes. What is retained is usage metadata — which key called, the endpoint, status, latency, and credits used — which is what billing and support require and contains no PHI. EvidenceMD also does not train, fine-tune, or evaluate its models on your API prompts or outputs. These are two separate commitments worth asking any vendor about individually: no-training means your content never improves a model, zero retention means your content is not kept at all. One practical consequence to design around: EvidenceMD cannot reproduce last week's question or answer for you, so if you need an audit trail of clinical content, store it on your side.

Can I use the EvidenceMD API in HIPAA-regulated workflows?

Yes. EvidenceMD is HIPAA compliant, with zero retention of clinical content, encryption in transit over TLS 1.2 or higher, encryption at rest with AES-256-GCM and Azure transparent data encryption, per-key access control, and usage records that contain no PHI. Application data is hosted on Microsoft Azure in East US 2. A Business Associate Agreement is executed as part of onboarding for eligible plans, before patient data flows through the API, and SOC 2 Type II is in progress rather than complete — EvidenceMD does not claim a finished report. Your finished product carries its own compliance obligations as the application clinicians and patients actually use, and synthetic or de-identified data is the right choice while you evaluate outputs.

Which languages does the EvidenceMD API support for patient-facing features?

Thirty. Pass a language parameter and the same endpoint returns the clinical answer, the patient-facing explanation, or the discharge instruction in any of 30 supported languages, case-insensitive, defaulting to English. The clinical reasoning happens once and the rendering changes, so the patient-facing text stays consistent with what the care team sees rather than being a separate translation pass that can drift. That makes one integration enough to serve a multilingual patient population and international clinician users, which is usually where teams building on a general model end up bolting on a translation vendor.

How does EvidenceMD support prior authorization and utilization review products?

It reasons over the documents those workflows actually turn on. EvidenceMD engages payer criteria by name — InterQual, MCG, Aetna Clinical Policy Bulletins, Cigna coverage policies — and CMS National and Local Coverage Determinations, so a drafted prior authorization request or appeal addresses the specific criterion a reviewer applies instead of generic medical-necessity language. For utilization review it assesses documentation against the two-midnight rule and the Medicare Inpatient-Only list and produces reviewer-ready justification for observation versus inpatient status. Under CMS-0057-F, effective January 1, 2026, affected plans must state the specific reason for a denial, which makes point-by-point rebuttal drafting a buildable feature rather than a letter template.

How much engineering work is it to migrate from OpenAI or Claude to EvidenceMD?

For most teams it is a base URL, a key, and a model name. The endpoint is OpenAI-compatible at https://evidencemd.ai/api/v1/chat/completions, authentication travels in an Authorization Bearer or x-api-key header, streaming uses standard server-sent events terminated with [DONE], and responses carry the usual choices, message, and finish_reason fields — so existing client code, retry logic, and observability keep working. Clinical parameters (specialty, language, include_thinking) pass through extra_body in the OpenAI SDK, and response_format is the native OpenAI parameter. Teams typically keep a general model for administrative text and route clinical calls to EvidenceMD rather than replacing everything at once.

Is the cost of a clinical API predictable enough to price my own product on?

With EvidenceMD, yes, because billing is per request rather than per token: a flat 4 credits ($0.20) for evidencemd-fast and evidencemd-pro, and 5 credits ($0.25) for evidencemd-deep, with evidence retrieval and citations included. That matters more in clinical work than elsewhere, because answer length varies enormously — a multi-comorbidity question can generate several times the reasoning of a simple one, and reasoning models that bill thinking as output tokens only reveal the cost after the fact. Failed requests that produce no answer are refunded automatically to your balance, so you are billed for answers rather than attempts, and you can forecast a monthly bill from request volume alone.

How quickly can a team ship a first clinical feature on the API?

Same day. Create a developer account, take the 10 free signup credits with no credit card, and make a first request from the dashboard playground or a cURL call. Build against synthetic or de-identified data while you evaluate output quality for your use case, then execute the BAA before any patient data flows. Paid top-ups begin at $10 for 200 credits, so the evaluation phase costs roughly what a couple of software seats would — which is usually the deciding factor for a founding team that wants a credible clinical prototype in front of design partners before committing engineering quarters to a medical evidence pipeline.

Documentation and sources

Primary sources for the API capabilities, compliance posture, and research claims on this page.

EvidenceMD API documentationEndpoints, models, parameters (specialty, language, include_thinking, response_format), authentication, streaming and code samples.EvidenceMD medical AI API overviewThe OpenAI-compatible medical AI API: clinical reasoning with peer-reviewed citations, JSON mode and 30-language support.EvidenceMD enterprise API and data handlingZero retention, ownership of inputs and outputs, BAA execution, and what usage metadata is kept.EvidenceMD trust centreHIPAA posture, encryption, hosting region, SOC 2 Type II status and the gated policy pack.EvidenceMD OpenAPI specificationMachine-readable schema for SDK generation, agent tool registration and developer tooling.EvidenceMD benchmark resultsPerformance on HealthBench Hard and evidence-based clinical reasoning benchmarks, with the evaluation conditions stated.Grounding LLMs in clinical diagnostics (Nature Communications, 2026) (opens in a new tab)Peer-reviewed study finding supervised fine-tuning outperforms prompt engineering for diagnostic accuracy, and that general models fall short in dynamic diagnostic workflows.LLM performance on clinical reasoning tasks (JAMA Network Open, 2025) (opens in a new tab)Cross-sectional study of 21 large language models finding off-the-shelf models perform poorly at generating differential diagnoses and navigating clinical uncertainty.CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) (opens in a new tab)The rule requiring affected plans to give a specific reason for a prior authorization denial, with compliance dates beginning January 1, 2026.HHS guidance on business associates (HIPAA) (opens in a new tab)The official definition of a business associate and what a Business Associate Agreement must cover — the baseline for evaluating any healthcare AI API.OpenAI chat completions API reference (opens in a new tab)The request and response shape EvidenceMD is compatible with, which is why an existing OpenAI integration migrates with a base URL and key change.

Related reading

Start building your clinical product on EvidenceMD

Clinical reasoning post-trained on medical specialties, evidence retrieved per request with peer-reviewed citations, reasoning tokens you can show, 30 languages, HIPAA compliant with zero retention — in an OpenAI-compatible API. Free to start, no credit card.

Best Healthcare AI API: Why Build with EvidenceMD (2026)