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.

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.

La « fenêtre d’interrogation » ne désigne pas nécessairement une interface dédiée. Elle correspond à l’endroit où l’utilisateur peut modifier les traits d’identité utilisés pour l’appel au téléservice INSi.

Cette modification peut être réalisée :

• soit via une fenêtre dédiée,

• soit directement dans la fiche d’identité du patient.

L’exigence est satisfaite dès lors que l’utilisateur peut modifier les traits (notamment le COG) et relancer l’interrogation, indépendamment du choix ergonomique du logiciel.