1hPatient Vault
Sign inGet Started

Patient Vault

Three verbs. The whole record.

STORE

Create and list patient demographic records, with endpoints for addresses, contacts, aliases, external identifiers, and deceased status.

View the endpoints →

ATTACH

Upload and list file attachments linked to a patient record, including consent forms and lab results.

View the endpoints →

FIND

Find patients by demographic criteria using exact or fuzzy matching.

View the endpoints →
Get Started

Register for Patient Vault, get the reference app, and fork it on GitHub.

80M

Americans served by apps on Patient Vault

SOC 2 Type II · HIPAA

BAA executed at production activation

30s

to your first authenticated call

Who This Is For

Built for healthcare developers, before and after their first line of code.

You're a developer or a small team building a healthcare app. The patient record is the part you shouldn't be building from scratch — whether you're about to write your first line of code or you're already in market and ready to consolidate the plumbing you wrote in a hurry. That work is done. Start with Patient Vault and spend your engineering time on the product your users actually came for.

YOU ARE

A developer building a healthcare app. Hackathon team, founder, or an existing company adding healthcare.

YOU AREN'T YET

Live in market with thousands of patients, integrated with payers, or in procurement cycles.

YOU WILL BE

In production in days, on the substrate dozens of apps already trust.

What It Replaces

Six months of infrastructure work.

Build it yourself, and you'll spend six months modeling demographics, chasing clinical history across providers, integrating labs, capturing consent, and standing up an audit trail your compliance reviewer can defend.

Patient Vault is the alternative: the patient record, already built, available as one API resource. You write the code that makes your product different — not the code every healthcare app has to write.

Skip the months of BAA negotiation. Patient Vault's BAA is one standard document, public at /baa, executed by clickwrap when you activate production. Sandbox access is instant and requires no BAA. Your legal team can review it on their schedule — the terms don't change.

What Patient Vault Holds

Everything your healthcare app needs to store.

Patient demographics. Addresses and contacts. Documents — PDFs, intake forms, scans. Observations — vitals, labs, anything structured. Attachments — wearable data, audio, arbitrary JSON your app needs to persist. Every read and write logged. Names change — aliases are first-class: legal, former, and chosen names all live on the record. Optional demographics — gender identity, pronouns, race, ethnicity, preferred language — align with USCDI.

What's In It

Three verbs. One mental model.

Every endpoint and every shape fits into one of three verbs. Learn the three and you've learned the API.

Store

Create and update patient records: demographics, identity, the canonical patient. PATCH what changes.

Attach

Add anything to a patient: addresses, contacts, documents, observations, wearable data, arbitrary attachments. Any file type, 50MB, virus-scanned.

Find

Locate patients in your vault. One endpoint, one boolean: exact true for a definitive lookup, false for probabilistic matching. Every result returns a confidence score.

Reading is just GET — the full record, paginated, or a metadata-only manifest of everything attached. Every read and write lands in an audit trail your compliance reviewer can defend.

Your First Hour

From zero to a working healthcare app.

STEP 1 · MINUTE 0–5 — STORE

Create your first patient.

POST /patient with demographics. Returns a server-assigned patientId.

curl -X POST https://api.1health.io/v2/patient \
  -H "Authorization: Bearer $KEY" \
  -d '{"firstName":"Maria","lastName":"Santos","dob":"1988-04-12","sex_at_birth":"female"}'

STEP 2 · MINUTE 5–20 — ATTACH

Attach data to the patient.

Attach an address, document, observation, or anything else your app needs to persist. Same pattern for every attachment type.

curl -X POST https://api.1health.io/v2/patient/{id}/address \
  -H "Authorization: Bearer $KEY" \
  -d '{"line1":"742 Evergreen Terrace","city":"Chicago","state":"IL","postalCode":"60614"}'

STEP 3 · MINUTE 20–40 — FIND

Find the patient.

Look up patients by identifier or demographics. One endpoint, one boolean — exact=true for a definitive lookup, exact=false for probabilistic matching. Every result carries a confidence score.

curl "https://api.1health.io/v2/patient/find?firstName=Maria&dob=1988-04-12&exact=false" \
  -H "Authorization: Bearer $KEY"
# → {"results":[{"patientId":"pt_a8f3c2b9d4e7","score":0.97}]}

STEP 4 · MINUTE 40–60 — GET

Get the full record.

Retrieve the canonical record with its observations and attachments — or the audit history of every read and write.

curl https://api.1health.io/v2/patient/{id} \
  -H "Authorization: Bearer $KEY"

That's it. The next hour is your product.

From Our Engineering

How we think about patient record design.

Essay · 12 min read

Seven rules for a modern patient record API

Every healthcare application eventually builds a patient record. Most of them build it twice. This is what to build the first time — seven design decisions, learned in production, that determine whether your patient record scales, complies, and survives.

By Neil Sethi, platform development at 1health · Read the essay →

The Seven Rules

  1. 1.Append-only events
  2. 2.Probabilistic identity
  3. 3.Merges as redirects
  4. 4.Scoped consent
  5. 5.Minimal exposure
  6. 6.Agent-legible by default
  7. 7.Outlives your stack

Pricing

Free to start. Pay only when you scale.

Free

$0

forever for your first 1,000 patients

  • ✓No credit card required
  • ✓BAA executed at production activation
  • ✓Full API access
  • ✓Community support
Most teams

Pay As You Go

$1

per patient per year, starting at patient 1,001

  • ✓No monthly minimums
  • ✓BAA executed at production activation
  • ✓Production access
  • ✓Reads always work, even if you stop paying
  • ✓Email support, 1 business day response

