AnpherosAnpheros PlatformDevelopers

Healthcare startups

How an interoperable medical-data infrastructure spares a startup from building patient records, consent, audit and integrations from scratch, a realistic path to production, and what the startup still owns.

For a healthcare startup, the fastest path to a working product is to build what makes it different and use infrastructure for what every medical product needs. Anpheros is interoperable medical-data infrastructure: patient records in HL7 FHIR R4, a REST and FHIR API, OAuth-based patient consent, provenance and audit, lab import, webhooks and SDKs. A startup can build its product on top instead of spending its first months on a medical database.

What a healthcare product needs before it can do anything useful

Almost every health product — a chronic-condition tracker, a remote-monitoring service, a pregnancy or medication app, a clinic tool, an AI assistant — needs the same foundation:

Foundation Built from scratch On Anpheros
Patient records design tables for measurements, diagnoses, medications, documents FHIR R4 record, 26 resource types
Standard codes research LOINC, ICD-10, ATC; build pickers recognised on write; bundled LOINC and ATC search
Medical data layer and API design and document an API REST v1 and FHIR R4, OpenAPI specification
Authentication for data access build API keys and OAuth API keys per project; OAuth 2.1 with PKCE, SMART on FHIR
Consent grant, scope, expiry and revocation logic built in, visible to the patient
Audit and provenance logging, history, a way to show it to users every read and write logged; every version kept
Lab data parsers for each lab format CSV, HL7 v2 ORU^R01 and JSON import
Events a queue and retry logic signed, retried webhooks
Client libraries write your own TypeScript and Dart / Flutter SDKs
AI context retrieval and summarisation code context API with token budget and source labels

None of these is the startup's product, and each is easy to get subtly wrong with medical data.

A realistic path

  1. Prototype in the sandbox. Sandbox access is self-service: sign in with Google and get a key in one click. Sandbox keys (sk_test_) reach only a separate database — your project's own copy of 30 synthetic patients — so a prototype, including one written with AI coding tools, never touches real data.
  2. Build the product layer. Screens, onboarding, your clinical content, your AI features; the medical record lives in Anpheros. Build a healthcare app
  3. Connect partners. A partner lab can send reports to your patients' records; a clinic can write on behalf of its organisation. Healthcare integrations
  4. Go to production. Production keys (sk_live_) are issued to verified organisations with a signed data processing agreement.

What you still own

Infrastructure does not remove a startup's own responsibilities:

Things to know about the current stage

Anpheros Platform is in private beta: single-zone hosting without automatic failover, no contractual SLA, rate limits of 600 requests per minute per key and per IP. SMART EHR launch is not supported yet. These limits are listed publicly so you can plan around them. Security, privacy and data residency · Limits

Frequently asked questions

Can we start without real patient data?

Yes. The sandbox is a separate database; each sandbox project gets its own 30 synthetic patients, and sandbox keys cannot reach production data.

Do our users need an Anpheros account?

Not if your project creates their records: your backend creates a patient per user and reads and writes it with your API key. People who already keep a record in Anpheros can instead give your application access through the consent page.

Can we leave later and take the data with us?

The records are standard FHIR R4. Patient/$everything returns a patient's whole record as a FHIR bundle.

Related