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.

Pour la commande de certificat, le numéro de FINESS n’est pas obligatoire, vous devez contractualiser avec l’ANS pour ensuite :

• Commander une carte CPx ;
• Demander les habilitations d’administrateur technique (F413), habilitations qui permettent de commander un certificat sur la PFNCG.

L’opérateur, afin d’être en mesure d’obtenir les certificats serveur qui l’authentifieront dans l’Espace de Confiance, doit renseigner son FINESS juridique dans le contrat d'adhésion. Les établissements reliés au FINESS géographique appartiendront à la structure mère enregistrée sous le FINESS juridique.

Ainsi, l'enregistrement du FINESS juridique suffit dans le cas où une structure a plusieurs établissements.

Quelle est la différence entre FINESS juridique et géographique ?

• Le numéro FINESS juridique, qui porte l'immatriculation des entités juridiques (EJ) régissant les établissements sanitaires, sociaux, médico-sociaux, correspond à la notion de personnalité morale et est associé au SIREN de l'entreprise au moment de son enregistrement.
• Le numéro FINESS géographique qui assure l’immatriculation des établissements géographiques (ET) correspond à une implantation géographique et est caractérisé par une et une seule catégorie d’établissement. Chaque numéro FINESS géographique est rattaché à une et une seule entité juridique.
• Cependant, il convient de noter que la logique d’attribution du numéro FINESS géographique diffère de celle du numéro SIRET, et que plusieurs numéros FINESS géographiques peuvent cohabiter au sein d’un même SIRET. En effet, à une même adresse, on peut retrouver plusieurs « établissements géographiques » FINESS (EPHAD, centre de formation, laboratoire, centre hospitalier, …), relevant d’une catégorie d’établissement différente mais appartenant à une même entité juridique.
• Le SIRET porté par le numéro FINESS est celui de l’établissement au moment de son enregistrement et de la parution de l’arrêté lui attribuant son numéro FINESS.
   

Pour l'adresse et le numéro SIRET, il faut contacter l'ARS compétente. 
Pour la raison sociale, cela relève de l'ordre des pharmaciens.

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

Voici un tableau récapitulatif pour mieux comprendre les différences entre les différents identifiants :

Remarque : Depuis octobre 2024, l'identifiant ADELI n'est plus utilisé.

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. 

Le scénario de test DMP/CONF.15.01 permet d'attester que les accès utilisateur pour la consultation de documents de santé depuis la fonction consommatrice DRIMBox sont bien tracés par cette dernière. Le déroulement des différentes étapes de test composant le scénario DMP/CONF.15.01 permet la mise en œuvre d'un tel workflow de consultation. Les éléments de preuve respectivement déposés en DMP/CONF.15.01.01 et DMP/CONF.15.01.02 doivent pouvoir être interprétés conjointement afin d'illustrer le processus de création de traces suite à une action utilisateur de consultation. 

Pour cela, les éléments suivants doivent être illustrés au sein de ces preuves de test : 

• Processus de consultation de documents de santé depuis l'interface utilisateur associée à la fonction consommatrice DRIMBox. 
• Logs logiciel ou traces d'audit correspondant aux actions de consultation effectuées par l'utilisateur. Il est à noter que le contenu de ces logs ou traces doit permettre une mise en correspondance avec les éléments démontrés au point précédent.

Il est important de relever que le prérequis associé au scénario de test DMP/CONF.15.01 qui mentionne : "intégré dans la base locale" ne s'applique pas aux solutions logicielles DRIMBox. En effet, étant donné qu'aucune exigence n'impose l'hébergement de documents de santé au sein d'une base locale, seule la consultation de documents de santé depuis le DMP doit être considérée afin de dérouler ce scénario de test pour une solution DRIMBox.

Les étapes n°1 à n°4 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é (création + suppression). Afin de démontrer la capacité de la fonction source DRIMBox à assurer le workflow correspondant aux étapes n°1 à n°4, la 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 (ajout/suppression 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, afin de faire une mise en correspondance avec le workflow d'alimentation.

L'étape n°5 du scénario de test doit être effectuée en impliquant la fonction consommatrice associée à la solution logicielle DRIMBox. Le déroulement de cette étape de test implique une tentative d'accès (appel contextuel) à la fonction consommatrice DRIMBox pour un patient non consentant à la consultation de son DMP. La ou les preuves déposées afin d'attester du déroulement de l'étape n°5 doivent illustrer cette tentative de consultation ainsi que l'échec qui en résulte.