Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

Integrazioni sanitarie

Pattern di integrazione supportati oggi: referti di laboratorio in una chiamata, cliniche che scrivono per conto di un'organizzazione, dispositivi, app di terze parti con consenso, webhook e SDK — e cosa non è disponibile.

Un'integrazione sanitaria collega un sistema che produce o necessita di dati sanitari — un laboratorio, una clinica, un dispositivo, un'altra applicazione — al record del paziente. Con Anpheros ogni integrazione passa attraverso la stessa API e le stesse regole: i dati vengono scritti come HL7 FHIR R4, attribuiti alla loro origine, visibili al paziente e condivisi con altre parti solo sotto il consenso del paziente. Questa pagina descrive i pattern di integrazione supportati dalla piattaforma oggi.

Esplora la directory delle integrazioni Anpheros per vedere ogni integrazione con il suo stato verificato (disponibile, beta o guida per sviluppatori), i dati e le risorse FHIR che scambia, la sua direzione, l'autenticazione e la documentazione.

Laboratori: report completi in una chiamata

Un laboratorio, o qualsiasi sistema che detiene referti di laboratorio, invia un report completo e la piattaforma trasforma ogni risultato in un laboratorio 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

• Formati: CSV (intestazioni rumene o inglesi, virgola decimale accettata), HL7 v2 ORU^R01 e JSON.
• I marcatori vengono mappati a LOINC quando il report fornisce un codice o il nome corrisponde alla terminologia della piattaforma; altri mantengono il codice proprio del laboratorio e sono elencati come unmapped.
• Ogni riga ottiene un identificatore stabile, quindi l'invio ripetuto dello stesso report salta ciò che è già stato importato.
• Fino a 500 righe per richiesta; ogni risultato porta la provenienza che nomina il sistema sorgente e il report.

Dettagli: Lab connector.

Cliniche: scrittura per conto di un'organizzazione

Le cliniche e le persone che vi lavorano sono risorse di directory (Organization, Practitioner, PractitionerRole). Il sistema di una clinica può quindi indicare chi sta dietro ogni richiesta:

• X-Anpheros-Acting-As: PractitionerRole/<id> — il professionista che opera tramite la tua applicazione; scritto nel log di accesso e mostrato al paziente per nome;
• X-Anpheros-On-Behalf-Of: Organization/<id> — l'organizzazione per cui viene effettuata una scrittura;
• X-Anpheros-Author-Ref: Practitioner/<id> — l'autore registrato in Provenance.

Con il consenso del paziente, la clinica legge l'intero record, comprese le informazioni scritte da altre organizzazioni, e modifica solo ciò che ha scritto autonomamente. Diverse risorse possono essere scritte atomicamente con un bundle FHIR transaction (POST /fhir/R4).

Un esempio pratico, dalla directory a una visita scritta come una singola transazione: Come integrare i sistemi delle cliniche con un backend FHIR.

Il flusso consenso → laboratorio Observation scritto da un progetto clinico → notifica nell'app del paziente è stato esercitato end-to-end con un progetto clinico di test.

Dispositivi e wearable

Le misurazioni dai dispositivi sono Observations con author_type: "device" e un codice LOINC — frequenza cardiaca, pressione sanguigna, SpO₂, peso, glucosio, passi, durata del sonno e altri (FHIR code systems). Anpheros Daily scrive i riassunti giornalieri che legge da Apple Health e Health Connect come Observations nello stesso modo. Anpheros non si connette direttamente ai cloud dei fornitori di dispositivi; la tua applicazione o il tuo backend legge il dispositivo e scrive il risultato. Come leggere Apple Health, Health Connect e Samsung Health e mappare ogni metrica a LOINC: Wearable data in FHIR.

Applicazioni di terze parti: accesso con consenso

Un'applicazione che desidera dati che una persona conserva già in Anpheros si registra una volta e richiede il consenso tramite OAuth 2.1 con PKCE (avvio standalone SMART on FHIR):

1. GET /oauth/authorize?...&scope=patient/Observation.rs?category=laboratory offline_access — la pagina di consenso ospitata;
2. la persona sceglie il record e la durata (30, 90, 180 o 365 giorni);
3. POST /oauth/token scambia il codice con un token di accesso (30 minuti) e un token di aggiornamento rotante (30 giorni);
4. l'applicazione vede solo quel paziente, solo all'interno dei suoi ambiti, sotto il proprio ID pairwise.

Autenticazione e OAuth

Eventi: reazione ai cambiamenti

Invece di effettuare il polling, registra un webhook. Le consegne sono firmate con HMAC-SHA256, ritentate con backoff per un massimo di 24 ore e trasportano ID, mai contenuti clinici. Quando un altro progetto scrive in un record a cui hai accesso, l'evento lo comunica (data.external: true, con la sorgente). Webhook

SDK

Gli SDK TypeScript (@anpheros/sdk) e Dart / Flutter (anpheros_sdk) implementano tutte le funzionalità sopra menzionate: importazione di referti di laboratorio (labs.importCsv, labs.importHl7, labs.importItems), OAuth con PKCE, gestione delle webhook e verifica delle firme. SDK

Cosa non è disponibile

• Connettori predefiniti per specifici sistemi EHR ospedalieri o sistemi informativi di laboratorio; le integrazioni sono costruite contro l'API.
• Lancio SMART EHR (lancio all'interno di un EHR); è supportato solo il lancio standalone.
• Integrazioni dirette con fornitori di dispositivi.

Correlati

• Come integrare sistemi clinici con un backend FHIR: tutorial passo-passo per EMR clinici
• Come normalizzare i dati medici: codici, unità, date, duplicati, validazione
• Come importare risultati di laboratorio in un record FHIR: tutorial passo-passo con CSV e HL7 v2
• Interoperabilità dei dati sanitari
• API Sanitarie
• Architettura
• Casi d'uso

Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card