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

Infrastructure du dossier médical numérique

L'infrastructure nécessaire à un dossier médical numérique — structure, historique, documents, isolation, consentement, audit, échange — et pourquoi elle est séparée de l'application destinée au patient.

Un dossier médical numérique nécessite deux choses distinctes : une application destinée au patient que les gens utilisent quotidiennement, et l'infrastructure sous-jacente qui stocke, protège et partage le dossier. Anpheros fournit la seconde : le stockage, la gestion des versions, l'identité, le consentement, l'audit et l'échange du dossier, via une API. L'application destinée au patient peut être Anpheros Daily, ou une application que vous développez.

Application versus infrastructure

	Application orientée patient	Infrastructure de données médicales
Qu'est-ce que c'est	écrans, notifications, rappels, graphiques, un assistant	l'enregistrement lui-même et les règles qui l'entourent
Changements fréquents	oui — conception, fonctionnalités, plateformes	rarement — il doit rester stable et compatible
Exemples de travail	un journal des symptômes, un rappel de médicaments, un calendrier familial	stockage FHIR, historique des versions, consentement, provenance, audit, importation de laboratoires, webhooks
Dans Anpheros	Anpheros Daily (Android, macOS, web)	Anpheros Platform (`platform.anpheros.com`)

Les séparer permet à un enregistrement de survivre à n'importe quelle application et d'être partagé entre plusieurs. Anpheros Daily suit cette séparation : ce que les gens enregistrent dans l'application est écrit sur la plateforme via la même API publique que toute autre application utilise, de sorte qu'il est disponible — avec le consentement du patient — à d'autres applications sous la même forme FHIR.

Ce que l'infrastructure doit fournir

Structure

Un enregistrement n'est utile que si d'autres logiciels peuvent le comprendre. Anpheros le stocke sous forme de ressources HL7 FHIR R4 — 26 types — avec des codes standard (LOINC, ICD-10, ATC, UCUM) et conserve le texte original à côté de chaque code. Plateforme FHIR

Historique

Les données médicales sont corrigées, pas écrasées. Chaque mise à jour crée une nouvelle version, lisible via /fhir/R4/{type}/{id}/_history ; les mises à jour conditionnelles avec If-Match empêchent deux rédacteurs de s'écraser mutuellement (une version obsolète répond 412).

Documents

Les scans et les PDF sont stockés sous forme de DocumentReference avec le fichier original : téléchargés via la plateforme ou directement dans le stockage, puis finalisés avec une somme de contrôle SHA-256 et une taille. Après finalisation, l'original ne peut pas être modifié ; les valeurs qui en sont extraites y renvoient (derived_from). Les fichiers sont conservés dans un compartiment de stockage européen crypté avec une clé gérée par le client, jusqu'à 25 MiB chacun.

Identité et isolation

Chaque application fonctionne à l'intérieur d'un projet et ne voit que ses propres patients (plus ceux qui lui ont accordé l'accès), sous ses propres identifiants par paire. Un enregistrement hors de sa portée n'existe pas pour elle (404).

Consentement

Un patient accorde à une application un accès pour une période (30 à 365 jours), à des types de ressources et des actions spécifiques, éventuellement limités à une catégorie. Les autorisations sont reflétées sous forme de ressources FHIR Consent et peuvent être révoquées à tout moment. Modèle de consentement et d'accès

Provenance et audit

Chaque écriture enregistre qui l'a écrite (patient, praticien, appareil, importation ou IA), pour quelle organisation et depuis quel système. Chaque lecture est enregistrée et présentée au patient par application.

Échange

L'enregistrement peut être exporté dans son intégralité (Patient/$everything), résumé au format International Patient Summary (Patient/$summary), alimenté par les laboratoires (CSV, HL7 v2 ORU^R01, JSON) et surveillé via des webhooks signés. Intégrations de soins de santé

Résidence et suppression

Les données sont stockées et traitées dans l'Union européenne. La suppression d'un patient supprime toutes les ressources de l'enregistrement.

Créer votre propre application destinée aux patients

Si vous créez la couche applicative, vous pouvez vous concentrer sur l'expérience utilisateur et utiliser Anpheros pour le dossier :

créer un patient pour chaque utilisateur (POST /v1/patients) ou demander le consentement d'un utilisateur Anpheros existant ;
écrire ce que l'utilisateur enregistre (/v1/patients/{id}/observations, /conditions, /medications, /documents) ;
relire ces informations sous forme de listes ou d'une chronologie (/v1/patients/{id}/timeline) ;
s'abonner aux webhooks pour actualiser les écrans lorsqu'un laboratoire ou une clinique ajoute quelque chose.

La procédure complète se trouve dans Créer une application de santé.

Liens connexes

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