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

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.
     

Initialement, le scénario précisait que l’éditeur DOIT exécuter le cas de test suivant sur l’espace de test d’interopérabilité des SIS pour un plan personnalisé de prévention (Type_Code : 11490-0) : CI-SIS-CR-VIL-N1-Create_doc-Sc2

Il s'agit du plan personnalisé de prévention au format PDF/A-1 pour le cas de tests CI-SIS-CR-VIL-N1-Create_doc-Sc2, en mentionnant le ou les destinataires initialement prévus à la création du document dans l’en-tête CDA N1 et le PDF/A-1. Hors, il a été identifié que le Type_Code « 11490-0 » ne correspond pas à un plan personnalisé de prévention. Ce code est associé à une lettre de suivi, type de document qui n’est pas référencé dans le REM LGC. L’utilisation de ce Type_Code dans le cadre du scénario introduit donc une incohérence entre le type de document attendu et le code utilisé, susceptible de générer les éditeurs.

Ainsi, le Type_Code attendu pour un plan personnalisé de prévention est "83869-8".

Afin de clarifier les attendus, notamment pour les documents intégrés depuis le DMP ou la MSSanté, la formulation « document CDA R2 N3 encapsulé » est remplacée par « document CDA R2 N3 avec une copie du document au format PDF dans la section FR-Document-PDF-copie ».

Cette évolution est uniquement rédactionnelle : le fond et l’objectif de l’exigence restent inchangés. En l'occurrence : Pour l’affichage des métadonnées issues d’un document CDA R2 N3, accompagné d’une copie au format PDF dans la section FR-Document-PDF-copie, le système ne DOIT afficher qu’une seule ligne dans l’espace documentaire.

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é.

1. Quel est le changement ?
Dans le cadre de l’exigence SC.MSS/UX.01, l’étape 3 du scénario doit être supprimée pour les RIS. Cette étape indiquait la création automatique d’un flux HL7 vers le DPI après dézippage de l’archive.
 

2. Pourquoi cette étape est-elle supprimée ?
L’exigence SC.MSS/UX.01 porte uniquement sur la capacité du système à identifier les courriels MSSanté contenant une archive IHE XDM. La création d’un flux HL7 ne fait pas partie du périmètre attendu et ne doit pas être prise en compte lors des vérifications de preuves.
 

3. Consignes pour les éditeurs et les vérifications
• Ne pas présenter de preuve liée à la création d’un flux HL7 vers le DPI.
• Les preuves doivent uniquement démontrer l’identification des courriels MSSanté contenant une archive IHE XDM.
 

4. Rappel du scénario applicable (sans l’étape 3)
Prérequis :
Un message contenant une archive zip au format IHE XDM en pièce jointe a été reçu.

Objectif :
Vérifier qu’il est possible d’identifier les courriels reçus via MSSanté avec archive zip au format IHE XDM en pièce jointe.

Étapes du scénario :
1. Montrer le respect du prérequis : réception d’un message MSSanté avec archive IHE XDM.
2. Montrer comment le système identifie les courriels reçus via MSSanté contenant une archive IHE XDM en pièce jointe.
 

1. Quel est le changement principal ?

   Avant : Tout système proposant un mot de passe comme facteur unique d’authentification devait limiter le nombre de tentatives d’accès et appliquer des critères de construction assurant un niveau suffisamment élevé de complexité des mots de passe des PS.

   Maintenant : Cette exigence s'applique uniquement à un système configuré avec la base de compte locale. Lorsque le système ne dispose d’aucune fonctionnalité de gestion de comptes utilisateurs locaux (création, stockage ou vérification de mots de passe) et que l’authentification est entièrement déléguée à un fournisseur d’identité externe (exemple : AD), l’exigence SC.SSI/IE.36 est non applicable.

   Ce changement est lié au fait que la rédaction initiale de l’exigence ne prenait pas en compte des cas d’usage remontés durant la procédure de référencement.

    

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

   L'éditeur peut déposer un justificatif expliquant les particularités de développement de l’application et indiquant qu’il n’existe aucune fonctionnalité de base locale de comptes.

    

3. Quelles obligations pour l’éditeur ?

   Aucune, il s’agit d’une prise en compte de cas d’usage existants.

    

Annexe – Nouvelles versions exigences, scénarios et preuves

Nouvelle version de l’exigence SC.SSI/IE.36

LORSQUE le système propose un mot de passe comme facteur unique d'authentification, ALORS le système DOIT : 

• permettre d'implémenter les mesures de restriction d’accès et de vérification de complexité des mots de passe prévues par le Référentiel d'identification électronique (volet ASPP) ;
• être conforme à ces exigences dans sa configuration par défaut.

NB : les administrateurs techniques ou métier ne sont pas concernés par cette exigence

Le système peut généralement se baser :

• soit sur une base de compte locale
• soit sur un annuaire (exemple AD)

Cette exigence s'applique à un système configuré avec la base de compte locale.

Nouveau scénario associé à l’exigence SC.SSI/IAM.36

SC.SSI/IE.36.01 :

Vérifier que le système limite le nombre de tentatives d'accès par mot de passe.

Etapes du scénario :

1. Demander l'ouverture d'une connexion par mot de passe en tant que PS sur un compte valide
2. Entrer un mot de passe incorrect plusieurs fois consécutives
3. Montrer que le système empêche de réaliser un nombre illimité de tentatives (temporisations, blocage préventif du compte...) ou qu'il requiert la complétion d'un captcha à chaque authentification

SC.SSI/IE.36.02 :

Vérifier que le système applique les critères de construction du mot de passe du compte du PS.

Etapes du scénario :

1. Demander la modification ou la création du mot de passe d’un compte de PS   
2. Entrer un mot de passe de 8 caractères composé uniquement de minuscules et de majuscules
3. Montrer que le système refuse ce mot de passe
4. Entrer un mot de passe de 8 caractères composé uniquement de minuscules et de chiffres
5. Montrer que le système refuse ce mot de passe
6. Entrer un mot de passe de 8 caractères composé uniquement de minuscules et de caractères spéciaux
7. Montrer que le système refuse ce mot de passe
8. Entrer un mot de passe composé de 14 chiffres uniquement
9. Montrer que le système refuse ce mot de passe

L’étape 4 a pour objectif de préciser le contenu attendu dans la preuve vidéo.

Elle ne correspond pas à une action supplémentaire.

Dans le cadre d'une consultation de l'environnement DMP, il est attendu que la fonction consommatrice associée à la solution DRIMBox soit en mesure de télécharger (au sens de récupérer) un ou plusieurs documents de santé.

Il peut s'agir de comptes-rendus d'imagerie, suite à une demande de visualisation de ceux-ci par l'utilisateur, ou bien de documents KOS, afin d'afficher l'intégralité des métadonnées associées à un examen d'imagerie. 

Cette action, réalisée par la solution DRIMBox, se retrouve au sein du contenu de l'exigence : "accès locaux aux documents qu'il stocke (y compris de manière temporaire)".

Par conséquent, aussi bien l'exigence, que le scénario et les preuves de test associées s'appliquent dans le cadre de l'homologation d'une solution DRIMBox.

Les captures et logs demandés en éléments de preuve doivent permettre d'attester que les accès locaux aux documents KOS récupérés sont bien tracés et que ces éléments peuvent faire l'objet d'une extraction.