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

Le formulaire et le contenu du test d'intrusion logiciel sont identiques pour les exigences SC.SSI/GEN.18 et SC.PSC.14. Par conséquent, vous ne devrez réaliser qu'un seul test d'intrusion, valable pour tous les profils. Il faudra toutefois fournir le rapport PDF du test en preuve pour chacune des exigences, y compris SC.SSI/GEN.18 pour le profil AHI.

L’exigence SC.SSI/GEN.18 s’applique spécifiquement au profil AHI, car ce dernier n’est pas concerné par le guichet EDC PSC de l’ANS, et donc n’a pas à satisfaire l’exigence SC.PSC.14 qui porte le test d’intrusion logiciel.

Ainsi, le test d’intrusion logiciel, nécessaire pour garantir un niveau minimal de sécurité, est bien requis pour tous les profils :

• À travers SC.SSI/GEN.18 pour le profil AHI ;
• À travers l'exigence SC.PSC.14 pour tous les autres profils du dispositif MS DUI Vague 2.

C'est un scénario nominal possible si les fichiers d'attente ne sont pas synchronisés au sein du logiciel. Si cette situation se produit :

• Côté DMP : La V2 sera stockée (comme version initiale ou de remplacement selon le choix fait à la Question 1).
• Côté MSSanté : Le destinataire ayant reçu la V1, l'émetteur DOIT obligatoirement renvoyer la V2 par MSSanté (selon le principe du "Annule et remplace" exigé en vague 1) afin de garantir que le correspondant dispose de la même information médicale que celle présente sur le DMP du patient.
   

Note : Les éditeurs sont encouragés, dans la mesure du possible, à synchroniser leurs files d'attente DMP et MSSanté pour éviter ces écarts.

Si le DMP n'a jamais reçu la version initiale (V1), toute tentative d'envoi d'une V2 contenant une métadonnée de remplacement (RPLC ou lien vers l'identifiant de la V1) sera refusée par le DMP, car le document à remplacer est inconnu de ses services. Dans ce scénario, le logiciel a deux options, la première étant fortement recommandée :

1. Option privilégiée : Envoyer directement la version finale (V2) au DMP en tant que document initial (V1 pour le DMP). Les modifications intermédiaires restent purement locales au logiciel métier.
2. Option secondaire : Envoyer de manière séquentielle la V1, puis la V2 avec sa requête de remplacement (génère un trafic technique peu utile).

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.