Healthcare data API: what to look for, and how to read and write a patient record in an hour

"Healthcare API" covers very different things: a hospital's HL7 v2 feed, a national e-prescription service, a wearable vendor's export, a FHIR server. If you are building a health app, a clinic tool or an AI assistant, what you need is narrower: a backend that holds a patient's record in a standard format, lets the patient decide who reads it, and gives you a clean API over it. This guide says what to look for and shows, with real calls, what the first hour looks like on Anpheros Platform.

What a healthcare data API has to do

Five things separate a usable health-data API from a database with HTTP in front of it.

• A standard format. HL7 FHIR R4 is the format hospitals, national systems and the EU's health data space use. A record stored in FHIR can be read by other systems without a custom bridge. A proprietary JSON cannot.
• Patient consent as a first-class object. Who may read what, for how long, revocable, visible to the patient. Not a checkbox in your own database.
• Provenance. Every value says who wrote it: the patient, a practitioner, a device, an import, a derived calculation. An AI assistant that cannot tell a lab result from a self-reported guess is dangerous.
• A sandbox with realistic data. You cannot test with real patients, and you should not have to invent 30 synthetic ones with six months of history yourself.
• Data residency you can name. For European users that means servers in the EU, under GDPR, with a data processing agreement.

Two ways in: REST and FHIR, same data

Anpheros Platform exposes the same record twice. A simple REST API (/v1) for product code, and strict FHIR R4 (/fhir/R4) for anything that must talk to the rest of the health system. Ids are identical in both; every v1 object carries its fhir reference.

export BASE=https://platform.anpheros.com
export KEY=sk_test_…

# patients your project can see
curl $BASE/v1/patients -H "Authorization: Bearer $KEY"

# lab results, newest first
curl "$BASE/v1/patients/$PID/observations?category=laboratory&limit=10" -H "Authorization: Bearer $KEY"

# active medications
curl "$BASE/v1/patients/$PID/medications?status=active" -H "Authorization: Bearer $KEY"

# everything on one timeline
curl "$BASE/v1/patients/$PID/timeline?from=2026-06-01" -H "Authorization: Bearer $KEY"

# the same data, strict FHIR
curl "$BASE/fhir/R4/Observation?patient=$PID&code=http://loinc.org|4548-4&_sort=-date" -H "Authorization: Bearer $KEY"

Behind these calls are 26 FHIR resource types (Patient, Observation, Condition, MedicationStatement, AllergyIntolerance, Immunization, DocumentReference, Encounter, Consent, Provenance and more), coded with LOINC for measurements, ICD-10 for conditions and ATC for medications.

Getting a key takes a minute

The sandbox is self-service and free. Sign in to the dashboard at platform.anpheros.com/dashboard, press Get a sandbox key, and you have an organization, a sandbox project and a sk_test_… key. The project comes with its own copy of 30 synthetic patients: adults, children and older people from across the EU, with conditions, medications, allergies, lab results and vital signs over six months. Change or delete anything; a reset brings them back.

Production keys (sk_live_…) go to verified organizations with a signed data processing agreement. Sandbox and production are different databases: a sandbox key physically cannot reach a real patient.

What else is in the box

• OAuth 2.1 with PKCE and SMART on FHIR standalone launch, so an app can ask a person for access to their own record.
• Consent with scopes, expiry and revocation, and an access log the patient can read.
• Signed webhooks (HMAC-SHA256, retried with backoff) for resource.created, consent.granted, consent.revoked, document.finalized.
• An AI context API that builds a provenance-labelled summary of a patient within a token budget.
• Lab report import from CSV, HL7 v2 ORU^R01 or JSON, mapped to LOINC.
• International Patient Summary ($summary) and SMART Health Links for sharing by QR.
• SDKs for Dart and TypeScript, an OpenAPI reference at /docs and a CapabilityStatement at /fhir/R4/metadata.

The full walkthrough, with responses, is at developers.anpheros.com/guides/first-hour.

Frequently asked questions

Is there a free healthcare API I can start with today?

Yes. The Anpheros sandbox is free and self-service: sign in, get a key, and you have 30 synthetic patients to read and write. Limits are 10 000 resource writes a day, 500 patients of your own and 250 MB of documents per project.

REST or FHIR, which should I use?

Use /v1 for your own product code: it is simpler and returns plain JSON. Use /fhir/R4 when another system has to read the data, when you need FHIR search, _history, $everything or $summary, or when a certification asks for it. Both see the same record.

How is patient consent handled?

A person grants an application access to their record through OAuth, choosing scopes and a duration (30, 90, 180 or 365 days). The grant can be revoked at any time, and the patient sees every read in an access log. Details in the consent model.

Where is the data hosted?

In the European Union (Cloud Run, europe-west4), with provenance and version history on every write. Production use requires a signed data processing agreement.

What does production cost?

Production starts at €49 a month for 2 500 stored patients, with the first month free; larger plans are €199 and €799 a month. The sandbox stays free. See pricing.

Does it work with AI agents?

Yes. There is an AI context API with provenance labels and a token budget, and an MCP server at platform.anpheros.com/mcp that any MCP-capable assistant can connect to. See EMR integration with AI medical assistants.