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

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. 

La spécification projet DRIMBox visionneuse définit en section 4.2.2 la structure de l'URL d'accès à la visionneuse associée à la fonctionnalité source DRIMBox.

Un tableau y est notamment mentionné afin de récapituler les contraintes s'appliquant à chacun des trois paramètres figurant au sein de l'URL : StudyInstanceUID, Accession Number et Identifiant compte-rendu. 

Par conséquent, il est attendu que les solutions logicielles DRIMBox se conforment à cette spécification concernant la structure des URL permettant de les atteindre.

L'accès à l'interface de la fonction consommatrice associée à une solution DRIMBox n'est possible qu'à partir d'une transaction d'appel contextuel initiée par un LPS de type RIS ou DPI. Suite à l'émission de la requête d'appel contextuel par le LPS, cinq réponses possibles peuvent être émises par la solution DRIMBox interrogée :

• Réponse HTTP 303 See Other mentionnant un header "Location" associé à un URL absolu. Dans ce cas, le LPS doit effectuer une redirection vers l'URL mentionné au sein de la réponse 303.
   
• Réponse HTTP 303 See Other mentionnant un header "Location" associé à un URL relatif. Dans ce cas, le LPS doit effectuer une redirection vers un URL correspondant à la concaténation du hostname DRIMBox ciblé par la requête d'appel contextuel et le chemin relatif mentionné au sein de la réponse 303.
   
• Réponse HTTP 302 Found mentionnant un header "Location" associé à un URL absolu. Dans ce cas, le LPS doit effectuer une redirection vers l'URL mentionné au sein de la réponse 302.
   
• Réponse HTTP 302 Found mentionnant un header "Location" associé à un URL relatif. Dans ce cas, le LPS doit effectuer une redirection vers un URL correspondant à la concaténation du hostname DRIMBox ciblé par la requête d'appel contextuel et le chemin relatif mentionné au sein de la réponse 302.
   
• Réponse HTTP 400 Bad Request indiquant que la requête d'appel contextuel reçu par la DRIMBox ne satisfait pas aux exigences mentionnées au sein de la spécification projet DRIMBox (problème de format, paramètre manquant, ...).

L'accès à l'interface de la fonction consommatrice associée à une solution DRIMBox n'est possible qu'à partir d'une transaction d'appel contextuel initiée par un LPS de type RIS ou DPI. Suite à l'émission de la requête d'appel contextuel par le LPS, cinq réponses possibles peuvent être émises par la solution DRIMBox interrogée :  

• Réponse HTTP 303 See Other mentionnant un header "Location" associé à un URL absolu. Dans ce cas, le LPS doit effectuer une redirection vers l'URL mentionné au sein de la réponse 303.
• Réponse HTTP 303 See Other mentionnant un header "Location" associé à un URL relatif. Dans ce cas, le LPS doit effectuer une redirection vers un URL correspondant à la concaténation du hostname DRIMBox ciblé par la requête d'appel contextuel et le chemin relatif mentionné au sein de la réponse 303.
• Réponse HTTP 302 Found mentionnant un header "Location" associé à un URL absolu. Dans ce cas, le LPS doit effectuer une redirection vers l'URL mentionné au sein de la réponse 302.
• Réponse HTTP 302 Found mentionnant un header "Location" associé à un URL relatif. Dans ce cas, le LPS doit effectuer une redirection vers un URL correspondant à la concaténation du hostname DRIMBox ciblé par la requête d'appel contextuel et le chemin relatif mentionné au sein de la réponse 302.
• Réponse HTTP 400 Bad Request indiquant que la requête d'appel contextuel reçu par la DRIMBox ne satisfait pas aux exigences mentionnées au sein de la spécification projet DRIMBox (problème de format, paramètre manquant, ...). 

Le partage de données d'imagerie entre deux solutions DRIMBox (fonction consommatrice interrogeant une fonction source) implique la mise en œuvre d'une connexion mTLS entre les deux entités. La description des certificats à exposer dans ce cadre peut être résumée de la manière suivante :

