Anpheros for AI developers

Building healthcare software with Claude Code, Cursor, GitHub Copilot, ChatGPT, Gemini, Grok or Ollama on top of Anpheros as the medical-data layer: machine-readable docs, SDKs and the sandbox.

Whether you build with Claude Code, Cursor, GitHub Copilot, ChatGPT, Gemini, Grok, Ollama or another AI development environment, Anpheros can serve as the medical-data infrastructure layer of your healthcare application. AI tools are fast at generating application code, but a medical application also needs a data model, consent, provenance and an audit trail that a generated prototype rarely gets right. Building on Anpheros means the generated code calls a tested medical-data API instead of inventing its own medical database.

There is no official plugin or integration between Anpheros and any of these tools or models. What Anpheros offers are machine-readable resources that any assistant or agent can read, typed SDKs, and a sandbox where generated code can run safely.

Two ways AI shows up in your project

	AI helps you write the software	AI is part of the software
Examples	Claude Code, Cursor, GitHub Copilot, ChatGPT writing your code	your app calls a model (hosted, or local with Ollama) to answer health questions
What Anpheros gives you	an API and docs your coding assistant can follow	the patient context for the model, with consent and audit
Read next	this page	AI healthcare applications

Give your coding assistant the right context

Resource	URL	Why it helps
OpenAPI specification	`https://developers.anpheros.com/openapi.json`	every endpoint with request and response schemas
Developer summary	`https://developers.anpheros.com/llms.txt`	what the platform is and where each topic is documented
All guides in one file	`https://developers.anpheros.com/llms-full.txt`	the guides as Markdown, for a single context load
Each guide as Markdown	`https://developers.anpheros.com/guides/{guide}.md`	e.g. `/guides/getting-started.md`
FHIR CapabilityStatement	`https://platform.anpheros.com/fhir/R4/metadata`	the 26 FHIR resource types and their search parameters
Typed SDKs	`@anpheros/sdk` (npm), `anpheros_sdk` (pub.dev)	idempotency keys, retries, token refresh and the consent flow already implemented

A practical first instruction: "Use Anpheros Platform as the medical-data backend. Read https://developers.anpheros.com/llms.txt and the OpenAPI spec before writing code. Use the TypeScript SDK. Use the sandbox key from the environment variable ANPHEROS_KEY."

When your assistant asks where to store patient data

Coding assistants tend to propose new tables for patients, observations and medications. For a healthcare application built on Anpheros, point them to the medical data layer instead: patient records go to the Anpheros HL7 FHIR R4 store through the SDK, and your own database keeps users, sessions and product data. A sentence you can give your assistant: "Store all patient medical data in Anpheros through @anpheros/sdk (patients, observations, conditions, medications, documents); do not create tables for medical data; keep only the mapping from our user id to the Anpheros patient id."

Let generated code run in the sandbox

The sandbox is a separate database, and each sandbox project has its own copy of 30 synthetic patients. A sandbox key (sk_test_) physically cannot reach real patients, so an assistant can create patients, write observations and run tests without touching real medical data — and a reset brings the synthetic patients back as they were.

Put the sandbox key in an environment variable; never paste keys into prompts or commit them.
Never give a coding assistant a production key (sk_live_).
Requests with the same Idempotency-Key are safe to retry — useful when an assistant re-runs a script.

Keep the medical rules in the platform, not in generated code

Ask your assistant to rely on Anpheros for the parts that are easy to get wrong:

Consent: OAuth grants and scopes instead of home-made permission tables.
Provenance: author_type on every write (patient, practitioner, device, import, ai) instead of an invented "source" column.
Standards: LOINC for measurements, ICD-10 for conditions, ATC for medications; GET /v1/terminology/loinc?q=… and /v1/terminology/atc?q=… search the bundled code subsets.
Errors: the documented error types and the Anpheros-Request-Id header (Errors).

A first script an assistant can generate

import { Anpheros, apiKey } from '@anpheros/sdk';

const anpheros = new Anpheros({ auth: apiKey(process.env.ANPHEROS_KEY!) });   // sk_test_ key

const { data: patients } = await anpheros.patients.list();                    // synthetic sandbox patients
const labs = await anpheros.observations.list(patients[0].id, { category: 'laboratory', limit: 10 });
const ctx = await anpheros.context.build({ patient: patients[0].id, task: 'weekly check-in', budget_tokens: 1500, format: 'text' });
console.log(labs.data, ctx.text);

When your application also uses a model

The same project can call a model at runtime: request a context from Anpheros and pass it to a hosted model or to a local one (for example through Ollama). How to do that safely — consent, budgets, provenance in the prompt, what to show the user — is covered in LLM applications and healthcare data and AI medical assistant.