Blog · Technology
Medical record retrieval partners for healthcare AI companies
Which medical record retrieval partners do healthcare AI companies use? The usual mix: a network connector, a patient-access app and a service that requests records from each provider.
By Tavrn Team · · 4 min read
Summarise with ChatGPT, Claude or Perplexity

Which medical record retrieval partners do healthcare AI companies use? The answer usually involves three kinds: a network connector for structured data, a patient-access app the patient controls, and a retrieval service that requests the full chart from each provider on the patient's authorization [1][5]. Each one returns a different part of the record.
Why one partner is rarely enough
No single source holds a patient's whole record. A 2018 study of 183,739 older patients found that a single EHR system captured, on average, only 16% to 27% of their encounters [4]. The rest happened somewhere else.
Exchange between hospitals is also uneven. In 2023, 70% of non-federal acute care hospitals in the US took part in all four areas of exchange (send, find, receive and integrate) at least sometimes [3]. Only 43% did so routinely [3]. A model that reads one system's data reads a partial chart.
That is why teams mix partners. Each one fills a gap the others leave.
The three kinds of partner
Partner type | How it gets records | What usually comes back | What it depends on |
|---|---|---|---|
Network connector | Queries national exchange networks for a stated purpose | Structured data built on the USCDI classes the site keeps [1] | An allowed exchange purpose, often treatment [1] |
Patient-access app | The patient connects their own portals and accounts | What each portal's standardized API exposes [2] | The patient signing in to every provider |
Retrieval service | Requests records from each provider on a signed authorization | The provider's own chart, including scanned and faxed pages | A valid authorization that names you [5] |
Network connectors
A network connector sends queries over national exchange frameworks. Under TEFCA, each query must carry an exchange purpose code [1]. The purpose decides whether a site has to answer. For treatment queries, nodes run by a health care provider or its delegate must respond [1]. For payment queries, responders may answer or not [1].
The data that comes back is at least the USCDI v3.1 data classes the responder keeps [1]. That works well for problems, medications and labs. It is a weaker fit when your model needs the full note, the scanned pages or an imaging study.
Patient-access apps
Certified EHRs must offer a standardized API that answers requests for one patient's data [2]. Patient-access apps use those APIs, or TEFCA's Individual Access Services, to pull records the patient asks for [1][2]. Under TEFCA, responders must answer Individual Access Services queries [1].
The limit is effort. The patient has to find and connect each provider, and the data is what each API exposes.
Retrieval services
A retrieval service asks each provider for the record directly. It works from a HIPAA authorization the patient signs. That document must describe the information, name who may disclose it, name the recipient and state each purpose [5]. For research, the expiration can be "end of the research study" [5].
This path reaches providers that are not on any network. It returns the chart as the provider keeps it. For substance-use treatment records, the consent must also meet 42 CFR Part 2, which lists its own required elements [6].
What to ask before you choose
Use the same questions for every partner, including your own team if you plan to build.
- Purpose. What legal basis does each request run on? A treatment query, a patient's own access request and a signed authorization each carry different rules [1][5].
- Coverage. Which providers can it reach, and what happens with the ones it cannot?
- Record types. Does it return notes, scanned pages, bills and imaging, or only structured data?
- Status. Can your product see each provider's status, by webhook or by polling?
- Security. Will the partner sign a BAA, and can you review its audit reports?
- Data use. Will the partner use your patients' records to train its own models?
Build or buy
Building retrieval in-house means staffing outreach to every provider. Someone has to send requests, follow up, log each attempt and handle each provider's rules. Ask whether that work is where your team should spend its time, or whether it belongs with the model and the product.
A partner makes sense when it covers the providers your users actually see. It also needs to deliver into your product without manual steps.
Where Tavrn fits
Tavrn is a retrieval service. Tavrn retrieves medical records from any US provider: one authorization in, complete record out, via platform, integration or API. One authorization covers every US provider the patient has seen.
Networks, records vendors and portals return about 63% of a patient's visits. Tavrn requests the rest from each provider by fax, mail, email and phone. Every open provider is contacted every 48 hours until it answers.
A webhook fires on every status change, or poll the request. Records arrive as each provider responds. Tavrn handles protected health information under HIPAA; a BAA is available on request. Tavrn doesn't use the records it retrieves or your organization's data to train AI models.
What to do next
See how the request lifecycle works for product teams on Tavrn for health tech. API keys are issued in the Tavrn dashboard after a 30-minute call.
Sources
- Standard Operating Procedure (SOP): Exchange Purposes (XPs), v5.1 — The Sequoia Project, TEFCA Recognized Coordinating Entity, 2026-07-01
- 45 CFR 170.315(g)(10) Standardized API for patient and population services — Electronic Code of Federal Regulations, 2026-10-01
- Interoperable Exchange of Patient Health Information Among U.S. Hospitals: 2023 (Data Brief 71) — Assistant Secretary for Technology Policy (ASTP/ONC), 2024-05-01
- Out-of-system Care and Recording of Patient Characteristics Critical for Comparative Effectiveness Research — Epidemiology (Lin KJ et al.), 2018-05-01
- 45 CFR 164.508 Uses and disclosures for which an authorization is required — Electronic Code of Federal Regulations, 2026-10-01
- 42 CFR 2.31 Consent requirements — Electronic Code of Federal Regulations, 2026-10-01


