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

Dans le cadre d'une dépublication d'un document KOS (suite à une dépublication du compte-rendu d'imagerie associé ou d'une suppression de l'examen d'imagerie référencé), le lot de soumission correspondant doit être construit par le logiciel DRIMBox à partir du contenu de l'archive locale correspondant aux précédentes étapes du cycle de vie dudit document KOS.

La spécification projet DRIMBox mentionne un ensemble d'éléments de filtrage devant être implémentés de manière obligatoire par les logiciels DRIMBox dans le cadre de la consultation de documents KOS, suite à leur récupération auprès de l'environnement DMP (pour plus de précisions, se référer à la section 4.6.2 du document). Trois critères de filtrage doivent à minima pouvoir être exploités par l'utilisateur : Modalité d'acquisition de l'examen ; Date d'acquisition de l'examen ; Région anatomique ciblée. 
En complément, le Guide d'Intégration DMP indique que le logiciel DRIMBox doit également proposer les éléments de filtrage suivants (pour plus de précisions, se référer aux exigences EX_3.1-1012, EX_3.1-1020, EX_3.1-1030) : Visibilité du document ; Date de publication du document ; Historique depuis la dernière connexion d’un professionnel de santé au DMP du patient.

Conformément au Guide d'Intégration DMP, il est nécessaire que le logiciel DRIMBox soit en mesure de s'identifier (via le jeton VIHF et le contenu du lot de soumission) et de s'authentifier (via le certificat de signature du lot de soumission) auprès de l'environnement DMP dans un contexte d'alimentation.

Trois modes d'authentification/identification sont ainsi envisageables : 
* Mode EJ : Utilisation du FINESS de l'entité juridique associée à la DRIMBox dans le cadre de l'identification. Utilisation du certificat de l'entité juridique associée à la DRIMBox dans le cadre de l'authentification. L'implémentation du mode EJ au sein du logiciel DRIMBox est cependant fortement déconseillée par le Guide d'Intégration DMP, car celui-ci sera à terme désactivé. 
* Mode EG : Utilisation du FINESS de l'entité géographique associée à la DRIMBox dans le cadre de l'identification. Utilisation du certificat de l'entité géographique associée à la DRIMBox dans le cadre de l'authentification.
* Mode EJ/EG : Utilisation du FINESS de l'entité géographique associée à la DRIMBox au sein des lots de soumissions envoyés à l'environnement DMP. Utilisation du FINESS de l'entité géographique ou juridique associée à la DRIMBox au sein des jetons VIHF transmis à l'environnement DMP. Utilisation du certificat de l'entité juridique associée à la DRIMBox dans le cadre de l'authentification.

Concernant le processus de création d'un document KOS associé à un examen d'imagerie, la première étape consiste en une récupération d'un compte-rendu d'imagerie par le logiciel DRIMBox, au moyen d'un flux HL7v2 ORU/MDM initié par un système RIS associé. A travers cette transaction, le logiciel DRIMBox aura connaissance du FINESS de l'entité géographique associée à la création du compte-rendu d'imagerie. Ainsi, dans le cadre de l'utilisation du mode d'authentification/identification EJ/EG au sein du logiciel DRIMBox, ce FINESS géographique pourra être mentionné dans le jeton VIHF ainsi que dans le lot de soumission transmis à l'environnement DMP. En revanche, il peut être nécessaire d'implémenter une table de correspondance entre FINESS géographique et FINESS juridique afin d'utiliser un certificat d'entité juridique dans le cadre de l'authentification du logiciel DRIMBox auprès de l'environnement DMP.

Pour plus de précisions concernant ce sujet, les ressources suivantes peuvent être consultées : 
* Guide d'Intégration DMP.
* https://esante.gouv.fr/quels-moyens-didentification-electronique-pour-quels-usages
* https://interop.esante.gouv.fr/ig/hl7v2/trans-cda-r2/mapping.html

Le contenu du Guide d'Intégration DMP ainsi que la définition technique fournie au sein de la spécification projet DRIMBox concernant la transaction d'appel contextuel, initiée par un LPS vers le logiciel DRIMBox, impliquent l'implémentation du mode d'accès "bris de glace" à l'environnement DMP au sein de ces deux types de logiciels (LPS et DRIMBox). En pratique, lorsqu'un professionnel de santé souhaite accéder aux examens d'imagerie d'un patient en situation d'urgence et sans avoir pu récupérer préalablement son consentement, alors le LPS procède à l'émission d'une requête d'appel contextuel vers le logiciel DRIMBox en y mentionnant la valeur "bris_de_glace" associée au paramètre "InformationEtConsentement". Suite à cela, le logiciel DRIMBox doit effectuer un accès à l'environnement DMP en mode bris de glace et adopter le comportement défini au sein des sections 2.2.2 et 3.2.2.1 du Guide d’intégration DMP.

Dans le cadre de la mise à jour d'un document KOS auprès de l'environnement DMP, le logiciel DRIMBox doit construire en amont un jeton VIHF afin de justifier son identification ainsi que son habilitation. Deux cas de figure sont ainsi à distinguer :

• Cas d'une mise à jour du document KOS suite à un ajustement du compte-rendu d'imagerie associé : Dans cette situation, le logiciel DRIMBox réceptionne le compte-rendu d'imagerie modifié au moyen d'un flux HL7v2 ORU/MDM initié depuis le système RIS associé. Les informations mentionnées au sein du compte-rendu d'imagerie (structure + utilisateur) sont à utiliser par le logiciel DRIMBox afin de créer un jeton VIHF propre au contexte de mise à jour.
• Cas d'une mise à jour du document KOS suite à un ajustement de contenu de l'examen d'imagerie associé : dans cette situation, le logiciel DRIMBox réceptionne l'information de mise à jour depuis le système PACS associé via un flux C-STORE IOCM ou HL7v2 OMI^O23. Les informations mentionnées au sein de l'archive locale du logiciel DRIMBox (précédent lot de soumissions associé au document KOS) sont à utiliser par le logiciel DRIMBox afin de créer un jeton VIHF propre au contexte de mise à jour.

