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

Les habilitations sont détaillées dans le paragraphe « 2.3 Habilitations » du Manuel Utilisateur ESMS https://trajectoire.sante-ra.fr/trajectoire/docs/AccesRestreint/ManuelUtilisateurESMS.pdf.

Les statuts sont utilisés pour suivre le traitement de la demande d’un usager dans ViaTrajectoire. Ils sont listés dans le paragraphe « 6.2 Filtrage des décisions d’orientation à afficher » du Manuel Utilisateur MDPH : https://trajectest.sante-ra.fr/trajectoire/docs/AccesRestreint/ManuelUtilisateurMDPH.pdf.

Il est nécessaire de disposer d’un certificat IGC Santé valide, de mettre en place les ressources CDA utilisées (Flux 1 et 3), de développer les échanges FHIR (Flux 1 à 5) et de vérifier les développements avec les validateurs Gazelle sur la plateforme EVSClient. 

L’accès au bac à sable se fait via une demande auprès du GCS Sara, qui édite et opère le service ViaTrajectoire.

Cette demande doit être effectuée en complétant le formulaire disponible à l’adresse suivante : https://esante.gouv.fr/sites/default/files/media/document/VTPH_Segur_Demander-Acces-aux-Environnements-VT.docx, puis en le transmettant au GCS Sara via le formulaire de contact disponible depuis votre Espace Authentifié du Portail de la e-santé pour les Entreprises du Numérique en Santé (https://esante.gouv.fr/ens | https://isconnect.esante.gouv.fr/enrollement/account/login/).

Les modalités d’accès à l’environnement de test et les URL sont communiquées en réponse à cette demande. 

Les spécifications fonctionnelles et techniques des échanges se trouvent ici https://esante.gouv.fr/volet-si-esms-viatrajectoire-module-ph.

En complément, vous pouvez trouver le guide d’implémentation fonctionnelle à l’adresse https://esante.gouv.fr/sites/default/files/media/document/VTPH_Guide-implementation.pdf et la spécification d’authentification via ce lien : https://esante.gouv.fr/sites/default/files/media/document/SPF_SISDO_ViaTrajectoire_Authentification_v1.2.pdf.

Vous pouvez également consulter la page dédiée sur le Portail de la e-santé pour les Entreprises du Numérique en Santé https://esante.gouv.fr/ens/offre/interoperabilite-viatrajectoire-module-handicap.

En vertu du RGPD vous devez déjà tracer l’accès aux données de santé à caractère personnel. Le fait de rajouter l’INS à ces données de santé à caractère personnel ne change rien. Il sera simplement vérifié que cette traçabilité est faite. Cette exigence sera vérifiée en s'assurant que lorsqu'un acteur accède au dossier d'un usager - doté ou non d'une INS (ouvre le dossier de cet usager) - cet accès est tracé dans la solution.

L’exigence SC.MSS/va1.15 telle que définie historiquement dans le référentiel client de messagerie MSSanté est erronée depuis sa publication. Elle décrit un mécanisme d’accusé de réception non conforme aux normes RFC. Cette anomalie est présente dans les référentiels de la vague 1 et reprise dans certains REM de la vague 2. Sur le terrain, les éditeurs ont majoritairement implémenté les accusés de réception conformément à la norme RFC.

L’exigence SC.MSS/va1.15 évolue pour s'aligner sur le mécanisme DSN normalisé afin de garantir la bonne émission et réception des accusés de réception par les solutions MSSanté.

La nouvelle version de l'exigences est la suivante : 
Le système DOIT permettre de demander un accusé de réception de type DSN lors de l'émission d'un courrier. Lors de l'envoi du message, le paramètre NOTIFY doit être positionné avec les valeurs SUCCESS,FAILURE,DELAY dans la commande SMTP "RCPT TO:"
Le mécanisme DSN est décrit dans la RFC 3461.
Exemple : RCPT TO: <adresse email> NOTIFY=SUCCESS,FAILURE,DELAY

