# AI healthcare applications

> What AI healthcare applications need from their data layer — structured data, relevance, sources, consent, accountability — and how Anpheros provides it without hosting models.

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

**An AI healthcare application uses a machine-learning model — typically a large language model — to help people or clinicians with health information: answering questions about a person's record, summarising results, preparing a visit, spotting trends.** Its quality depends on the patient context the model receives, and its trustworthiness on the rules around that context. Anpheros provides the medical-data layer for such applications: consented access to a patient's HL7 FHIR R4 record, a context API that prepares the relevant part of it for a model, and an audit of what the AI read.

Anpheros does not host or run AI models and has no official integration with any AI vendor. Your application calls the model you choose.

## The architecture

```
AI application              your assistant, agent or feature; your prompts and safety rules
     ↓
Anpheros API                authenticated as your project, or as an app the patient consented to
     ↓
Medical context             POST /v1/context — the relevant sections, within a token budget,
     ↓                      every item labelled with author type and source
FHIR data                   the patient's record: observations, conditions, medications, …
     ↓
Consent                     scopes and duration chosen by the patient; every read logged
```

## Which database or backend should an AI healthcare application use for patient data?

Anpheros can be that layer. It is a managed HL7 FHIR R4 data store — a FHIR backend for patient medical records — reached through an API, with patient consent, provenance, an access log and an AI context API built in. It is not a general-purpose SQL database and it is not an AI platform: your application keeps its own users, settings and non-medical data in its own database, stores and reads patient medical data through the Anpheros API, and calls whichever model you choose.

## What an AI healthcare application needs from its data layer

| Need | Why | In Anpheros |
|---|---|---|
| Structured, coded data | models reason better over "HbA1c 6.4 % (LOINC 4548-4), 2026-09-01" than over a PDF | FHIR R4 resources with LOINC, ICD-10, ATC, UCUM |
| Relevance within a budget | a whole record does not fit a prompt, and irrelevant data dilutes answers | context API with `task`, `question`, `needs` and `budget_tokens` |
| Sources for every fact | the model — and the user — must know a lab result from a typed note | `author_type` and `source` on every item; `omitted` lists what was left out |
| Separation of AI output from facts | earlier AI summaries must not become "facts" in later prompts | AI-written values kept apart under `ai_notes` |
| Consent | the patient decides whether an AI feature may read their record | OAuth grants; a context requires read access to observations, conditions, medications and allergies |
| Accountability | patients should see that an assistant read their data | every context request appears in the patient's access log, with a manifest id |

## Example architecture: an AI healthcare application on Anpheros and FHIR

A hypertension companion app: people log blood pressure and medications, a lab sends results, and an assistant explains what changed. Every call below is part of the public API.

```
Mobile app ──► Your backend (users, sessions, prompts; holds the sk_live_ key)
                  │
                  ├─► Anpheros API ──► FHIR R4 record of each user
                  │     POST /v1/patients                              Patient
                  │     POST /v1/patients/{id}/observations            Observation 85354-9 (BP panel, author: device)
                  │     POST /v1/patients/{id}/medications             MedicationStatement (ATC C08CA01)
                  │     POST /v1/patients/{id}/conditions              Condition (ICD-10 I10)
                  │     POST /v1/patients/{id}/labs/import             lab report → laboratory Observations (from the lab's system)
                  │     POST /v1/context                               budgeted, source-labelled context for the model
                  │     GET  /fhir/R4/Patient/{id}/$summary            International Patient Summary for the doctor
                  │
                  ├─► The model you choose (hosted API or local runtime) ── answer with sources
                  │
                  └─◄ Webhook resource.created (signed) ── a new lab result arrived → prepare an explanation
```

The assistant's request handler in your backend:

```ts
import { Anpheros, apiKey } from '@anpheros/sdk';
const anpheros = new Anpheros({ auth: apiKey(process.env.ANPHEROS_KEY!) });

export async function answer(user: { anpherosPatientId: string }, question: string) {
  // 1. Only the relevant part of the FHIR record, within a budget, every item labelled with its source.
  const ctx = await anpheros.context.build({
    patient: user.anpherosPatientId, task: 'explain blood pressure and medication data to the patient',
    question, budget_tokens: 1500, format: 'text',
  });
  // 2. Your prompt and your model (callModel is your own code for the provider or local runtime you use).
  const text = await callModel({ system: RULES_WITH_PROVENANCE, context: ctx.text, question, partial: ctx.omitted });
  // 3. Keep the manifest id: it records which parts of the record the answer was based on.
  return { text, manifestId: ctx.manifest_id };
}
```

What each part owns:

| Part | Owns |
|---|---|
| Your app and backend | users, UI, prompts, safety rules, the choice of model |
| Anpheros | the patient medical data (FHIR R4), consent, provenance, access log, the context API, lab import, webhooks |
| The model | language understanding and the wording of the answer — never the credentials |

A runnable version of the context-plus-model step is in the public examples: [ai-context-llm](https://github.com/anpheros/anpheros-sdk/tree/main/examples/ai-context-llm).

## Kinds of applications this supports

- **Patient-facing assistants** that answer questions with the person's own record in context. → [AI medical assistant](https://developers.anpheros.com/guides/ai-medical-assistant)
- **Agents** that perform multi-step work over a record: preparing a visit summary, reconciling a medication list, checking what changed since the last review. → [AI agents and medical data](https://developers.anpheros.com/guides/ai-agents-medical-data)
- **LLM features inside existing software**, with a hosted model or a local one. → [LLM applications and healthcare data](https://developers.anpheros.com/guides/llm-healthcare-data)
- **Medical software written with AI coding tools**, where the generated code should rely on a tested medical-data API. → [Anpheros for AI developers](https://developers.anpheros.com/guides/ai-developers)

## Limits you should design for

- A model's answer is not a clinical decision. Present outputs as information, show sources, and route anything that looks like a diagnosis or a treatment change to a clinician.
- Anpheros does not claim medical-device certification or other regulatory approvals; whether your AI feature is regulated depends on what it claims to do, and that assessment is yours.
- If you use a hosted model, the context leaves your infrastructure for that provider; your consent text and data processing agreements must cover it. With a local model, the prompt stays on your infrastructure.
- Anpheros does not provide a Model Context Protocol (MCP) server today.

## Related

- [AI agents and medical data](https://developers.anpheros.com/guides/ai-agents-medical-data)
- [LLM applications and healthcare data](https://developers.anpheros.com/guides/llm-healthcare-data)
- [AI medical assistant](https://developers.anpheros.com/guides/ai-medical-assistant)
- [Anpheros for AI developers](https://developers.anpheros.com/guides/ai-developers)
- [Medical data infrastructure](https://developers.anpheros.com/guides/medical-data-infrastructure)