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

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.

Le système désigne le LGO donc la visualisation doit se faire au travers du LGO. En revanche, comme il s'agit d'une préconisation, le développement de cette fonctionnalité n'est pas obligatoire pour le référencement vague 1. Elle le deviendra pour la vague 2.

Le montant de la facture transmise au client et à l'ASP en fin de projet doit correspondre au montant total (100%) - la partie "Prestation Segur" doit être reportée dans le JSON et doit être inférieure ou égale au montant déclaré lors de l'avance (dépôt du dossier).

Pour plus d'informations, veuillez vous référer à la partie "4.4 Conditions relatives à la réalisation de la Prestation principale" de l'Appel à Financement (AF) de votre dispositif.

Nous nous situons au niveau local avec répercussion sur le DMP et la MS Santé comme pour le cas d'une modification. Si le document est supprimé uniquement dans le DMP et pas en local (ex : le patient fait la suppression lui-même), il n’y a pas besoin d'informer les destinataires MS Santé.

Pour rappel, le pharmacien ne peut pas supprimer ou modifier directement un document dans le DMP, il doit le faire depuis son LGO pour répercuter ensuite la mise à jour ou la suppression dans le DMP. Ceci assure une synchronisation entre DMP et logiciels métiers.

Le SGL doit pouvoir gérer deux situations :

1. Alimentation directe du DMP :
   • Si le SGL alimente le DMP lui-même, il doit fournir sa propre homologation CNDA.
   • Si le SGL utilise un module/PFI sous-traitant (invisible pour le client), il doit fournir l’homologation CNDA du sous-traitant et préciser son interconnexion avec le module lors du référencement de l’ensemble [SGL + module] (1 seul référencement).
2. Alimentation via la PFI de l’hôpital :
   • Le SGL laisse l’hôpital gérer les envois au DMP avec sa PFI, préalablement choisie par l’hôpital.
   • Dans ce cas, le SGL n’a pas à fournir d’homologation CNDA, mais doit démontrer qu’il peut envoyer les comptes-rendus via messages ORU, qui seront routés par la DSI vers la PFI hospitalière.

L'intégration d'une interface Mailiz n'a pas de lien avec le choix du profil MSS. Si vous choisissez le profil Mailiz en déploiement, les preuves déposées devront correspondre à ce profil.

Vous devez faire un groupement d'éditeurs pour répondre à tout le périmètre des exigences, il faut cocher "OUI".

A noter qu'un composant additionnel ne doit pas faire l’objet d’un coût supplémentaire pour le client. 

Vous devez demander le raccordement à Pro Santé Connect en remplissant le formulaire dédié, disponible ici.