FAQ des industriels

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

Non, il n’est pas demandé que le logiciel référencé affiche le numéro unique de référencement. En revanche, les noms commerciaux et versions affichés par le logiciel doivent permettre la vérification aisée par l’acheteur du bon référencement de la solution sur le site officiel de l’ANS.

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. 

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.

Pour DRIMBOX, dès l'entame de votre parcours de référencement Ségur, il est nécessaire d'avoir inscrit votre solution auprès du guichet CNDA et auprès du guichet Espace de Confiance Pro Santé Connect (dans Convergence). Les éléments suivants seront demandés à l'étpae éligibilité du dossier administratif du parcours référencmeent Ségur : 
- Les Numéros NIE / NIL (Numéro d'Identification Editeur et Numéro d'identification Logiciel) et éventuellement NIL des composants additionnels, obtenus auprès du guchet CNDA. .
- le Numéro Unique de Référencement (NRU) au guichet Espace de Confiance Pro Santé Connect en tant qu’Editeur de Logiciel Utilisateur et/ou de Logiciel Proxy e-Santé.
Veuillez noter que le référencement Ségur ne pourra vous être attribué que si l'ensemble des preuves demandées dans le DSR choisi sont déposées et conformes et que toutes les homologations CNDA nécessaires obtenues. Nous vous encourageons également de prendre connaissance du chapitre 4 du DSR choisi précisant des informations supplémentaires quant à l'avancement attendu des candidatures à l'approche des différents jalons réglementaires. 

Pour le RIS, dès l'entame de votre parcours de référencement Ségur, il est nécessaire d'avoir inscrit votre solution auprès du guichet CNDA et auprès du guichet Espace de Confiance Pro Santé Connect (dans Convergence). Les éléments suivants seront demandés à l'étpae éligibilité du dossier administratif du parcours référencmeent Ségur : 
- Les Numéros NIE / NIL (Numéro d'Identification Editeur et Numéro d'identification Logiciel) et éventuellement NIL des composants additionnels, obtenus auprès du guchet CNDA. .
- le Numéro Unique de Référencement (NRU) au guichet Espace de Confiance Pro Santé Connect en tant qu’Editeur de Logiciel Utilisateur et/ou de Logiciel Proxy e-Santé.
Veuillez noter que le référencement Ségur ne pourra vous être attribué que si l'ensemble des preuves demandées dans le DSR choisi sont déposées et conformes et que toutes les homologations CNDA nécessaires obtenues. Nous vous encourageons également de prendre connaissance du chapitre 4 du DSR choisi précisant des informations supplémentaires quant à l'avancement attendu des candidatures à l'approche des différents jalons réglementaires. 

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 prestation secondaire a pour objectif de monitorer et de garantir dans la durée la performance de la Solution logicielle en termes d’alimentation de Mon espace santé, comme précisé dans l'appel à financement correspondant.

Pour la DRIMBox, la prestation secondaire a pour objectif de monitorer et de garantir dans la durée la performance de la Solution logicielle en termes de disponibilité de service, comme précisé dans l'appel à financement correspondant.

En tant qu’éditeur, vous devez en effet déclarer vos distributeurs dans Convergence, dans l’étape Eligibilité, étape entre la candidature administrative et le dépôt des preuves.

Non, les distributeurs (dûment déclarés par l’éditeur) n’ont pas de candidature administrative à réaliser dans Convergence pour le référencement Ségur de la solution qu’ils distribuent. C’est l’éditeur de la solution qui réalise les démarches de référencement Ségur de la solution dans Convergence.

Une fois les PV validés, l'ANS publie l'information sur son site internet, confirmant que la solution logicielle a fait l'objet de premières installations réussies (comme précisé dans l'article 6.3 de l'appel à financement correspondant). Le fournisseur peut alors demander le paiement du solde pour les prestations réalisées pour ces établissements ainsi que pour l'ensemble des Prestations Ségur réalisées.
 

Le processus de réalisation et de validation des PV pilotes par l'ANS comprend plusieurs étapes :

- Etablissement des PV -  Pour chaque établissement pilote, un PV post-installation est établi. Ce PV doit être signé par le client, attestant de la bonne réalisation de la prestation Ségur et de la stabilité de la solution logicielle, comme notifié dans le chapitre 6.3 de l'appel à financement correspondant

- Transmission des PV et vérification - Les PV signés sont transmis à l'ASP pour vérification de conformité (chapitre 6.3 de l'appel à financement - insérer le lien). L'ASP examine ensuite les PV pour s'assurer que toutes les exigences et critères de conformité ont été respectés.

- Validation des PV et publication des résultats - Si les PV sont conformes, l'ASP informe le fournisseur de la validation des installations pilotes. L'ANS publie l'information sur son site internet, confirmant que la solution logicielle a fait l'objet de premières installations réussies (comme notifié dans le chapitre 6.3 de l'appel à financement)

Lé périmètre pilote désigne un ensemble de trois établissements de santé sélectionnés par le fournisseur pour valider la stabilité et la conformité de la solution logicielle avant de généraliser la transmission des demandes de soldes, comme spécifié dans le chapitre 6.3 de l'appel à financement correspondant. 

Les demandes de financement et de paiement de l’avance doivent avoir été déposées par le Fournisseur, et validées par l’ASP pour les 3 Clients concernés. Pour justifier du bon déroulé d'une prestations pilote, le fournisseur établit un PV (procès verbal) d'installation pilote qui doit ensuite être transmis à l'ANS qui vérifie sa conformité et informe le fournisseur du résultat de ces contrôles (chapitre 6.3 de l'appel à financement). 

En cas de conformité, l'ANS publiera sur son site internet l'information selon laquelle la Solution logicielle a bien fait l'objet de premières installations réussies. 

Un établissement pilote dans le cadre de la Vague 2 du Ségur est un établissement de santé sélectionné par le fournisseur pour valider la stabilité et la conformité de la solution logicielle. Comme précisé dans le chapitre 6.3 de l'appel à financement correspondant, trois établissements pilotes (par solution référencée) doivent être sélectionnées pour confirmer la stabilité de la solution logicielle. 

Pour être Pilotes, les demandes de financement et de paiement de l’avance doivent avoir été déposées par le Fournisseur, et validées par l’ASP pour les 3 Clients concernés. 

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. 

Les certificats devront être rattachés au FINESS juridique de l'ES, le FINESS géographique étant véhiculé dans le VIHF des transactions DMP.

Néanmoins les certificats peuvent être rattachés aux FINESS géographiques. Dans ce cas il faut des certificats différents pour chaque FINESS géographique.

Profil Général : Dans le cadre de la procédure de vérification de conformité Ségur, la capacité des solutions SGL (profil général) à appeler INSi n'est pas vérifiée. Profil RI : Dans le cadre de la procédure de vérification de conformité Ségur est vérifiée la capacité des solutions SGL (profil RI) à appeler l'opération de recherche d'INSi par carte vitale et par traits et l'opération de vérification unitaire d'INSi grâce à une identification électronique de type CPx et certificat logiciel.

Une Instance logicielle est définie comme l’installation en production d’une version logicielle sur un même serveur physique ou logique, utilisé par une ou plusieurs structures médicale sur un ou des sites géographiques et/ou entités juridiques différentes, et nécessitant un déploiement pour chaque nouvelle version. Un serveur correspond à une instance de base de données. Dans une installation en SaaS, sauf cloisonnement particulier nécessitant des mises à jour sur des infrastructures séparées, une seule instance est comptabilisée. Les instances de test, de pré-production, de qualification, de développement ne sont pas pris en compte comme des instances logicielles.