FAQ de l'offre : Ségur du numérique en santé

1. Quel est le changement principal ?

Lors de la publication des REM RIS et DB, MDV et DCC le GIi DMP 2.10 [DMP4] était publié en version release candidate (RC) (pas d'homologation CNDA).
La version du GI DMP 2.9 [DMP5] a donc été pointée dans les exigences.
La publication officielle du GI DMP 2.10 API PSC intégrant toutes ces exigences, cette référence à la 2.9 n’est plus nécessaire et devient source d’erreur pour les candidats.

2. Concrètement, qu’est-ce que ça implique ?

Les exigences concernées qui mentionnent GI DMP 2.9 [DMP5] peuvent désormais être lues comme faisant référence au GI DMP 2.10 – API PSC [DMP4].

3. Quand appliquer ce changement ?

Immédiatement, pour toutes les implémentations, vérifications et homologations en cours ou à venir.

4. Quelles obligations pour l’éditeur ?

Se conformer à la version GI DMP 2.10 – API PSC [DMP4].

La mention de l'autorité d'affectation associée à l'identifiant IPP au sein de la requête d'appel contextuel est indiqué en section 4.6.1 de la spécification projet DRIMBox (paramètre PatientIDIssuer). A ce jour, il n'existe pas de définition explicite quant à la valeur devant être associée à ce paramètre lors de la génération des requêtes d'appel contextuel.

Cependant, l'implémentation d'un mécanisme basé sur la structure HL7v2 du sous-composant 4 associé au champ PID-3 est encouragée. Dans ce cadre, nous recommandons de mentionner l'ensemble du segment CX-4 (composé des éléments 4.1, 4.2 et 4.3) en tant que valeur associée au paramètre PatientIDIssuer au sein de la requête d'appel contextuel.

Toutefois, en pratique, la valeur associée à ce paramètre doit demeurer modulable afin de s'adapter au contexte et à l'environnement de déploiement propre à chaque solution logicielle. Ainsi, il peut être envisagé que le système appelant ne renseigne que les éléments CX-4.1, CX-4.2 ou une combinaison de ceux-ci pour le paramètre "PatientIDIssuer" au sein de la requête d'appel contextuel. 

La spécification projet DRIMBox visionneuse définit en section 4.2.2 la structure de l'URL d'accès à la visionneuse associée à la fonctionnalité source DRIMBox.

Un tableau y est notamment mentionné afin de récapituler les contraintes s'appliquant à chacun des trois paramètres figurant au sein de l'URL : StudyInstanceUID, Accession Number et Identifiant compte-rendu. 

Par conséquent, il est attendu que les solutions logicielles DRIMBox se conforment à cette spécification concernant la structure des URL permettant de les atteindre.

L'accès à l'interface de la fonction consommatrice associée à une solution DRIMBox n'est possible qu'à partir d'une transaction d'appel contextuel initiée par un LPS de type RIS ou DPI. Suite à l'émission de la requête d'appel contextuel par le LPS, cinq réponses possibles peuvent être émises par la solution DRIMBox interrogée :

• Réponse HTTP 303 See Other mentionnant un header "Location" associé à un URL absolu. Dans ce cas, le LPS doit effectuer une redirection vers l'URL mentionné au sein de la réponse 303.
   
• Réponse HTTP 303 See Other mentionnant un header "Location" associé à un URL relatif. Dans ce cas, le LPS doit effectuer une redirection vers un URL correspondant à la concaténation du hostname DRIMBox ciblé par la requête d'appel contextuel et le chemin relatif mentionné au sein de la réponse 303.
   
• Réponse HTTP 302 Found mentionnant un header "Location" associé à un URL absolu. Dans ce cas, le LPS doit effectuer une redirection vers l'URL mentionné au sein de la réponse 302.
   
• Réponse HTTP 302 Found mentionnant un header "Location" associé à un URL relatif. Dans ce cas, le LPS doit effectuer une redirection vers un URL correspondant à la concaténation du hostname DRIMBox ciblé par la requête d'appel contextuel et le chemin relatif mentionné au sein de la réponse 302.
   
• Réponse HTTP 400 Bad Request indiquant que la requête d'appel contextuel reçu par la DRIMBox ne satisfait pas aux exigences mentionnées au sein de la spécification projet DRIMBox (problème de format, paramètre manquant, ...).

Un auto-éditeur n’est pas éligible à l’Appel à Financement. Comme précisé dans le chapitre 4.1 de l'Appel à Financement, les solutions dites autoéditées, c’est-à-dire développées et utilisées exclusivement par leur propre opérateur, sont explicitement exclues du dispositif et considérées comme hors marché.

Les comptes créés sur Convergence en Vague 1 sont généralement repris sur iSC à condition que le mandataire social / représentant social de l'entreprise ait transmis le KBIS et une pièce d'identité.

Cette étape étant réalisée au cas par cas, nous vous conseillons de contacter l'équipe Convergence à l'adresse suivante : ans-support-convergence@esante.gouv.fr

La candidature doit être déposée par l’éditeur du logiciel dans Convergence, et non par l’établissement de santé.
Pour toute information complémentaire, nous vous invitons à consulter la page dédiée à la procédure de référencement sur le Portail Industriels

Oui, il est possible de combiner certains critères, selon leur pertinence. Il n’est pas obligatoire de pouvoir interroger individuellement tous les critères listés dans l’exigence.

La date de référence à laquelle un dossier de preuves est considéré comme complet correspond à la date de dépôt par l’éditeur du dossier complet accompagné de l’ensemble des preuves.

Celles-ci pourraient faire l'objet d'échange entre l'Editeurs et l'équipe de Conformité de l'ANS.

L'Appel à Financement (II - Calendrier du SONS) précise deux dates :

• Date 2 - Date limite de dépôt d'un dossier complet de preuves de conformité
• Date 3 - Date de fin des échanges entre l'Editeur et l'ANS pour validation du dossier de preuves
   

Oui, il est possible de combiner certains critères, selon leur pertinence. Il n’est pas obligatoire de pouvoir interroger individuellement tous les critères listés dans l’exigence.