FAQ de l'offre : Ségur du numérique en santé

L’exigence DMP UX 27 stipule que le système doit proposer au professionnel de santé une fonction de recherche et/ou de filtrage basée sur les métadonnées XDS des documents issus du DMP.

Afin d'éclairer la mise en œuvre de cette exigence, voici des précisions à titre indicatif et illustratif sur le niveau d'exigence réglementaire et les recommandations UX destinées à optimiser l'usage au quotidien par le professionnel de santé.

1. Cadre réglementaire et portée de l'exigence
   • Sur le plan réglementaire : Le texte de l'exigence SC.DMP/UX.27 n'impose pas de liste exhaustive de métadonnées obligatoires à filtrer, ni de modalités techniques strictes d'implémentation du filtrage (par exemple, type d'interface ou combinaison exacte de filtres).
   • Conséquence pour la conformité : Les éléments présentés ci-dessous ne constituent pas des exigences strictes de vérification, mais des recommandations d'ergonomie et de bonnes pratiques.
2. Recommandations fonctionnelles (À titre indicatif et d'amélioration UX)
   Pour offrir une valeur ajoutée maximale aux professionnels de santé et leur permettre de retrouver rapidement les informations pertinentes au sein du DMP du patient, il est fortement recommandé de proposer :
   • Des fonctionnalités combinées :
     • Un module de filtrage ciblé par critère.
     • Une possibilité de tri (ex. tri chronologique inverse par défaut).
     • Une recherche par mot-clé au sein des métadonnées affichées.
3. Exemples de critères et métadonnées recommandés pour le filtrage / tri
   Afin d'optimiser la lisibilité de la liste des documents, il est pertinent d'offrir des capacités de recherche ou de filtre sur les champs de métadonnées suivants :
   • La date du document / de l'acte :
     • Filtrage par période (ex. derniers 6 mois, année en cours) ou intervalle de dates.
   • La nature du document médical :
     • Par intitulé du type-code : Compte-rendu d'imagerie, Compte-rendu de Biologie, Lettre de liaison, Prescription de produits de santé, Synthèse Médical etc.
     • Par titre précis : Échographie abdominale, Consultation de cardiologie, etc.
   • L'auteur du document :
     • Par nom de l'auteur : Recherche textuelle ou sélection de l'émetteur.
     • Par profession / spécialité : Filtrage par Médecin généraliste, Radiologue, Pharmacien, Orthophoniste etc.
     • Par établissement / structure : Filtrage par centre hospitalier, cabinet, laboratoire, etc.
   • Le niveau de confidentialité :
     • Le filtrage sur l’invisibilité des documents fait l’objet d’une vérification obligatoire de cette exigence.

Conclusion

Bien que la liberté d'implémentation soit laissée à l'éditeur quant aux métadonnées XDS choisies pour le filtrage, l'intégration de ces critères clés (Date, Type/Titre, Auteur/Profession/Établissement) constitue un levier majeur d'ergonomie et d'efficacité pour le gain de temps médical.
 

Oui. L'exigence SC.SSI/IE.38.01 prévoit que « le système DOIT permettre au professionnel de fermer sa session ». Dès lors qu'un professionnel de santé peut accéder à la solution via plusieurs interfaces distinctes nécessitant une authentification, cette exigence doit être satisfaite sur chacune de ces interfaces.

Ainsi, toute interface authentifiée donnant accès à la solution doit permettre au professionnel de santé de se déconnecter et conduire à la fermeture effective de sa session.

Bonne pratique sécurité

Cette exigence vise explicitement les accès des professionnels de santé. Elle ne s'applique donc pas formellement aux interfaces destinées aux patients.

Toutefois, lorsque la solution propose également des interfaces accessibles aux patients après authentification, il est recommandé d'appliquer le même principe de sécurité en permettant au patient de fermer sa session et en garantissant la fermeture effective de celle-ci. Cette approche constitue une bonne pratique de sécurité visant à limiter les risques d'accès non autorisés, notamment en cas d'utilisation de postes ou d'équipements partagés.

Non. Le certificat de conformité HDS de l’hébergeur constitue un élément de preuve recevable pour les populations relevant du périmètre de l’hébergement (par exemple : exploitation, administration ou maintenance de l’infrastructure lorsqu’elles sont couvertes par le périmètre certifié).

Toutefois, ce certificat ne permet pas à lui seul de démontrer que les autres populations intervenant sur le système d’information de l’éditeur (par exemple : conception, développement, intégration, support fonctionnel, etc.) bénéficient également des actions de sensibilisation exigées.

L’éditeur doit obligatoirement compléter cette preuve par une documentation décrivant son dispositif de sensibilisation (PSSI ou autre document équivalent) pour les populations non couvertes par le certificat HDS.

Il doit donc fournir également une PSSI pour une partie du périmètre ce qui justifie de compléter le template correspondant pour y pointer les éléments attendus.
 

L’identification du patient doit comporter l’ensemble des éléments constitutifs de l’identité INS, à savoir :

• le nom de naissance ;
• les prénoms de naissance ;
• la date de naissance ;
• le sexe ;
• le lieu de naissance – code INSEE ;
• le matricule INS, complété par son OID.

Cet attendu est explicitement précisé par l’exigence DB.SO.105, qui mentionne l’utilisation des informations contenues dans l’entête du Compte-Rendu pour l’identification du patient, à savoir « INS accompagné de ses traits stricts ».

Dans le cadre de la trace d’audit définie par DB.SO.43, ces informations doivent être véhiculées au niveau du « ParticipantObjectID » du bloc « C.Patient AuditMessage/ParticipantObjectIdentification ».

Aucun format de représentation particulier n’est imposé par la spécification. L’utilisation d’un format tel que HL7 CX est possible mais non obligatoire ; une représentation libre est acceptable dès lors que l’ensemble des éléments constitutifs de l’identité INS est effectivement véhiculé et exploitable.

La formulation actuelle de DB.SO.43, qui mentionne uniquement « Identifiant INS du patient », peut prêter à confusion. Cet attendu doit être compris en cohérence avec DB.SO.105 et avec la définition des traits stricts composant l’INS.

Les travaux d'extension du dispositif ROC ont commencé pour les établissements ayant une activité PSY et SSR, avec comme objectif une extension rapide dans le contexte des établissements ex-DG.

Le dispositif ROC concerne exclusivement les établissements de santé, quel que soit le statut (public, privé à but non lucratif et privé à but lucratif).

Néanmoins les téléservices AMC proposés dans le cadre de la médecine de ville sont proches des téléservices proposés dans le cadre du dispositif ROC.

L'activité d’hospitalisation à domicile (HAD) est incluse dans la première phase de déploiement du dispositif ROC auprès des établissements ex-DG (EPS et EBNL) ayant une activité hospitalière médecine – chirurgie – obstétrique – odontologie (MCOO).

Le dispositif ROC couvre l’ensemble des prestations des établissements : les actes et consultations externes (ACE) et les séjours. Les principes généraux de fonctionnement de ROC (usage de téléservices temps réel en amont de la facturation dématérialisée permettant de sécuriser celle-ci) sont les mêmes pour l'activité externe et les séjours.

Après une première phase de déploiement avec ROC V1 dans les établissements publics MCO, le dispositif étend son périmètre aux secteurs PSY, HAD et SMR, avec une expérimentation sur les établissements du secteur privé (ex-OQN) qui est en cours d'organisation (ROC V2).

La reprise du rôle d'opérateur national du déploiement et de la supervision (ONDS) par l'ANS s'effectue progressivement suite à une première phase de réversibilité qui a été conduite entre juin et décembre 2024 avec le précédent opérateur national du déploiement.

Le dispositif ROC concerne tous les établissements de santé, quel que soit le statut (public, privé à but non lucratif et privé à but lucratif).