FAQ Entreprise du numérique en santé

Le consentement n’a pas vocation à être recueilli à chaque consultation. Le consentement est rattaché à un épisode de soins, lequel dépend des modalités de prise en charge :

• Pour un médecin traitant ou un spécialiste suivant régulièrement un patient, l’épisode de soins peut être long et continu.
• Le patient n’a donc pas à redonner son consentement à chaque acte ou consultation.

L’éditeur doit permettre le recueil initial du consentement, la possibilité pour le patient de changer d’avis, sans obligation de clôturer systématiquement l’épisode de soins.

Les modalités de traitement des modifications de structures sont décrites dans les AF.

Vous devrez redéposer vos preuves sur chaque DSR sur lesquels vous candidatez.

Les durées de conservation sont une responsabilité du responsable de traitement.

En tant qu'éditeur, vos logiciels doivent être capables de gérer deux durées de conservation distinctes :

• Les traces techniques (ex. logs d'erreurs, événements système) pour le support et la maintenance du logiciel, conservées sur une courte période de 6 mois à 1 an (recommandations CNIL).
• Les traces applicatives (ex. journaux d'accès aux dossiers patients) pour des raisons légales et de traçabilité, conservées sur une longue période de 20 ans, conformément à la durée de conservation des dossiers médicaux (article R.1112-7 du code de la santé publique).

Ces traces constituent des données à caractère personnel et il faut donc prévoir des mesures de sécurité adaptées à cette longue durée de conservation, ainsi qu’une information adaptée (par exemple, via les conditions générales d'utilisation (CGU) ou la politique de confidentialité) du responsable de traitement, voire une capacité d’adaptation des durées par ce dernier.

Le numéro RRPS doit être utilisé lorsqu’il existe. Lorsqu’il n’existe pas et qu’un autre numéro national est disponible, l’utilisation de cet autre numéro est tolérée. 

Vous pouvez soumettre votre demande d'enrôlement à l'ASP dès que la candidature administrative de la solution logicielle que vous éditez ou distribuez a été validée par l'ANS (statut éligible sur Convergence suite à la finalisation de la phase de dépôt du dossier administratif).

L'enrôlement auprès de l'Agence de services et de paiement (ASP) peut ensuite être effectué avant l'obtention du référencement Ségur. Dans ce cas, vous avez la possibilité de demander un enrôlement anticipé (enrôlement initial s'il s'agit de votre premier enrôlement auprès de l'ASP, vague 1 comprise ; ou enrôlement complémentaire s'il s'agit d'un second enrôlement, ou plus, auprès de l'ASP, vague 1 comprise). Cela vous permet d'accéder aux outils de test pour anticiper les démarches relatives à la demande de financement.

Dès l'obtention du référencement réalisée lors de la phase de dépôt et d'instruction du dossier de preuves sur Convergence, vous devez finaliser votre enrôlement ou effectuer un enrôlement initial via le Portail du Ségur Numérique.

Vous pouvez vous référer à la page dédiée au financement SONS de la vague 2 du Ségur du numérique en santé disponible sur le Portail Industriel de l'ANS.

Pour toute question relative à Pro Santé Connect (PSC) ou sur l'espace de confiance PSC, veuillez-vous référer à la FAQ dédié.

Non, les données provenant de l'annuaire santé ne sont pas modifiables. De fait, si une modification de la fiche utilisateur a lieu, il faut alors vérifier que les données entrées manuellement ne viennent pas en contradiction avec les informations de l'annuaire santé.

Néanmoins, il est bien sûr possible d’ajouter (et non pas remplacer) sur la fiche utilisateur des éléments qui ne sont pas dans l'annuaire.

Pour qu'un médecin soit éligible au financement SONS, il doit être inscrit au RPPS ainsi qu'à l'ordre des médecins. Dès lors que l'une des deux ou les deux conditions ne sont pas réunies, alors le financement ne peut être octroyé. Cette règle s'applique également aux médecins retraités.

Le blocage de l’alimentation du DMP doit être unitaire et choisi par l’utilisateur.
L’utilisateur DOIT effectuer une action pour NE PAS ENVOYER dans le DMP (ex : case à cocher, bouton-radio…).
Cette action DOIT être effectuée pour CHAQUE document qu’il souhaite retenir.
Ce comportement DOIT être par défaut et DOIT être immuable : il NE DOIT PAS être configurable ou débrayable par l’utilisateur.

Non, un changement complet de Solution Logicielle nécessite des prestations qui ne font pas partie du périmètre Ségur.
Le dispositif SONS LGC n'a pas vocation à financer le remplacement complet des logiciels.
Toutefois, si l'offre du Fournisseur permet d'identifier séparément les prestations du périmètre Ségur, alors ces dernières pourront bénéficier du financement SONS.

Après certification, le CNDA remet à l’éditeur :

• L'attestation de conformité ;
• La lettre de référencement.

L’éditeur utilise ensuite l’attestation de conformité comme preuve de certification auprès de l’ANS.

Vous trouverez ci-dessous un exemple d'attestation de conformité :

Image

L'export des données doit être réalisé sous un format standard, structuré et/ou non structuré, au choix de l’éditeur (ex : HL7 CDA, HL7 FHIR, PDF, DOC, DOCX, XML, etc.), avec une documentation détaillant la procédure à réaliser. La profondeur de l’historique doit être paramétrable dans la procédure. Le format des fichiers mis à disposition doit être lisible, exhaustif, exploitable, et documenté par l’éditeur.

Nous vous invitons à vous référer au DSR de votre couloir au chapitre 3.2.

• Contexte
  Les exigences SC.CDA/DD.22 et LGC.MDV.04 visent à vérifier la capacité du système à produire des documents structurés au format CDA R2 N3, conformément aux volets de contenu du CI-SIS :
  Les scénarios associés décrivent les étapes de saisie des données et de génération des documents.

   

• Problématique commune
  Dans les scénarios initiaux, certaines étapes pouvaient laisser entendre que la saisie des données devait être réalisée directement dans un document ouvert, ce qui revient à imposer un choix ergonomique aux éditeurs. Or, les LPS peuvent proposer différents parcours utilisateurs, par exemple :

  • saisie des données directement dans un document,
  • saisie des données dans le dossier patient, puis génération du document a posteriori,
  • toute autre ergonomie équivalente.

  Ces choix relèvent de l’implémentation et ne doivent pas être contraints par le scénario de conformité.

   

• Principe de clarification commun
  Pour SC.CDA/DD.22 et LGC.MDV.04, l’exigence porte exclusivement sur la capacité du système à produire un document CDA R2 N3 conforme au volet CI-SIS concerné, indépendamment de la manière dont les données ont été saisies.
  La saisie des données peut donc être effectuée :
  soit directement dans le document, soit en amont dans le LPS, avant la génération du document.
  Les deux approches sont conformes dès lors que le document généré respecte le volet CI-SIS applicable.

   

• Simplification de Scénarios 
   

  SC.CDA/DD.22.01 – Mesures de l’enfant
  Scénario :
  Vérifier que le système est capable de produire le document « Mesures de l’enfant » en CDA R2 N3, conformément au volet de contenu CSE-MDE [CI-SIS].
  Étapes :
  1.    Saisir les mesures de l’enfant
  2.    Générer le document « Mesures de l’enfant » au format CDA R2 N3, conformément au volet de contenu CI-SIS
   

  LGC.MDV.04.01.01 – Synthèse médicale
  Scénario :
  Vérifier que le système est capable de produire une synthèse médicale en CDA R2 N3, conformément au volet [CISIS16] du CI-SIS.
  Étapes :
  1.    Saisir les données d’une synthèse médicale
  2.    Générer le document « Synthèse médicale » au format CDA R2 N3, conformément au volet [CISIS16] du CI-SIS

   

• Conséquence pour les éditeurs
  Les éditeurs : 
  • NE SONT PAS TENUS d’implémenter une saisie directement dans un document ouvert,
  • PEUVENT librement définir le parcours de saisie le plus adapté à leur ergonomie,
  • DOIVENT garantir que le document généré est conforme au format CDA R2 N3 et au volet CI-SIS applicable.
    Cette clarification vise à harmoniser l’interprétation des scénarios et à éviter toute contrainte ergonomique non justifiée.
     

Scénarios des exigences concernées :

• MSS/CONF.01.01
• MSS/CONF.03.01
• MSS/CONF.04.01
• MSS/CONF.05.01
• MSS/CONF.06.01
• MSS/CONF.07.01
• MSS/CONF.11.01
• MSS/CONF.14.01
• MSS/CONF.15.01
• MSS/CONF.16.01
• MSS/CONF.21.01
   

Les scénarios des exigences MSS/CONF.xx.01 sont complétés afin de mentionner explicitement le job MOTCO.

Tous les tests des exigences MSS.CONF peuvent être validés avec le job global ou ils peuvent être validés exigence par exigence avec un test unitaire. Ces tests sont décrits dans le Manuel d'utilisation de l'outil de test MSSanté MOTCO2 [MOTCO]