784 questions / réponses
784 questions / réponses
Oui, l’API FHIR de l’Annuaire Santé est prévue pour être interrogée à la demande lors de la rédaction du mail.
Cette réponse vous a-t-elle été utile ?
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.
Cette réponse vous a-t-elle été utile ?
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é.
Cette réponse vous a-t-elle été utile ?
Oui, l’API FHIR de l’Annuaire Santé est prévue pour être interrogée à la demande lors de la rédaction du mail.
Cette réponse vous a-t-elle été utile ?
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.
Cette réponse vous a-t-elle été utile ?
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é.
Cette réponse vous a-t-elle été utile ?
Pour rappel, les exigences ETH.13 et ETH.14 sont les suivantes : "S’il existe un lien d’intérêt entre la société éditrice du système et des acteurs de l’écosystème de la santé, le système doit garantir, d’une part, la bonne compréhension de ce lien par le professionnel de santé utilisateur et, d’autre part, l’information et la bonne compréhension du patient."
Le lien d’intérêt désigne l’ensemble des relations ou intérêts, directs ou indirects, actuels ou passés, qu’une société peut entretenir avec un tiers, dès lors que ces relations sont en lien avec l’objet de son activité. Dans le cadre d’un système de téléconsultation, cela concerne notamment les partenariats entretenus avec des établissements de santé, mutuelles, laboratoires, entreprises technologiques, prestataires techniques, éditeurs de logiciels ou tout autre acteur économique. L’objectif de ces exigences est d’assurer une transparence totale sur les partenariats et liens d'intérêt susceptibles d’influencer l’usage du système ou les décisions de prise en charge, afin de prévenir tout risque de conflit d’intérêts et de maintenir la confiance des professionnels de santé et des patients.
Pour répondre à ces exigences, il est attendu de la société éditrice qu’elle mette à disposition des documents clairs, accessibles et explicites décrivant l’ensemble des liens d’intérêt existants, en précisant la nature des relations, qu’elles soient contractuelles, financières, techniques ou stratégiques, sans ambiguïté. Ces informations doivent permettre au professionnel de santé de comprendre précisément le cadre de ces relations et au patient d’être correctement informé de leur existence et de leur nature. Elles doivent figurer dans des documents officiels tels que les Conditions Générales d’Utilisation, la politique de confidentialité ou tout autre support contractuel mis à disposition des utilisateurs, et être tenues à jour.
Cette réponse vous a-t-elle été utile ?
Pour rappel l’exigence ETH.26 est la suivante : "Si les données recueillies avant, pendant, après la téléconsultation sont partagées avec d'autres acteurs, notamment des sous-traitants, ALORS le Système DOIT garantir la bonne compréhension par le patient de l’existence de ce partage et de sa finalité."
Pour répondre à l’exigence ETH.26, l’information relative au partage des données du patient doit être formulée de manière claire, explicite et accessible. Le patient doit comprendre que ses données peuvent être partagées, avec quels acteurs ou sous-traitants, et dans quel objectif précis (hébergement, maintenance technique, analyse statistique, etc.).
Les destinataires des données doivent être clairement identifiés, au moyen d’une liste transparente et facilement accessible, intégrée notamment dans la politique de confidentialité, les Conditions Générales d’Utilisation ou tout autre document porté à la connaissance du patient.
En complément, le système doit prévoir un mécanisme de reconnaissance explicite attestant que le patient a pris connaissance de cette information et la comprend (case à cocher, formulaire de consentement, ou dispositif équivalent), afin d’en garantir la traçabilité et de permettre au patient d’exercer pleinement ses droits en matière de protection des données.
Cette réponse vous a-t-elle été utile ?
Le corpus documentaire associé au projet DRIM-M comporte deux éléments définissant l'affichage de l'intégralité des traits stricts INS au sein de l'interface DRIMBox consommatrice : l'exigence INS/va1.36 issue du REM DRIM-M ainsi que la section 4.6.2 de la spécification projet DRIMBox.
Ainsi, l'utilisateur doit être en mesure de consulter les données d'identification patient suivantes au démarrage de la DRIMBox :
- Nom de naissance : affichage par défaut au lancement de l'interface utilisateur.
- Premier prénom de naissance : affichage par défaut au lancement de l'interface utilisateur.
- Date de naissance : affichage par défaut au lancement de l'interface utilisateur.
- Sexe : affichage par défaut au lancement de l'interface utilisateur.
- Lieu de naissance : affichage par défaut au lancement de l'interface utilisateur.
- Matricule INS : affichage possible via paramétrage de l'utilisateur. (existence du champ obligatoire)
- Nature du matricule INS (OID) : affichage possible via paramétrage de l'utilisateur. (existence du champ obligatoire)
- Liste des prénoms de naissance : affichage possible via paramétrage de l'utilisateur. (existence du champ obligatoire)
- Prénom utilisé : affichage possible via paramétrage de l'utilisateur. (existence du champ obligatoire)
- Nom utilisé : affichage possible via paramétrage de l'utilisateur. (existence du champ obligatoire)
En considérant le workflow global de consultation de données de santé associé à la fonction consommatrice DRIMBox, deux flux permettent à cette dernière d'avoir connaissance de l'intégralité des traits stricts INS du patient ciblé :
- Transaction d'appel contextuel initiée par un système LPS à destination de la solution DRIMBox (Cf. section 4.6.1 de la spécification projet DRIMBox). Dans le cadre de cette interaction, le LPS transmet les traits INS suivants à la solution DRIMBox : Nom de naissance ; Premier prénom de naissance ; Date de naissance ; Sexe ; Lieu de naissance ; Matricule INS ; Nature du matricule INS (OID).
- Transaction TD3.1 initiée par la solution DRIMBox vers l'environnement DMP afin de récupérer les lots de soumission associés aux documents publiés sur ce dernier. Suite à cette interaction, la solution DRIMBox récupère l'intégralité des traits INS associés au patient ciblé (au travers des métadonnées "sourcePatientId" et "sourcePatientInfo").
Ainsi, parmi l'exhaustivité des traits stricts INS, trois d'entre eux ne peuvent être connus de la fonction consommatrice DRIMBox qu'à la suite d'une transaction TD3.1 vers le DMP : Liste des prénoms de naissance ; Prénom utilisé ; Nom utilisé.
Par conséquent, le workflow associé au lancement de la fonction consommatrice DRIMBox a été défini afin de tenir compte de ces aspects, pour rappel :
- Mise en oeuvre d'une transaction d'appel contextuel, initiée par un système LPS à destination de la fonction consommatrice DRIMBox.
- Authentification de l'utilisateur via ProSantéConnect.
- Interaction TD3.1 entre la solution DRIMBox et l'environnement DMP permettant de récupérer les métadonnées XDS associées aux documents d'intérêt publiés sur le DMP.
- Ouverture de l'interface DRIMBox (fonction consommatrice) présentant les résultats de la transaction TD3.1.
Au sein du workflow présenté ci-dessus, la combinaison entre les étapes n°1 et n°3 implique que l'intégralité des traits stricts INS du patient soient connus de la solution DRIMBox au démarrage de son interface.
Cette réponse vous a-t-elle été utile ?
Afin de garantir la compatibilité avec les nouvelles cartes CPx4, une mise à jour de la Cryptolib en version 5.2 minimum est requise.
Par ailleurs, pour l’usage sans contact, les lecteurs doivent être compatibles avec le protocole MIFARE DESFire EV3.
À noter :
- les cartes CPx3 actuellement déployées restent utilisables jusqu’à leur échéance ;
- les cartes CPx4 commencent à être distribuées progressivement selon les professions.
Pour vous accompagner, consultez le guide « Je mets à jour ma Cryptolib ».
Cette réponse vous a-t-elle été utile ?