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

Dans l’outil IGC, l’administrateur technique peut gérer l’ensemble de ses certificats depuis la page « suivi des certificats ». Il a notamment accès à la date de fin de validité de l'ensemble des certificats du parc géré.

Le Code officiel géographique (COG) utilisé est bien issu des fichiers officiels INSEE. Certains cas de tests incluent des communes supprimées pour illustrer des cas réels d’historique administratif. 

Si l’éditeur constitue une base locale des COG, il doit impérativement l’alimenter et la maintenir à jour à partir de l’ensemble des fichiers disponibles sur le site de l’INSEE (communes actuelles, événements, COG complet).

Le représentant légal de la structure concernée par le certificat peut déléguer tout ou une partie de la gestion de ses certificats à un tiers, via le portail meshabilitation. La délégation de la commande et l'installation des certificats au fournisseur sont comprises dans les prestations Ségur.

Non, cela n'est pas interdit. Toutefois dans le cadre des échanges automatisés décrits dans les exigences, seuls sont concernés les CDA.

Conformément aux indications formulées au sein du référentiel Espace de Confiance ProSantéConnect ainsi que du volet CI-SIS relatif aux API ProSantéConnect, une connexion mTLS est exigée entre le proxy e-santé et l'environnement ProSantéConnect. En complément, cette connexion mTLS doit être mise en œuvre dans le cadre d'une authentification OAuth 2.0 et conformément au référentiel RFC 8705. 

En conséquence, il n'est pas nécessaire de mettre en oeuvre l'utilisation d'un "client_secret". Cette indication s'applique également dans le cadre des interactions entre le proxy e-santé et les APIs ProSantéConnect (API PSC DMP notamment). 

Il est important de noter que la ou les clés privées associées au(x) certificat(s) client mis en œuvre dans le cadre de la connexion mTLS mentionnée ci-dessus doivent être archivées au sein d'un keystore sécurisé implémenté directement sur le proxy e-santé.

Il n'est pas obligatoire d'être opérateur MSSanté pour répondre aux exigences. Il faut néanmoins pouvoir prouver la capacité à pouvoir émettre un message au format demandé par le DSR et qui pourra être reconnu par un opérateur MSSanté.

Le DPI peut envoyer automatiquement les CR Biologie médicale vers l'extérieur sans intervention du clinicien. Toutefois, 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é)

Non, un distributeur n'a aucune action à réaliser pour le référencement de la solution. Le référencement de la solution est pris en charge par l'éditeur de la solution. Ce dernier doit déclarer ses distributeurs dans le dossier administratif du référencement Ségur. Un mandat de distribution devra également être fourni à l'ASP par le distributeur au moment de l'enrôlement au guichet ASP.

Suite à la publication du décret du 8 octobre 2019, l’utilisation de l’Identité Nationale de Santé (INS) pour référencer les données de santé est obligatoire depuis le 1er janvier 2021 pour tous les logiciels, systèmes PACS compris.
Au sein du référentiel INS, l'ANS précise donc que, d'après les articles R. 1111-8-1 à R. 1111-8-7 du Code de la Santé Publique,  le numéro d'inscription au répertoire national d'identification des personnes physiques (dit « NIR » ou numéro de sécurité sociale) constitue désormais l'identifiant national dans les champs de la santé et du médico-social.
Les systèmes PACS doivent donc être en mesure de récupérer, de stocker et de transmettre le matricule INS au travers des échanges de données d'imagerie auxquels ils participent, en plus des autres traits stricts d'identités constituant l'Identité Nationale de Santé, le matricule seul n'étant pas suffisant pour différencier l'identité :
* Nom de naissance
* Premier prénom de naissance
* Date de naissance
* Sexe
* Code INSEE du lieu de naissance
Par ailleurs, il est également nécessaire de prendre en compte les traits d'identité complémentaires afin que le système PACS puisse se conformer au référentiel d'identitovigilance :
* Nom utilisé : nom utilisé par l’usager dans la vie courante, enregistré obligatoirement lorsque différent du nom de naissance
* Prénom utilisé : prénom utilisé par l’usager dans la vie courante, enregistré obligatoirement lorsque différent du premier prénom de naissance
Il est à noter que les interactions entre la DRIMbox et le(s) PACS, les requêtes ne sont pas basées sur l'INS mais sur le StudyInstanceUID, cela permet à la DRIMbox d'être déployée même si le PACS n'est pas encore INS compatible

Dans le cadre du processus de consultation de documents KOS par la fonction consommatrice d'un logiciel DRIMBox, tel que défini au sein de la spécification projet DRIMBox, le premier acteur impliqué est le LPS initiant une requête d’appel contextuel. Dans ce cadre, le LPS est responsable de la qualification de l’intégralité des traits INS en amont de la construction de la requête d’appel contextuel émise à destination du logiciel DRIMBox. Ainsi, les traits d'identité INS qui sont réceptionnés par le logiciel DRIMBox peuvent être considérés comme « fiables ». 
A partir du contenu associé à la requête d'appel contextuel reçue, la fonction consommatrice du logiciel DRIMBox est en mesure d’interroger l'environnement DMP afin de déterminer quels documents d’intérêt doivent être présentés à l’utilisateur au sein de son IHM (Cf. transaction TD3.1 définie au sein du Guide d'Intégration DMP). 
A l'issue de cette première interaction avec l'environnement DMP, le logiciel DRIMBox récupère un certain nombre de métadonnées associées au contexte de publication du document d’intérêt. C’est uniquement à partir de cette étape que l'interface de consultation du logiciel DRIMBox peut être constituée (pour plus de précisions, se référer à l'exigence DB.CO.54 de la spécification projet DRIMBox). 
Les métadonnées récupérées par la fonction consommatrice du logiciel DRIMBox auprès de l'environnement DMP peuvent elles-mêmes être considérées comme « fiables » car résultant d’un contexte de publication du document KOS construit à partir de l’analyse d’un compte-rendu d’imagerie, lui-même issu d’une demande d’acte d’imagerie remplie par un professionnel de santé.
Ainsi, l’ensemble du processus aboutissant à l’affichage des informations au sein de l’IHM de la DRIMBox consommatrice permet de conserver une cohérence avec celles saisies initialement lors de la planification de l’examen d’imagerie du patient.