Questions fréquentes

Si vous étiez en cours de référencement précédemment, alors vous devez candidater et déposer l'ensemble des preuves demandées, produites à partir de la version présentée en Référencement ("version candidate" de la Convention de Référencement)

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]
 

L’exigence SC.MSS/va1.15 telle que définie historiquement dans le référentiel client de messagerie MSSanté est erronée depuis sa publication. Elle décrit un mécanisme d’accusé de réception non conforme aux normes RFC. Cette anomalie est présente dans les référentiels de la vague 1 et reprise dans certains REM de la vague 2. Sur le terrain, les éditeurs ont majoritairement implémenté les accusés de réception conformément à la norme RFC.

L’exigence SC.MSS/va1.15 évolue pour s'aligner sur le mécanisme DSN normalisé afin de garantir la bonne émission et réception des accusés de réception par les solutions MSSanté.

La nouvelle version de l'exigences est la suivante : 
Le système DOIT permettre de demander un accusé de réception de type DSN lors de l'émission d'un courrier. Lors de l'envoi du message, le paramètre NOTIFY doit être positionné avec les valeurs SUCCESS,FAILURE,DELAY dans la commande SMTP "RCPT TO:"
Le mécanisme DSN est décrit dans la RFC 3461.
Exemple : RCPT TO: <adresse email> NOTIFY=SUCCESS,FAILURE,DELAY

Les nouveaux scénarios et preuves sont également mis à jour : 

Scénario - Accusé de réception par l'opérateur destinataire
Etapes :

1. Préparer un courriel.
2. Choisir l'option qui permet d'avoir un accusé de réception de type DSN.
3. Envoyer le message.

Preuves : 

• Preuve 1 : Produire des copies d’écran : du courriel envoyé afin de valider la preuve.
• Preuve 2 : Produire des copies d’écran : de l’accusé de réception reçu suite à l’envoi du courriel émis.

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. 

1. Problématique
La preuve demandée pour l’exigence INS/va1.53 n’est pas adaptée pour le REM LGC, car elle repose sur la fourniture d’un flux HL7 v2, ce qui a du sens dans un contexte hospitalier.
 

2. Objectif de l’exigence
Vérifier la non transmission sous format informatisé du matricule INS et de son OID lorsque l’identité du patient n’est pas qualifiée.
Nous complétons le scénario et les preuves avec la possibilité d’utiliser une arche IHE_XDM
 

3. Scénario applicable
Objectif : Vérifier la non-utilisation du matricule INS (et de l’OID) pour une identité non qualifiée.

Étapes :

1. Disposer d’une identité au statut « identité récupérée ».
2. Produire un document de santé destiné à un échange informatisé ou un message d’interopérabilité IHE PAM contenant une INS non qualifiée.
3. Vérifier que le matricule INS et l’OID ne sont pas utilisés pour référencer le document ou le message.

4. Preuves attendues

Preuve 1 : Démonstration (capture d’écran, vidéo, etc.) montrant l’identité (et son statut) et la donnée de santé produite.

Preuve 2 : Mise à disposition d’une archive IHE_XDM contenant le document de santé ou un message IHE PAM avec une INS non qualifiée.
 

Le fichier ModelStat, destiné à répertorier les statistiques relatives au fonctionnement d'une solution DRIMBox mentionne deux colonnes relatives à la mise en oeuvre d'une transaction d'appel contextuel. 

La première d'entre elle, "Nombre_Appel" (colonne AI du fichier Excel) permet de tracer la réception unitaire d'une requête d'appel contextuel par la DRIMBox. Ainsi, pour chaque message correspondant réceptionné, cette colonne doit faire apparaître une valeur "1". 

La colonne suivante, corrélée à la première, "Statut_Appel" permet d'indiquer si la transaction d'appel contextuel en question correspond à un cas passant ou à l'inverse à une situation d'erreur. 

En résumé, pour chaque requête d’appel contextuel reçue par la DRIMBox, la colonne « Nombre_Appel » est complétée avec la valeur « 1 » et le résultat du traitement de cette requête est indiqué au niveau de la colonne « Statut_Appel » : "succes" ou "erreur".

La colonne "Nombre_Appel" pourra ensuite être calculée lors de la conception du fichier KPIs unifié par les parties prenantes suivant le model exposé.