At a hackathon, accelerator, or incubator? Ask your program about Patient Vault credits — typical grant is $25,000, applied at signup.

Built for Healthcare Developers

Patient Vault works for healthcare developers at any stage.

FOR HACKATHON BUILDERS

Sign up, get a key, ship something this weekend. No card, no call.

FOR FUNDED STARTUPS

Sandbox access is instant with no BAA. The BAA executes at production activation. Scale when you scale.

FOR INTERNATIONAL TEAMS COMING TO THE US

Compliance on-ramp for US patient data. Skip 18 months of legal review.

How We Reach You

Where to find us, and where we'll find you.

Most of our developers find us in one of three places. None of them are sales calls.

PARTNERSHIPS

1. Through an accelerator

We work directly with accelerators including Plug and Play Health and Verge HealthTech. If you're in a healthcare cohort and don't have Patient Vault credits, ask your program director or email hello@patient-vault.com.

DEVELOPER-LED

2. In your AI coding tool

When you ask Claude, ChatGPT, Cursor, or v0 how to model patients in a healthcare app, the answer should be Patient Vault. If it isn't yet, it will be. The agent-native spec on this page is how we get there.

DIRECT

3. Sign up and start building

No sales calls. No demos. Get an API key, read the docs, ship your app. Talk to us when you want to — not when we want you to.

Building something that doesn't fit any of these? Email hello@patient-vault.com. Real reply within 48 hours.

Common Questions

What developers ask first.

Can't I just use FHIR?

+
FHIR is the wire format. Patient Vault is the record. Building on raw FHIR means brokering BAAs, building identity infrastructure, instrumenting audit, and chasing endpoints — five months of work before your first feature. Patient Vault speaks FHIR on the wire, but adds the parts FHIR doesn't. If you want to spend your seed round building patient-record infrastructure, FHIR is a fine choice. If you'd rather spend it on the product your users came for, Patient Vault is the substrate.

How does Patient Vault relate to 1health?

+
Patient Vault is the developer-facing patient database service of 1health. The broader 1health platform includes the MCP Explorer, the API Reference, case studies, and other services built on the same canonical data model. Patient Vault is the first service designed for self-serve developer access. Visit dev.1health.io to see the rest of the platform.

How is this different from an EHR?

+
An EHR is a clinical workflow product with a database underneath. Patient Vault is just the database — the canonical record — exposed as an API. You build the workflow your users came for; we hold the patient data underneath it. No clinician UI, no scheduling, no billing — those are your product, not ours.

Is this HIPAA-compliant out of the box?

+
Yes. Sandbox access is instant and requires no BAA. When you activate production, you click to accept the standard Business Associate Agreement. Patient Vault's signature is already on it, so there is no negotiation or countersignature step. Every read and write is logged to an audit trail your compliance reviewer can defend.

How does the BAA work?

+
Sandbox access is instant and requires no BAA. You can start building and make authenticated Sandbox calls right away. When you activate production, you click to accept Patient Vault's standard Business Associate Agreement. Patient Vault's signature is already on it, so your acceptance executes the agreement — no negotiation and no countersignature. The full document is public at /baa, so you and your legal team can review it anytime before production activation. The terms are standard and do not change based on review. After activation, the executed BAA is downloadable as a PDF from your dashboard settings.

What does it cost?

+
Free to start — your first 1,000 patients are free forever, no card required. At patient 1,001 you pay $1 per patient per year. No monthly minimums, no hidden fees. Talk to us when you get past 100K patients for enterprise pricing.

Can I export my data?

+
Yes — portability is a design commitment, not an afterthought. Patient records outlive companies. Export is specified as GET /patient/{id}/export?format=fhir-r4: the full event stream as a FHIR R4 Bundle with provenance intact, not a snapshot. Specified in v1.1 ahead of implementation so you can build against a stable target.

Who's already building on this?

+
Some of the largest payers in the US run critical care transition apps on Patient Vault — that's how the platform reaches 80M Americans today. You're building on the same substrate they trust, and your patient data lives in your own isolated vault alongside that scale.

Does Patient Vault give me access to other developers' patient data?

+
No. Your patients live in your own isolated vault. You see only the patients you create. Cross-vault queries are not included.

Is the free tier a limited version of the product?

+
No — it's the full product, not a stripped-down tier. From your first patient you get every endpoint and full Sandbox API access with no BAA required. The BAA executes when you activate production. Nothing in the API is gated. Your first 1,000 patients are free; at patient 1,001 you start paying $1 per patient per year. It's metered, not freemium — you're never on a lesser Patient Vault. Support moves from community to 1-business-day email once you're on the paid plan. Reads on existing patients keep working even if you stop paying.

What kind of files can I attach?

+
Any file type — PDFs, images, audio, documents, structured data. Files are virus-scanned on upload and limited to 50 MB each. Attach as many as you need to each patient.

For Agents

This page is built for you too.

Every route we publish ships with an agents.md file — a structured spec your coding agent reads in one fetch. Start at the index and drill down; each file links one level deeper.

agents.md

Every route ships with an agents.md file — request/response schemas, real JSON examples, every error code, and links to child routes. Generated from source on every change, so it never drifts. No key, no login: plain markdown at a predictable URL.

Using agents.md with your AI tools

Point Claude, Cursor, v0, or ChatGPT at the file for the route you're integrating and it writes correct calls on the first try. Step-by-step guide for each tool →

first call: curl https://mcp.dev.1hdev.io/agents-docs-index/patient