Skip to content

For health tech

Medical record retrieval API for health-tech and AI companies

Tavrn is medical record retrieval as an API for digital-health products, clinical AI and research platforms: the patient signs one HIPAA authorization, your product opens a retrieval request per provider, and Tavrn requests each one through the networks, records vendors and portals, then by fax, mail, email and phone for the providers outside them. A webhook fires on every status change and the documents are downloaded with the same key. Start on synthetic data with a self-serve sandbox key.

Get a sandbox keyHealth-tech overview

What health-tech teams build on it

Care navigation and second opinion

The full outside record behind a member’s case, from every provider they name, before the navigator or reviewing specialist starts.

Clinical AI and chart review

Complete source documents for models that summarise, abstract or audit a chart, including the scanned notes, faxed records and imaging reports that never reach a network.

Virtual specialty care

Prior imaging, pathology and labs for a patient seen remotely, requested on the authorization they sign at intake and delivered as each provider responds.

Trial matching and recruitment

Records under a research authorization, which can run to the end of the study (45 CFR 164.508), retrieved from each outside provider for screening and enrolment.

Records-heavy workflows at scale

Requests created by API or spreadsheet bulk order, each with its own status and contact log, so volume does not turn into an inbox.

By request, not by network query

The record a network does not hold

Networks, records vendors and portals return about 63% of a patient’s visits in Tavrn’s own requests. Tavrn requests the other 37% from each provider directly, on the same authorization, and returns the document the provider released.

One authorization, every provider
The patient signs once. That authorization names your organization and the purpose of use and covers every US provider the patient has seen; research and navigation requests do not depend on a treatment relationship.
Networks first, then the rest
Each provider is requested the way it actually responds: network, release-of-information vendor, portal, fax, mail, email or phone. Every open provider is contacted every 48 hours until it answers.
Documents as released
Records come back as the provider released them, searchable (OCR), with a cover page: notes, scanned charts, imaging reports with DICOM, pathology, labs and bills, rather than a normalised summary.
Provider fees at cost
Any provider fee is passed through at cost under the approval threshold you set; a request that needs approval pauses as action_required until you answer.

Integration path

Sandbox key to production in four steps

The sandbox serves the production contract on synthetic data. Only the base URL and the key change when you go live.

  1. 01

    Get a sandbox key

    Sign up at sandbox.tavrn.ai with a work email and export the tavrn_sk_test_ key. Every request sends it as Authorization: Bearer.

  2. 02

    Create the case and upload the authorization

    POST /v2/cases for the patient, then sign-upload to attach the signed authorization PDF. Your own identifiers travel on external_id and metadata and come back on every webhook.

  3. 03

    Open a retrieval request per provider

    POST a retrieval request with the facility and the record types you need. Send an Idempotency-Key so a retry never opens a second retrieval.

  4. 04

    Receive webhooks, download documents

    Register an endpoint with POST /v2/webhooks; verify the signature and download each file from its URL when documents_available arrives, or poll the request and the 30-day event log.

Data model

Six objects

A case holds a patient; a retrieval request is one provider under that case; documents hang off the request. Facilities and requestors are the supporting directories, and events are the audit trail.

ObjectWhat it isFields your product cares about
CaseThe patient and the matter the requests belong toid, external_id, client name and date of birth, metadata (JSON, echoed on webhooks), platform_url
Retrieval requestOne provider, one set of record types, its own lifecycleid, status (received, processing, action_required, completed, cancelled), stage, requested_records[].type, costs, action_required_reason, completion_detail
DocumentA file retrieved for a requestid, file name and type, record type, a download URL valid for an hour, issued with the same key
FacilityA provider organization in Tavrn’s directory of about 425,000Searchable by name, alias, phone, fax, address or NPI; or passed inline by name and location
RequestorThe profile requests go out underOrganization name, the authorization and invoice approval settings that apply to its requests
Event and webhookWhat changed, and where Tavrn delivers itEvent id, type, created_at and data; 30-day event log; signed deliveries with a 90-day delivery log