Pour plus de précisions concernant ce sujet, deux référentiels peuvent être consultés : le volet CI-SIS Transport Synchrone pour Client Lourd et le Guide d’intégration DMP.

Dès le début du parcours de référencement Ségur pour DRIMBOX, il est nécessaire d’avoir inscrit votre solution :

• Au guichet CNDA pour obtenir les Numéros NIE / NIL (Numéro d’Identification Éditeur et Numéro d’Identification Logiciel), ainsi que le NIL des composants additionnels si nécessaire.
• Au guichet Espace de Confiance Pro Santé Connect (Convergence) pour obtenir le Numéro Unique de Référencement (NRU) en tant qu’Éditeur de Logiciel Utilisateur et/ou de Logiciel Proxy e-Santé.

Ces informations seront demandées lors de l’étape d’éligibilité du dossier administratif du parcours Ségur.

Attention : Le référencement Ségur ne pourra être attribué que si toutes les preuves demandées dans le DSR choisi sont déposées et conformes, et que toutes les homologations CNDA nécessaires sont obtenues.

Nous vous recommandons également de consulter le chapitre 4 du DSR choisi, qui détaille l’avancement attendu des candidatures à l’approche des différents jalons réglementaires.

La spécification projet DRIMBox définit un ensemble de codes d'erreur au travers de l'exigence DB.SO.47. 

Ceux-ci sont relatifs aux diverses situations non-passantes auxquelles la fonction source DRIMBox peut être confrontée. 

Parmi les codes d'erreurs spécifiés, E1001 et E1201 peuvent être invoqués pour un cas d'erreur identique. 

Le cas de figure associé correspond à la réception d'une requête d'appel à la visionneuse source mentionnant une valeur de StudyInstanceUID inconnue de la DRIMBox. 

Si la DRIMBox utilise l'identifiant StudyInstanceUID comme clé afin d'interroger sa base d'archivage locale, alors il n'est pas possible de distinguer le cas où la valeur de cet identifiant est incorrecte de celui où l'identifiant est correct mais n'a aucune correspondance avec un KOS archivé. 

Ainsi, dans cette situation, il est toléré que l'un ou l'autre des deux codes d'erreur possibles soit retenu par la DRIMBox : E1001 ou E1201. 

Le fichier ModelStat, destiné à répertorier les statistiques relatives au fonctionnement d'une solution DRIMBox mentionne deux colonnes relatives à la mise en oeuvre d'une transaction d'appel contextuel. 

La première d'entre elle, "Nombre_Appel" (colonne AI du fichier Excel) permet de tracer la réception unitaire d'une requête d'appel contextuel par la DRIMBox. Ainsi, pour chaque message correspondant réceptionné, cette colonne doit faire apparaître une valeur "1". 

La colonne suivante, corrélée à la première, "Statut_Appel" permet d'indiquer si la transaction d'appel contextuel en question correspond à un cas passant ou à l'inverse à une situation d'erreur. 

En résumé, pour chaque requête d’appel contextuel reçue par la DRIMBox, la colonne « Nombre_Appel » est complétée avec la valeur « 1 » et le résultat du traitement de cette requête est indiqué au niveau de la colonne « Statut_Appel » : "succes" ou "erreur".

La colonne "Nombre_Appel" pourra ensuite être calculée lors de la conception du fichier KPIs unifié par les parties prenantes suivant le model exposé.

Dans le cadre d'une consultation de l'environnement DMP, il est attendu que la fonction consommatrice associée à la solution DRIMBox soit en mesure de télécharger (au sens de récupérer) un ou plusieurs documents de santé.

Il peut s'agir de comptes-rendus d'imagerie, suite à une demande de visualisation de ceux-ci par l'utilisateur, ou bien de documents KOS, afin d'afficher l'intégralité des métadonnées associées à un examen d'imagerie. 

Cette action, réalisée par la solution DRIMBox, se retrouve au sein du contenu de l'exigence : "accès locaux aux documents qu'il stocke (y compris de manière temporaire)".

Par conséquent, aussi bien l'exigence, que le scénario et les preuves de test associées s'appliquent dans le cadre de l'homologation d'une solution DRIMBox.

Les captures et logs demandés en éléments de preuve doivent permettre d'attester que les accès locaux aux documents KOS récupérés sont bien tracés et que ces éléments peuvent faire l'objet d'une extraction. 

Dans le cadre de l'utilisation de l'outillage associé à la session de test Homologation SEGUR vague 2 DRIM-M, l'opérateur peut être amené à constater des résultats d'exécution contraires à ce qui est attendu. 

Par exemple, dans le cas où un résultat de validation "Failed" est obtenu à l'issue d'un processus impliquant un ou plusieurs fichiers entrants à priori passants.

Si cette situation est rencontrée par l'opérateur et que celui-ci estime que l'écart entre le résultat d'exécution obtenu et celui attendu n'est pas de son fait (dysfonctionnement de l’outillage de test, incohérence d'un scénario, ou autre), le lien permanent correspondant à l'exécution de l'outil peut tout de même être transmis dans le cadre du déroulement des scénarios associés à la session de test Homologation SEGUR vague 2 DRIM-M. 

Le moniteur analysera alors la situation afin d'estimer la suite à donner et une discussion entre l'opérateur et le moniteur pourra se mettre en place si nécessaire.