Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card
Fiabilité, état et incidents
Où Anpheros fonctionne, ce qui est surveillé, sauvegardes quotidiennes et récupération à un instant T, communication des incidents, exportation et suppression des données, et ce qui n'est pas encore en place (pas de SLA, pas de page de statut publique).
Ce qu'Anpheros fait aujourd'hui pour maintenir l'API disponible et vos données récupérables, comment vous êtes informé des problèmes, et ce qui n'est pas encore en place. La plateforme Anpheros est en bêta privée ; cette page décrit la configuration actuelle, et non les objectifs présentés comme des garanties.
Hébergement
| Aujourd'hui | |
|---|---|
| Région | Union Européenne uniquement : Google Cloud europe-west4 (Pays-Bas), derrière un edge Cloudflare |
| API | Cloud Run, autoscalé jusqu'à 3 instances ; FHIR R4 à /fhir/R4, REST à /v1 |
| Base de données | PostgreSQL géré dans une zone unique, sans basculement automatique : une panne de zone entraîne une panne complète |
| Sandbox | une base de données séparée ; les clés de sandbox (sk_test_) ne peuvent pas accéder aux données de production |
| Niveau de service | meilleur effort ; pas d'accord de niveau de service contractuel pendant la bêta |
Surveillance
- Les contrôles de disponibilité appellent le point de terminaison de santé de la plateforme depuis trois régions ; lorsqu'il cesse de répondre, l'équipe est alertée par e-mail.
- Des alertes sont également déclenchées en cas d'erreurs serveur supérieures à 5 %, de réponses lentes (p95 supérieur à 2 secondes pendant 10 minutes), d'une part élevée de réponses 4xx, d'épuisement du pool de base de données, d'échecs d'écriture du journal d'audit, d'une chaîne d'audit rompue, de réutilisation d'un jeton de rafraîchissement OAuth, et de points de terminaison de webhook désactivés après des échecs répétés.
- Il n'y a pas encore de page de statut publique. Les contrôles ci-dessus sont internes. Une page de statut ne sera publiée que lorsqu'elle pourra afficher des mesures réelles de ces contrôles, et non un message manuscrit "tous les systèmes opérationnels".
Sauvegardes et récupération
- Base de données : sauvegarde automatisée tous les jours à 02:00 UTC, conservation de 7 sauvegardes, plus récupération à un instant T pour les 7 derniers jours ; la protection contre la suppression est activée.
- Documents : versionnement d'objets et suppression logique de 7 jours sur le bucket de stockage, chiffré avec une clé gérée par le client.
- Journal d'audit : une copie immuable (append-only) en dehors de la base de données, vérifiée quotidiennement pour détecter les lacunes et les falsifications.
- Test de restauration : le 20 septembre 2026, la base de données de production a été clonée à un point temporel trois minutes auparavant ; le clone était utilisable après environ 10 minutes et le nombre d'enregistrements correspondait à la source. Une restauration complète nécessite également un redéploiement, soit environ 5 minutes supplémentaires.
En cas de problème
- L'alerte parvient à l'équipe ; les requêtes affectées sont tracées par leur identifiant de requête (chaque réponse contient un en-tête
Anpheros-Request-Id; citez-le lorsque vous nous contactez). - Une credential compromise est révoquée en premier ; si l'intégrité des données est compromise, les écritures sont arrêtées et la base de données est restaurée à un point antérieur à l'incident.
- Les organisations dont les données ont été affectées sont informées directement, dans le respect des délais de leur accord de traitement des données ; pour une violation de données personnelles, dans les 72 heures suivant sa découverte, conformément au RGPD.
- Une analyse post-mortem suit dans les 5 jours ouvrables.
Les modifications apportées à l'API, y compris les renforcements liés à la sécurité, sont annoncées dans le journal des modifications.
Vos données : exportation, conservation et suppression
- Exportation : les enregistrements sont au format standard HL7 FHIR R4 ;
Patient/$everythingrenvoie l'intégralité du dossier d'un patient sous forme de bundle FHIR, et$summaryun International Patient Summary. Rien n'est au format propriétaire. - Suppression : une organisation peut supprimer les ressources qu'elle a écrites (FHIR
DELETE, ouDELETEsur les ressources/v1) ; les versions antérieures restent dans l'historique de la ressource. Ce qui advient des données de production lorsqu'un plan prend fin est détaillé dans les conditions tarifaires. - Audit : chaque lecture et écriture est enregistrée et visible par le patient. Les lignes d'audit sont actuellement conservées indéfiniment ; une période de conservation par type d'enregistrement est une décision juridique en attente.
Pas encore en place
- basculement automatique entre zones, et un SLA contractuel ;
- une page de statut publique avec la disponibilité mesurée ;
- certifications formelles (par exemple ISO 27001 ou SOC 2) : aucune n'est revendiquée.
Ceux-ci sont listés afin que vous puissiez en tenir compte dans votre planification. Questions : [email protected].
Liens connexes
- Sécurité, confidentialité et résidence des données
- Limites et limites de débit
- Versionnement et journal des modifications
- Tarification
Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card