# Backend et base de données d'une application médicale

> Ce que le backend et la base de données d'une application médicale doivent gérer, quelles parties Anpheros fournit en tant que base de données de santé gérée, ce qui reste dans votre backend, trois façons de se connecter et comment rester synchronisé avec les webhooks.

Source: https://developers.anpheros.com/fr/guides/medical-app-backend

**Le backend d'une application médicale est le côté serveur d'une application de santé : il stocke les données des patients, applique qui peut les consulter, conserve un historique des modifications et communique avec les laboratoires, les cliniques et d'autres services.** Avec Anpheros, la partie médicale de ce backend — la base de données de santé qui contient le dossier de chaque patient, avec son historique, son consentement, sa provenance, son audit, son importation de laboratoire et ses événements — est fournie par la plateforme via une API, et votre propre backend ne conserve que ce qui est spécifique à votre produit.

## Ce qu'un backend médical doit gérer

| Responsabilité | Pourquoi c'est difficile dans le domaine de la santé | Avec Anpheros |
|---|---|---|
| Un modèle de données médicales | des dizaines de types de données, chacun avec des codes standard | HL7 FHIR R4, 26 types de ressources, LOINC / ICD-10 / ATC / UCUM |
| Gestion des versions | les données médicales sont corrigées, jamais écrasées silencieusement | chaque mise à jour est une nouvelle version ; `If-Match` pour les mises à jour conditionnelles |
| Documents | les originaux doivent rester inchangés et traçables | originaux immuables avec SHA-256, stockage UE chiffré avec une clé gérée par le client |
| Contrôle d'accès | par patient, par application, par type de données | isolation des projets, identifiants par paire, scopes OAuth avec filtres de catégorie |
| Consentement | le patient décide et peut changer d'avis | autorisations pour 30 à 365 jours, révocables, reflétées comme FHIR `Consent` |
| Audit | les patients et les régulateurs demandent qui a vu quoi | chaque lecture et écriture est enregistrée et visible par le patient |
| Provenance | une valeur d'un laboratoire n'est pas une valeur saisie par un patient | type d'auteur, organisation, praticien et système source à chaque écriture |
| Intégrations | les laboratoires envoient du CSV, HL7 v2, JSON ; les applications ont besoin d'événements | importation de laboratoire, transactions FHIR, webhooks signés |
| Retries sûrs | une médication ou un résultat dupliqué est une erreur clinique | `Idempotency-Key` sur chaque création |
| Données de test | les vrais patients ne doivent jamais être présents en développement | une base de données sandbox avec des patients synthétiques |

## Ce qui reste dans votre backend

- vos **utilisateurs et comptes**, ainsi que la correspondance entre chaque utilisateur et son identifiant patient Anpheros (l'identifiant par paire vu par votre projet) ;
- les **données produit** qui ne sont pas médicales : paramètres, abonnements, contenu, plannings de rappels ;
- les **règles métier** — quel membre de votre personnel peut voir quel patient dans votre produit ;
- la **clé API**, qui ne doit jamais être intégrée dans une application mobile ou web.

## Trois façons de se connecter

**1. Votre backend détient la clé API (le plus courant).** Votre application appelle votre backend ; votre backend appelle Anpheros avec une clé `sk_live_` et voit les patients que votre projet a créés.

```ts
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'application agit pour le patient avec OAuth.** Pour les personnes qui ont déjà un enregistrement Anpheros, une application mobile ou web est un client OAuth *public* avec PKCE : la personne consent sur la page hébergée et l'application reçoit un jeton d'accès de 30 minutes et un jeton de rafraîchissement rotatif pour cet enregistrement unique. Les SDK implémentent le flux (`OAuthFlow`).

**3. Partenaires serveur à serveur.** Un client confidentiel (avec un secret, conservé sur un serveur) peut utiliser le flux de code d'autorisation, ou `client_credentials`, qui se comporte comme une clé API pour ce projet.

## Garder votre backend synchronisé

Abonnez-vous aux webhooks au lieu d'interroger périodiquement. Les livraisons sont signées (`Anpheros-Signature`, HMAC-SHA256 sur le timestamp et le corps), au moins une fois et potentiellement dans le désordre ; dédupliquez par ID d'événement et ignorez les versions obsolètes.

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

## Gestion des erreurs et des limites

- Traitez `404` comme "non visible pour vous", jamais comme une preuve qu'un enregistrement n'existe pas.
- `403` signifie que les identifiants existent mais peuvent ne pas permettre cela — un scope manquant, ou une ressource écrite par une autre organisation.
- `429` est accompagné de `Retry-After` ; les SDK attendent et réessaient automatiquement, comme ils le font pour `5xx`.
- Conservez les `Anpheros-Request-Id` des appels échoués pour le support.

[Erreurs](https://developers.anpheros.com/fr/guides/errors) · [Limites et limites de débit](https://developers.anpheros.com/fr/guides/limits)

## Questions fréquentes

### Quelle base de données une application médicale devrait-elle utiliser ?
Une qui conserve les données médicales sous une forme standard et versionnée, et qui contrôle l'accès par patient. Anpheros est une base de données de santé gérée, construite sur HL7 FHIR R4 : le dossier de chaque patient est versionné et interrogeable, chaque écriture porte une provenance, et une application ne voit un patient que si elle a créé le dossier ou si le patient y a consenti. Votre propre base de données conserve le reste des données de votre produit — comptes, facturation, contenu. Pour les compromis liés à la conception de vos propres tables à la place, consultez [FHIR vs. une base de données médicale personnalisée](https://developers.anpheros.com/fr/guides/fhir-vs-custom-database).

### Existe-t-il une base de données gratuite pour les applications médicales ?
Oui. Le sandbox Anpheros est gratuit : connectez-vous avec Google, obtenez une clé en un clic, et votre projet bénéficie de ses 30 patients synthétiques et jusqu'à 10 000 écritures par jour. La production commence à 99 € par mois pour 2 500 patients, avec le premier mois gratuit ; l'accès à la production est réservé aux organisations vérifiées ayant signé un accord de traitement des données. Voir [Tarifs](https://developers.anpheros.com/fr/guides/pricing).

### Puis-je conserver de vraies données de patients dans le sandbox gratuit ?
Non. Le sandbox est réservé aux données synthétiques uniquement : chaque projet sandbox obtient ses propres patients synthétiques, et les clés du sandbox ne peuvent pas accéder à la production. Les dossiers de vrais patients appartiennent à un projet de production.

## Liens connexes

- [FHIR vs. une base de données médicale personnalisée](https://developers.anpheros.com/fr/guides/fhir-vs-custom-database) : quand concevoir vos propres tables et quand utiliser FHIR
- [Comment construire une API de santé avec TypeScript](https://developers.anpheros.com/fr/guides/healthcare-api-typescript) : tutoriel étape par étape avec Express
- [Comment construire une application de santé avec Flutter](https://developers.anpheros.com/fr/guides/healthcare-app-flutter) : tutoriel étape par étape avec le SDK Dart
- [Développement de logiciels de santé](https://developers.anpheros.com/fr/guides/healthcare-software)
- [Construire une application de santé](https://developers.anpheros.com/fr/guides/build-a-healthcare-app)
- [Architecture](https://developers.anpheros.com/fr/guides/architecture)
- [API de données médicales](https://developers.anpheros.com/fr/guides/medical-data-api)
- [SDK](https://developers.anpheros.com/fr/guides/sdks)