FAQ des industriels

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.

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.

Conformément aux indications formulées au sein du référentiel Espace de Confiance ProSantéConnect ainsi que du volet CI-SIS relatif aux API ProSantéConnect, une connexion mTLS est exigée entre le proxy e-santé et l'environnement ProSantéConnect. En complément, cette connexion mTLS doit être mise en œuvre dans le cadre d'une authentification OAuth 2.0 et conformément au référentiel RFC 8705. 

En conséquence, il n'est pas nécessaire de mettre en oeuvre l'utilisation d'un "client_secret". Cette indication s'applique également dans le cadre des interactions entre le proxy e-santé et les APIs ProSantéConnect (API PSC DMP notamment). 

Il est important de noter que la ou les clés privées associées au(x) certificat(s) client mis en œuvre dans le cadre de la connexion mTLS mentionnée ci-dessus doivent être archivées au sein d'un keystore sécurisé implémenté directement sur le proxy e-santé.

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).

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 être 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. 

La création de votre compte Gazelle est réalisée par les équipes de référencement dès que votre dossier de candidature est déclaré éligible. 

Il y a un délai d'environ une semaine d'instruction durant lequel vous seront transmises les informations pour accéder à Gazelle. 

Ce n'est pas systématique. L'éditeur doit assurer la compatibilité ascendante de ses solutions et déclarer les modifications à l'ANS. Ce principe est décrit dans les conventions de référencement pour chaque SONS.

Non, cela dépend des usages de l'INS et des besoins de la structure.

De manière générale, dans le cadre d'une prise en charge, l’INS est récupérée quand le patient ou l’usager concerné est devant le professionnel de prise en charge.

En effet, Pro Santé Connect va être disponible en authentification pour les téléservices. Le projet est en cours et en bonne voie.

Indépendamment du programme Ségur, il est obligatoire de référencer les données de santé avec l'INS depuis le 1er janvier 2021. La nouvelle version du corpus documentaire qui va être publiée prochainement par arrêté devient opposable à travers cette publication. Même s'il n'y a pas de nouvelle homologation ou référencement Ségur, indépendamment du couloir, les logiciels ont l'obligation de respecter ce cadre réglementaire et ce corpus documentaire.

Il faut cependant noter qu’une nouvelle autorisation CNDA pourrait être demandée mais uniquement en cas d’évolution majeure sur le téléservice INSi (le corpus documentaire soumis à la concertation ne concerne pas le fonctionnement du téléservice INSi).

Les REM étant en cours d’être mises à jour à ce sujet, cette réponse sera apportée à la suite de leur publication.

Si après l’opération de vérification, le téléservice renvoie un retour KO, alors l’identité doit intégrer une liste de travail.

La problématique de la gestion des tirets n'est pas un dysfonctionnement du téléservice INSi mais le résultat d’une recherche stricte qui est réalisée depuis la dernière version. Il est envisageable d'assouplir cette règle dans une prochaine mise à jour. 

Le téléservice ne renvoie une identité que si le nom de naissance est strictement identique. Donc ce qui est effectivement préconisé, c'est que si vous faites l'appel avec un tiret et que vous n'avez pas l'identité, vous avez tout à fait la possibilité de refaire un appel sans le tiret. 

Par ailleurs, des difficultés pour récupérer certaines identités sont constatées. Il y a une synchronisation des bases qui est en cours depuis le mois de juillet et qui doit se terminer en décembre de cette année. Cette synchronisation va manifestement améliorer la qualité des bases et faciliter la qualification.

Le premier risque, évidemment, est un risque d'identitovigilance parce que l'INS permet de sécuriser l'identité du patient et l'identité : sans INS il n’est donc pas possible d’alimenter Mon espace santé, le DMP, etc. 

Mais la priorité, bien entendu, est la prise en charge du patient ; rien ne doit empêcher la prise en charge d'un patient. L’absence d’INS ne remet absolument pas en question la prise en charge des usagers. Et d'ailleurs, tous les usagers n'ont pas vocation à avoir une INS et cela n'empêche pas leur prise en charge.

Pour le détenteur de l'application il n’est pas nécessaire d’appeler de téléservice ou demander la pièce d’identité. 

En effet, la procédure pour installer l'application carte Vitale est équivalente à une qualification : il y a une étape d'enrôlement, de vérification de la personne, etc. Il y a une mise en cohérence de ses traits par rapport aux bases, celle du téléservice, avec un document d'identité qui doit être fourni recto verso. Il y a un algorithme qui vérifie effectivement si les traits sont cohérents. Cet enrôlement est comme s'il y avait physiquement l'appel au téléservice et la vérification à partir du document d'identité pour le détenteur de l’application.

Lors d’échange de fichier pdf dans des documents conforme au standard CDA r2 niveau 1, il est obligatoire d’intégrer le datamatrix INS dans le fichier pdf.

Lors d’échange de documents de santé conforme au standard CDA r2 niveau 3, l’intégration des données de l’identité nationale de santé dans l’entête CDA est obligatoire, l’intégration du datamatrix INS est optionnelle. En revanche, les logiciels permettant la rematérialisation des documents CDA r2 niveau 3 doivent générer le datamatrix à partir des données de l’INS de l’entête CDA et l’ajouter au document rematérialisé. Les fonctions de dématérialisation concernées sont : la création de pdf à partir d’un document CDA r2 niveau 3 et l’impression d’un document CDA r2 niveau 3.

Nous avons établi une liste des erreurs les plus fréquentes, afin de mieux mettre en visibilité les points à vérifier avant de candidater, pour réduire les rejets des candidatures au référencement Ségur du numérique en santé.

Notre partenaire, le GIE SESAM-Vitale, constitue un support pour poser vos questions concernant le développement de votre solution, l’intégration du téléservice INSi et pour vous aider à résoudre d’éventuels problèmes techniques.  

Ce guichet unique est disponible par téléphone au 02 43 57 42 88, de 9h à 12h et de 14h à 18h du Lundi au Vendredi, et par email.

Le non-respect de cette obligation a plusieurs impacts : 

• vos clients ne référenceront pas l'INS dans leurs logiciels, ce qui impliquera de possibles pénalités vis-à-vis de plusieurs dispositifs (Ségur vague 1, HOPEN, référencement portail dans Mon espace santé, etc.) ;
• vos clients ne seront pas en conformité avec la réglementation. Ils seront donc responsables en cas d'erreurs d'identification de leurs patients et usagers ;
• l'échange et le partage de données de santé par vos clients sera moins fluide ;
• l'identité utilisée par vos clients ne sera pas celle de référence, issue des bases de l'Etat civil ;
• vos clients ne référenceront pas l'INS dans leurs logiciels, ce qui impliquera de possibles pénalités vis-à-vis de plusieurs dispositifs (Ségur vague 1, HOPEN, référencement portail dans Mon espace santé, etc.).

Vous devez proposer une solution INS-compatible à vos clients afin de leur permettre de respecter l'obligation, depuis le 1er janvier 2021, de référencer toutes les données de santé avec l'INS. 

L’INS n’est pas mise en évidence dans la liste des données de l’application carte Vitale de TEST. Même si cela n’affecte pas les tests, nous ferons, dans une future version, une modification sur les intitulés des données de l’identité patient à l’image de l’application de production.

Oui, la condition pour créer une identité est d'avoir a minima les champs nom de naissance, premier prénom de naissance, date de naissance, sexe et code officiel géographique du lieu de naissance. Pour autant, un éditeur ne peut pas rendre obligatoire d’autres traits pour la création d’une identité.