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.

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.

Il vise à :

• signaler au pharmacien la nécessité d’une délivrance prioritaire,
• permettre une anticipation (commande, mise à disposition rapide),
• refléter un besoin métier réel (antibiothérapie, morphiniques, etc.).

Même si l’usage n’est pas systématique, le champ répond à une logique opérationnelle.

Oui.
Les éditeurs peuvent utiliser les catégories proposées (par exemple : synthèses, comptes rendus), ou définir leurs propres catégories métier.
Par exemple, il est possible de créer une catégorie « santé de l’enfant » regroupant des comptes rendus, des vaccinations et d’autres documents pédiatriques.
Ces catégories n’ont pas vocation à correspondre strictement aux catégories du jeu de valeurs 66. Les regroupements peuvent également être réalisés selon d’autres critères, tels que les métadonnées, l’origine du document ou le type d’établissement.

Aucune modalité n’est imposée. Les éditeurs restent libres quant au moment, à la méthode et à l’interface de comparaison.
Dans certains cas, les analyses ne sont pas directement comparables (par exemple la TSH selon le réactif utilisé). Si le logiciel affiche ces analyses sur une même courbe, il doit simplement indiquer, via un avertissement, que les valeurs peuvent ne pas être directement comparables.

Deux régimes distincts s’appliquent à l’alimentation du DMP.

Dans le fonctionnement par défaut, le patient est informé et dispose d’un droit d’opposition (impliquant une action supplémentaire avec un clic de sa part). En l’absence d’opposition, l’alimentation du DMP peut être réalisée.

En revanche, la consultation du DMP nécessite un consentement explicite du patient, car elle implique l’accès à des données. Une notification est alors envoyée au patient lorsqu’un professionnel de santé consulte son espace santé.
 

Cette exigence traite principalement des difficultés liées aux prénoms composés.

Par exemple, pour le prénom « Jean Christophe Pierre », plusieurs combinaisons peuvent être envisagées : Jean, Jean-Christophe, Christophe, Jean Christophe ou encore Jean-Christophe Pierre.

L’objectif est que le logiciel propose des combinaisons plausibles, afin de permettre au professionnel de corriger l’interprétation du premier prénom.

Ce cas est précisé dans les commentaires de l’exigence (colonne G du référentiel).

À noter que les situations comportant trois prénoms composés sont rares, mais doivent néanmoins pouvoir être gérées.

Non.

Deux stratégies sont possibles : soit une vérification en masse, réalisée de manière périodique, soit une vérification déclenchée lors d’un événement système (par exemple à l’ouverture du dossier). Si une vérification périodique est déjà mise en œuvre, cela permet de satisfaire l’exigence.

Les deux exigences se distinguent toutefois par leur périmètre. L’exigence SC.INS.13 concerne les INS qualifiées depuis plus de quatre ans, tandis que SC.INS.15 concerne les NIA, avec une vérification attendue au minimum tous les ans.

L’exigence mentionne un événement système, mais le scénario précise la règle d’une vérification annuelle minimale pour les NIA. Un éditeur peut toutefois effectuer ces vérifications plus fréquemment sans difficulté.

Il s’agit d’un "ou" : l’éditeur peut choisir l’un ou l’autre mécanisme.

Oui. Dans ce contexte, le matricule INS saisi correspond au NIR saisi.

L’objectif est de vérifier la cohérence entre le NIR, la date de naissance et le sexe. Cette vérification permet de s’assurer que le message est envoyé au bon patient, notamment lorsque le NIR utilisé est celui d’un ayant droit (par exemple pour la facturation).

Sur le plan fonctionnel, si le NIR est cohérent avec la date de naissance et le sexe, le système peut proposer l’envoi du message. En revanche, en cas d’incohérence, le système doit alerter l’utilisateur et empêcher l’envoi.

Seul le statut à la fin de la période est attendu.

Par exemple, pour l’année 2025, on considère la situation au 31 décembre 2025 à 23h59. Les changements de statut intervenus au cours de l’année ne doivent pas être comptabilisés séparément.

L’objectif est de simplifier le calcul et de refléter l’état final des identités.