Les nouveaux scénarios et preuves sont également mis à jour : 

Scénario - Accusé de réception par l'opérateur destinataire
Etapes :

1. Préparer un courriel.
2. Choisir l'option qui permet d'avoir un accusé de réception de type DSN.
3. Envoyer le message.

Preuves : 

• Preuve 1 : Produire des copies d’écran : du courriel envoyé afin de valider la preuve.
• Preuve 2 : Produire des copies d’écran : de l’accusé de réception reçu suite à l’envoi du courriel émis.

Dans le cas d'un cabinet d'imagerie identifié par un RPPS-rang, en l'absence de BAL applicative proposée par l'opérateur MSSanté de la structure, le renvoi des courriers de la BAL perso / orga vers la BAL applicative n'est pas applicable.

Dans ce cas, c'est la BAL organisationnelle ou personnelle du médecin auquel le RIS devra accéder directement (selon les exigences MSS/CONF.07, MSS/CONF.10, MSS/CONF.11 et MSS/CONF.28 du REM RIS vague 2) pour récupérer les documents reçus et, lorsque l'INS est qualifié, les intégrer automatiquement dans le dossier patient correspondant (selon l'éxigence SC.MSS/UX.07 du REM RIS vague 2).

Dans un contexte de consommation entre une solution DRIMBox et l'environnement DMP, il est pertinent d'afficher le statut associé aux objets KOS et aux CR d'imagerie récupérés. 

Cette nécessité d'afficher le statut des documents obtenus est d’ailleurs portée dans le Guide d’Intégration DMP afin de garantir une cohérence fonctionnelle avec les autres logiciels homologués.

Même si le statut "Approved" est le plus fréquemment rencontré, il reste important de proposer cet affichage au Professionnel de Santé utilisateur de la solution DRIMbox. Cela lui permet de visualiser l’historique des documents précédemment publiés dans le DMP, de comprendre les raisons ayant conduit à la publication de nouvelles versions, et d’identifier à quel moment et par quel acteur ces mises à jour ont été réalisées.

Il est également précisé dans le Guide d’intégration DMP que la récupération et l’affichage des documents comportant un statut "Archived" ou "Deprecated" peut être proposé via une case à cocher. Ce mécanisme permet de préserver un affichage nominal clair en évitant toute confusion pour l’utilisateur (référence EX_3.1‑1030).

Le processus d’alimentation de documents KOS auprès de l'environnement DMP est effectué automatiquement, via une authentification indirecte, à partir de la fonction source DRIMBox.
La solution logicielle DRIMbox est donc être considérée comme l'entité responsable de l'action d'alimentation.

Par conséquent, pour le niveau "fiche" XDS, il convient de renseigner la métadonnée "author" avec une valeur correspondant au système DRIMBox. Ainsi, la métadonnée XDS "authorperson" au niveau "fiche" doit contenir à minima une structuration des balises tel que défini dans la section 2.4.8 du volet CI-SIS "Références d’Objets d’un Examen d’Imagerie", la métadonnée authorPerson va contenir l'identifiant de la structure qui alimente le DMP, elle-même récupéré depuis le header du CR d'Imagerie.

A noter qu'il est possible d'ajouter optionnellement un author complémentaire à la fiche.

La métadonnée XDS "legalAuthenticator", au niveau "fiche", doit quant à elle correspondre à un professionnel de santé. La valeur mentionnée pour la métadonnée XDS "legalAuthenticator" représente la personne physique (professionnel de santé) responsable de la validation du compte-rendu d'imagerie ayant engendré la création et la publication du document KOS. 
Pour plus de précisions concernant la valeur à associer aux métadonnées XDS "author" et "legalAuthenticator" au niveau "fiche", se référer à la section 2.4.8 du volet CI-SIS "Références d’Objets d’un Examen d’Imagerie".