Le blocage de l’alimentation du DMP doit être unitaire et choisi par l’utilisateur.
L’utilisateur DOIT effectuer une action pour NE PAS ENVOYER dans le DMP (ex : case à cocher, bouton-radio…).
Cette action DOIT être effectuée pour CHAQUE document qu’il souhaite retenir.
Ce comportement DOIT être par défaut et DOIT être immuable : il NE DOIT PAS être configurable ou débrayable par l’utilisateur.

La transmission de données patient via MSSanté n'implique pas de disposer d'une identité INS qualifiée. Dans le cas ou l'INS du patient n'est pas qualifiée, le document transmis ne doit pas contenir l'INS et OID.

L'INS doit être utilisée pour référencer les données de santé produites dans la cadre de la prise en charge sanitaire ou le suivi médico-social de la personne. Seuls les acteurs de la santé et du médico-social concourant à la prise en charge de l’usager, au suivi médico-social de la personne, ou menant des actions de prévention sont tenus d’utiliser l'INS. Il convient donc de s'assurer que les documents respectent bien ce cadre et sont porteurs de l'INS.

A noter : les documents réalisés à des fins de facturation, destinés à des organismes de sécurité sociale ou à des organismes d'Assurance Maladie complémentaire ne doivent pas contenir l'INS.

Vous devez demander le raccordement à Pro Santé Connect en remplissant le formulaire dédié, disponible ici.

Il convient de se référer à la matrice des droits fonctionnels du SI-DMP, dans laquelle sont indiquées les différentes habilitations concernant les transactions associées à la TD3.3 (gestion des attributs des documents).

Le professionnel de santé étant identifié dans l’entête du CDA : identifiant national de PS dans les Métadonnées authorPerson et legalAuthenticator.

Non, les données provenant de l'annuaire santé ne sont pas modifiables. De fait, si une modification de la fiche utilisateur a lieu, il faut alors vérifier que les données entrées manuellement ne viennent pas en contradiction avec les informations de l'annuaire santé.

Néanmoins, il est bien sûr possible d’ajouter (et non pas remplacer) sur la fiche utilisateur des éléments qui ne sont pas dans l'annuaire.

Oui, l'envoi de tous les documents produits dans le cadre du Ségur du numérique en santé est systématique et automatique. Cette fonctionnalité doit être paramétrée par défaut (permettant ainsi d'atteindre les objectifs d'usage pour la ROSP des médecins = avenant 9).
Néanmoins, la fonction doit être désactivable, au cas par cas, pour les patients ne souhaitant pas l'envoi systématique de leurs documents dans leur espace santé.
Par ailleurs, pour certains documents (CR de biologie, par exemple)  il est important de bien définir la visibilité du document par le patient et les autres intervenants de la prise en charge, dans le cas où une consultation d'annonce est nécessaire. (Masquer le document dans le DMP, ne pas envoyer automatiquement le document par MSSanté)

L'exigence traite principalement du cas des messages envoyés depuis des BAL applicatives, mais la modification de l'adresse de retour est possible pour tout type de BAL. Si vous ne gérez que des BAL personnelles et n'implémentez pas d'adresse de retour, vous devez le mentionner dans la réponse au cas de test.

Non, l’ordre d’affichage des traits n’est pas une exigence. Néanmoins, il convient de respecter l’exigence SI 11 du RNIV : « Les traits d’identités affichés conformément à la réglementation doivent pouvoir être facilement distingués, sans risque d’équivoque, par les acteurs concernés ». 

Il faudra à minima que l’INS apparaisse au moins 1 fois sur le document.

D'après les textes relatifs à l'INS, l'édition du datamatrix INS est nécessaire puisque le code associé à la prescription ne reprend pas l'INS à date. 
En revanche, la mise en oeuvre du datamatrix INS n'est pas demandée dans les DSR et donc ne sera pas vérifiée dans le cadre de la vérification de conformité au Ségur du numérique en santé. 

Non, cette vérification "en masse" n’est pas exigée dans le cadre des DSR Vague 1. Les textes exigent néanmoins que les INS présentes dans une base de données soient vérifiées a minima tous les 5 ans. Votre solution doit donc permettre à vos clients d'assurer une vérification de leur base d'INS dans ce délai.

Non, il n’est pas demandé que le logiciel référencé affiche le numéro unique de référencement. En revanche, les noms commerciaux et versions affichés par le logiciel doivent permettre la vérification aisée par l’acheteur du bon référencement de la solution sur le site officiel de l’ANS.

L'éditeur doit à minima préciser les éléments suivants :

• pour quelle raison des pièces d’identité sont-elles stockées et dans quel(s) cas un accès ultérieur à ces documents est-il prévu ?
• les principes du RGPD sont-ils appliqués (protection des données stockées, information du patient, etc.) ?
• algorithme de chiffrement utilisé et taille des clés,
• modalités de gestion de la durée de conservation,
• précisions sur la "gestion des secrets" :
  • de quelle façon les clés de chiffrement sont-elles générées ?
  • de quelle façon les clés de chiffrement sont-elles protégées ?
  • qui peut y accéder ?
  • comment sont-elles gérées dans le temps ?
  • comment s’exécute le processus de déchiffrement d’un document préalablement chiffré lorsque celui-ci est nécessaire ?

Oui la pièce justificative ayant été utilisée pour s’assurer de la cohérence entre l’identité physique et numérique doit être sélectionnée.
Néanmoins un utilisateur n’est pas obligé de scanner et d’insérer dans son SI la pièce justificative lui ayant permis de valider / qualifier l’identité.
Pour rappel, le statut validé peut-être attribué de deux manières :

1. l'utilisateur peut manuellement indiquer que l'identité est validée.
2. le statut validé peut automatiquement être déduit en fonction de la nature de la pièce justificative sélectionnée.

A noter : la solution doit obligatoirement proposer la première option. Si la seconde option est proposée, celle-ci doit être désactivable.

La documentation doit a minima aborder les points suivants : algorithme de chiffrement et tailles des clés, gestion de la durée de conservation et traitement de suppression, gestion des clés de chiffrement (génération, protection des clés, restriction des droits d’accès aux clés, processus de déchiffrement).
Cette réponse s'applique aux profils de stockage des pièces d'identités des DSR RI, SLG, RIS, LGC, MS.
Cette exigence se réfère à la règle n°19 du guide d'implémentation INS.

Profil général : dans le cadre de la procédure de vérification de conformité Ségur est vérifiée la capacité des solutions LGC (profil général) à appeler l'opération de recherche d'INSi par carte vitale et par traits et l'opération de vérification unitaire d'INSi, a minima, grâce à une identification électronique de type CPx.

Profil centres de santé : dans le cadre de la procédure de vérification de conformité Ségur est vérifiée la capacité des solutions LGC (profil centres de santé) à appeler l'opération de recherche d'INSi par carte vitale et par traits et l'opération de vérification unitaire d'INSi grâce à une identification électronique de type CPx et certificat logiciel.

En vertu du RGPD vous devez déjà tracer l’accès aux données de santé à caractère personnel. Le fait de rajouter l’INS à ces données de santé à caractère personnel ne change rien. Il sera simplement vérifié que cette traçabilité est faite. Cette exigence sera vérifiée en s'assurant que lorsqu'un acteur accède au dossier d'un usager - doté ou non d'une INS (ouvre le dossier de cet usager) - cet accès est tracé dans la solution.