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

Application de dossier de santé personnel (DSP) avec FHIR

Tutoriel : le backend d'un DSP connecté sur FHIR R4 — données des personnes, laboratoires, documents et appareils, une chronologie, un IPS à partager, le consentement. Code testé.

Une application de dossier médical personnel (DMP) conserve les informations de santé d'une personne — résultats, mesures, diagnostics, médicaments, documents — dans un dossier que la personne contrôle, collectées à partir de nombreuses sources plutôt qu'à partir d'un seul hôpital. Les parties difficiles ne sont pas les écrans : il s'agit d'intégrer les données des laboratoires, des cliniques et des appareils sous une forme utilisable, de suivre l'origine de chaque élément et de permettre à la personne de partager le dossier sans en perdre le contrôle. Ce tutoriel construit le backend d'un DMP sur HL7 FHIR R4 avec le SDK Anpheros TypeScript ; le code ci-dessous a été exécuté sur une instance locale de la plateforme avec une clé sandbox.

Dossiers de santé personnels (DSPs) connectés, déconnectés et liés

Un DSP connecté est celui qui vaut la peine d'être construit aujourd'hui. C'est aussi vers quoi s'oriente la politique : aux États-Unis, les DME certifiés doivent offrir aux patients un accès API basé sur FHIR à leurs données (US Core), et dans l'Union européenne, l'Espace européen des données de santé donne aux personnes le droit d'accéder à leurs données de santé électroniques et de les partager avec les fournisseurs de leur choix, mis en œuvre progressivement à partir de 2029.

D'où proviennent les données d'un PHR

1. La personne : mesures à domicile, symptômes, médicaments pris, affections connues. Marquez-les comme rapportées par le patient.
2. Rapports de laboratoire : la plupart des gens reçoivent des PDF ; certains laboratoires peuvent envoyer du HL7 v2 ou du CSV. Chaque résultat doit devenir une Observation codée (API des résultats de laboratoire).
3. Documents : lettres de sortie, rapports d'imagerie, ordonnances. Conservez le fichier original, inchangé, à côté des données structurées.
4. Appareils et wearables : pas quotidiens, fréquence cardiaque, sommeil, tension artérielle provenant d'Apple Health ou de Health Connect (données de wearables en FHIR).
5. Prestataires : aux États-Unis, APIs FHIR d'accès patient des hôpitaux et des assureurs, accessibles avec SMART on FHIR ; ailleurs, principalement des documents et des résumés tels que le Résumé International du Patient.

Chaque source écrit dans le même enregistrement. Ce qui le rend fiable, c'est que chaque élément enregistre qui l'a écrit et de quel système (provenance des données médicales).

L'architecture

 person ──► your PHR app (mobile / web) ──► your backend ──► Anpheros: one FHIR R4 record per person
                                               │                 ├─ Observations, Conditions, Medications, Documents…
   lab report, PDF, device data ───────────────┘                 ├─ Provenance on every write
                                                                 ├─ access log the person can see
   other apps, doctors, AI assistants ◄── consent (OAuth) ───────┴─ $summary (IPS) to share

Votre backend détient la clé du projet (sk_test_… dans le sandbox, jamais dans l'application). Votre application connecte les utilisateurs avec votre propre authentification et communique avec votre backend ; le backend associe chaque utilisateur à un enregistrement patient.

Étapes

Installez le SDK (npm install @anpheros/sdk) et obtenez une clé de sandbox gratuite depuis le tableau de bord. L'exemple utilise un panneau lipidique HL7 v2 à deux résultats (lipid-panel.hl7) et n'importe quel PDF (report.pdf).

import { readFile } from 'node:fs/promises';
import { Anpheros, apiKey } from '@anpheros/sdk';

const anpheros = new Anpheros({ auth: apiKey(process.env.ANPHEROS_KEY!) });

// 1. One record per person who signs up in your PHR app
const jane = await anpheros.patients.create({ given: 'Jane', family: 'Doe', birth_date: '1984-07-19', gender: 'female' });

// 2. Something the person measured at home
await anpheros.observations.create(jane.id, {
  code: '85354-9', category: 'vital-signs', effective_at: '2026-10-01T08:30:00-05:00', author_type: 'patient',
  components: [{ code: '8480-6', value: 128, unit: 'mm[Hg]' }, { code: '8462-4', value: 82, unit: 'mm[Hg]' }],
});

// 3. A diagnosis and a medication the person reports
await anpheros.conditions.create(jane.id, { code: 'E11.9', system: 'http://hl7.org/fhir/sid/icd-10',
  display: 'Type 2 diabetes mellitus without complications', clinical_status: 'active', onset: '2021-03-15', author_type: 'patient' });
await anpheros.medications.create(jane.id, { code: 'A10BA02', display: 'Metformin 500 mg', status: 'active',
  dosage: '500 mg twice a day', start: '2021-03-20', author_type: 'patient' });

// 4. A lab report the person received, as the lab sent it (HL7 v2)
const lab = await anpheros.labs.importHl7(jane.id, await readFile('lipid-panel.hl7', 'utf8'), { sourceSystem: 'springfield-lis' });

// 5. A PDF they want to keep with the record
const doc = await anpheros.documents.upload(jane.id,
  { title: 'Chest X-ray report', kind: 'imaging_report', content_type: 'application/pdf', date: '2026-10-03' },
  await readFile('report.pdf'));

// 6. One timeline for the home screen
const timeline = await anpheros.timeline.list(jane.id, { limit: 10 });

// 7. A summary to share with a new doctor: the International Patient Summary
const ips = await anpheros.fhir.summary(jane.id);

// 8. Who else can read this record (empty until the person consents to another app)
const grants = await anpheros.grants.of(jane.id);

Imprimé à partir de cette exécution :

lab:       created 2, unmapped []
document:  final
timeline:  2026-10-03  document    Chest X-ray report
           2026-10-02  observation Cholesterol in HDL [Mass/volume] in Serum or Plasma
           2026-10-02  observation Cholesterol [Mass/volume] in Serum or Plasma
           2026-10-01  observation Blood pressure panel
           2021-03-20  medication  Metformin 500 mg
           2021-03-15  condition   Type 2 diabetes mellitus without complications
IPS:       Allergies, Medications, Problems, Results, Vital signs
grants:    0

Tout ce qui précède est stocké en tant que FHIR R4 — Patient, Observation, Condition, MedicationStatement, DocumentReference — de sorte que le même enregistrement peut être lu avec n'importe quel client FHIR (GET /fhir/R4/Patient/{id}/$everything) et déplacé ailleurs intact. Les appels /v1 dans le SDK sont une vue simplifiée des mêmes ressources ; API de données médicales les liste.

Partage sans perdre le contrôle

Un PHR existe pour être partagé, selon les conditions de la personne :

• Avec un médecin : le Résumé International du Patient ($summary) est un document FHIR conçu pour les cliniciens — problèmes, médicaments, allergies, résultats — que votre application peut afficher, imprimer ou envoyer. La plateforme FHIR décrit $summary et $everything.
• Avec une autre application : l'autre application demande le consentement via OAuth 2.1 et SMART on FHIR ; la personne choisit quelles données (par exemple, uniquement les résultats de laboratoire) et pour combien de temps, et peut le révoquer à tout moment. Comment implémenter le consentement patient avec SMART on FHIR explique la procédure.
• Avec un assistant IA : POST /v1/context crée un résumé budgétisé et étiqueté par source du dossier pour un modèle, et la lecture apparaît dans le journal d'accès (Comment créer une application d'IA pour la santé).
• Transparence : chaque lecture et écriture, par n'importe quelle application, est enregistrée par application, et la personne peut consulter le journal et les autorisations actives.

