Votre question concerne quel type d'offre ?
Votre question concerne quel couloir Ségur ?
Votre question concerne quel dispositif Ségur ?
Votre question concerne quel produit ou service produit?
Votre question concerne quelle thématique ?
- Dans le cas d'un CDAR2N1, le PDF à mettre en pièce jointe doit être identique à celui encapsulé dans le CDA.
- Dans le cas d'un CDAR2N3, "Le document de santé au format PDF doit afficher tous les éléments de l’entête du document CDA ainsi que les zones textuelles des différentes sections du corps du document CDA."
Cette réponse vous a-t-elle été utile ?
Oui, il est en effet recommandé que la récupération de l'INS soit seulement effectuée par le référentiel d'identité mais il n’est pas interdit que d’autres logiciels appelle le téléservice INSi et récupère l'INS. Dans le cas où celle-ci est récupérée par le RI, elle peut ensuite être véhiculée aux autres logiciels via un connecteur d'interopérabilité.
Cette réponse vous a-t-elle été utile ?
La transmission de données patient via MSSanté n'implique pas de disposer d'une identité INS qualifiée. Dans le cas ou l'INS du patient n'est pas qualifiée, le document transmis ne doit pas contenir l'INS et OID.
Cette réponse vous a-t-elle été utile ?
L'INS doit être utilisée pour référencer les données de santé produites dans la cadre de la prise en charge sanitaire ou le suivi médico-social de la personne. Seuls les acteurs de la santé et du médico-social concourant à la prise en charge de l’usager, au suivi médico-social de la personne, ou menant des actions de prévention sont tenus d’utiliser l'INS. Il convient donc de s'assurer que les documents respectent bien ce cadre et sont porteurs de l'INS.
A noter : les documents réalisés à des fins de facturation, destinés à des organismes de sécurité sociale ou à des organismes d'Assurance Maladie complémentaire ne doivent pas contenir l'INS.
Cette réponse vous a-t-elle été utile ?
Le système désigne le LGO donc la visualisation doit se faire au travers du LGO. En revanche, comme il s'agit d'une préconisation, le développement de cette fonctionnalité n'est pas obligatoire pour le référencement vague 1. Elle le deviendra pour la vague 2.
Cette réponse vous a-t-elle été utile ?
Nous nous situons au niveau local avec répercussion sur le DMP et la MS Santé comme pour le cas d'une modification. Si le document est supprimé uniquement dans le DMP et pas en local (ex : le patient fait la suppression lui-même), il n’y a pas besoin d'informer les destinataires MS Santé.
Pour rappel, le pharmacien ne peut pas supprimer ou modifier directement un document dans le DMP, il doit le faire depuis son LGO pour répercuter ensuite la mise à jour ou la suppression dans le DMP. Ceci assure une synchronisation entre DMP et logiciels métiers.
Cette réponse vous a-t-elle été utile ?
Vous devez demander le raccordement à Pro Santé Connect en remplissant le formulaire dédié, disponible ici.
Cette réponse vous a-t-elle été utile ?
Un client lourd est un logiciel installé sur un ordinateur en réseau ou non. Dans ce cas la plupart des ressources sont installées en local à la différence d’un client léger. Dans le cas d’un client léger, les ressources sont installées sur un réseau.
Vous avez l'obligation de sélectionner un des deux profils pour proposer Pro Santé Connect à vos clients.
Vous n'avez pas d'obligation de réponse à cette exigence si vous avez la possibilité de vous connecter à un autre opérateur que Mailiz pour fournir les preuves d'envoi de message MSSanté.
Vous avez la liste exhaustive des domaines de messagerie Mailiz sur la liste blanche accessible ici ( LIEN : https://espacedeconfiance.mssante.fr/listeblanchemssante.xml )
Cette réponse vous a-t-elle été utile ?
Que ce soit pour une modification ou une suppression, le procédé reste le même. Le système doit toujours proposer d'envoyer un email au(x) destinataire(s) initiaux.
Cette réponse vous a-t-elle été utile ?
Non, chaque preuve doit être déposée séparément dans le formulaire en suivant scrupuleusement les formats imposés.
Cette réponse vous a-t-elle été utile ?
L’accès par client lourd en CIBA à Pro Santé Connect n’étant pas initialement inclus dans la vague 1 du Ségur, une dérogation a été mise en place. Cette dernière permet de tolérer un accès par client lourd en CIBA à Pro Santé Connect au lieu de l’accès par client lourd via une application native avec renvoi vers navigateur externe attendu et s’applique uniquement à la vague 1 du Ségur.
Le scénario attendu est le suivant :
- Scénario - application native : Accès par client lourd en CIBA
- Vérifie les exigences du référentiel PSC : EX PSC 01, 03, 04, 05, 08, 09, 10, 14, 15, 20, 25, 28, 29, 30, 31
- Prérequis : la vidéo doit être en plein écran :
- Etapes de la vidéo de preuve :
- Afficher la page des CGU du service ou un autre document que l'utilisateur peut consulter facilement avant utilisation du service ayant une page web dédiée accessible via un lien ou un contrat entre l'utilisateur et le service, par contrat peut être entendu un document que l'utilisateur valide en cochant une case
- Parcourir les CGU jusqu'au paragraphe PSC
- Fermer les CGU
- Se rendre sur la zone d'interface utilisateur qui gère la connexion
- Action de lancement de la connexion à PSC
- Authentification par CPS ou eCPS valide
- Affichage de la zone du logiciel indiquant que la connexion est valide
- Se rendre sur la zone d'interface utilisateur qui gère la déconnexion
- Action de lancement de la déconnexion
- Action de lancement de la connexion à PSC
Cette réponse vous a-t-elle été utile ?
Non, l’ordre d’affichage des traits n’est pas une exigence. Néanmoins, il convient de respecter l’exigence SI 11 du RNIV : « Les traits d’identités affichés conformément à la réglementation doivent pouvoir être facilement distingués, sans risque d’équivoque, par les acteurs concernés ».
Cette réponse vous a-t-elle été utile ?
Il faudra à minima que l’INS apparaisse au moins 1 fois sur le document.
Cette réponse vous a-t-elle été utile ?
Non, cette vérification "en masse" n’est pas exigée dans le cadre des DSR Vague 1. Les textes exigent néanmoins que les INS présentes dans une base de données soient vérifiées a minima tous les 5 ans. Votre solution doit donc permettre à vos clients d'assurer une vérification de leur base d'INS dans ce délai.
Cette réponse vous a-t-elle été utile ?
Non, les DSR vague 1 n'imposent pas un type d'inferface spécifique avec un opérateur MSSanté.
Cette réponse vous a-t-elle été utile ?
L'éditeur doit à minima préciser les éléments suivants :
- pour quelle raison des pièces d’identité sont-elles stockées et dans quel(s) cas un accès ultérieur à ces documents est-il prévu ?
- les principes du RGPD sont-ils appliqués (protection des données stockées, information du patient, etc.) ?
- algorithme de chiffrement utilisé et taille des clés,
- modalités de gestion de la durée de conservation,
- précisions sur la "gestion des secrets" :
- de quelle façon les clés de chiffrement sont-elles générées ?
- de quelle façon les clés de chiffrement sont-elles protégées ?
- qui peut y accéder ?
- comment sont-elles gérées dans le temps ?
- comment s’exécute le processus de déchiffrement d’un document préalablement chiffré lorsque celui-ci est nécessaire ?
Cette réponse vous a-t-elle été utile ?
Oui la pièce justificative ayant été utilisée pour s’assurer de la cohérence entre l’identité physique et numérique doit être sélectionnée.
Néanmoins un utilisateur n’est pas obligé de scanner et d’insérer dans son SI la pièce justificative lui ayant permis de valider / qualifier l’identité.
Pour rappel, le statut validé peut-être attribué de deux manières :
- l'utilisateur peut manuellement indiquer que l'identité est validée.
- le statut validé peut automatiquement être déduit en fonction de la nature de la pièce justificative sélectionnée.
A noter : la solution doit obligatoirement proposer la première option. Si la seconde option est proposée, celle-ci doit être désactivable.
Cette réponse vous a-t-elle été utile ?
En vertu du RGPD vous devez déjà tracer l’accès aux données de santé à caractère personnel. Le fait de rajouter l’INS à ces données de santé à caractère personnel ne change rien. Il sera simplement vérifié que cette traçabilité est faite. Cette exigence sera vérifiée en s'assurant que lorsqu'un acteur accède au dossier d'un usager - doté ou non d'une INS (ouvre le dossier de cet usager) - cet accès est tracé dans la solution.
Cette réponse vous a-t-elle été utile ?