Built for technology partners
A medical records API for platforms whose customers need the outside record.
Your customers ask you for the outside record and you have nowhere to get it. Building it means network participation, provider directories, patient matching, document parsing and the legal apparatus around all of it, and none of that is the product you set out to build. The incumbent electronic medical record systems do not sell you the answer either.
The decision
A platform needs the outside record as data.
Product, engineering and partnership leads at health technology companies whose customers are treating providers: intake and care-coordination platforms, EHR-adjacent tools, risk and quality products, and anyone whose roadmap contains "get the outside records".
Every platform serving care operations eventually arrives at the same wall. Your customers ask for the outside record, and getting it means joining networks, resolving provider identities, matching patients, parsing documents nobody formatted for machines, and carrying the legal apparatus that makes any of it lawful. None of that differentiates your product, and the large electronic medical record vendors are not going to sell you the answer.
Vivlio already does that work for provider organizations. The public API is the same capability, addressable: you provision your customers as clients, push their patients and appointments in, and read back the record as structured data under each customer’s own authority.
The full reference is yours for the asking - request it below. It covers authentication, the scope model, every endpoint, the field reference for all fourteen record domains, and the changelog. A platform team should be able to decide whether an integration is worth a meeting before it takes one, so the request does not commit you to a call.
The list below is what a platform needs before it can build on someone else’s retrieval, and what Vivlio does to the record beyond fetching it.
Before the decision
What the technology partner record has to contain.
Not a generic records list. What has to be on the table before this decision can be made well.
One integration, not a network project
Network participation, provider directories, patient matching and document parsing are the cost of the outside record. They are also not your product. This is one REST API over the top of all of it.
Patient identity that survives your roster
Batch upsert matches on the external identifier you already use, then on demographics, before creating anything. Sending the same patient again updates them rather than doubling them.
Record data, not a pile of PDFs
Fourteen domains - medications, allergies, problem list, encounters, notes, vitals, labs, procedures, immunizations, care team, plan of care and the histories - arrive as parsed data your product can render, diff or act on. The underlying files stay available through their own endpoints when the document itself is what matters.
Authority, declared per customer
Each of your customers authenticates with its own NPI and purpose of use. The authorization travels with the token, so your platform never becomes the thing asserting a legal basis it does not have.
An event, not a poll
Signed webhooks tell your product when a patient's record has changed. Signature validation is documented, with the digest over the raw body.
What arrives
Organized for this decision, not just retrieved.
Retrieval is the commodity. What arrives has already been sorted for the decision above, and each line says where it came from.
- One record per event, whichever source sent it
- The same discharge summary released by a hospital and again by its health system arrives once, with both sources named, so your product is not left de-duplicating someone else's records.
- A source and a date on every line
- Every record carries the organization that released it and when it arrived. Anything you build on top can show its provenance, because the provenance came with the data.
- Structure you do not have to invent
- Domains are separate endpoints with stable shapes rather than one blob to be mined. What your product needs is addressable without a parsing layer of your own.
- Errors you can act on
- Failures return a structured error with a code, a message, the offending field and a request identifier, so a support conversation starts with the request rather than a screenshot.
The record
This is what arrives.
The portal itself, rendered from the product's own source over a synthetic patient. Every line carries the organization that released it and the date it arrived.
Vivlio portal, release 5.30.0, rendered from source · Synthetic patient, no PHI
Rivera, Elena
Showing 1–10 of 27 records
| Date of Service | Record Title | Facility | Department/Location | Provider | Transaction Date | |
|---|---|---|---|---|---|---|
| 08/27/2026 | Progress Note | Northside Regional Medical Center | Internal Medicine | Priya Natarajan, MD | 09/02/2026 | |
| 08/14/2026 | Consult Note | Atlanta Cardiology Associates | Cardiology | Marcus Bell, MD | 09/02/2026 | |
| 07/30/2026 | Admission Discharge | Northside Regional Medical Center | Inpatient | Hannah Okafor, DO | 09/02/2026 | |
| 07/22/2026 | Clinical Document | Peachtree Family Medicine | Primary Care | Daniel Reyes, MD | 09/02/2026 | |
| 06/09/2026 | Image Document | Lakeview Imaging Partners | Radiology | Sunil Mehta, MD | 09/02/2026 | |
| 05/12/2026 | Operative Note | Northside Regional Medical Center | Surgery | Grace Lindqvist, MD | 09/02/2026 | |
| 03/03/2026 | Patient History | Peachtree Family Medicine | Primary Care | Daniel Reyes, MD | 09/02/2026 | |
| 01/15/2026 | Progress Note | Atlanta Cardiology Associates | Cardiology | Marcus Bell, MD | 09/02/2026 | |
| 12/02/2025 | Clinical Document | Lakeview Imaging Partners | Radiology | Sunil Mehta, MD | 09/02/2026 | |
| 10/21/2025 | Consult Note | Northside Regional Medical Center | Endocrinology | Rina Adeyemi, MD | 09/02/2026 |
Demographics
Decatur, GA 30030
Data Summary
Encounters
Vitals
Allergies
Immunizations
Problem List
Care Team
Questions
Questions technology partner teams ask first.
Answered here in the same words as the structured data behind the page, so what a search engine shows is what a reader gets.
- What does the API return?
- Parsed record data by domain, read-only, across fourteen domains: medications, allergies, problem list, encounters, notes, vitals, labs and diagnostics, procedures and surgeries, immunizations, care team, plan of care, social history, family history and general history. Every record names the source document it was parsed from, and on request carries that document's file name, the facility that submitted it and the date it arrived. The patient's files are available through their own endpoints when the document itself is what matters. List responses are paginated with limit and offset, report whether more remain, and can be filtered by date and, on several domains, by type. The full field reference for every domain is in the API reference, which you can request from this page.
- How does authentication work for a platform with many customers?
- Two token types. A Partner token, obtained through an OAuth 2.0 client-credentials exchange, manages your own clients and their API keys: create a client when you onboard a customer, issue keys at partner or client level, update or soft-delete as your own accounts change. A Client token, carrying that customer's NPI and declared purpose of use, is what actually reads patients and records. Tokens are signed JWTs with a sixty-minute life, and every call is HTTPS.
- Whose authority do the records move under?
- Your customer's, not yours and not ours. A client token carries an NPI and a declared purpose of use, and the records move for treatment under that provider's authority with a signed BAA behind it. That makes the fit test simple: if your customers are treating providers, this works the way it is built. If the use is case management eligibility, payer or utilization review, or disability and legal, that is a different legal basis and a conversation to have before anything is built.
- Can we load patients at volume?
- Yes. Patients can be created one at a time or upserted in batches of up to a hundred per call, matched first on the external identifier you already use and then on demographics before a new record is created, so re-sending your roster does not duplicate it. Providers and appointments have the same shape of endpoint, so a platform can mirror its own scheduling into Vivlio and let retrieval follow the calendar.
- How do we know when something arrives?
- Webhooks, signed, configured per client. Each request carries an X-Webhook-Signature header holding an HMAC-SHA256 digest of the raw body, computed with your client secret. Validate before you parse: an unvalidated webhook endpoint is an open door. The validation code is in the API reference, which you can request from this page.
- Can we read the API reference before we talk to you?
- Yes. Request it with the form on this page and it comes by email; you do not have to book a call to get it. It covers authentication, the scope model, every endpoint, the field reference for all fourteen record domains, pagination, rate limits and the error codes, plus the changelog. Two things are not in it: what a partner pays, and how a sandbox tenant gets provisioned. Both are quick answers on the call.
Also built for
The same job, a different decision.
Every branch does the same work on the outside record. What changes is who is deciding, and what.
Home health
The face-to-face note, orders, discharge summary and medications, assembled before the first visit.
PACE
The intake checklist, from twelve months of progress notes to the medication list, assembled before the team meets.
Structured family caregiving
Diagnosis documentation, the H&P, medications and the functional evidence, assembled before the nurse's first home visit.
Chart prep
What happened to tomorrow's patients since their last visit, retrieved and organized the night before.
Talk to us
Request the API reference
Tell us who you are and what your platform needs the outside record for, and the reference comes by email. The calendar opens here too, for the things it does not answer: the sandbox, the scopes your integration needs, what your customers would have to sign, and what it costs.
- Request the referenceTwo minutes. Name, work email, phone and company, and what your platform needs the outside record for if you can say.
- Pick a timeThirty minutes on the integration itself: the sandbox, the scopes, what your customers sign and what it costs. Optional; the request is already with us.
Who this is for, and who it is not
- Coverage comes firstVivlio retrieves from providers, hospitals and health systems it can reach through national exchange networks and direct connections. Name the facilities your patients come from on the form and we check coverage before anyone spends thirty minutes on a demo.
- You can say what the chasing costsThe form asks how many hours a week your team loses to chasing records. If nobody can put a number near it, the case for Vivlio is not there yet, and we would rather say so than sell you a demo.
- Patients and files at volumeThis is built for intake that runs every day. For one record, once, your patient can request it from the provider directly, and that will be faster than going through us.
- Treatment, with the paperwork doneProduction access needs an NPI, a declared purpose of use and a signed BAA. Nobody swipes a card onto live PHI.
If none of those describe you, say so in the last field and we will come back in writing instead of booking a call.
Or call sales directly at 404-777-5772
Step 1 of 2
Request the API reference
Step 2 of 2
Book a 1:1 call
Thanks. Your request for the API reference is with us and the reply comes by email. If you would rather walk the integration live, pick a time below.
Step 2 of 2
We will come back in writing
Thanks - that is a useful answer. Before either of us spends thirty minutes, we will come back by email with the two or three questions that size what record chasing is actually costing your team, and what we can reach for the facilities you named. If the numbers are there, we will send a time then.
If you would rather just talk, the sales line below reaches the same people.