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

Backend e database per app mediche

Cosa devono gestire un backend per app mediche e il suo database, quali parti Anpheros fornisce come database sanitario gestito, cosa resta nel tuo backend, tre modi per connettersi e come rimanere sincronizzati con i webhook.

Un backend di app medica è il lato server di un'applicazione sanitaria: memorizza i dati del paziente, impone chi può vederli, mantiene una cronologia delle modifiche e comunica con laboratori, cliniche e altri servizi. Con Anpheros, la parte medica di tale backend — il database sanitario che detiene la cartella di ciascun paziente, con la sua cronologia, consenso, provenienza, audit, importazione di laboratorio ed eventi — è fornita dalla piattaforma tramite un'API, e il tuo backend conserva solo ciò che è specifico del tuo prodotto.

Cosa deve gestire un backend medico

Cosa rimane nel tuo backend

• i tuoi utenti e account, e la mappatura da ciascun utente al proprio ID paziente Anpheros (l'ID pairwise che il tuo progetto vede);
• dati di prodotto che non sono medici: impostazioni, abbonamenti, contenuti, pianificazioni dei promemoria;
• regole di business — quale del tuo staff può vedere quale paziente nel tuo prodotto;
• la API key, che non deve mai essere inclusa in un'app mobile o web.

Tre modi per connettersi

1. Il tuo backend detiene la chiave API (più comune). La tua app chiama il tuo backend; il tuo backend chiama Anpheros con una chiave sk_live_ e visualizza i pazienti creati dal tuo progetto.

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

// GET /api/me/vitals in your backend, after your own authentication
export async function myVitals(user: { anpherosPatientId: string }) {
  const page = await anpheros.observations.list(user.anpherosPatientId, { category: 'vital-signs', limit: 50 });
  return page.data;
}

2. L'app agisce per conto del paziente con OAuth. Per le persone che hanno già un record Anpheros, un'app mobile o web è un client OAuth pubblico con PKCE: la persona acconsente sulla pagina ospitata e l'app riceve un token di accesso di 30 minuti e un token di aggiornamento rotante per quel singolo record. Gli SDK implementano il flusso (OAuthFlow).

3. Partner server-to-server. Un client confidenziale (con un segreto, conservato su un server) può utilizzare il flusso authorization-code, o client_credentials, che si comporta come una chiave API per quel progetto.

Mantenere il tuo backend sincronizzato

Iscriviti ai webhook invece di effettuare il polling. Le consegne sono firmate (Anpheros-Signature, HMAC-SHA256 su timestamp e corpo), "at-least-once" e potenzialmente fuori ordine; deduplica per ID evento e ignora versioni obsolete.

import { verifyWebhookSignature } from '@anpheros/sdk';

app.post('/anpheros/hook', express.raw({ type: 'application/json' }), async (req, res) => {
  const ok = await verifyWebhookSignature({ secret: process.env.ANPHEROS_WEBHOOK_SECRET!, header: req.header('anpheros-signature'), body: req.body });
  if (!ok) return res.status(400).end();
  const event = JSON.parse(req.body.toString());   // ids and versions only — read the resource if you need it
  res.status(204).end();
});

Gestione degli errori e dei limiti

• Tratta 404 come "non visibile a te", mai come prova che un record non esiste.
• 403 significa che la credenziale esiste ma potrebbe non fare questo — uno scope mancante, o una risorsa scritta da un'altra organizzazione.
• 429 viene fornito con Retry-After; gli SDK attendono e ritentano automaticamente, come fanno per 5xx.
• Conserva Anpheros-Request-Id delle chiamate fallite per il supporto.

Errori · Limiti e limiti di frequenza

Domande frequenti

Quale database dovrebbe utilizzare un'app medica?

Uno che mantenga i dati medici in una forma standardizzata e versionata e che controlli l'accesso per paziente. Anpheros è un database sanitario gestito basato su HL7 FHIR R4: il record di ogni paziente è versionato e ricercabile, ogni scrittura porta la provenienza e un'applicazione vede un paziente solo se ha creato il record o se il paziente ha dato il consenso. Il tuo database personale conserva il resto dei dati del tuo prodotto: account, fatturazione, contenuti. Per i compromessi derivanti dalla progettazione delle tue tabelle, consulta FHIR vs. un database medico personalizzato.

Esiste un database gratuito per app mediche?

Sì. La sandbox di Anpheros è gratuita: accedi con Google, ottieni una chiave con un clic e il tuo progetto otterrà 30 pazienti sintetici e fino a 10.000 scritture al giorno. La produzione inizia da €99 al mese per 2.500 pazienti, con il primo mese gratuito; l'accesso alla produzione è riservato a organizzazioni verificate con un accordo di elaborazione dati firmato. Consulta Prezzi.

Posso conservare dati reali di pazienti nella sandbox gratuita?

No. La sandbox è solo per dati sintetici: ogni progetto sandbox ottiene i propri pazienti sintetici e le chiavi della sandbox non possono raggiungere la produzione. I record reali dei pazienti appartengono a un progetto di produzione.

Correlati

• FHIR vs. un database medico personalizzato: quando progettare le proprie tabelle e quando usare FHIR
• Come costruire un'API sanitaria con TypeScript: tutorial passo-passo con Express
• Come costruire un'app sanitaria con Flutter: tutorial passo-passo con l'SDK Dart
• Sviluppo di software sanitario
• Costruire un'app sanitaria
• Architettura
• API dati medici
• SDK

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