Familles

De nombreux Dossiers Médicaux Personnels (DMP) sont gérés par une seule personne pour plusieurs individus : enfants, conjoint, parent âgé. Donnez à chaque personne son propre dossier et liez-la au tuteur, plutôt que de mélanger les données de chacun en un seul. Le consentement est alors donné par dossier. Dossier médical du patient décrit le modèle.

Ce qu'il faut construire soi-même et ce qu'il ne faut pas

Vous construisez l'expérience : l'intégration, la manière dont les résultats sont expliqués, les rappels, les graphiques, la langue que la personne lit. Anpheros fournit l'enregistrement, les formats standard, le consentement, la provenance, le journal d'accès et les opérations de laboratoire, de document et de résumé.

Ce qu'Anpheros ne fait pas aujourd'hui pour un PHR : il ne se connecte pas aux portails patients des hôpitaux ou aux API d'accès patient américaines au nom de la personne (votre application peut le faire avec un client SMART on FHIR et écrire ce qu'elle reçoit), il ne lit pas les rapports PDF via l'API, et il ne donne pas de conseils médicaux. L'application PHR d'Anpheros elle-même, Anpheros Daily, est construite sur cette même API.

Questions fréquemment posées

Qu'est-ce qu'un dossier de santé personnel (DSP) ?

Un dossier de santé personnel (DSP) est un enregistrement des informations de santé d'une personne que cette personne conserve et contrôle, collecté à partir de plusieurs sources — ses propres entrées, des laboratoires, des cliniques, des appareils — plutôt que conservé par un seul fournisseur.

Quelle est la différence entre un DSP et un DSE ?

Un DSE est conservé par une organisation de soins de santé et couvre ce que ses fournisseurs ont enregistré. Un DSP est conservé par la personne et peut combiner des données de tous ses fournisseurs et appareils. Un DSP lié est une fenêtre sur le DSE d'un fournisseur ; un DSP connecté utilise des normes pour rassembler plusieurs sources.

Un DSP doit-il utiliser FHIR ?

Si les données doivent un jour être partagées avec un médecin, une autre application ou un assistant IA, oui : FHIR R4 fournit des ressources codées et versionnées que d'autres systèmes comprennent déjà, et c'est le format des API d'accès patient aux États-Unis et du résumé patient européen.

Comment une application DSP obtient-elle des données des hôpitaux ?

Aux États-Unis, via les API d'accès patient FHIR que les DSE certifiés et de nombreux assureurs exposent, en utilisant SMART on FHIR pour permettre à la personne d'autoriser l'application. Ailleurs, il s'agit principalement de documents et de résumés, importés et stockés à côté de données structurées.

Où une application DSP doit-elle conserver les clés d'API ?

Sur votre serveur. Une clé de projet peut lire chaque enregistrement créé par votre projet, elle ne doit donc jamais être intégrée dans une application mobile ou web ; l'application communique avec votre backend, et les applications d'autres personnes utilisent OAuth avec le consentement de la personne.

Liens Utiles

• Créer une application de santé : le guide général
• Dossier médical du patient : contenu du dossier et qui peut y accéder
• Infrastructure de dossier médical numérique
• Données des appareils portables en FHIR : Apple Health, Health Connect et Samsung Health
• API des résultats de laboratoire
• SDK

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