Healthcare integrations
Integration patterns supported today: lab reports in one call, clinics writing on behalf of an organisation, devices, consented third-party apps, webhooks and SDKs — and what is not available.
A healthcare integration connects a system that produces or needs health data — a laboratory, a clinic, a device, another application — to the patient's record. With Anpheros every integration goes through the same API and the same rules: data is written as HL7 FHIR R4, attributed to its source, visible to the patient, and shared with other parties only under the patient's consent. This page describes the integration patterns the platform supports today.
Laboratories: whole reports in one call
A laboratory, or any system that holds lab reports, sends a complete report and the platform turns every result into a laboratory Observation:
curl -X POST https://platform.anpheros.com/v1/patients/$PID/labs/import \
-H "Authorization: Bearer $KEY" -H "Content-Type: text/csv" \
-H "X-Anpheros-Source-System: labx" -H "Idempotency-Key: report-2026-0917-77" \
--data-binary @report.csv
- Formats: CSV (Romanian or English headers, decimal comma accepted), HL7 v2 ORU^R01 and JSON.
- Markers are mapped to LOINC when the report gives a code or the name matches the platform's terminology; others keep the lab's own code and are listed as
unmapped. - Every row gets a stable identifier, so re-sending the same report skips what was already imported.
- Up to 500 rows per request; each result carries provenance naming the source system and report.
Details: Lab connector.
Clinics: writing on behalf of an organisation
Clinics and the people who work there are directory resources (Organization, Practitioner, PractitionerRole). A clinic's system can then say who is behind each request:
X-Anpheros-Acting-As: PractitionerRole/<id>— the practitioner working through your application; written to the access log and shown to the patient by name;X-Anpheros-On-Behalf-Of: Organization/<id>— the organisation a write is made for;X-Anpheros-Author-Ref: Practitioner/<id>— the author recorded inProvenance.
With the patient's consent the clinic reads the whole record, including what other organisations wrote, and changes only what it wrote itself. Several resources can be written atomically with a FHIR transaction bundle (POST /fhir/R4).
The flow consent → lab Observation written by a clinic project → notification in the patient's app has been exercised end-to-end with a test clinic project.
Devices and wearables
Measurements from devices are Observations with author_type: "device" and a LOINC code — heart rate, blood pressure, SpO₂, weight, glucose, steps, sleep duration and others (FHIR code systems). Anpheros Daily writes the daily summaries it reads from Apple Health and Health Connect as Observations in the same way. Anpheros does not connect directly to device vendors' clouds; your application or backend reads the device and writes the result.
Third-party applications: consented access
An application that wants data a person already keeps in Anpheros registers once and asks for consent through OAuth 2.1 with PKCE (SMART on FHIR standalone launch):
GET /oauth/authorize?...&scope=patient/Observation.rs?category=laboratory offline_access— the hosted consent page;- the person chooses the record and the duration (30, 90, 180 or 365 days);
POST /oauth/tokenexchanges the code for an access token (30 minutes) and a rotating refresh token (30 days);- the application sees only that patient, only within its scopes, under its own pairwise id.
Events: reacting to changes
Instead of polling, register a webhook. Deliveries are signed with HMAC-SHA256, retried with backoff for up to 24 hours and carry ids, never clinical content. When another project writes into a record you have access to, the event says so (data.external: true, with the source). Webhooks
SDKs
The TypeScript (@anpheros/sdk) and Dart / Flutter (anpheros_sdk) SDKs implement all of the above — lab import (labs.importCsv, labs.importHl7, labs.importItems), OAuth with PKCE, webhooks management and signature verification. SDKs
What is not available
- Ready-made connectors to specific hospital EHRs or laboratory information systems; integrations are built against the API.
- SMART EHR launch (launching inside an EHR); only standalone launch is supported.
- Direct device-vendor integrations.