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

Medical App Backend und Datenbank

Was ein Medical App Backend und seine Datenbank handhaben müssen, welche Teile Anpheros als verwaltete Gesundheitsdatenbank bereitstellt, was in Ihrem Backend verbleibt, drei Verbindungsarten und wie Sie mit Webhooks synchron bleiben.

Ein medizinischer App-Backend ist die Serverseite einer Gesundheitsanwendung: Er speichert Patientendaten, erzwingt, wer sie sehen darf, führt eine Historie von Änderungen und kommuniziert mit Laboren, Kliniken und anderen Diensten. Mit Anpheros wird der medizinische Teil dieses Backends – die Gesundheitsdatenbank, die die Akte jedes Patienten mit seiner Historie, Zustimmung, Herkunft, Audit-Protokoll, Laborimport und Ereignissen enthält – von der Plattform über eine API bereitgestellt, und Ihr eigenes Backend speichert nur das, was spezifisch für Ihr Produkt ist.

Was ein medizinischer Backend-Service handhaben muss

Zuständigkeit	Warum es im Gesundheitswesen schwierig ist	Mit Anpheros
Ein medizinisches Datenmodell	Dutzende von Datenarten, jede mit Standardcodes	HL7 FHIR R4, 26 Ressourcentypen, LOINC / ICD-10 / ATC / UCUM
Versionierung	medizinische Daten werden korrigiert, niemals stillschweigend überschrieben	jedes Update ist eine neue Version; `If-Match` für bedingte Updates
Dokumente	Originale müssen unverändert und nachvollziehbar bleiben	unveränderliche Originale mit SHA-256, EU-Speicher verschlüsselt mit einem kundenseitig verwalteten Schlüssel
Zugriffskontrolle	pro Patient, pro Anwendung, pro Datentyp	Projektisolation, paarweise IDs, OAuth-Scopes mit Kategorie-Filtern
Einwilligung	der Patient entscheidet und kann seine Meinung ändern	Berechtigungen für 30–365 Tage, widerrufbar, gespiegelt als FHIR `Consent`
Audit	Patienten und Aufsichtsbehörden fragen, wer was gesehen hat	jeder Lese- und Schreibvorgang wird protokolliert und ist für den Patienten sichtbar
Provenienz	ein Wert aus einem Labor ist kein vom Patienten eingegebener Wert	Autorentyp, Organisation, Praktiker und Quellsystem bei jedem Schreibvorgang
Integrationen	Labore senden CSV, HL7 v2, JSON; Apps benötigen Ereignisse	Laborimport, FHIR-Transaktionen, signierte Webhooks
Sichere Wiederholungsversuche	eine duplizierte Medikation oder ein Ergebnis ist ein klinischer Fehler	`Idempotency-Key` bei jedem Create
Testdaten	echte Patienten dürfen niemals in der Entwicklung sein	eine Sandbox-Datenbank mit synthetischen Patienten

Was in Ihrem Backend verbleibt

Ihre Benutzer und Konten sowie die Zuordnung jedes Benutzers zu seiner Anpheros-Patienten-ID (der paarweise ID, die Ihr Projekt sieht);
Produktdaten, die nicht medizinisch sind: Einstellungen, Abonnements, Inhalte, Erinnerungspläne;
Geschäftsregeln – welche Ihrer Mitarbeiter welche Patienten in Ihrem Produkt sehen dürfen;
der API-Schlüssel, der niemals in einer mobilen oder Web-App ausgeliefert werden darf.

Drei Verbindungswege

1. Ihr Backend hält den API-Schlüssel (am gebräuchlichsten). Ihre App ruft Ihr Backend auf; Ihr Backend ruft Anpheros mit einem sk_live_-Schlüssel auf und sieht die Patienten, die Ihr Projekt erstellt hat.

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. Die App agiert für den Patienten mit OAuth. Für Personen, die bereits einen Anpheros-Datensatz haben, ist eine mobile oder Web-App ein öffentlicher OAuth-Client mit PKCE: Die Person stimmt auf der gehosteten Seite zu und die App erhält einen 30-minütigen Zugriffstoken und einen rotierenden Refresh-Token für diesen einen Datensatz. Die SDKs implementieren den Flow (OAuthFlow).

3. Server-to-Server-Partner. Ein vertraulicher Client (mit einem Secret, das auf einem Server gespeichert wird) kann den Authorization-Code-Flow verwenden oder client_credentials, was sich wie ein API-Schlüssel für dieses Projekt verhält.

Backend synchron halten

Webhooks abonnieren statt Polling. Lieferungen sind signiert (Anpheros-Signature, HMAC-SHA256 über Zeitstempel und Body), mindestens einmal und möglicherweise außer Reihenfolge; deduplizieren nach Event-ID und veraltete Versionen ignorieren.

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();
});

Fehlerbehandlung und Limits

Behandeln Sie 404 als "für Sie nicht sichtbar", niemals als Beweis dafür, dass ein Datensatz nicht existiert.
403 bedeutet, dass die Anmeldeinformationen existieren, aber möglicherweise nicht dazu berechtigen – ein fehlender Scope oder eine Ressource, die von einer anderen Organisation geschrieben wurde.
429 tritt zusammen mit Retry-After auf; die SDKs warten und versuchen es automatisch erneut, wie auch bei 5xx.
Bewahren Sie die Anpheros-Request-Id fehlgeschlagener Aufrufe für den Support auf.

Fehler · Limits und Ratenlimits

Häufig gestellte Fragen

Welche Datenbank sollte eine medizinische App verwenden?

Eine, die medizinische Daten in einem standardisierten, versionierten Format speichert und den Zugriff pro Patient steuert. Anpheros ist eine verwaltete Healthcare-Datenbank, die auf HL7 FHIR R4 basiert: Der Datensatz jedes Patienten ist versioniert und durchsuchbar, jeder Schreibvorgang trägt eine Herkunftsinformation, und eine Anwendung sieht einen Patienten nur, wenn sie den Datensatz erstellt hat oder der Patient zugestimmt hat. Ihre eigene Datenbank speichert die restlichen Daten Ihres Produkts – Konten, Abrechnung, Inhalte. Die Kompromisse beim Entwurf eigener Tabellen finden Sie unter FHIR vs. eine benutzerdefinierte medizinische Datenbank.

Gibt es eine kostenlose Datenbank für medizinische Apps?

Ja. Die Anpheros-Sandbox ist kostenlos: Melden Sie sich mit Google an, erhalten Sie mit einem Klick einen Schlüssel, und Ihr Projekt erhält 30 synthetische Patienten und bis zu 10.000 Schreibvorgänge pro Tag. Die Produktion beginnt bei 99 € pro Monat für 2.500 Patienten, wobei der erste Monat kostenlos ist; der Produktionszugang ist für verifizierte Organisationen mit einer unterzeichneten Datenverarbeitungsvereinbarung bestimmt. Siehe Preise.

Kann ich echte Patientendaten in der kostenlosen Sandbox speichern?

Nein. Die Sandbox ist nur für synthetische Daten bestimmt: Jedes Sandbox-Projekt erhält seine eigenen synthetischen Patienten, und Sandbox-Schlüssel können die Produktion nicht erreichen. Echte Patientenakten gehören in ein Produktionsprojekt.