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

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.

Dans le cadre du déroulement des scénarios de test d'interopérabilité associés au processus d'homologation SEGUR vague 2 DRIM-M, l'intégration de documents KOS au sein d'une solution DRIMBox peut être demandé en tant que prérequis. L'objectif d'un tel processus consiste à limiter les interactions entre la solution DRIMBox et l’environnement de test DMP.

Deux situations doivent alors être distinguées en fonction du rôle joué par la solution DRIMBox au sein de laquelle le ou les documents KOS doivent être intégrés : 

• Fonction source : L'intégration d'un document KOS préalablement au déroulement d'un scénario de test permet de simuler une situation de première publication réussie de celui-ci auprès de l'environnement DMP, et ainsi de focaliser les étapes de test sur la gestion du cycle de vie du document KOS (mise à jour, dépublication) ainsi que sur la capacité de la solution DRIMBox à répondre à une requête WADO-RS (mise en œuvre des contrôles auprès de l'archive locale). 
  Sans ce prérequis d'intégration d'un document KOS au sein de la solution DRIMBox, plusieurs étapes de test supplémentaires auraient été nécessaires afin de se trouver dans les conditions permettant de réaliser le workflow demandé.  
• Fonction consommatrice : L'intégration de documents KOS préalablement au déroulement d'un scénario de test permet de pouvoir utiliser les fonctionnalités standards de la solution à son démarrage (navigation, visualisation/export des images référencées), sans qu'une transaction de consultation auprès du DMP soit nécessaire.

Afin de satisfaire aux prérequis d'intégration de documents KOS, plusieurs processus peuvent être envisagés. Ceux-ci sont également à distinguer en fonction du rôle joué par la solution DRIMBox concernée : 

• Fonction source :
  • Le ou les documents KOS peuvent être intégrés au sein de la solution DRIMBox au travers d'un mécanisme classique de génération, puis publication auprès de l'environnement de test DMP. A cet effet, l'ANS met à disposition un ensemble de jeux de données HL7v2, CDA, DICOM permettant de réaliser intégralement ce workflow et ainsi d'aboutir à une solution DRIMBox dont l'archive locale contient les documents KOS ciblés.
  • Le chargement de documents KOS au sein de la solution DRIMBox peut également être effectué au moyen d'un import d'archive IHE-XDM, sous réserve de ne pas activer automatiquement la fonction de resynchronisation, cf. exigence DB.SO.28 issue de la spécification projet DRIMBox. Dans ce cas, l'archive IHE-XDM doit être construite par le participant à partir des jeux de données mis à disposition par l'ANS.
  • Enfin, tel qu'envisagé au sein de la section 4.7 de la spécification projet DRIMBox, les documents KOS ciblés ainsi que les métadonnées associées peuvent être intégrés directement au sein de l'archive locale de la solution DRIMBox au moyen d'un mécanisme propriétaire. 
     
• Fonction consommatrice :
  • Le ou les documents KOS peuvent être intégrés au sein de la solution DRIMBox au moyen d'un mécanisme classique de consultation auprès de l'environnement de test DMP. Cependant, cela implique que le ou les documents KOS ainsi consultés doivent avoir préalablement été publiés au sein de l'environnement de test DMP. Implicitement, cet aspect fait donc également partie des responsabilités du participant dans le cas où le processus de consultation classique est mis en œuvre.
  • De la même manière que pour la fonction source, les documents KOS ciblés peuvent être intégrés directement au sein de l'interface de la solution DRIMBox au moyen d'un mécanisme propriétaire. Dans ce cas, l’affichage des documents KOS présentés à l’utilisateur au démarrage de la solution DRIMBox peut présenter un mode dégradé car certaines informations sont normalement issues des métadonnées XDS récupérées auprès de l'environnement DMP. 

Afin de tester l'intégralité des mécanismes de contrôle implémentés par les Solutions DRIMBox candidates au référencement SEGUR DRIM-M, certaines situations "non-passantes" sont intégrées au sein des scénarios de test définis dans ce contexte.

Ces cas d'erreur peuvent résulter de l'exploitation de jeux de données volontairement corrompus ou d'interaction entre la solution DRIMBox et un simulateur présentant un défaut de configuration intentionnel.

Il est donc cohérent que pour ces situations l'utilisateur constate un résultat d'exécution non-passant au sein de l'interface du simulateur/validateur. 

L'EntryUUID correspond à un identifiant de ressource, affecté dans un contexte d'enregistrement d'un document au sein de l'environnement DMP. La valeur de cet identifiant est fixée par le DMP lui-même, suite à une publication ou une mise à jour du document en question. 

Dans le cadre de la publication d’un document KOS par la fonctionnalité source d'un logiciel DRIMBox, le lot de soumission envoyé à destination de l'environnement DMP ne doit pas mentionner de valeur pour la métadonnée "XDSDocumentEntry.entryUUID". Suite à la réception de l'acquittement de publication du document KOS au sein de l'environnement DMP, le logiciel DRIMBox n’est pas tenu de sauvegarder l’EntryUUID affecté au document par le DMP.

En revanche, afin d'effectuer un remplacement ou une dépublication d'un document KOS auprès de l'environnement DMP, il est nécessaire d'avoir préalablement connaissance de la valeur de l’identifiant EntryUUID associée du document. Cette valeur peut être récupérée au moyen d'une transaction spécifique (TD3.1b - Recherche d’identifiant technique, telle que définie au sein du Guide d'Intégration DMP). 

