Votre question concerne quel type d'offre ?
Votre question concerne quel couloir Ségur ?
Votre question concerne quel dispositif Ségur ?
Votre question concerne quel produit ou service produit?
Votre question concerne quelle thématique ?
L’éditeur doit impérativement renseigner les informations CNDA suivantes (signalées par un *) dans l’outil de gestion des candidatures :
- Numéro d’Identification Editeur (NIE délivré par le CNDA)
- Numéro d’Identification Logiciel (NIL délivré par le CNDA)
- Attestation de dépôt d'une demande d'obtention des labellisations CNDA (Assurance Maladie)
Cette réponse vous a-t-elle été utile ?
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 :
- 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).
- 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).
- 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.
Cette réponse vous a-t-elle été utile ?
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.
Cette réponse vous a-t-elle été utile ?
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é.
Cette réponse vous a-t-elle été utile ?
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).
Cette réponse vous a-t-elle été utile ?
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.
Cette réponse vous a-t-elle été utile ?
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.
Cette réponse vous a-t-elle été utile ?
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.
Cette réponse vous a-t-elle été utile ?
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.
Cette réponse vous a-t-elle été utile ?
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.
Cette réponse vous a-t-elle été utile ?
L’AF précise les connecteurs inclus dans la prestation Ségur. Cette dernière est limitée à l’installation, la configuration, la qualification de 5 flux différents au total, en priorisant le flux identité entrant (si pertinent), le flux DMP, le flux MSS Pro, le flux MSS Citoyenne et le flux HL7 ORU/OUL vers l'éventuel DPI/PFI (si pertinent).
Cette réponse vous a-t-elle été utile ?
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.
Cette réponse vous a-t-elle été utile ?
Le Numéro de version technique du logiciel est l’identifiant unique de la solution. Il présente obligatoirement les caractéristiques suivantes :
- Le Numéro de version technique est aisément accessible à l’utilisateur dans l’IHM (Interface HommeMachine) du logiciel,
- Le Numéro de version technique doit évoluer dès qu’un élément du code source est modifié, y compris un simple patch,
- La succession chronologique des versions techniques doit être clairement compréhensible au travers d’une numérotation alphanumérique
Cette réponse vous a-t-elle été utile ?
La convention de référencement Ségur stipule que l’éditeur doit pouvoir commercialiser le logiciel référencé au plus tard dans les 2 mois à compter de l’entrée en vigueur de la Convention. La date d’entrée en vigueur de la convention est la date de décision du référencement.
Cette réponse vous a-t-elle été utile ?
L'éditeur des fonctionnalités de PFI peut être un groupement de solutions : certains éditeurs font référencer une solution en se regroupant avec un ou plusieurs partenaires. Toutefois, dans tous les cas, un seul éditeur porte le référencement et le financement SONS (tout en déclarant ses partenaires). C'est l'interlocuteur unique de l'ANS et de l'ASP.
Cette réponse vous a-t-elle été utile ?
Les logiciels pouvant candidater au programme Ségur doivent répondre aux fonctionnalités décrites dans les DSR (Dossier de Spécifications de Référencements). Toutefois le DSR DPI ne s'adresse pas aux dossiers de spécialité.
Cette réponse vous a-t-elle été utile ?
Pour rejoindre l'Espace de Confiance Pro Santé Connect, consultez l'onglet dédié à l'EdC sur le parcours de raccordement à PSC
Cette réponse vous a-t-elle été utile ?
Le numéro de version technique du Logiciel est l'identifiant unique de la solution.
Cette réponse vous a-t-elle été utile ?
L'éditeur doit à minima préciser les éléments suivants :
- pour quelle raison des pièces d’identité sont-elles stockées et dans quel(s) cas un accès ultérieur à ces documents est-il prévu ?
- les principes du RGPD sont-ils appliqués (protection des données stockées, information du patient, etc.) ?
- algorithme de chiffrement utilisé et taille des clés,
- modalités de gestion de la durée de conservation,
- précisions sur la "gestion des secrets" :
- de quelle façon les clés de chiffrement sont-elles générées ?
- de quelle façon les clés de chiffrement sont-elles protégées ?
- qui peut y accéder ?
- comment sont-elles gérées dans le temps ?
- comment s’exécute le processus de déchiffrement d’un document préalablement chiffré lorsque celui-ci est nécessaire ?
Cette réponse vous a-t-elle été utile ?
Oui, il est possible de ne remplir qu’un seul formulaire pour la structure. La commande du certificat se fait avec le FINESS géographique du GIE. Pour plus d’informations, nous vous invitons à consulter le guide spécifique à la radiologie, disponible depuis le site esanté accessible via le lien suivant
Cette réponse vous a-t-elle été utile ?
Vous ne trouvez pas la réponse à votre question ?
Posez nous votre question !
Besoin d'une mise en relation avec nos experts dédiés ?