• Fonction source : Conformément au contenu de l'exigence DB.SO.90 issu de la spécification projet DRIMBox, la fonction source présente un certificat IGC-Santé rattaché au FQDN atteint par la fonction consommatrice tierce.
• Fonction consommatrice : La fonction consommatrice présente le certificat IGC-Santé correspondant au FQDN déployé au sein de la fonction source qui lui est associée. Dans le cas où la fonction source qui lui est associée expose plusieurs FQDN (donc de facto possède plusieurs certificats), le choix du certificat à présenter est libre. 

En accord avec la section 4.6.1 de la spécification projet DRIMBox, le mécanisme permettant à un utilisateur d'accéder à l'interface de la fonction consommatrice du logiciel DRIMBox est le suivant : Dans le cadre de la consultation d'un dossier patient au sein d'un LPS, l'utilisateur effectue une action déclenchant l'émission d'une requête d'appel contextuel à destination du logiciel DRIMBox. Suite à la réception de cette requête et à son traitement, le logiciel DRIMBox retourne une réponse HTTP 302 ou HTTP 303 mentionnant un lien de redirection vers son interface. Le LPS appelant réceptionne alors ce message de réponse et effectue la redirection indiquée.

Un ensemble d'informations complémentaires peuvent être précisées concernant le processus de traitement de la requête d'appel contextuel par la solution DRIMBox ainsi que la création d'une URL de redirection. Il est attendu que la réception d'une requête d'appel contextuel par le backend du logiciel DRIMBox entraîne la création d'une instance unique de frontend DRIMBox, associée aux informations issues du message reçu. L'accès à cette instance unique de frontend est rendue possible au travers d'une URL intégrant un UUID permettant de l'identifier. Cette URL d'accès est alors transmise au LPS appelant via le lien de redirection mentionné au sein du message de réponse HTTP 302/303. La robustesse du mécanisme de génération des UUID permettant d'identifier les différentes sessions créées par la solution DRIMBox peut être optimisée en y associant un timestamp.  

Il est à souligner que l'utilisation d'un cookie de session ne nous paraît pas indispensable afin d'assurer l'accès du LPS appelant au frontend de la solution DRIMBox. Dans le cas où un tel mécanisme est envisagé et que celui-ci échoue en raison d'un défaut d'utilisation du cookie de session, l'accès au frontend du logiciel DRIMBox doit tout de même être rendu possible. 
 

Dans le cadre du processus d'authentification à l'environnement DMP, préalable à la publication d'un document KOS, la fonction source de la solution DRIMbox doit utiliser un certificat ORG AUTH CLI, délivré par l’IGC-Santé et correspondant à la situation d’exercice du professionnel de santé ayant validé le compte-rendu d’imagerie associé. 
Afin de respecter la philosophie générale du projet DRIM-M, ainsi que l'ensemble des workflows définis au sein de la spécification projet DRIMBox, le choix du certificat à utiliser dans le cadre de l'authentification auprès de l'environnement DMP doit prioritairement être effectué en accord avec le segment "legalAuthenticator/assignedEntity/representedOrganization" mentionné au sein du compte-rendu d'imagerie associé à la production du document KOS à publier.
L'attribut PRT-8 mentionné au sein du message HL7v2 véhiculant le compte-rendu d'imagerie à destination de la solution DRIMBox doit théoriquement faire apparaître une information identique à celle référencée par le segment "legalAuthenticator/assignedEntity/representedOrganization" issu du document CDA. Le choix du certificat d'authentification à mettre en oeuvre auprès de l'environnement DMP peut donc également être effectué à partir de cet attribut. Cependant, nous priorisons une interprétation du contenu associé au compte-rendu d'imagerie afin de sélectionner le certificat à mettre en oeuvre. 
L'implémentation d'une vérification de cohérence systématique entre ces deux sources d'information (compte-rendu CDA / message HL7v2) par la solution DRIMBox n'est pas obligatoire, la responsabilité concernant la cohérence de ces données incombant  au système producteur du compte-rendu CDA et du message HL7v2 associé. Néanmoins, un tel contrôle peut être défini par les éditeurs de solutions DRIMBox s'ils le souhaitent . Dans ce cas, une situation non-passante (écart entre le document CDA et le message HL7v2 au niveau de la mention du professionnel de santé) doit interrompre le processus de production du document KOS et une alerte doit être remontée auprès de l'administrateur du système producteur de ces données.