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

Vous trouverez ci-dessous, une image d’une boite de vaccin qui vous permettra de répondre à l’exigence ERGO 4 et sur laquelle vous trouverez le numéro de lot, la date d’expiration, le Datamatrix ainsi que le nom du vaccin qui doit ressortir dans votre logiciel.

Image

Image

Image

Un Opérateur Développeur désigne un Opérateur MSSanté qui développe et met en œuvre (le cas échéant avec l’aide d’un sous-traitant) pour lui-même ou pour le compte d’Opérateurs Acheteurs les composants spécifiques aux exigences MSSanté (exemple : connecteur MSSanté).

Un Opérateur Acheteur désigne un Opérateur qui a recours à la technologie d’un Opérateur Développeur (disposant d’un contrat Opérateur MSSanté signé avec l’ANS) en lui achetant les composants techniques tels que le connecteur MSSanté (ex : les établissements sanitaires Opérateurs MSSanté qui achètent leur connecteur MSSanté auprès d’un Opérateur MSSanté tiers).

Le nombre de BAL pris en compte dans le calcul du financement est celui déclaré à la date fixée dans le contrat Opérateurs.

Le montant HT de chaque prestation Ségur, le taux de TVA applicable et le montant TTC (pour les fournisseurs assujettis à la TVA) doivent être indiqués dans TOUS les bons de commande. Le calcul des montants de chacune des prestations doit être réalisé selon les étapes suivantes afin d’éviter les erreurs :

1. Vérifier que le montant HT du bon de commande est bien inférieur ou égal au plafond HT réglementaire correspondant a la tranche déterminée par le service de calcul, tel qu’indiqué dans les appels à financements concernés ;
2. Appliquer à ce montant le taux de TVA auquel le fournisseur est soumis et selon les dispositions en vigueur dans le code général des impôts.
3. Faire figurer sur le bon de commande puis sur la facture les montants HT, TVA, et TTC, en s’assurant de l’exactitude des informations

De plus amples informations notamment sur le modèle à adopter ainsi que des exemples sont disponibles en cliquant ici

La convention de référencement Ségur stipule que l’éditeur doit pouvoir commercialiser le logiciel référencé au plus tard dans les 2 mois à compter de l’entrée en vigueur de la Convention. La date d’entrée en vigueur de la convention est la date de décision du référencement.

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

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.