Par suppression, on entend l'accès au document qui n'existe plus : ce document n’est pas ou plus accessible à l’utilisateur car il peut avoir été supprimé, masqué, ou que le PS n'est pas habilité.

Dans tous les cas, il faut l’indiquer à l’utilisateur et celui-ci doit toujours avoir la capacité de le supprimer

Si l’épisode de soins se poursuit, la transaction TD03 peut être renouvelée automatiquement par le logiciel, sans action explicite du professionnel ni du patient.

Cette tolérance a été précisée dans le guide d’intégration DMP, afin de ne pas introduire une contrainte métier irréaliste.

Le consentement n’a pas vocation à être recueilli à chaque consultation. Le consentement est rattaché à un épisode de soins, lequel dépend des modalités de prise en charge :

• Pour un médecin traitant ou un spécialiste suivant régulièrement un patient, l’épisode de soins peut être long et continu.
• Le patient n’a donc pas à redonner son consentement à chaque acte ou consultation.

L’éditeur doit permettre le recueil initial du consentement, la possibilité pour le patient de changer d’avis, sans obligation de clôturer systématiquement l’épisode de soins.

Les durées de conservation sont une responsabilité du responsable de traitement.

En tant qu'éditeur, vos logiciels doivent être capables de gérer deux durées de conservation distinctes :

• Les traces techniques (ex. logs d'erreurs, événements système) pour le support et la maintenance du logiciel, conservées sur une courte période de 6 mois à 1 an (recommandations CNIL).
• Les traces applicatives (ex. journaux d'accès aux dossiers patients) pour des raisons légales et de traçabilité, conservées sur une longue période de 20 ans, conformément à la durée de conservation des dossiers médicaux (article R.1112-7 du code de la santé publique).

Ces traces constituent des données à caractère personnel et il faut donc prévoir des mesures de sécurité adaptées à cette longue durée de conservation, ainsi qu’une information adaptée (par exemple, via les conditions générales d'utilisation (CGU) ou la politique de confidentialité) du responsable de traitement, voire une capacité d’adaptation des durées par ce dernier.

Le numéro RRPS doit être utilisé lorsqu’il existe. Lorsqu’il n’existe pas et qu’un autre numéro national est disponible, l’utilisation de cet autre numéro est tolérée. 

Il n'est pas indispensable de récupérer la totalité des données du professionnel concerné.
A minima doivent être récupérées et utilisées les données d'identification et d’échanges de données :

• numéro RPPS
• nom/prénom
• profession/spécialité
• "catégorie" (professionnel en exercice vs étudiant/interne)
• Adresse(s) MSS.

Les autres données peuvent être récupérées en fonction de l'usage.

Le blocage de l’alimentation du DMP doit être unitaire et choisi par l’utilisateur.
L’utilisateur DOIT effectuer une action pour NE PAS ENVOYER dans le DMP (ex : case à cocher, bouton-radio…).
Cette action DOIT être effectuée pour CHAQUE document qu’il souhaite retenir.
Ce comportement DOIT être par défaut et DOIT être immuable : il NE DOIT PAS être configurable ou débrayable par l’utilisateur.

Non, les exigences sont structurées en éléments de preuve distincts, qui doivent être déposés séparément, à leur emplacement respectif sur la plateforme Convergence, et ce en respectant les formats imposés.

Le code d'erreur 905 doit être envoyé (Cf : https://interop.esante.gouv.fr/ig/hl7v2/trans-cda-r2/error-codes.html)

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.

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

Oui, l’API FHIR de l’Annuaire Santé est prévue pour être interrogée à la demande lors de la rédaction du mail.

Aucun champ supplémentaire n’est exigé.
Vous pouvez toutefois proposer des critères additionnels, mais ceux cités dans l’exigence doivent être présents à minima.

L’interface doit obligatoirement proposer tous les critères suivants : RPPS, nom d’exercice, prénom d’exercice, profession, spécialité, raison sociale, voie/rue, code postal, ville, adresse email MSSanté.