Record types

Requested by type, per provider

Each retrieval request names the record types it needs. The reference enumerates them; the common ones are below, with custom descriptions for anything else.

  • Medical records, including ER and mental-health records
  • Abstracted medical records
  • Radiology reports and the imaging itself (DICOM)
  • Billing records: physician, institutional, ER, radiology, anesthesiology, ambulance
  • Pathology reports, slides and blocks
  • Pharmacy and infusion records
  • Custom medical, billing or imaging requests

Sandbox

Build before you buy

The sandbox is a separate deployment of the Enterprise API v2 with synthetic facilities and patients. No call, no contract, no production data.

Self-serve key
A work email and a bot check; free-mail and disposable addresses are rejected. The key page shows usage, rotates or revokes the key and can extend the sandbox once by 14 days.
Scenarios you control
A header or a notes token chooses the lifecycle: complete by default, no records, payment needed and others. An advance endpoint moves a request forward instead of waiting.
Same contract as production
Same endpoints, stages, error envelope and webhook signatures. Limits of 25 retrieval requests, 3 webhook endpoints and 20 uploads keep it a test bed.
Production access
An organization admin creates the tavrn_sk_live_ key in the Tavrn platform after onboarding. Book a demo to set up your organization.

Coverage

Any US provider, from one authorization

100,000+

provider requests processed through Tavrn

500+

organizations, from solo practices to national organizations

425,000

provider organizations in the directory, all 50 states and DC

Security

Controls for sensitive medical records

Protected health information, handled under HIPAA and audited for SOC 2.

Security details

FAQ

Retrieval as an API, answered

Is Tavrn an API or a retrieval service?
Both, and that is the point. The API is the contract your product integrates: cases, retrieval requests, documents and webhooks. Behind it, Tavrn’s retrieval operation requests each provider through the networks, records vendors and portals, then by fax, mail, email and phone, follows up every 48 hours and checks every delivery against the request. Your product sees one status per provider and the documents when they arrive.
Do we need a treatment relationship or an NPI?
No. Records are released to you under the patient’s signed HIPAA authorization (45 CFR 164.508), which names your organization and the purpose of use. Research and navigation requests do not depend on a treatment relationship, which is what the national networks require for a treatment-purpose query.
How does this compare with Particle Health, Health Gorilla or Metriport?
Network APIs query the national health-data networks for a patient and return what participating organizations share, usually as FHIR or C-CDA. Tavrn requests the record from each provider the patient named, on the patient’s authorization, including the providers outside every network, and returns the documents as released. Many teams use both: a network query first, a Tavrn request for the rest. The API page has the side-by-side.
What format do the records come in?
As the provider released them: PDFs and scans made searchable (OCR) with a cover page, organised by provider and date of service; DICOM for imaging; pathology slides and blocks shipped physically when requested. Each document has its own record type and a download URL issued with the same API key. Tavrn returns the source document rather than a normalised FHIR bundle, so nothing the provider sent is dropped.
How do we know where each request is?
Every retrieval request carries a public status (received, processing, action_required, completed, cancelled) and a finer stage, and every contact with the provider is logged with date, channel and outcome. A webhook fires on every status change, when the team needs an answer, and when documents are available; GET /v2/events keeps 30 days of events and the request list accepts public_updated_since for reconciliation.
How are provider fees handled?
Provider invoices are passed through at exact cost. You set an approval threshold per requestor; a request whose invoice is under it proceeds, and one over it pauses as action_required with the amount until you answer by API or on the platform.
How is patient data handled?
Tavrn handles protected health information under HIPAA and a BAA is available on request. Records are encrypted at rest and in transit, API keys are scoped per resource and can be rotated at any time, and Tavrn does not use the records it retrieves or your organization’s data to train AI models. SOC 2 Type 1 and Type 2 reports, the HIPAA attestation and security policies are on the trust center.

Start building

First request on synthetic data today

Get a sandbox key with a work email, or book a demo to set up production access for your organization.

Get a sandbox keyAPI details
Book a demo