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

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