Votre question concerne quel type d'offre ?
Votre question concerne quel couloir Ségur ?
Votre question concerne quel dispositif Ségur ?
Votre question concerne quel produit ou service produit?
Votre question concerne quelle thématique ?
Non, l'exigence PGSSI-S IEU 2 n'est pas applicable lorsque la solution est esclave de l'identité.
Cette réponse vous a-t-elle été utile ?
Il doit être possible de voir la création ou le résultat de la création d’un patient dans la solution avec son identifiant privé et ses 5 attributs. Il doit être possible aussi de visualiser que ce patient est associé à son INS, même si peut être les étapes du scénario de conformité sont faites en même temps.
Il faudrait donc, s’il n’est pas possible de visualiser la création d’un patient via la GAP, avoir le flux de création permettant de créer le patient et celui pour associer l’INS dans la solution (si différent), puis d’avoir une copie écran d’un compte usager associé à son matricule INS.
NB : Attention à ne pas confondre la création de l'identité (au niveau de la GAP) et la création du compte dans le DMN. Si la solution ne permet pas l'accès à la GAP, cela signifie qu'il ne peut récupérer l'identité.
Cette réponse vous a-t-elle été utile ?
Comme noté à la page 14 du référentiel 1.2.2 : « Le Référentiel d’Interopérabilité et de Sécurité des Dispositifs Médicaux Numériques (DMN) exige une méthode d’authentification des usagers à 2 facteurs. Le Système doit donc implémenter cette méthode d’authentification (exigence IEU 9.1). » Le développement de la double authentification est donc obligatoire pour un DMN s'il y a un accès patient, et c’est une exigence qui sera vérifiée par l’ANS.
Par contre, il est également indiqué : « Pour tenir compte du cas où l’activation de l’authentification des usagers à 2 facteurs diminue l’usage de la solution et entraîne une perte de chance pour l’usager, le fabricant du DMN peut sous sa responsabilité ne pas activer systématiquement l’authentification à deux facteurs. ». Cela signifie que l’activation du double facteur peut ne pas être systématique pour l’ensemble des patients. Ce point est de la responsabilité de l'entreprise du numérique en santé développant le DMN.
Enfin, il est précisé dans le scénario IEU 9.1 : « L'accès du patient à une interface de déclaration simple dans le cadre d'un parcours de télésurveillance n'est pas soumis à ce scenario de conformité et ne nécessite pas d'authentification à deux facteurs systématique. » . Cela signifie que dans le cadre d’une déclaration simple, c’est-à-dire dans le cas où un patient accède à un simple formulaire de saisie de données (hors du DMN), il n’est pas soumis au développement du double facteur.
Cette réponse vous a-t-elle été utile ?
Le référentiel d’identification électronique se borne à faire en sorte que les identifiants utilisés pour les usagers soient des identifiants uniques et sectoriels de préférence. Il n'existe aujourd'hui aucune exigence qui encadre ce cas de figure, même si la qualité de l’identification d’un usager est l’un des principes fondamentaux de la qualité et de la sécurité de sa prise en charge.
Cette réponse vous a-t-elle été utile ?
Dans le cas d'une candidature pour un DMN pour lequel l'implémentation de l'Identité Nationale de Santé est non applicable, la conformité aux exigences IEU 7 et IEU 8 n'est pas obligatoire. Ces deux exigences sont donc "Non applicables".
En cas de non applicabilité, une déclaration sur l'honneur justifiée devra être fournie à la place de la preuve attendue.
Cette réponse vous a-t-elle été utile ?
Vous trouverez ci-dessous, une image d’une boite de vaccin qui vous permettra de répondre à l’exigence ERGO 4 et sur laquelle vous trouverez le numéro de lot, la date d’expiration, le Datamatrix ainsi que le nom du vaccin qui doit ressortir dans votre logiciel.
Cette réponse vous a-t-elle été utile ?
Les éditeurs ayant déjà déposé un dossier pour une solution déjà référencée Ségur dans un autre couloir, devront déposer l’ensemble des pièces pour le(s) nouveau(x) couloir(s) pour lequel ils demandent le référencement. Libre à eux de déposer les mêmes pièces si celles-ci font foi pour les solutions candidates. Par ailleurs l’ANS a travaillé sur des évolutions des modalités de référencement : il sera possible de déposer les preuves et valider les développements par lots fonctionnels et techniques.
Cette réponse vous a-t-elle été utile ?
L’accès par client lourd en CIBA à Pro Santé Connect n’étant pas initialement inclus dans la vague 1 du Ségur, une dérogation a été mise en place. Cette dernière permet de tolérer un accès par client lourd en CIBA à Pro Santé Connect au lieu de l’accès par client lourd via une application native avec renvoi vers navigateur externe attendu et s’applique uniquement à la vague 1 du Ségur.
Le scénario attendu est le suivant :
- Scénario - application native : Accès par client lourd en CIBA
- Vérifie les exigences du référentiel PSC : EX PSC 01, 03, 04, 05, 08, 09, 10, 14, 15, 20, 25, 28, 29, 30, 31
- Prérequis : la vidéo doit être en plein écran :
- Etapes de la vidéo de preuve :
- Afficher la page des CGU du service ou un autre document que l'utilisateur peut consulter facilement avant utilisation du service ayant une page web dédiée accessible via un lien ou un contrat entre l'utilisateur et le service, par contrat peut être entendu un document que l'utilisateur valide en cochant une case
- Parcourir les CGU jusqu'au paragraphe PSC
- Fermer les CGU
- Se rendre sur la zone d'interface utilisateur qui gère la connexion
- Action de lancement de la connexion à PSC
- Authentification par CPS ou eCPS valide
- Affichage de la zone du logiciel indiquant que la connexion est valide
- Se rendre sur la zone d'interface utilisateur qui gère la déconnexion
- Action de lancement de la déconnexion
- Action de lancement de la connexion à PSC
Cette réponse vous a-t-elle été utile ?
Les solutions référencées Ségur Vague 1 doivent couvrir les aspects suivants, entre autres :
- Génération et visualisation du CR-Bio en CDA R2 N3 auto-présentable ainsi qu’en PDF/A-1 et CDA R2 N1 conformément au CI-SIS, avec les informations structurées (INS, analyses en LOINC, commentaires, etc.), ainsi que les analyses éventuellement sous traitées, soit comme un PDF encapsulé à partir du CR Bio reçu par MSSANTÉ du sous-traitant, soit, en respect de la cible, avec une lecture du CDA R2 N3 et/ou du flux HL7 v2 IHE ILW généré par le sous-traitant ;
- Envoi systématique et automatisé au DMP, éventuellement via un connecteur partenaire, au format CDA R2 N3 et PDF en CDA R2 N1 (ce dernier n’étant prévu que pour une période transitoire de 2 ans, avec, au 1er janvier 2024, l’envoi au DMP uniquement du CDA R2 N3), selon le guide d’intégration DMP compatibilité (v2.4.0 ou supérieure), avec possibilité de modification / retrait de documents ;
- Envoi systématique et automatisé par MSSanté éventuellement via un connecteur partenaire, au format CDA R2 N3 et PDF/A-1), vers le patient et les professionnels correspondants, depuis une boîte aux lettres applicative du SGL, avec possibilité d’envoi de correctifs et de compléments, conformément au RGPD ;
- Pour le contexte hospitalier et dans la perspective d’un envoi au DMP et par MSSANTÉ éventuellement géré au travers de connecteurs et/ou du DPI, la capacité de transmettre au DPI les CDA R2 N3 / N1 et les PDF/A-1 via un flux HL7 v2 via des messages ORU/OUL (contexte profil IHE LTW), avec données de masquage et de connexion secrète pour les cas où c’est nécessaire (certaines analyses pour les patientes mineures, consultation d’annonce VIH, etc.) ;
Tous ces éléments sont précisés dans le paragraphe 2.2 du DSR Bio SGL Vague 1 : https://esante.gouv.fr/sites/default/files/media_entity/documents/DSR-BIO-SGL-Va1.pdf
Cette réponse vous a-t-elle été utile ?
L’information de remplacement d’un document reçu par la Messagerie Sécurisée de Santé est portée par l’élément relatedDocument. Cet élément précise l’identifiant du document à remplacer (voir # 3.5.5.23.2 du volet structuration minimale du CI-SIS v1.9).
Cette réponse vous a-t-elle été utile ?
Indépendament du Ségur, transmettre les documents en CDAR2 N1 par MSSanté et au DMP est aujourd'hui un minimum. Toutefois dans le cadre du Ségur, il n'y aura pas de financement en cas de non respect des exigences sur l'usage du CDAR2 N3 + PDF, car ceci est un point fondamental du couloir Biologie Médicale. Par ailleurs, nous rappelons que c'est bien le SGL qui structure le document au format CDAR2N3 et non la PFI qui, si elle est présente, se charge de l'envoi de ce document par MSSanté ou via le DMP.
Cette réponse vous a-t-elle été utile ?
Envoi systématique et automatisé au DMP, éventuellement via un connecteur partenaire, au format CDA R2 N3 et PDF en CDA R2 N1 (ce dernier n’étant prévu que pour une période transitoire de 2 ans, avec, au 1er janvier 2024, l’envoi au DMP uniquement du CDA R2 N3), selon le guide d’intégration DMP compatibilité (v2.4.0 ou supérieure), avec possibilité de modification / retrait de documents.
Cette réponse vous a-t-elle été utile ?
L'AF précise qu'il s'agit de l'envoi d'un message, sans imposer une pièce jointe. L'envoi doit être fait à l'adresse de test "reponse.automatique-test@patient.mssante.fr".
Cette réponse vous a-t-elle été utile ?
Non, les DSR vague 1 n'imposent pas un type d'inferface spécifique avec un opérateur MSSanté.
Cette réponse vous a-t-elle été utile ?
ERRATUM – Pour se référencer aux exigences du référentiel Pro Santé Connect à partir des exigences citées dans les DSR, il faut s’appuyer sur la table de correspondance suivante :
Cette réponse vous a-t-elle été utile ?
La procédure d’obtention du label SI commun MDPH est ouverte à toute personne morale propriétaire d’une solution logicielle destinée aux Maisons Départementales des Personnes Handicapées (MDPH). Celle-ci inclut les MDPH qui développent leurs propres solutions conjointement avec les Conseils Départementaux avec lesquels elles sont liées.
La labellisation est une démarche volontaire. Chaque candidat peut s’engager dans le processus s’il estime que sa solution est conforme aux exigences et au périmètre du référentiel fonctionnel (RF) en vigueur à la date d’octroi du label
Cette réponse vous a-t-elle été utile ?
En règle générale, si un tiers héberge des données de santé pour le compte d’un établissement, celui-ci doit recevoir une certification HDS.
En revanche, si deux entités sont coresponsables, comme c’est le cas pour les GHT, cette obligation peut être levée.
La Direction Générale de l’Offre de Soins (DGOS) requiert un avenant à la convention constitutive du GHT. Il doit préciser “les conditions, les périmètres de traitement des données, et les établissements parties prenantes de la coresponsabilité." Un établissement support qui peut héberger les données santé pour le compte des autres établissements du GHT est alors commissionné.
Sont aussi exclus de l’obligation de recourir à un prestataire agréé ou certifié HDS :
- les organismes d’Assurance Maladie obligatoire et complémentaire dans le cadre de leur activité de prise en charge des frais de santé ; ces organismes manipulent des données de santé mais ils n’en sont pas à l’origine ;
- les organismes de recherche dans le domaine de la santé, si leurs bases de données ne sont pas constituées à des fins de prévention, de diagnostic, de soins ou de suivi social et médico-social ;
- les associations qui proposent des activités sportives à des personnes handicapées.
Les conditions d’exemption sont détaillées dans le référentiel Maturin-H, publié début 2022.
Cette réponse vous a-t-elle été utile ?
Selon votre métier d’hébergement, il existe deux périmètres de certification :
- Mon activité concerne la disposition de locaux d’hébergement physique et d’infrastructure matérielle.
Il vous faut un certificat Hébergeur d’infrastructure physique.
Ce certificat couvre les deux types d’activités (cf image 1) - Mon activité concerne la mise à disposition d’une infrastructure virtuelle, de mise à disposition de plateforme logicielle, d’administration-exploitation et/ou de sauvegarde externalisée.
Il vous faut un certificat Hébergeur infogéreur.
Il comprend 4 types d’activités (cf image 2)
Important : Si votre activité d’hébergeur s’inscrit dans les deux types d’activité, l’hébergeur doit obtenir les deux certifications.
Cette réponse vous a-t-elle été utile ?
Les principales étapes de l’accréditation pour les organismes de certification sont les suivantes :
- Etape 1 : Dossier de candidature
Vous complétez et envoyez le dossier de candidature à l’accréditation HDS auprès du COFRAC ou de l’organisme équivalent au niveau européen. - Etape 2 : Examen du dossier
Le Cofrac vérifier que le dossier de candidature est complet et le cas échéant, conclut un contrat avec l’organisme demandeur. - Etape 3 : Recevabilité technique
Le Cofrac vérifie que les exigences d’accréditation sont respectées.
Durée: entre 1 et 6 mois. - Etape 4 : Autorisation
En cas de décision favorable du Cofrac, la demande d'accréditation est prononcée : vous êtes autorisé à délivrer des certificats HDS pendant 9 mois. - Etape 5 : Mise en œuvre
Vous disposez d’un délai de 9 mois pour finaliser votre accréditation. Le Cofrac réalise une évaluation siège et une observation d’audit sur site. L’accréditation est délivrée pour une durée de 4 ans après l’évaluation siège. - Etape 6 : Renouvellement
Une observation d’audit a lieu tous les ans. Pour les cycles suivants, l’accréditation est délivrée pour une durée de 5 ans avec une évaluation siège et une observation tous les 15 mois.
Cette réponse vous a-t-elle été utile ?
Il existe 6 types d’activités pour lesquelles un hébergeur de données santé peut être certifié :
- la mise à disposition et le maintien en condition opérationnelle des sites physiques permettant d’héberger l’infrastructure matérielle du système d’information utilisé pour le traitement des données de santé ;
- la mise à disposition et le maintien en condition opérationnelle de l’infrastructure matérielle du système d’information utilisé pour le traitement de données de santé ;
- la mise à disposition et le maintien en condition opérationnelle de la plateforme d’hébergement d’applications du système d’information ;
- la mise à disposition et le maintien en condition opérationnelle de l’infrastructure virtuelle du système d’information utilisé pour le traitement des données de santé ;
- l’administration et l’exploitation du système d’information contenant les données de santé ;
- la sauvegarde de données de santé.
Vous pouvez consulter la liste complète des HDS certifiés, avec les activités concernées, sur notre site :
Cette réponse vous a-t-elle été utile ?