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

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.

Par suppression, on entend l'accès au document qui n'existe plus : ce document n’est pas ou plus accessible à l’utilisateur car il peut avoir été supprimé, masqué, ou que le PS n'est pas habilité.

Dans tous les cas, il faut l’indiquer à l’utilisateur et celui-ci doit toujours avoir la capacité de le supprimer

Oui, il est possible de combiner certains critères, selon leur pertinence. Il n’est pas obligatoire de pouvoir interroger individuellement tous les critères listés dans l’exigence.

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é.

Si l’épisode de soins se poursuit, la transaction TD03 peut être renouvelée automatiquement par le logiciel, sans action explicite du professionnel ni du patient.

Cette tolérance a été précisée dans le guide d’intégration DMP, afin de ne pas introduire une contrainte métier irréaliste.

Les codes 00 / 01 / 02 sont suffisants. Il n’est pas nécessaire de les traduire en OK / KO.

Oui. L’exigence SC.PSC.01 est une exigence générale du référentiel et doit être respectée par l’ensemble des éditeurs. Elle impose la capacité d’intégration de Pro Santé Connect via un navigateur externe, reposant sur un Authorization Code Flow.
L’exigence SC.PSC.13 (profil CIBA) introduit une modalité complémentaire spécifique aux clients lourds, permettant une authentification sans recours au navigateur (via eCPS ou carte CPS).

Ainsi, un éditeur ayant choisi le profil CIBA doit :

• Implémenter le mode CIBA (SC.PSC.13) ; 
• Et maintenir la capacité d’authentification via navigateur externe (SC.PSC.01).

Ces deux modalités ne sont donc pas exclusives dans le cadre actuel des référentiels, même si cela peut soulever des questions de cohérence ou de simplification.