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

Le Référentiel d’Exigences Minimales et le Dossier de Spécification de Référencement (DSR) du dispositif dédié aux Logiciels de Gestion de Cabinet (LGC) du couloir Médecin de ville incluent dans leur périmètre l’obtention de l’agréement au cahier des charges "Guide d'intégration Ordonnance numérique" [GION2] auprès du CNDA (SC.ORDN/CONF.01).

Le Cahier des charges ordonnance numérique Médecins précise que le logiciel doit être certifié Logiciel d’Aide à la Prescription en médecine ambulatoire auprès de la HAS Haute Autorité de Santé - Certification des logiciels des professionnels de santé.

Pour plus de précision sur l’Ordonnance Numérique, vous pouvez vous référer au webinaire dédié sur le sujet.

La suppression de l’exigence DB.SO.106 initialement référencée au sein du REM DRIM-M a été actée suite à la constatation de son inapplicabilité. 

La mise à jour du REM DRIM-M n’ayant à l’heure actuelle pas été mise en œuvre au sein de la plateforme Convergence, l'exigence DB.SO.106 reste assignée aux candidatures à l’homologation SEGUR vague 2 pour les solutions DRIMBox. 

Par conséquent, la preuve de test associée à l'exigence DB.SO.106 peut être renseignée avec la mention « Non applicable au REM DRIM-M » en attendant une mise à jour corrective ultérieure de la plateforme Convergence.

La suppression de l’exigence DB.SO.34 initialement référencée au sein du REM DRIM-M a été actée suite à la constatation de son inapplicabilité. 

La mise à jour du REM DRIM-M n’ayant à l’heure actuelle pas été mise en œuvre au sein de la plateforme Convergence, l'exigence DB.SO.34 reste assignée aux candidatures à l’homologation SEGUR vague 2 pour les solutions DRIMBox. 

Par conséquent, la preuve de test associée à l'exigence DB.SO.34 peut être renseignée avec la mention « Non applicable au REM DRIM-M » en attendant une mise à jour corrective ultérieure de la plateforme Convergence.

La suppression de l’exigence DB.CO.131 initialement référencée au sein du REM DRIM-M a été actée suite à la constatation de son inapplicabilité. 

La mise à jour du REM DRIM-M n’ayant à l’heure actuelle pas été mise en œuvre au sein de la plateforme Convergence, l'exigence DB.CO.131 reste assignée aux candidatures à l’homologation SEGUR vague 2 pour les solutions DRIMBox. 

Par conséquent, la preuve de test associée à l'exigence DB.CO.131 peut être renseignée avec la mention « Non applicable au REM DRIM-M » en attendant une mise à jour corrective ultérieure de la plateforme Convergence.

Ces exigences SC.SSI/IAM.91 et SC.SSI/IAM.92 définissent la manière dont le système doit tracer certaines opérations et gérer la robustesse des mots de passe administrateurs.

Avant, le système devait conserver les traces de l’ensemble des opérations mentionnées (SC.SSI/IAM.91) et permettre à la structure de santé de mettre en place une politique de mots de passe robuste s’il gérait des comptes d’administration dans sa base de compte propre (SC.SSI/IAM.92).

Maintenant, le système doit uniquement conserver les traces des opérations mentionnées qu’il gère localement (SC.SSI/IAM.91) et peut utiliser un MIE sans mot de passe s’il garantit un niveau de sécurité équivalent ou supérieur, par exemple une clé FIDO (SC.SSI/IAM.92).

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

Concrètement :

• Dans la nouvelle version de l'exigence SC.SSI/IAM.91 : possibilité pour chaque scénario de déposer un justificatif expliquant le fonctionnement de l’application et indiquant que l’action n’est pas gérée localement.
• Dans la nouvelle version de l'exigence version SC.SSI/IAM.92 : possibilité de montrer l’authentification au système d’un administrateur pour justifier de l’utilisation d’un MIE sans mot de passe (NB : les codes PIN sont proscrits).

A noter qu'il n'y a aucune obligation pour l'éditeur, il s’agit d’une prise en compte de cas d’usage existants.

