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

Initialement, le scénario précisait que l’éditeur DOIT exécuter le cas de test suivant sur l’espace de test d’interopérabilité des SIS pour un plan personnalisé de prévention (Type_Code : 11490-0) : CI-SIS-CR-VIL-N1-Create_doc-Sc2

Il s'agit du plan personnalisé de prévention au format PDF/A-1 pour le cas de tests CI-SIS-CR-VIL-N1-Create_doc-Sc2, en mentionnant le ou les destinataires initialement prévus à la création du document dans l’en-tête CDA N1 et le PDF/A-1. Hors, il a été identifié que le Type_Code « 11490-0 » ne correspond pas à un plan personnalisé de prévention. Ce code est associé à une lettre de suivi, type de document qui n’est pas référencé dans le REM LGC. L’utilisation de ce Type_Code dans le cadre du scénario introduit donc une incohérence entre le type de document attendu et le code utilisé, susceptible de générer les éditeurs.

Ainsi, le Type_Code attendu pour un plan personnalisé de prévention est "83869-8".

Afin de clarifier les attendus, notamment pour les documents intégrés depuis le DMP ou la MSSanté, la formulation « document CDA R2 N3 encapsulé » est remplacée par « document CDA R2 N3 avec une copie du document au format PDF dans la section FR-Document-PDF-copie ».

Cette évolution est uniquement rédactionnelle : le fond et l’objectif de l’exigence restent inchangés. En l'occurrence : Pour l’affichage des métadonnées issues d’un document CDA R2 N3, accompagné d’une copie au format PDF dans la section FR-Document-PDF-copie, le système ne DOIT afficher qu’une seule ligne dans l’espace documentaire.

1. Problématique
La preuve demandée pour l’exigence INS/va1.53 n’est pas adaptée pour le REM LGC, car elle repose sur la fourniture d’un flux HL7 v2, ce qui a du sens dans un contexte hospitalier.
 

2. Objectif de l’exigence
Vérifier la non transmission sous format informatisé du matricule INS et de son OID lorsque l’identité du patient n’est pas qualifiée.
Nous complétons le scénario et les preuves avec la possibilité d’utiliser une arche IHE_XDM
 

3. Scénario applicable
Objectif : Vérifier la non-utilisation du matricule INS (et de l’OID) pour une identité non qualifiée.

Étapes :

1. Disposer d’une identité au statut « identité récupérée ».
2. Produire un document de santé destiné à un échange informatisé ou un message d’interopérabilité IHE PAM contenant une INS non qualifiée.
3. Vérifier que le matricule INS et l’OID ne sont pas utilisés pour référencer le document ou le message.

4. Preuves attendues

Preuve 1 : Démonstration (capture d’écran, vidéo, etc.) montrant l’identité (et son statut) et la donnée de santé produite.

Preuve 2 : Mise à disposition d’une archive IHE_XDM contenant le document de santé ou un message IHE PAM avec une INS non qualifiée.
 

L’étape 4 a pour objectif de préciser le contenu attendu dans la preuve vidéo.

Elle ne correspond pas à une action supplémentaire.

Conformément aux exigences prévues au chapitre 4 des DSR et à la section 4.3 de l’Appel à financement, pour les solutions logicielles pour lesquelles vous souhaitez mobiliser des financements Ségur, la déclaration de l’ensemble des versions techniques ayant fait l’objet d’une information publique auprès de vos clients concernant un arrêt de maintenance et/ou un arrêt de commercialisation est obligatoire.

À cet effet, le fichier modèle de déclaration des versions obsolètes, disponible dans le formulaire d’éligibilité, doit être complété. Dans le cas où aucune version obsolète n’est à déclarer, cette situation devra être explicitement mentionnée dans le fichier dédié. 

Cette démarche est un prérequis obligatoire à l’obtention du financement Ségur vague 2.

Oui, l’API FHIR de l’Annuaire Santé est prévue pour être interrogée à la demande lors de la rédaction du mail.

Aucun champ supplémentaire n’est exigé.
Vous pouvez toutefois proposer des critères additionnels, tels que voie/rue désormais proposé par l’API Annuaire ou la BAL préférentielle qui sera bientôt publiée par l’annuaire mais ceux cités dans l’exigence doivent être présents à minima.

L’interface doit obligatoirement proposer tous les critères suivants : RPPS, nom d’exercice, prénom d’exercice, profession, spécialité, raison sociale, code postal, ville, adresse email MSSanté.

Cette exigence a pu donner lieu à des interprétations différentes quant à son périmètre d’application, notamment en ce qui concerne le moment d’affichage et le niveau auquel la confirmation « j’ai compris » doit être demandée.

Cette confirmation est destinée à l’utilisateur (professionnel de santé) et doit être affichée à la première connexion, puis de manière périodique selon une fréquence paramétrable (par exemple tous les 180 jours). Elle n’a pas vocation à être affichée au niveau du patient ou du dossier patient.

• Quel est l’objectif de l’exigence ?

L’exigence SC.DMP/CONF.21 impose que le système informe chaque professionnel de santé (PS) que son RPPS est utilisé pour la traçabilité nationale et pour le contrôle d’accès au DMP/MES. L’objectif est d’assurer la transparence et de sensibiliser les utilisateurs au bon usage du DMP.

• Quelle information doit obligatoirement être affichée ?

Deux textes doivent apparaître :

• Texte d’information générale :
  « Le logiciel peut effectuer des requêtes de recherche de document au nom de l'utilisateur sur les DMP/MES et permet d'en consulter, sur action manuelle, les documents d'intérêt. Ces interactions sont tracées avec l'identifiant national de l'utilisateur et le patient est notifié de ces interactions. »
• Texte du bouton « j’ai compris » :
  « Toute consultation de ma part d'un DMP/MES pour lequel le patient (ou son représentant légal) n'a pas donné son consentement m'expose à des poursuites. »
   
• À quelle fréquence cette information doit-elle être affichée ?

À la première connexion de l’utilisateur après la mise à jour Ségur, puis à intervalle régulier paramétrable (valeur par défaut : 180 jours).

• Cette demande concerne-t-elle chaque patient ?

Non. Le clic « j’ai compris » ne doit pas être demandé pour chaque patient. La validation est réalisée une seule fois par utilisateur, à la fréquence programmée.

• Obligations pour l’éditeur

• Afficher le texte obligatoire sans modification
• Garantir une fréquence paramétrable (défaut : 180 jours)
• Affichage une seule fois par utilisateur, pas par patient

Oui, un composant "EAI/librairie" non autonome intégré dans le proxy doit passer son agrément au CDNA pour obtenir sa propre homologation.