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

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.

Dans le cadre d'une solution logicielle DRIMBox, les trois éléments relevés ne sont effectivement pas véhiculés au sein de la requête d'appel contextuel émise par le RIS/DPI. Cela correspond à un arbitrage historique pris dans le cadre des travaux menés au sein du projet DRIM-M.

Cependant, il est à noter que le "workflow de démarrage" de la fonction consommatrice associé à la solution DRIMBox a été défini en tenant compte de cet aspect, pour rappel :
 

1. Mise en oeuvre d'une transaction d'appel contextuel, initiée par le RIS/DPI à destination de la fonction consommatrice DRIMBox.
2. Authentification de l'utilisateur via PSC (peut être transparente selon le cas de figure).
3. Interaction TD3.1 entre la DRIMBox et le DMP permettant de récupérer les métadonnées XDS associées aux documents publiés sur le DMP. Cela s'applique implicitement en considérant l'exigence DB.CO.54 mentionnée au sein de la spécification projet DRIMBox.
4. Ouverture de l'interface DRIMBox (fonction consommatrice) présentant les résultats de la transaction TD3.1.

Au sein du workflow présenté ci-dessus, l'étape n°3 permet notamment de traiter la récupération des traits INS stricts du patient. En effet, les métadonnées "sourcePatientId" et "sourcePatientInfo" mentionnent l'intégralité des traits INS requis pour l'affichage au sein de l'interface DRIMBox (certains étant redondants avec les éléments mentionnés dans la requête d'appel contextuel). Cette transaction étant réalisée en amont de l'ouverture de l'interface utilisateur, l'ensemble des traits INS du patient pourront y figurer.

Il est à noter que la spécification projet DRIMBox (section 4.6.1) définit la requête d'appel contextuel "nominale" applicable dans le cadre du processus d'homologation SEGUR vague 2 DRIM-M. Suite à cette étape, lors du déploiement de solutions DRIMBox en production, il est tout à fait envisageable d'étendre les requêtes d'appel contextuel générées par la DRIMBox en y ajoutant un ou plusieurs headers répondant à un contexte ou une architecture donnée. 

En revanche, le contenu de la requête d'appel contextuel ne pourra être réduit (au sens de suppression de certains headers définis en section 4.6.1 de la spécification projet DRIMBox) entre les phases d'homologation et de production.

Le corpus documentaire associé au projet DRIM-M comporte deux éléments définissant l'affichage de l'intégralité des traits stricts INS au sein de l'interface DRIMBox consommatrice : l'exigence INS/va1.36 issue du REM DRIM-M ainsi que la section 4.6.2 de la spécification projet DRIMBox.

Ainsi, l'utilisateur doit être en mesure de consulter les données d'identification patient suivantes au démarrage de la DRIMBox :

• Nom de naissance : affichage par défaut au lancement de l'interface utilisateur.
• Premier prénom de naissance : affichage par défaut au lancement de l'interface utilisateur.
• Date de naissance : affichage par défaut au lancement de l'interface utilisateur.
• Sexe : affichage par défaut au lancement de l'interface utilisateur.
• Lieu de naissance : affichage par défaut au lancement de l'interface utilisateur.
• Matricule INS : affichage possible via paramétrage de l'utilisateur. (existence du champ obligatoire)
• Nature du matricule INS (OID) : affichage possible via paramétrage de l'utilisateur. (existence du champ obligatoire)
• Liste des prénoms de naissance : affichage possible via paramétrage de l'utilisateur. (existence du champ obligatoire)
• Prénom utilisé : affichage possible via paramétrage de l'utilisateur. (existence du champ obligatoire)
• Nom utilisé : affichage possible via paramétrage de l'utilisateur. (existence du champ obligatoire)

En considérant le workflow global de consultation de données de santé associé à la fonction consommatrice DRIMBox, deux flux permettent à cette dernière d'avoir connaissance de l'intégralité des traits stricts INS du patient ciblé :

• Transaction d'appel contextuel initiée par un système LPS à destination de la solution DRIMBox (Cf. section 4.6.1 de la spécification projet DRIMBox). Dans le cadre de cette interaction, le LPS transmet les traits INS suivants à la solution DRIMBox : Nom de naissance ; Premier prénom de naissance ; Date de naissance ; Sexe ; Lieu de naissance ; Matricule INS ; Nature du matricule INS (OID).
• Transaction TD3.1 initiée par la solution DRIMBox vers l'environnement DMP afin de récupérer les lots de soumission associés aux documents publiés sur ce dernier. Suite à cette interaction, la solution DRIMBox récupère l'intégralité des traits INS associés au patient ciblé (au travers des métadonnées "sourcePatientId" et "sourcePatientInfo").

Ainsi, parmi l'exhaustivité des traits stricts INS, trois d'entre eux ne peuvent être connus de la fonction consommatrice DRIMBox qu'à la suite d'une transaction TD3.1 vers le DMP : Liste des prénoms de naissance ; Prénom utilisé ; Nom utilisé.

Par conséquent, le workflow associé au lancement de la fonction consommatrice DRIMBox a été défini afin de tenir compte de ces aspects, pour rappel :

1. Mise en oeuvre d'une transaction d'appel contextuel, initiée par un système LPS à destination de la fonction consommatrice DRIMBox.
2. Authentification de l'utilisateur via ProSantéConnect.
3. Interaction TD3.1 entre la solution DRIMBox et l'environnement DMP permettant de récupérer les métadonnées XDS associées aux documents d'intérêt publiés sur le DMP.
4. Ouverture de l'interface DRIMBox (fonction consommatrice) présentant les résultats de la transaction TD3.1.

Au sein du workflow présenté ci-dessus, la combinaison entre les étapes n°1 et n°3 implique que l'intégralité des traits stricts INS du patient soient connus de la solution DRIMBox au démarrage de son interface.

Les spécificités des DRIMbox font que certains flux sont effectivement en HTTP et ne peuvent être protégés par l’utilisation du chiffrement.

Les flux suivants font exception au point de contrôle C17 :

• Défi ACME HTTP-01,
• URL de téléchargement des CRLs IGC Santé et CRLs IGC du marché,
• URL de téléchargement des ACs IGC Santé et ACs IGC du marché,
• Répondeur OCSP IGC Santé et IGC du marché.

Tous les autres flux doivent être protégés par l’utilisation du chiffrement.

NB : pour les quatre types de flux cités, les réponses sont sécurisées : 

• Le protocole ACME utilise l'empreinte d'une clé de compte,
• Les CRLs sont signées par la clé privée de l'AC intermédiaire de l'IGC,
• L'AC intermédiaire est signée par la clé privée de l'AC RACINE, et l'AC RACINE est signée par sa clé privée,
• Le service OCSP signe ses réponses vers le client qui envoie la requête.

La mention de l'autorité d'affectation associée à l'identifiant IPP au sein de la requête d'appel contextuel est indiqué en section 4.6.1 de la spécification projet DRIMBox (paramètre PatientIDIssuer). A ce jour, il n'existe pas de définition explicite quant à la valeur devant être associée à ce paramètre lors de la génération des requêtes d'appel contextuel.

Cependant, l'implémentation d'un mécanisme basé sur la structure HL7v2 du sous-composant 4 associé au champ PID-3 est encouragée. Dans ce cadre, nous recommandons de mentionner l'ensemble du segment CX-4 (composé des éléments 4.1, 4.2 et 4.3) en tant que valeur associée au paramètre PatientIDIssuer au sein de la requête d'appel contextuel.

Toutefois, en pratique, la valeur associée à ce paramètre doit demeurer modulable afin de s'adapter au contexte et à l'environnement de déploiement propre à chaque solution logicielle. Ainsi, il peut être envisagé que le système appelant ne renseigne que les éléments CX-4.1, CX-4.2 ou une combinaison de ceux-ci pour le paramètre "PatientIDIssuer" au sein de la requête d'appel contextuel.