Connecter son DPI au DMP via FHIR : guide technique pour DSI

Connexion DPI/DMP via FHIR : un chantier devenu incontournable

La connexion DPI DMP via FHIR est désormais au coeur des obligations pesant sur les établissements de santé français. Le Ségur du Numérique a transformé ce qui était un projet technique parmi d'autres en une exigence réglementaire assortie de financements conditionnés. Pour les DSI hospitaliers, la question n'est plus de savoir s'il faut connecter le DPI au DMP, mais comment le faire de manière fiable, conforme et pérenne.

Les chiffres parlent d'eux-mêmes. Plus de 420 millions de documents ont été déposés dans le DMP en 2025, et l'adoption de Mon Espace Santé par les usagers progresse chaque trimestre. En parallèle, la directive NIS2 renforce les obligations de cybersécurité des établissements de santé, ce qui impose des flux d'échange maîtrisés et traçables.

Ce guide détaille les profils FHIR R4 à implémenter, les étapes techniques de l'intégration et les erreurs fréquentes à éviter pour réussir votre projet de connexion.

Les profils FHIR à implémenter pour le DMP

L'alimentation du DMP repose sur un ensemble de ressources FHIR qui doivent être implémentées de manière cohérente. Chaque ressource correspond à un rôle précis dans le flux de soumission et de consultation de documents.

DocumentReference : la ressource centrale

La ressource DocumentReference est le pivot de l'intégration DPI/DMP. Elle décrit un document clinique (compte rendu, lettre de liaison, résultat de biologie) avec ses métadonnées : type de document, auteur, date de création, patient concerné, statut et format.

En contexte français, DocumentReference porte les métadonnées XDS nécessaires à l'indexation dans le registre du DMP. Le profil FR Core impose des extensions spécifiques : le type de document selon la nomenclature du CI-SIS, la classe du document, le cadre d'exercice et le secteur d'activité de l'auteur. Le document lui-même, généralement un CDA R2 ou un PDF encapsulé dans un CDA, est référencé en pièce jointe (attachment).

Patient : l'identification par l'INS

La ressource Patient porte l'identité du patient telle qu'elle doit être transmise au DMP. Le profil FR Core Patient impose l'utilisation de l'INS (Identité Nationale de Santé) comme identifiant principal. L'INS se compose du matricule INS (le NIR ou NIA), de l'OID du système d'identification, et des traits stricts : nom de naissance, premier prénom de l'état civil, date de naissance et sexe.

Le statut de qualification de l'INS doit être renseigné dans la ressource. Seul un INS qualifié permet l'alimentation du DMP.

Practitioner et PractitionerRole : l'identification du professionnel

Practitioner identifie le professionnel de santé auteur du document. En France, l'identifiant RPPS (ou ADELI pour les professions non encore migrées) est obligatoire. Le profil FR Core Practitioner inclut les extensions pour la civilité d'exercice et les qualifications.

PractitionerRole précise le rôle du professionnel dans sa structure : spécialité médicale, service d'exercice, période d'activité. Cette ressource fait le lien entre le Practitioner et l'Organization. Elle est indispensable pour renseigner les métadonnées XDS relatives à l'auteur du document.

Organization : l'identification de la structure

La ressource Organization représente l'établissement de santé qui produit le document. Le profil FR Core impose l'identifiant FINESS (établissement ou juridique selon le contexte). L'adresse, le type de structure et les télécommunications complètent la ressource.

Bundle : le regroupement transactionnel

Le Bundle de type "transaction" regroupe l'ensemble des ressources nécessaires à une soumission au DMP en une seule requête HTTP. Un Bundle typique d'alimentation contient : la DocumentReference, le Patient, le Practitioner, le PractitionerRole, l'Organization, et le document clinique en binaire (Binary). Le serveur DMP traite le Bundle de manière atomique, ce qui garantit la cohérence des données déposées.

Les volets du CI-SIS applicables

