# Architecture de l'application de santé

> Diagrammes et flux de données : patient vers application vers API Anpheros vers enregistrement FHIR et services externes, et agent IA vers API de contexte vers données autorisées.

Source: https://developers.anpheros.com/fr/guides/architecture

Anpheros est la couche de données médicales entre votre application (ou agent IA) et l'enregistrement du patient. Votre application conserve sa propre interface utilisateur et sa logique métier ; l'enregistrement médical, le consentement, la provenance et l'audit résident dans Anpheros et sont accessibles via une seule API.

```
  Your application, backend or AI agent
  (mobile app, web app, clinic system, lab system, LLM-based assistant)
                        │  HTTPS · API key (sk_test_ / sk_live_) or OAuth token (at_…)
                        ▼
  Anpheros Platform API
  ├─ /v1        simplified REST: patients, observations, conditions, medications,
  │             documents, timeline, provenance, context, labs, webhooks
  ├─ /fhir/R4   strict FHIR R4: 26 resource types, search, history, transactions,
  │             $everything, $summary (IPS), $validate
  └─ /oauth     OAuth 2.1 + PKCE, SMART on FHIR, OpenID Connect
                        │  every request: project isolation · scopes · rate limits
                        ▼
  One FHIR R4 record per patient
  ├─ versions of every resource (history)   ├─ Provenance for every write
  ├─ Consent resources for every grant      └─ access log visible to the patient
                        │
                        ▼
  Events out: signed webhooks to your server (ids only, never clinical content)
```

## La vue du patient : de la personne aux services externes

```
Patient
   ↓   uses an app, chooses what to share, sees every access
Healthcare application          Anpheros Daily, or your own app
   ↓   REST v1 / FHIR R4 over HTTPS, API key or OAuth token
Anpheros API
   ↓   isolation, scopes, idempotency, provenance
FHIR medical data               the patient's record: 26 resource types, every version kept
   ↓   only what the patient allowed, only for as long as allowed
External healthcare services    laboratories (lab import), clinics (directory, acting-as),
                                other apps (OAuth / SMART), your backend (webhooks)
```

## La vue IA : de l'agent aux données autorisées

```
AI agent or LLM application     runs the model you choose — hosted or local
   ↓   POST /v1/context  {patient, task, question, budget_tokens}
Medical context API             plans which parts of the record matter, fits them into the budget,
   ↓                            labels every item with author type and source, records a manifest
Authorised medical data         only records the project created or the patient granted;
                                the read appears in the patient's access log
```

