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

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

En prérequis de ce scénario de test, il est demandé à ce que cinq documents soient publiés sur le DMP ciblé. Parmi ces documents, les contraintes implicites suivantes doivent s'appliquer :

• Un des cinq documents doit être visible au patient ou aux responsables légaux du patient.
• Un des cinq documents doit être non masqué aux professionnels de santé. 

L'étape n°1 du scénario de test consiste en une indication relative aux preuves de test à fournir. En effet, l'ensemble des éléments de preuve déposés doivent faire figurer une mention permettant d'identifier l'utilisateur. Cette information pourra être utilisée dans le cadre d'une analyse croisée des différents éléments de preuve fournis. 

Les étapes n°2 à n°5 du scénario de test doivent être effectuées en impliquant la fonction source associée à la solution logicielle DRIMBox. Au travers de ces étapes de test, il est attendu qu'un workflow de gestion du cycle de vie d'un document KOS puisse être démontré (remplacement + suppression + masquage + invisibilisation). Afin de démontrer la capacité de la fonction source DRIMBox à assurer le workflow correspondant aux étapes n°2 à n°5, le ou les éléments de preuve déposés doivent illustrer les aspects suivants : 

• Déroulement de bout en bout du workflow de gestion du cycle de vie d'un document KOS, depuis l'envoi d'un message HL7v2 jusqu'à l'impact sur le DMP (remplacement/suppression/masquage/invisibilisation d'un document).
• Opérations effectuées par la fonction source associée à la solution logicielle DRIMBox. Etant donné que la fonction source DRIMBox ne dispose pas d'interface utilisateur, cet aspect de la preuve peut être attesté au travers de la mise à disposition de traces d'audit ou logs logiciels. 

L'étape n°6 du scénario de test implique l'utilisation de la fonction consommatrice DRIMBox afin de permettre à un utilisateur de visualiser un document préalablement publié sur le DMP. Les preuves déposées afin d'attester du déroulement de l'étape n°6 doivent illustrer à la fois le processus de consultation d'un document de santé depuis l'interface de la fonction consommatrice DRIMBox ainsi que les traces ou logs attestant des actions de consultation effectuées par l'utilisateur. 

Après obtention du plein exercice, l'inscription à l'ordre est obligatoire.
Le professionnel est alors enregistré dans le RPPS comme professionnel pleinement reconnu, avec conservation de son numéro RPPS.
L'employeur ou employé doit fermer l'activité PADHUE dans le Portail RPPS+.
L’inscription à l’ordre doit être réalisée par le professionnel.