Le cadre d'interopérabilité CI-SIS définit des volets métier qui spécifient la structure attendue des documents cliniques. Les volets les plus courants pour un DPI hospitalier sont :

• VSM (Volet de Synthèse Médicale) : le document de référence du médecin traitant
• CR de biologie : les résultats d'analyses de laboratoire structurés
• Lettre de liaison : document de sortie d'hospitalisation transmis au médecin traitant
• CR d'imagerie : compte rendu radiologique
• CR de consultation : synthèse d'une consultation spécialisée
• Prescription : ordonnance dématérialisée

Chaque volet précise les sections CDA obligatoires, les terminologies à utiliser (CIM-10, CCAM, LOINC, NABM) et les contraintes de validation. L'éditeur du DPI doit implémenter les volets correspondant aux documents que son logiciel produit.

Les étapes techniques de l'intégration

L'intégration DPI/DMP est un projet structuré qui se décompose en six étapes. Chacune constitue un prérequis pour la suivante.

Etape 1 : qualification INS

La qualification de l'INS est le fondement de tout le flux d'alimentation. Sans INS qualifié, aucun document ne peut être déposé dans le DMP. La qualification consiste à vérifier l'identité du patient auprès du téléservice INSi (Identité Nationale de Santé intégrée), opéré par l'Assurance Maladie.

Concrètement, le DPI envoie les traits d'identité du patient (nom de naissance, prénom, date de naissance, sexe) au téléservice INSi, qui retourne le matricule INS correspondant si les traits concordent. Le DPI doit alors stocker l'INS qualifié et l'associer de manière permanente au dossier patient.

Point de vigilance : la qualification INS impose une identitovigilance rigoureuse. Les erreurs de saisie, les homonymies ou les changements d'état civil (mariage, rectification) doivent être gérés par des procédures documentées. Le DPI doit implémenter un mécanisme de requalification périodique.

Etape 2 : intégration Pro Santé Connect

Pro Santé Connect (PSC) est le fournisseur d'identité des professionnels de santé. Son intégration est obligatoire pour l'alimentation du DMP, car le DMP exige une authentification forte du professionnel auteur du document.

L'intégration technique repose sur le protocole OpenID Connect. Le DPI doit rediriger le professionnel vers la page de connexion PSC, récupérer le jeton d'identité contenant l'identifiant RPPS, et vérifier la validité du jeton. Ce jeton sert ensuite à renseigner les ressources Practitioner et PractitionerRole dans le Bundle FHIR soumis au DMP.

Le flux d'authentification doit être transparent pour le professionnel. L'objectif est qu'il se connecte une fois en début de session et que toutes les soumissions au DMP soient authentifiées automatiquement pendant la durée du jeton.

Etape 3 : mapping des ressources FHIR

Le mapping consiste à établir la correspondance entre le modèle de données interne du DPI et les ressources FHIR attendues par le DMP. C'est un travail minutieux qui touche chaque champ de chaque ressource.

Pour chaque type de document (lettre de liaison, CR de biologie, prescription), il faut identifier les données sources dans le DPI, les transformer selon les contraintes du profil FR Core, et les structurer dans un document CDA conforme au volet CI-SIS correspondant.

Les points critiques du mapping sont les terminologies (correspondance entre les codes internes du DPI et les nomenclatures nationales), les identifiants (INS, RPPS, FINESS), et les métadonnées documentaires (type, classe, statut du document). Une matrice de correspondance exhaustive est indispensable avant de commencer le développement.

Etape 4 : implémentation des transactions IHE

L'alimentation du DMP repose sur le profil IHE XDS.b (Cross-Enterprise Document Sharing). La transaction principale est ITI-41 (Provide and Register Document Set), qui soumet un document accompagné de ses métadonnées au registre/dépôt du DMP.

