Questions fréquentes

Les contrôles ne sont pas à effectuer par la PFI.
Les logiciels DPI ou RIS doivent comparer l’ensemble des traits d’identités (nom de naissance, 1er prénom de naissance, date de naissance, sexe, code INSEE du lieu de naissance, (liste des prénoms, matricule INS et OID si identité au statut qualifié présente)) du document reçu avec les traits des patients de sa base de données. 

Oui, le RIS doit obligatoirement pouvoir alimenter le DMP par API Pro Santé Connectée

Oui, il doit être possible d'envoyer le courriel MDN à une ou plusieurs BAL organisationnelles ou personnelles en fonction de la BAL destinataire du mail initial.

La solution doit obtenir l’agrément du CNDA conformément à l'addendum 8 du cahier des charges SESAM-Vitale [APCV1] ​

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.05.01
• MSS/CONF.06.01
• MSS/CONF.07.01
• MSS/CONF.11.01
• MSS/CONF.12.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]

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]
 

La spécification projet DRIMBox définit un ensemble de codes d'erreur au travers de l'exigence DB.SO.47. 

Ceux-ci sont relatifs aux diverses situations non-passantes auxquelles la fonction source DRIMBox peut être confrontée. 

Parmi les codes d'erreurs spécifiés, E1001 et E1201 peuvent être invoqués pour un cas d'erreur identique. 

Le cas de figure associé correspond à la réception d'une requête d'appel à la visionneuse source mentionnant une valeur de StudyInstanceUID inconnue de la DRIMBox. 

Si la DRIMBox utilise l'identifiant StudyInstanceUID comme clé afin d'interroger sa base d'archivage locale, alors il n'est pas possible de distinguer le cas où la valeur de cet identifiant est incorrecte de celui où l'identifiant est correct mais n'a aucune correspondance avec un KOS archivé. 

Ainsi, dans cette situation, il est toléré que l'un ou l'autre des deux codes d'erreur possibles soit retenu par la DRIMBox : E1001 ou E1201.