Ces exigences SC.SSI/IAM.91 et SC.SSI/IAM.92 définissent la manière dont le système doit tracer certaines opérations et gérer la robustesse des mots de passe administrateurs.

Avant, le système devait conserver les traces de l’ensemble des opérations mentionnées (SC.SSI/IAM.91) et permettre à la structure de santé de mettre en place une politique de mots de passe robuste s’il gérait des comptes d’administration dans sa base de compte propre (SC.SSI/IAM.92).

Maintenant, le système doit uniquement conserver les traces des opérations mentionnées qu’il gère localement (SC.SSI/IAM.91) et peut utiliser un MIE sans mot de passe s’il garantit un niveau de sécurité équivalent ou supérieur, par exemple une clé FIDO (SC.SSI/IAM.92).

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

Concrètement :

• Dans la nouvelle version de l'exigence SC.SSI/IAM.91 : possibilité pour chaque scénario de déposer un justificatif expliquant le fonctionnement de l’application et indiquant que l’action n’est pas gérée localement.
• Dans la nouvelle version de l'exigence version SC.SSI/IAM.92 : possibilité de montrer l’authentification au système d’un administrateur pour justifier de l’utilisation d’un MIE sans mot de passe (NB : les codes PIN sont proscrits).

A noter qu'il n'y a aucune obligation pour l'éditeur, il s’agit d’une prise en compte de cas d’usage existants.

Ces exigences SC.SSI/IAM.91 et SC.SSI/IAM.92 définissent la manière dont le système doit tracer certaines opérations et gérer la robustesse des mots de passe administrateurs.

Avant, le système devait conserver les traces de l’ensemble des opérations mentionnées (SC.SSI/IAM.91) et permettre à la structure de santé de mettre en place une politique de mots de passe robuste s’il gérait des comptes d’administration dans sa base de compte propre (SC.SSI/IAM.92).

Maintenant, le système doit uniquement conserver les traces des opérations mentionnées qu’il gère localement (SC.SSI/IAM.91) et peut utiliser un MIE sans mot de passe s’il garantit un niveau de sécurité équivalent ou supérieur, par exemple une clé FIDO (SC.SSI/IAM.92).

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

Concrètement :

• Dans la nouvelle version de l'exigence SC.SSI/IAM.91 : possibilité pour chaque scénario de déposer un justificatif expliquant le fonctionnement de l’application et indiquant que l’action n’est pas gérée localement.
• Dans la nouvelle version de l'exigence version SC.SSI/IAM.92 : possibilité de montrer l’authentification au système d’un administrateur pour justifier de l’utilisation d’un MIE sans mot de passe (NB : les codes PIN sont proscrits).

A noter qu'il n'y a aucune obligation pour l'éditeur, il s’agit d’une prise en compte de cas d’usage existants.

1. Quel est le changement principal ?
Les anciens scénarios évoquaient une « fenêtre de paramétrage » et ne prenaient pas en compte les nuances liées aux « évènements systèmes ». Les nouvelles exigences imposent que la vérification ou la récupération de l’INS se déclenche automatiquement en tâche de fond, soit à l’ouverture du dossier patient, soit lors d’évènements systèmes planifiés.

2. Quand la vérification est-elle faite ?
À l’ouverture du dossier patient ou lors d’un évènement système planifié.

Annexe – Nouveaux scénarios et jeux de test
SC.INS.13 – Vérification après 4 ans
 

Prérequis :
- Disposer d'un patient dont l'identité est au statut "identité qualifiée" ou "identité récupérée" depuis plus de 4 ans

