9 available, 1 in beta and 4 documented patterns. Only integrations verified against the live platform are marked Available; a developer guide is a tested pattern you build on the API, not a turnkey connector.
Laboratories and diagnosticsAvailable
Laboratory report import
Send a whole lab report as HL7 v2 ORU^R01, CSV or JSON; every result becomes a laboratory Observation coded with LOINC where the mapping is safe.
Into AnpherosFHIR: Observation, Provenance
Technical details
- Source
- Laboratory system, LIS export or any app holding a lab report
- Destination
- The patient's record in Anpheros
- Authentication
- Project API key on your server (sk_test_ in the sandbox, sk_live_ in production)
- Data mapping
- OBX-3 code^text^LN → Observation.code (LOINC); other code systems kept as the lab's own code with the exact text. OBX-5/6/7/8 → value, unit, referenceRange, interpretation. OBR-3 or MSH-10 → report id in Provenance.
- Validation
- Up to 500 rows per request. Markers that cannot be mapped to LOINC are kept with the lab's code and returned in
unmapped, never dropped. - Errors
- Problem responses with a stable code and the offending field; see Errors.
- Retries and idempotency
- Send an Idempotency-Key with the report id: a retry returns the same answer. Every row also gets a stable identifier, so re-sending a report skips rows already imported.
- Provenance
- Provenance with author type
import, the X-Anpheros-Source-System you send and the report id. - Consent and authorization
- Write into patients your project created, or into a person's record under an OAuth grant that includes write scope.
- SDK
- TypeScript and Dart: labs.importHl7, labs.importCsv, labs.importItems
- Verification
- Live since September 2026; consent → lab Observation → notification in the patient's app exercised end-to-end with a test clinic project (23 Sep 2026). Duplicate detection limited to the same patient since 13 Oct 2026.
Patient applicationsAvailable
Consented app access (SMART on FHIR)
A third-party app asks the person for access through OAuth 2.1 with PKCE; it then reads (and, if allowed, writes) only that record, only within the granted scopes.
Two-wayFHIR: Patient, Observation, Condition, MedicationStatement, AllergyIntolerance, Immunization, DocumentReference
Technical details
- Source
- The person's Anpheros record
- Destination
- Your patient-facing or clinical application
- Authentication
- OAuth 2.1 + PKCE, SMART on FHIR standalone launch, OpenID Connect; 30-minute access tokens, rotating 30-day refresh tokens
- Data mapping
- No mapping: the app receives standard FHIR R4 resources under its own pairwise patient id.
- Validation
- Scopes are enforced server-side on every read, search and derived view (context, timeline, $everything).
- Errors
- 401 invalid_token for expired or revoked tokens; 403 for resources outside the grant.
- Retries and idempotency
- Refresh tokens rotate; presenting one twice revokes the whole chain, so do not refresh concurrently.
- Provenance
- Every read is written to the access log the person sees in the app.
- Consent and authorization
- The person chooses the record and the duration (30, 90, 180 or 365 days) and can revoke access at any time.
- Verification
- Inferno SMART App Launch STU2, Standalone Launch group: 22/22 tests passed (23 and 28 Sep 2026). EHR launch is not supported.
Patient applicationsAvailable
Anpheros Daily
Anpheros's own personal health app. It keeps the person's record on the platform, so anything it records is readable by apps the person has approved.
Two-wayFHIR: Observation, Condition, MedicationStatement, MedicationAdministration, DocumentReference, Appointment, Immunization
Technical details
- Source
- The person's entries, scans and connected phone health data
- Destination
- The person's Anpheros record
- Authentication
- The person's own account; third parties reach the data only through a consent grant
- Data mapping
- The app writes FHIR R4 with LOINC, ICD-10 and ATC codes; what the person typed stays in their language with Resource.language.
- Validation
- Same validation as every other client of the API.
- Errors
- Shown to the person in the app.
- Retries and idempotency
- Writes are retried by the app; the platform deduplicates by identifier.
- Provenance
- Each item is labelled as entered by the person, imported from a device or document, or written by a clinic.
- Consent and authorization
- The person owns the record and decides which apps and clinics see it.
- Verification
- Two-way sync with the platform since September 2026. Available on the web and macOS; mobile store releases are in preparation.
AI and healthcare intelligenceAvailable
AI context API
POST /v1/context returns the part of a record relevant to a question, within a token budget, each item labelled with its author type and source. You pass only that to the model you choose.
From AnpherosFHIR: Observation, Condition, MedicationStatement, AllergyIntolerance, DocumentReference, Provenance
Technical details
- Source
- The patient's FHIR record
- Destination
- Your AI feature, with the model provider of your choice
- Authentication
- Project API key on your server, or an OAuth access token from the person
- Data mapping
- Sections are summarised from FHIR resources; AI-produced values are labelled and kept apart from clinical ones. QuestionnaireResponse is not included.
- Validation
- Under an OAuth grant, sections outside the consent are not read at all and are listed by name in
omitted. - Errors
- Standard problem responses; an empty section is returned as empty, not invented.
- Retries and idempotency
- Read-only; safe to repeat.
- Provenance
- Each answer has a manifest_id recording which parts of the record it was based on.
- Consent and authorization
- Data minimisation is on you as well: send the model only the context, never credentials, and make sure the person's consent and your agreements cover the model provider.
- Verification
- Consent filtering covered by automated tests (tests/test_derived_views_consent.py, 13 Oct 2026). Anpheros has no built-in integration with any model provider.
Developer toolsAvailable
Webhooks
React to changes instead of polling: signed HTTPS deliveries when resources are created, updated or written by another project.
From Anpheros
Technical details
- Source
- Anpheros
- Destination
- Your public HTTPS endpoint
- Authentication
- HMAC-SHA256 signature on every delivery, verifiable with both SDKs
- Data mapping
- Deliveries carry ids, never clinical content; you read the resource with your own credentials.
- Validation
- Only public HTTPS endpoints are accepted; local, private and reserved addresses are refused at registration.
- Errors
- An endpoint that fails 10 times in a row is disabled until you re-enable it; exhausted deliveries can be re-queued in bulk.
- Retries and idempotency
- 10 attempts with backoff, for up to 24 hours.
- Provenance
- External writes are marked
data.external: true with the source. - Consent and authorization
- You receive events only for records you created or have an active grant for.
- Verification
- Hardened and redeployed 13 Oct 2026 (DNS-rebinding protection, connection only to verified IPs).
Developer toolsAvailable
TypeScript SDK
@anpheros/sdk on npm: patients, FHIR, lab import, AI context, OAuth with PKCE, webhooks and signature checks.
Two-way
Technical details
- Authentication
- API key (server) or OAuth tokens
- Verification
- Published on npm; source and examples under Apache-2.0 on GitHub.
Developer toolsAvailable
Dart and Flutter SDK
anpheros_sdk on pub.dev for Flutter apps and Dart servers: the same surface as the TypeScript SDK.
Two-way
Technical details
- Authentication
- OAuth with PKCE in apps; API keys only on servers
- Verification
- Published on pub.dev under the verified publisher anpheros.com.
Developer toolsAvailable
FHIR R4 validator
Paste a resource and see what the platform would accept or refuse before you write a line of integration code. Nothing is stored.
Into Anpheros
Technical details
- Authentication
- None (public, rate-limited)
- Verification
- Examples cross-checked with the official HL7 validator: 0 errors on the valid ones, every deliberate mistake reported.
Developer toolsAvailable
Sandbox with synthetic patients
Every project gets its own sandbox with 30 synthetic patients (conditions, medications, labs, vitals, six months of data), resettable at any time.
Two-way
Technical details
- Authentication
- Sandbox key (sk_test_) from the dashboard, in one click
- Verification
- Self-service since 28 Sep 2026; separate from production data.
AI and healthcare intelligenceBeta
MCP server for AI assistants
“Anpheros FHIR” at platform.anpheros.com/mcp lets an MCP client (for example Claude) search and read FHIR data and build an AI-ready context, through the same API, scopes and audit as any other client.
From AnpherosFHIR: Patient, Observation, Condition, MedicationStatement, AllergyIntolerance, Provenance
Technical details
- Source
- An Anpheros project or one person's consented record
- Destination
- An AI assistant or agent that speaks the Model Context Protocol
- Authentication
- Sandbox API key (sk_test_), or OAuth with dynamic client registration and PKCE for one person's record
- Data mapping
- Tools return FHIR R4 or the context API's labelled summary; nothing is reformatted for the model.
- Validation
- Live keys (sk_live_) are refused; under OAuth the default access is read-only.
- Errors
- 401 with WWW-Authenticate when credentials are missing; tool errors carry the API's problem message.
- Retries and idempotency
- Stateless; each tool call is an ordinary API request.
- Provenance
- Writes are recorded with source system urn:anpheros:mcp.
- Consent and authorization
- OAuth access is granted by the person on the hosted consent screen, read-only unless they allow more.
- Verification
- Live since 11 Oct 2026; listed in the official MCP registry as com.anpheros/fhir; connected from Claude.ai as a custom connector on the sandbox. Real records over OAuth are not switched on yet.
EHR and clinical systemsDeveloper guide
Clinic and EHR systems
A clinic's system writes visits, diagnoses and results on behalf of its organisation, atomically, and reads the whole record with the patient's consent.
Two-wayFHIR: Organization, Practitioner, PractitionerRole, Encounter, Condition, ServiceRequest, DiagnosticReport, Observation
Technical details
- Source
- Your clinical system or practice software
- Destination
- The patient's Anpheros record (and back)
- Authentication
- Project API key or OAuth; acting-as and on-behalf-of headers name the practitioner and organisation
- Data mapping
- You map your system to FHIR R4; write several resources in one transaction Bundle (POST /fhir/R4). urn:uuid references inside a Bundle are resolved; conditional references are not.
- Validation
- FHIR R4 structural validation and required bindings are enforced; check payloads first with the public validator.
- Errors
- A failed transaction writes nothing.
- Retries and idempotency
- Idempotency-Key on writes.
- Provenance
- X-Anpheros-Author-Ref is recorded as the author; the patient sees the practitioner by name.
- Consent and authorization
- With consent the clinic reads the whole record but changes only what it wrote itself.
- Verification
- Pattern exercised end-to-end with a test clinic project. There are no ready-made connectors to specific hospital EHRs, and no EHR (in-EHR) launch.
Wearables and fitnessDeveloper guide
Apple Health (HealthKit)
HealthKit data lives on the iPhone; there is no server-to-server API. Your iOS app reads it with the person's permission and writes daily summaries as device Observations.
Into AnpherosFHIR: Observation, Provenance
Technical details
- Source
- HealthKit on the person's iPhone, read by your app
- Destination
- The person's Anpheros record
- Authentication
- HealthKit permission on the device + OAuth consent (or your project key on your backend)
- Data mapping
- Each metric → an Observation with a LOINC code and UCUM unit; author type
device. - Validation
- Unknown metrics stay out rather than being guessed into a wrong code.
- Errors
- Your app handles denied HealthKit permissions; the API returns problem responses for invalid Observations.
- Retries and idempotency
- Use a stable identifier per day and metric, so a re-sync does not duplicate.
- Provenance
- Recorded as a device measurement with your source system.
- Consent and authorization
- Two layers: the iOS permission and the person's Anpheros consent.
- Verification
- Mapping and code checked in the guide. Not affiliated with or endorsed by Apple.
Wearables and fitnessDeveloper guide
Health Connect (Android)
Health Connect is an on-device store on Android. Your Android or Flutter app reads it with the person's permission and writes Observations.
Into AnpherosFHIR: Observation, Provenance
Technical details
- Source
- Health Connect on the person's phone, read by your app
- Destination
- The person's Anpheros record
- Authentication
- Health Connect permission on the device + OAuth consent (or your project key on your backend)
- Data mapping
- Each record type → an Observation with a LOINC code and UCUM unit; author type
device. - Validation
- Same as any Observation write.
- Errors
- Your app handles revoked permissions; the API returns problem responses for invalid Observations.
- Retries and idempotency
- Stable identifier per day and metric.
- Provenance
- Recorded as a device measurement with your source system.
- Consent and authorization
- Two layers: the Android permission and the person's Anpheros consent.
- Verification
- Mapping and code checked in the guide. Not affiliated with or endorsed by Google.
Telemedicine and care deliveryDeveloper guide
Remote patient monitoring
Devices or a monitoring app write measurements; the care team's system subscribes to webhooks instead of polling and reads the new Observations.
Two-wayFHIR: Observation, CarePlan, Goal, CareTeam
Technical details
- Source
- Connected devices or a monitoring app
- Destination
- A care team's dashboard or alerting system
- Authentication
- Project API key on servers; OAuth for patient-facing apps
- Data mapping
- LOINC-coded vital-sign Observations, linked to a CarePlan and Goals.
- Validation
- Same as any Observation write.
- Errors
- Webhook deliveries that keep failing disable the endpoint until you re-enable it.
- Retries and idempotency
- Webhooks: 10 attempts with backoff; idempotent writes with Idempotency-Key.
- Provenance
- Device measurements are labelled as such.
- Consent and authorization
- The person's consent decides which care team sees the data.
- Verification
- Documented pattern on the live API. Anpheros does not connect directly to device vendors' clouds.
