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 ?
- Dispositif: Dossier Patient Informatisé (DPI)
- (-) Dossier Patient Informatisé (DPI)
Oui, l'appel contextuel via PSC du web PS DMP doit obligatoirement être implémenté dans le cadre de la vague 2.
Cette réponse vous a-t-elle été utile ?
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.
Cette réponse vous a-t-elle été utile ?
Le Code officiel géographique (COG) utilisé est bien issu des fichiers officiels INSEE. Certains cas de tests incluent des communes supprimées pour illustrer des cas réels d’historique administratif.
Si l’éditeur constitue une base locale des COG, il doit impérativement l’alimenter et la maintenir à jour à partir de l’ensemble des fichiers disponibles sur le site de l’INSEE (communes actuelles, événements, COG complet).
Cette réponse vous a-t-elle été utile ?
Ce n'est pas exigé dans les fonctionnalités Ségur : c'est au SGL du laboratoire producteur du CR de réaliser cet envoi. Un établissement de santé reste cependant libre d'organiser les flux internes à son SIH selon sa stratégie.
Cette réponse vous a-t-elle été utile ?
Les fonctionnalités vague 2 du DPI doivent permettre à un professionnel d'intégrer au DPI tout document présent dans le DMP qui lui semblerait pertinent pour la prise en charge d'un patient. Il peut donc choisir d'intégrer des CR BIO, mais ce n'est pas une intégration systématique.
Cette réponse vous a-t-elle été utile ?
Non, cela n'est pas interdit. Toutefois dans le cadre des échanges automatisés décrits dans les exigences, seuls sont concernés les CDA.
Cette réponse vous a-t-elle été utile ?
Le code d'erreur 905 doit être envoyé (Cf : https://interop.esante.gouv.fr/ig/hl7v2/trans-cda-r2/error-codes.html)
Cette réponse vous a-t-elle été utile ?
La transmission de données patient à un autre professionnel 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 ?
Le format demandé dépendra du type de document que vous souhaitez transmettre. Nous vous suggérons de consulter les REM en ce qui concerne le format des documents de santé. Vous pouvez consulter l'annexe 5.3 du DSR.
Cette réponse vous a-t-elle été utile ?
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.
Cette réponse vous a-t-elle été utile ?
Non, vos référencements obtenus ne sont pas conditionnés à vos futurs référencements Vague 2.
Cette réponse vous a-t-elle été utile ?
Le test doit être daté de moins d'un an.
Cette réponse vous a-t-elle été utile ?
Le mode d'hébergement est pris en compte au niveau des exigences SSI ainsi que des points de contrôle du test d'intrusion dans le cas où un industriel ou un tiers sous sa responsabilité assure l'hébergement de tout ou partie des composants du système, ou fournit tout ou partie du système sous forme de service (SaaS).
En revanche, les OS ne sont pas pris en compte dans les exigences SSI.
Cette réponse vous a-t-elle été utile ?
Le choix du responsable de la sécurité dépend de la structure de l'éditeur. Cela implique d'identifier les personnes qui ont les compétences et l'expertise pour prendre en charge la sécurité de la solution. Il peut s'agir de responsables sécurité, de développeurs sécurité expérimentés, d'architectes sécurité, etc.
Cette réponse vous a-t-elle été utile ?
La désignation des personnes responsables de la sécurité des produits nécessite les étapes suivantes :
- Identifier les exigences spécifiques de votre produit en matière de sécurité ;
- Évaluer les compétences et l'expérience des membres de votre équipe ;
- Désigner les responsabilités en matière de sécurité en fonction des compétences des membres de l'équipe ;
- Formaliser ces responsabilités dans les rôles et responsabilités de l'équipe.
Cette réponse vous a-t-elle été utile ?
Des recommandations sur la désignation des responsabilités en matière de sécurité sont fournies dans diverses ressources, notamment le guide d'hygiène de l'ANSSI, la PGSSI-S de l'ANS et la norme ISO 27002.
Cette réponse vous a-t-elle été utile ?
La désignation d'acteurs responsables de la sécurité apporte plusieurs avantages, notamment :
- Une meilleure gestion des risques de sécurité ;
- Une responsabilité claire pour les problèmes de sécurité ;
- Une amélioration de la coordination des activités de sécurité ;
- Une sensibilisation accrue à la sécurité au sein de l'équipe de développement ;
- Une conformité aux normes de sécurité.
Cette réponse vous a-t-elle été utile ?
La négligence dans la désignation des responsables de la sécurité peut entraîner un certain nombre de risques, notamment :
- Des failles de sécurité non détectées ;
- Des retards dans la réponse aux incidents de sécurité ;
- Un manque de coordination dans la gestion des risques ;
- Une faible sensibilisation à la sécurité au sein de l'équipe.
Cette réponse vous a-t-elle été utile ?
L'exigence a pour objectif de vérifier si une sensibilisation générale aux enjeux et aux risques à la SSI est menée auprès des équipes du système (équipes de conception, de développement, d'installation, d'exploitation, d'administration, de maintenance, de support, etc.). Il est préconisé d'effectuer cette sensibilisation à minima annuellement pour l'ensemble des équipes et pour chaque nouvel arrivant. Cette sensibilisation peut être effectuée par des équipes de l'éditeur ou des prestataires qu'il choisit librement.
Dans le cas où le système est destiné à traiter des données à caractère personnel, alors la sensibilisation doit intégrer des obligations légales (en particulier le règlement général sur la protection des données) ainsi que des réglementations applicables.
Cette réponse vous a-t-elle été utile ?
La responsabilité de la rédaction du plan d'assurance sécurité du système peut être partagée entre l'éditeur et l'hébergeur ou le fournisseur de services SaaS, en fonction des accords contractuels. Cependant, il est essentiel que ce plan soit clairement et doit contenir :
- Le cadre juridique : les références légales, les réglementations et les obligations contractuelles liées à l'hébergement du système, en précisant les responsabilités et les droits des parties impliquées, etc. ;
- Les mesures de sécurité : les dispositions et les procédures de sécurité mises en place pour protéger le système hébergé (ex: contrôles d'accès, protection des données, etc.) ;
- Les engagements entre l'hébergeur et la structure utilisatrice comme par exemple des garanties de disponibilité, des délais de réponse en cas de problème, des mesures de résilience en cas de panne, etc. ;
- L'environnement de mise en œuvre du système : il s'agit de décrire l'environnement technique et opérationnel dans lequel le système doit être déployé (ex: configuration réseau, connectivité, etc.).
Cette réponse vous a-t-elle été utile ?
Vous ne trouvez pas la réponse à votre question ?
Posez nous votre question !
Besoin d'une mise en relation avec nos experts dédiés ?