En FHIR, cette transaction se traduit par l'envoi d'un Bundle de type transaction vers le endpoint du DMP. Le Bundle contient la DocumentReference (métadonnées), le Binary (document CDA), et les ressources de contexte (Patient, Practitioner, Organization).

La consultation de documents existants dans le DMP utilise les transactions ITI-18 (Registry Stored Query) pour rechercher des documents et ITI-43 (Retrieve Document Set) pour récupérer un document. En FHIR, ces transactions correspondent à des requêtes GET sur les endpoints DocumentReference et Binary.

Etape 5 : tests sur les bacs à sable ANS

L'ANS met à disposition des environnements de test (bacs à sable) qui simulent le comportement du DMP en conditions proches de la production. Ces environnements permettent de valider chaque flux sans risque pour les données réelles des patients.

Le processus de test suit une progression logique. D'abord, la validation unitaire de chaque ressource FHIR contre les profils FR Core à l'aide du validateur officiel HL7. Ensuite, la validation des documents CDA contre les schématrons du CI-SIS. Puis le test de bout en bout : soumission d'un document au bac à sable, vérification de l'indexation, et consultation du document déposé.

L'ANS fournit également des jeux de données de test (patients fictifs avec INS de test) pour alimenter les scénarios. Chaque scénario de test doit couvrir les cas nominaux et les cas d'erreur : patient inconnu, document invalide, authentification expirée, doublon de document.

Etape 6 : dossier de preuves pour le référencement Ségur

Le référencement Ségur conditionne l'accès aux financements publics. Pour l'obtenir, l'éditeur doit constituer un dossier de preuves démontrant la conformité de son implémentation aux exigences du DSR (Dossier de Spécifications de Référencement) de son couloir.

Le dossier de preuves contient les captures d'écran des flux fonctionnels, les traces techniques des échanges avec le bac à sable (requêtes HTTP, réponses, documents CDA), les rapports de validation des profils FHIR, et la documentation de l'ergonomie utilisateur. Chaque exigence du DSR doit être couverte par au moins une preuve.

Le dépôt se fait auprès de l'ANS via la plateforme dédiée. Le délai d'instruction varie de quelques semaines à plusieurs mois selon la complétude du dossier et la charge de l'équipe de référencement. Anticiper la constitution du dossier dès le début du projet est fortement recommandé.

Les erreurs fréquentes et comment les éviter

Après plusieurs projets d'intégration DPI/DMP, certaines erreurs reviennent systématiquement. Les identifier en amont fait gagner des semaines de développement.

INS non qualifié : le blocage silencieux

C'est l'erreur la plus courante et la plus coûteuse. Un établissement lance son projet d'alimentation du DMP sans avoir d'abord fiabilisé la qualification INS dans son DPI. Résultat : les flux sont développés, testés, déployés, mais aucun document ne part vers le DMP parce que la majorité des patients n'ont pas d'INS qualifié.

La solution : traiter la qualification INS comme un projet à part entière, en amont de l'intégration DMP. Mettre en place des indicateurs de suivi (taux de qualification par service, délai moyen de qualification) et former les équipes d'admission à l'identitovigilance.

Documents CDA mal formés : le rejet silencieux

Le DMP valide la conformité des documents CDA soumis. Un document qui ne respecte pas les contraintes du volet CI-SIS applicable est rejeté, mais le message d'erreur retourné est souvent peu explicite. L'éditeur voit un code d'erreur technique sans comprendre quel champ ou quelle section pose problème.

La prévention passe par une validation locale systématique avant chaque soumission. Intégrer le validateur CDA (schématrons du CI-SIS) dans la chaîne de traitement du DPI permet de détecter les erreurs avant qu'elles n'atteignent le DMP. Constituer une bibliothèque de documents CDA de référence pour chaque volet est également une bonne pratique.

Gestion des erreurs réseau insuffisante

Les flux DMP transitent par le réseau. Les coupures, les timeouts et les erreurs transitoires sont inévitables. Un DPI qui ne gère pas correctement ces situations risque de perdre des documents ou de les soumettre en doublon.

