Le CIBA est prévu dans la vague 2 du Ségur en tant que profil optionnel. En cas de client lourd, l'éditeur doit proposer les deux solutions (code flow et CIBA) => SC.PSC.01 et SC.PSC.13. Le profil est obligatoire lorsque l’éditeur a choisi d’implémenter dans sa solution logicielle l’authentification ProSanté Connect par le protocole CIBA (§3.1 du DSR DPI).

La dernière version de ce document est disponible sur la page dédiée du Dispositif concerné ainsi que via son lien de téléchargement direct : 

La date de la version publiée est par ailleurs indiquée sur le lien de téléchargement du document.

Pour votre information, voici un historique des versions publiées : 

La dernière version de ce document est disponible sur la page dédiée du Dispositif concerné ainsi que via son lien de téléchargement direct : 

La date de la version publiée est par ailleurs indiquée sur le lien de téléchargement du document.

Pour votre information, voici un historique des versions publiées : 

Oui, l'appel contextuel via PSC du web PS DMP doit obligatoirement être implémenté dans le cadre de la vague 2. Aussi, le mode AIR simplifié est-il obligatoire pour la consultation du DMP par API dans le couloir Hôpital.

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)

Les conditions d'éligibilité des établissements aux Prestations Ségur dans le cadre du SONS HOP-DPI-Va2 sont listées au §4.2 de l'Appel à Financement.

• Le format CDA R2 N1 est envoyé de façon systématique. Il est utilisé pour l’impression et la visualisation. 
• Le format CDA R2 N3, lorsqu’il existe, peut être envoyé, sous condition d’être lié à la version N1 qui lui correspond (liaison XFRM). Le format CDA R2 N3 est utilisé pour l’affichage de données structurées ou sous forme graphique dans le logiciel

L’alimentation du DMP avec des CR d’imagerie peut être réalisée avec les développements qui ont été financés en vague 1. Lors de la vague 1, des établissements ont choisi d'envoyer au DMP les CR d'imagerie reçus dans le DPI, via la PFI, notamment les CR d'imagerie rédigés dans les PACS. Les éditeurs de DPI ont quand même dû réaliser des développements spécifiques.

Une lettre d’engagement, fournie par l’Editeur, précise en quoi son logiciel répond aux critères de définition des fonctionnalités logicielles minimales décrites dans la section 2.1 du DSR.

 Il s'agit de proposer un service d'accès Web-PS à la consultation DMP via deux méthodes techniquement différentes. Il est donc demandé d’implémenter les deux manières.

Les fonctionnalités vague 2 du DPI permettent à un professionnel d'intégrer au DPI tout document présent dans le DMP qui lui semblerait pertinent pour la prise en charge d'un patient. Il peut donc choisir d'intégrer des CR BIO, mais ce n'est pas une intégration systématique.

Non, dans les fonctionnalités Ségur, c'est au SGL du laboratoire producteur du CR de réaliser cet envoi. Un ES reste cela dit libre d'organiser les flux internes à son SIH selon sa stratégie.

Si un établissement recueille les non-oppositions dans le RI et souhaite mettre à jour le flux identités pour transmettre cette info au DPI, l'éditeur de DPI ne peut pas facturer la mise en oeuvre de ce flux, comprise dans la Prestation vague 2. En revanche, l'éditeur du RI est libre de sa stratégie commerciale vis à vis de l’établissement qui souhaite installer cette fonctionnalité.

Le format demandé dépendra du type de document que vous souhaitez transmettre. Nous vous suggérons de consulter les REM en ce qui concerne le format des documents de santé. Vous pouvez consulter l'annexe 5.3 du DSR.

Le dépôt des preuves peut être effectué en une fois ou par chapitre de preuves via la plateforme Convergence.

Le test doit être daté de moins d'un an.

L'INSi & le DMP sont des piliers fondamentaux du dispositif Ségur, ils continueront à être des prérequis sur la Vague 2. 

En ce qui concerne l'utilisation de solutions déjà homologuées, les mêmes règles qu'en vague 1 s'appliqueront. Les homologations requises pour le référencement s'appliquent aux solutions candidates.

Le mode d'hébergement est pris en compte au niveau des exigences SSI ainsi que des points de contrôle du test d'intrusion dans le cas où un industriel ou un tiers sous sa responsabilité assure l'hébergement de tout ou partie des composants du système, ou fournit tout ou partie du système sous forme de service (SaaS).
En revanche, les OS ne sont pas pris en compte dans les exigences SSI.

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

• Numéro d'Identification Editeur (NIE) : Numéro d’Identification de l’Editeur, délivré par le Centre National de Dépôt et d’Agrément (CNDA). 
• Numéro d'Identification Logiciel (NIL) : Numéro d’Identification Logiciel, délivré par le Centre National de Dépôt et d’Agrément (CNDA) pour l’agrément au titre du composant proposé par l’Editeur