# 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.

Source: https://developers.anpheros.com/guides/healthcare-startups

**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](https://developers.anpheros.com/guides/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](https://developers.anpheros.com/guides/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:

- **Regulatory status of your product.** If your software makes diagnostic or therapeutic claims it may be regulated as a medical device; that assessment is yours. Anpheros does not claim medical-device certification or other regulatory approvals.
- **Clinical safety** of your content and of any AI feature.
- **Your users' accounts** and the relationship with them.
- **Your own compliance** as a controller of personal data; Anpheros processes the record under a data processing agreement and keeps it in the EU.

## 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](https://developers.anpheros.com/guides/security) · [Limits](https://developers.anpheros.com/guides/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

- [Healthcare software development](https://developers.anpheros.com/guides/healthcare-software)
- [Build with Anpheros](https://developers.anpheros.com/guides/build-with-anpheros)
- [Medical app backend and database](https://developers.anpheros.com/guides/medical-app-backend)
- [Use cases](https://developers.anpheros.com/guides/use-cases)
- [AI healthcare applications](https://developers.anpheros.com/guides/ai-healthcare)