Vérifier que le système déclenche l’opération de vérification automatiquement, soit à l'ouverture du dossier du patient, soit de façon planifiée pour tous les dossiers dont l'identité a été qualifiée et/ou récupérée depuis plus de 4 ans.
Étapes du scénario :
1. Montrer que le système dispose d'un patient dont l'identité est au statut "identité qualifiée" ou "identité récupérée" depuis plus de 4 ans.
2. Vérifier que le système déclenche l’opération de vérification en tâche de fond soit automatiquement soit à l'ouverture du dossier patient
3. Disposer d’un fichier bouchon qui renvoie « OK » à l’appel de vérification
4. Vérifier que le statut de l’identité et les traits d'identité sont inchangés
Jeu(x) de test à utiliser :
L'ANS met à l'ensemble des jeux de test INS à cette adresse : https://industriels.esante.gouv.fr/produits-et-services/referentiel-ins
Le patient à utiliser pour le test est BRANCHY MAX PATRICK
WS_INS3_verifierInsAvecTraitsIdentite_reponseOK.xml

SC.INS.15 – Vérification et récupération sur évènement système
 

Prérequis :
- Disposer d'un patient dont l'identité est au statut "qualifiée" ou "récupérée", avec un matricule INS de type NIA
- Disposer d'un fichier bouchon qui renvoie KO quand la vérification est appelée.
- Disposer d’un fichier bouchon qui renvoie un code « 00 » (1 seul patient trouvé) lors d’un appel de récupération.
- Disposer d’un fichier bouchon qui renvoie un code « 01 » (pas de correspondance trouvée) lors d’un appel de récupération.

Vérifier que, pour toute identité au statut « Identité récupérée » ou « Identité qualifiée » avec un matricule INS de type NIA, le système lance en tâche de fond lorsqu'un événement système survient, l’opération de vérification.

Cas 1 : Vérification KO + récupération réussie (code 00)
Étapes du scénario :
1- Montrer que le système dispose d'un patient dont le matricule INS est qualifié de type NIA
2- Vérifier que le système déclenche l’opération de vérification en tâche de fond à l'ouverture du dossier patient
3- Montrer la trace de la requête de vérification et le retour KO
4- Montrer la trace de la requête et le retour de l’opération de récupération de l’INSi "00"
5- Après la procédure automatique de récupération, montrer la fiche d’identité du patient est mise à jour et dispose maintenant d’un NIR
 

Jeu(x) de test à utiliser :
L'ANS met à l'ensemble des jeux de test INS à cette adresse : https://industriels.esante.gouv.fr/produits-et-services/referentiel-ins

Cas 1 :
Le patient à utiliser pour le test est BRANCHY MAX PATRICK avec un NIA positionné dans la base locale.
WS_INS3_verifierInsAvecTraitsIdentite_reponseKO.xml
Reponse_numcasINSI_01_CasNominal1.xml
Cas 2 : Vérification KO + récupération échouée (code 01)
Étapes du scénario :
1- Montrer que le système dispose d'un patient dont le matricule INS est qualifié de type NIA
2- Vérifier que le système déclenche l’opération de vérification en tâche de fond à l'ouverture du dossier patient
3- Montrer la trace de la requête de vérification et le retour KO
4- Montrer la trace de la requête et le retour de l’opération de récupération de l’INSi "01".
5- Montrer que dans la fiche patient, le matricule INS et son OID ont été supprimés et que le statut de l’identité a été rétrogradé
6- Montrer l’alimentation de la liste de travail des identités à destination de l’identitovigilance. (seulement si SC.INS.09 est applicable à ce couloir)
Jeu(x) de test à utiliser :
L'ANS met à l'ensemble des jeux de test INS à cette adresse : https://industriels.esante.gouv.fr/produits-et-services/referentiel-ins

Cas 2 :
Le patient à utiliser pour le test est LORMIER RAPHAEL LOUIS.
WS_INS3_verifierInsAvecTraitsIdentite_reponseKO.xml
REP_CR01_Aucune identite trouvee.xml
 

La dernière version de ce document est disponible sur la page dédiée du dispositif concerné ainsi que via son lien de téléchargement direct : 

La date de la version publiée est par ailleurs indiquée sur le lien de téléchargement du document.

Pour votre information, voici un historique des versions publiées : 

La dernière version de ce document est disponible sur la page dédiée du dispositif concerné ainsi que via son lien de téléchargement direct : 

La date de la version publiée est par ailleurs indiquée sur le lien de téléchargement du document.

Pour votre information, voici un historique des versions publiées :