Questions fréquentes

Le contenu des traces fonctionnelles attendues est défini par l’exigence SC.MSS/CONF.18.
L’objectif est de permettre un suivi des actions significatives réalisées sur les boîtes aux lettres MSSanté, sans conserver l’intégralité des échanges IMAP/SMTP ni le contenu des messages.

Ainsi, pour chaque boîte aux lettres, il est attendu a minima que les traces permettent de connaître :

• l’identifiant de l’auteur de l’action, dûment authentifié ;
• l’horodatage local du poste au moment de l’action ;
• le type d’action réalisée (consultation, envoi, suppression, etc.) ;
• la demande effectuée sur le serveur de messagerie MSSanté ;
• la réponse fournie par le serveur (y compris en cas d’échec).

Le contenu des messages ne doit en aucun cas être tracé. Le choix du niveau de détail des traces et des traitements suivis est laissé à l’appréciation de l’éditeur, dans la mesure où ces traces visent avant tout à le protéger, notamment en cas de requête judiciaire ou d’incident de sécurité. Il est toutefois attendu a minima que les actions d’envoi et de suppression de messages soient tracées.

Concernant la durée de conservation :

• Comme indiqué au §5 du référentiel #2 MSSanté, une durée de conservation de 6 mois est recommandée pour ces traces fonctionnelles.
• Le responsable de traitement (LPS) reste libre de définir la durée exacte de conservation, en fonction de son analyse de risques et de son cadre réglementaire.
• Les traces doivent être soumises aux mêmes mesures de sécurité et de confidentialité que les données MSSanté auxquelles elles se rattachent (mesures organisationnelles, techniques, etc.).

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.

Oui. Si vous étiez en cours de référencement lors des précédents guichets de référencement MDV sur Wiin.io, notez qu'il n'y a pas de reprise de données entre Wiin.io et Convergence.

La phase de test implique la réalisation de tests en boîte grise, où l'auditeur dispose d'informations préalables, ainsi que la réalisation de compléments en boîte noire, où l'auditeur agit sans informations préalables dans le but de repérer les failles et d'obtenir une évaluation exhaustive de la sécurité de l'application. Cette phase dure en moyenne 3 à 4 jours.

La clause de revoyure permet d'avoir un engagement de la part de l'auditeur pour tester de nouveau les exigences non validées lors du test d'intrusion et d'effectuer un contre-audit afin de vérifier si les mesures de sécurité nécessaires ont été mises en œuvre.

La phase de rapport consiste à la fourniture par l'auditeur du rapport du test d’intrusion en remplissant et en signant électroniquement le formulaire correspondant. Ce document regroupe l’ensemble des résultats du test d’intrusion ainsi que le référencement de l’application.  

Non. La différence principale est :

• 0502 : le dossier patient est vierge. Les données IPS peuvent être intégrées sans risque de conflit.
• 0501 : le dossier contient déjà des données. Il existe un risque de conflit entre données existantes et données issues de l’IPS.

La mention « sans supprimer la donnée existante » vise à éviter un écrasement global du dossier.

Non.

• En cabinet individuel : le professionnel voit uniquement ses statistiques.
• En cabinet de groupe : chaque professionnel voit ses propres statistiques.
• En structure (centre de santé, MSP, etc.) : un niveau structure (FINESS) peut exister et les statistiques sont colligés à la maille du Finess

Il n’est pas demandé de gérer des habilitations complexes.

Non. Ce document concerne uniquement les logiciels qui gèrent des professionnels réalisant des implants (dentistes, sages-femmes, cardiologues, etc.).
Le principe est :

• Si le logiciel produit un PDF de carte d’implant, il doit pouvoir être envoyé au DMP avec le type documentaire adéquate.
• Si le logiciel ne produit pas ce document, il y a une obligation de savoir l’envoyer avec le bon type code en N1.
   

Les codes de lieux de naissance sont historisés côté INSEE. Certaines communes peuvent être fusionnées, disparaître ou être remplacées. L’exigence vise à prendre en compte cette historisation.

Si un code ne peut pas être associé à une commune dans le logiciel , il doit être possible pour le médecin de saisir un libellé manuellement, afin notamment de différencier des patients homonymes.
Pour éviter les échecs d’appel aux téléservices, fréquemment causés par un lieu de naissance incorrect, il est recommandé soit d’identifier rapidement la commune correcte, soit de permettre au médecin de sélectionner « lieu de naissance inconnu » (code 99999). Cette approche permet d’éviter les saisies erronées ainsi que les échecs d’appel aux téléservices.

En termes d’interface, même si le lieu de naissance est inconnu, un champ texte libre doit être disponible afin de permettre au professionnel de renseigner un libellé utile à l’identification du patient.