Le modèle ne reçoit jamais d'identifiants et n'appelle jamais Anpheros lui-même ; votre application demande le contexte et décide quoi envoyer au modèle. Deux exemples complets avec les appels API : une application IA de santé dans [Applications IA de santé](https://developers.anpheros.com/fr/guides/ai-healthcare) et un agent consenti dans [Agents IA et données médicales](https://developers.anpheros.com/fr/guides/ai-agents-medical-data). Détails : [Agents IA et données médicales](https://developers.anpheros.com/fr/guides/ai-agents-medical-data), [Applications LLM et données de santé](https://developers.anpheros.com/fr/guides/llm-healthcare-data).

## Le dossier

Chaque patient possède un dossier composé de ressources FHIR R4 : `Observation` pour les signes vitaux, les résultats de laboratoire, les symptômes et les résumés d'activité quotidienne, `Condition` et `EpisodeOfCare`, `MedicationStatement` et `MedicationAdministration`, `DocumentReference`, `Immunization`, `AllergyIntolerance` et d'autres — 26 types au total, listés en direct dans la CapabilityStatement (`GET /fhir/R4/metadata`). Il n'y a pas de schéma propriétaire à apprendre : l'API REST est une vue simplifiée des mêmes ressources, avec les mêmes identifiants.

Rien n'est écrasé silencieusement. Chaque mise à jour crée une nouvelle version (`/fhir/R4/{type}/{id}/_history`), et chaque version enregistre le projet qui l'a écrite et l'organisation pour le compte de laquelle elle a été écrite.

## Deux façons d'accéder

| | Clé API | Jeton d'accès OAuth |
|---|---|---|
| Aspect | `sk_test_…` / `sk_live_…` | `at_…` |
| Utilisé par | votre serveur | une application agissant pour un patient |
| Voit | les patients créés par votre projet | exactement un patient, dans les limites des scopes accordés par le patient |
| Usage typique | le backend de votre propre application, un système de laboratoire, une intégration de clinique | une application tierce ou un assistant IA accédant à un dossier que le patient possède déjà |

Un projet ne voit jamais les patients d'un autre projet, sauf si le patient accorde l'accès. Chaque projet obtient son propre identifiant pour la même personne (identifiants par paires), de sorte que les identifiants ne peuvent pas être corrélés entre les applications, et un dossier hors de votre portée répondra `404`, jamais `403`.

## Deux environnements

Le bac à sable (sandbox) et la production sont des bases de données distinctes. Une clé de bac à sable (`sk_test_`) ne peut physiquement pas accéder à de vrais patients ; chaque projet de bac à sable obtient sa propre copie de 30 patients synthétiques, qu'il peut modifier librement et réinitialiser. Les clés de production (`sk_live_`) sont délivrées à des organisations vérifiées.

## Flux de données

**Votre application écrit.** `POST /v1/patients/{id}/observations` avec un `Idempotency-Key`. La plateforme stocke un `Observation` FHIR, écrit un `Provenance` (type d'auteur : patient, praticien, appareil, importation ou IA), enregistre l'accès et envoie un webhook `resource.created` aux points de terminaison abonnés.

**Une autre application lit avec consentement.** Le patient l'approuve sur la page de consentement hébergée (`/oauth/authorize`), en choisissant l'enregistrement et la durée (30 à 365 jours). L'application échange le code contre des jetons et ne lit que ce que les scopes autorisent. Le patient voit l'application, ses scopes et chaque lecture dans son journal d'accès, et peut la révoquer à tout moment.

**Un laboratoire livre des résultats.** `POST /v1/patients/{id}/labs/import` avec un rapport CSV, HL7 v2 ORU^R01 ou JSON ; chaque résultat devient un `Observation` de laboratoire avec des codes LOINC lorsque connus, et le renvoi du même rapport est sans risque.

**Un modèle d'IA a besoin de contexte.** `POST /v1/context` renvoie les parties de l'enregistrement pertinentes pour une tâche, dans la limite d'un budget de jetons, chaque élément étant étiqueté avec sa source ; l'appel est enregistré avec un identifiant de manifeste. Le modèle lui-même s'exécute où vous le souhaitez.

## Où Anpheros se situe par rapport à une construction personnalisée

| Préoccupation | Construction personnalisée | Avec Anpheros |
|---|---|---|
| Modèle de données médicales | conception de tables pour chaque type d'enregistrement | Ressources FHIR R4, 26 types |
| Interopérabilité | formats d'exportation personnalisés | FHIR R4, International Patient Summary, SMART on FHIR |
| Consentement | création de la logique d'octroi, de portée, d'expiration et de révocation | Octrois OAuth 2.1 reflétés comme FHIR `Consent` |
| Audit | création de journaux et d'un moyen de les présenter aux patients | chaque lecture et écriture enregistrée et visible par le patient |
| Intégration des laboratoires | analyse du format de chaque laboratoire | Importation CSV, HL7 v2 ORU et JSON |
| Contexte IA | écriture du code de récupération et de résumé | API de contexte avec budget de jetons et étiquettes de provenance |

## Liens connexes

- [Qu'est-ce qu'Anpheros ?](https://developers.anpheros.com/fr/guides/what-is-anpheros)
- [Développement de logiciels de santé](https://developers.anpheros.com/fr/guides/healthcare-software)
- [Backend et base de données d'applications médicales](https://developers.anpheros.com/fr/guides/medical-app-backend)
- [Créer une application de santé](https://developers.anpheros.com/fr/guides/build-a-healthcare-app)
- [Modèle de consentement et d'accès](https://developers.anpheros.com/fr/guides/consent)
- [Sécurité, confidentialité et résidence des données](https://developers.anpheros.com/fr/guides/security)