De manière générale, il est préconisé de ne pas sauvegarder la valeur de l'identifiant EntryUUID au sein du logiciel DRIMBox après une transaction de publication ou de remplacement d'un document KOS auprès de l'environnement DMP. En effet, celle-ci est susceptible d'évoluer suite à une modification du document effectuée directement depuis l'interface du Web-PS DMP. Ainsi, même si elle est archivée au sein du logiciel DRIMBox, cette valeur ne pourra pas être réutilisée directement sans que l'opérateur ne s'assure au préalable qu'aucune modification intermédiaire du document KOS n'a eu lieu. 

Concernant le contexte d'export de l'archive locale d'un logiciel DRIMBox au format IHE-XDM, les spécifications associées indiquent qu'il est obligatoire de mentionner une valeur d’EntryUUID au sein des lots de soumission composant l'archive (pour plus de précisions, se référer au volet CI-SIS Echange de Documents de Santé). Dans ce cadre, nous préconisons que le logiciel DRIMBox soit en mesure de générer ses propres valeurs d'identifiant EntryUUID, afin de compléter les différents lots de soumission composant l’archive au format IHE-XDM.

Dans le cas d'une architecture composée de plusieurs logiciels DRIMBox d'un même opérateur en hébergement "On Premise" au sein de différents établissements de santé et d'un proxy e-santé mutualisé pour l'intégralité de ces déploiements, il n'est pas nécessaire de démultiplier les commandes de l'ensemble des certificats. En effet, dans ce cas, seul un "Client_ID" attribué par ProSantéConnect et un certificat "ORG_AUTH_CLI" (CN=Client_ID de l'opérateur DRIMbox et OU=idStructure de l'opérateur proxy) sont à implémenter. 

Une fois obtenu, suite à une demande de Datapass effectuée par l'opérateur, l'identifiant Client_ID pourra être intégré à tous les logiciels DRIMBox déployés au sein de l'architecture mentionnée ci-dessus. Cet aspect n'est pas spécifique au projet DRIM-M, il s'agit d'un processus déjà documenté dans le cadre des architectures communautaires utilisant le service ProSantéConnect.

En revanche dans le cadre des interactions effectuées directement entre les logiciels DRIMBox composant l'architecture mentionnée ci-dessus et le service ProSantéConnect (endpoint d'introspection notamment), il est nécessaire de mettre en œuvre un certificat ORG_AUTH_CLI propre à chaque logiciel DRIMbox (CN=Client_ID et OU=SIRET opérateur DRIMbox).