Trois mécanismes sont indispensables. Premièrement, un système de retry avec backoff exponentiel pour les erreurs transitoires (codes HTTP 5xx, timeouts). Deuxièmement, un mécanisme d'idempotence pour éviter les doublons en cas de retry : chaque document soumis doit porter un identifiant unique vérifié côté serveur. Troisièmement, une file d'attente persistante qui stocke les documents en attente d'envoi et les retransmet automatiquement après une interruption.

Ergonomie négligée : le frein à l'adoption

Un flux DMP techniquement parfait mais qui impose au professionnel de santé trois clics supplémentaires par patient sera contourné. L'alimentation du DMP doit être transparente, intégrée au parcours de soin existant, sans effort supplémentaire pour le clinicien.

L'idéal est une alimentation automatique : dès que le professionnel valide un compte rendu dans le DPI, le document est soumis au DMP en arrière-plan. Le professionnel est simplement notifié du succès ou de l'échec. L'interface doit afficher clairement le statut DMP de chaque document (envoyé, en attente, en erreur) et permettre un renvoi manuel en cas de besoin.

Ressources officielles et environnements de test

Pour mener à bien votre projet d'intégration, voici les ressources de référence.

Documentation technique

• CI-SIS : le cadre d'interopérabilité de l'ANS, disponible sur esante.gouv.fr, contient tous les volets techniques et les guides d'implémentation
• FR Core Implementation Guide : les profils FHIR français publiés par Interop'Santé sur le serveur de publication, avec exemples et jeux de valeurs
• Documentation DMP : le guide d'intégration technique du DMP, accessible aux éditeurs référencés sur la plateforme ANS
• Spécifications IHE : les profils XDS.b et les transactions ITI sur ihe.net

Environnements de test

• Bac à sable DMP : environnement simulant le DMP en conditions proches du réel, accessible après inscription auprès de l'ANS
• Validateur FHIR : validator.fhir.org pour tester la conformité des ressources FHIR aux profils FR Core
• Gazelle : la plateforme de test IHE Europe pour valider les transactions XDS.b
• Bac à sable INSi : environnement de test du téléservice d'identification INS

Communauté et support

• Forum Interop'Santé : pour les questions techniques sur les profils FHIR français
• MSSanté : la messagerie sécurisée, souvent couplée à l'alimentation DMP dans les projets Ségur
• Webinaires ANS : sessions régulières de présentation des nouvelles spécifications et retours d'expérience
• Hébergement : vos données de santé doivent être stockées chez un hébergeur certifié HDS

Ce qu'il faut retenir

La connexion d'un DPI au DMP via FHIR R4 est un projet structurant qui demande méthode et rigueur. Six étapes conditionnent sa réussite : qualification INS, intégration Pro Santé Connect, mapping des ressources FHIR, implémentation des transactions IHE, tests sur les bacs à sable ANS, et constitution du dossier de preuves Ségur.

Les facteurs de succès sont avant tout organisationnels. Traiter la qualification INS comme un projet à part entière, valider les documents CDA localement avant toute soumission, prévoir une gestion robuste des erreurs réseau, et surtout concevoir une ergonomie qui rend l'alimentation du DMP transparente pour le professionnel de santé.

Le référencement Ségur n'est pas une fin en soi : c'est la garantie que votre DPI s'inscrit dans l'écosystème national de santé numérique. Avec Mon Espace Santé qui gagne en adoption, chaque document correctement déposé dans le DMP améliore la continuité des soins pour vos patients.

Pour les DSI qui souhaitent un accompagnement technique sur ce chantier, l'essentiel est de démarrer par un diagnostic de l'existant : état de la qualification INS, capacité du DPI à produire des documents CDA conformes, et maturité de l'infrastructure réseau. C'est sur cette base que se construit un plan d'intégration réaliste et un calendrier tenable.