Besoin d’aide ? Toutes les réponses et ressources utiles pour les ENS

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. 

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. 
 

Les endpoints d'accès à un logiciel DRIMBox, tel que définis au sein du corpus documentaire associé au projet DRIM-M et tels que délivrés par le registre national ANS, comportent notamment deux paramètres : "ID_DRIMBox" (identifiant unique d'un logiciel DRIMBox) et "ID_Registre" (identifiant du fournisseur pour un site donné). 
Au vu des différents types d'architecture possibles pour le déploiement d'un logiciel DRIMBox, la gestion de ces paramètres peut soulever certaines interrogations. Afin de répondre à celles-ci, nous pouvons envisager deux architectures de déploiement d'un logiciel DRIMBox et étudier la gestion des paramètres "ID_DRIMBox" et "ID_Registre" qui en découle : 

• Cas d’un logiciel DRIMBox au sein d'un établissement et utilisé par un radiologue ayant plusieurs situation AM (activités libérales). Dans cette situation, les URLs implémentés par le logiciel DRIMBox comporteront tous le même paramètre "ID_DRIMbox" et le même "ID_Registre" dans ce cas un seul logiciel DRIMBox et PACS sont déployés. Aussi une instance DRIMBox peut être utilisée par plusieurs professionnels de santé comportant plusieurs situations d'exercice.
• Cas d’un logiciel DRIMBox avec un PACS desservant deux établissements. Dans cette situation, les URLs implémentés par le logiciel DRIMBox comporteront tous le même paramètre "ID_DRIMbox" puisqu'un seul logiciel DRIMBox est déployé. De manière identique, l'ensemble des URLs implémentés par le logiciel DRIMBox mentionneront le même "ID_Registre" puisqu'un seul site est identifié, depuis lequel sont desservis les deux établissements. 

Trois phases peuvent être distinguées afin d'assurer la gestion du cycle de vie d'un examen d'imagerie au niveau de l'archive locale associée au logiciel DRIMBox :

1. Dans le cadre de la réalisation d'un examen d'imagerie, un compte-rendu d'imagerie ainsi qu'un ensemble d'images médicales sont produits. Ces informations, une fois envoyées à la fonctionnalité source du logiciel DRIMBox, permettent la création d'un document KOS mentionnant l'ensemble des informations à utiliser afin d'accéder ultérieurement aux images. Une fois le document KOS créé par le logiciel DRIMBox et publié au sein de l'environnement DMP (transaction TD2.1a du Guide d'Intégration DMP), une nouvelle entrée est ajoutée au sein de l'archive locale de la DRIMBox (pour plus de précisions, voir section 4.5.7 de la spécification projet DRIMBox).
    
2. Dans le cadre d'une modification de contenu d'un examen d'imagerie (suppression/ajout d'images médicales, changement de visibilité du compte-rendu d'imagerie, ou autre), le document KOS associé doit être mis à jour en conséquence par le logiciel DRIMBox et remplacé au sein de l'environnement DMP (transaction TD2.1b du Guide d'Intégration DMP). Une fois la mise à jour effectuée auprès de l'environnement DMP, celle-ci doit également être répercutée au niveau de l'archive locale associée au logiciel DRIMBox. Cet ajustement aura pour conséquence un remplacement du document KOS archivé, ainsi que du lot de soumission associé (fichier METADATA.xml).
    
3. Dans le cadre d'une dépublication d'un compte-rendu d'imagerie ou en cas de suppression de l'intégralité des images associées à un examen d'imagerie médicale, alors le document KOS associé doit être dépublié de l'environnement DMP (transaction TD3.3c du Guide d'Intégration DMP). Conformément aux indications fournies en section 4.5.8.1 de la spécification projet DRIMBox, le document KOS sera alors identifié comme dépublié au niveau du stockage local. L’objet DICOM KOS en tant que tel peut éventuellement être supprimé de la base d’archivage, mais son identification et statut doivent être tracés afin de fournir une réponse précise lors de la demande d’accès aux images qu'il référence. 

Oui. En effet, c’est un changement d’habitude, de pratique à prendre pour tous les professionnels de santé et au sein de chaque établissement de soins (sanitaire ou médico-social).

Pour rappel :

• c’est une étape à faire une seule fois par patient pour chaque professionnel de santé ; A noter : cette action ne doit être faite qu’une seule fois par professionnel de santé.
• à terme l’application de la carte vitale permettra une qualification automatique ;
• la qualification de l’INS vise à associer le dossier du patient en local dans le logiciel métier avec celui du DMP afin de pouvoir transmettre automatiquement les documents et les rendre disponibles dans Mon Espace Santé.

Dans le cadre d'une demande de consultation d'un document KOS par un professionnel de santé depuis l'interface du logiciel DRIMBox, ce dernier doit tout d'abord contrôler le consentement du patient à une telle opération (information véhiculée au travers du paramètre "InformationEtConsentement" mentionné au sein de la requête d'appel contextuel provenant du LPS). Ensuite, le logiciel DRIMBox doit initier une transaction permettant d'effectuer un test d'existence du DMP et de récupérer les conditions d'accès à celui-ci (transaction TD0.2 mentionnée au sein du Guide d'Intégration DMP). Enfin, et si cela s'avère nécessaire, le logiciel DRIMBox doit ajouter une autorisation du professionnel de santé pour la consultation de ce DMP (pour plus de précisions à ce sujet, se référer à la transaction TD0.3 définie au sein du Guide d'Intégration DMP).

Pour DRIMBOX, la plaquette commerciale ou tout autre document décrivant le périmètre fonctionnel que couvre votre solution logicielle est recevable. L'objectif étant de vérifier que votre solution logicielle répond au périmètre fonctionnel du dispositif choisi.

Pour le RIS, la plaquette commerciale ou tout autre document décrivant le périmétre fonctionnel que couvre votre solution logicielle est recevable. L'objectif étant de vérifier que votre solution logicielle répond au périmètre fonctionnel du dispositif choisi.

Dans le cas spécifique des nouveaux-nés, il faut attendre un délai technique (7 à 10 jours) pour créer l’INS. Les documents qui pourront être demandés pour identifier le patient seront le livret de famille ou un extrait d’acte de naissance, ainsi que les papiers d’identité du parent présent.

Pour en savoir plus :

Pour MSSanté, dans le PDF, on utilise la base « code » qui est imposée par le type code et son nom. Pour le DMP, on utilise le « title », qui sera visible des PS et patients. Pour certains documents ce dernier est imposé par le CI-SIS ; pour d’autres c’est à la main de l’utilisateur, idéalement sur proposition du logiciel (et cela correspond à l’exigence du GI DMP).