Périmètre logiciel ciblé

La vague 1 de la Task-Force s’adresse aux éditeurs de RIS uniquement.

Les fournisseurs de RIS peuvent s’associer à d’autres logiciels en sous-traitance ou en cotraitance (Plateforme d’intermédiation – PFI – ou DPI possédant le rôle de PFI), par exemple pour assurer la fonction de transport des Compte-Rendu D’Imagerie afin d’alimenter le DMP et échanger en MSSanté.

Liste des logiciels ciblés

Ce document s’adresse à différents types de fournisseurs de logiciels :

Fournisseurs de Système RIS

Si le RIS est associé à un autre logiciel :

Fournisseurs de Connecteurs (PFI ou DPI faisant rôle de PFI) pour l’Alimentation du DMP, interfacés au RIS
Fournisseurs de Connecteurs (PFI ou DPI faisant rôle de PFI) pour l’échange des Comptes-Rendus d’Imagerie Médicale interfacés au RIS, via le système de messagerie sécurisée de Santé (MSSanté), pour échanges avec les PS demandeurs et la messagerie citoyenne.

Définition d’un RIS (Radiology Information System) ou SIR (Système d’Information Radiologique)

Un Système d’information radiologique (ci-après le RIS) est défini comme l'outil métier des radiologues qui assure l'ensemble des fonctions suivantes : gestion des rendez-vous patients, programmation des modalités d’imagerie, génération et envoi des comptes rendus de radiologiques. Un RIS met à disposition une liste de travail “Dicom Modality Worklist” et produit au minimum des messages HL7 de type ADT, ORU et ORM. L’Agence du Numérique en Santé (ANS) se réserve le droit de demander les pièces justificatives de l’éligibilité du logiciel dans le cadre de la procédure de référencement.

Les SIR font partie des SIH (Systèmes d'Information Hospitaliers).

Ils s'intègrent avec les PACS (Picture Archiving and Communication System).

Les domaines concernés par cette Task-Force sont : la Radiologie Conventionnelle, la Mammographie, le Scanner, l’Imagerie par Résonnance Magnétique (IRM), l’échographie.

Ne sont pas éligibles au référencement les logiciels suivants :

Logiciels de Cardiologie ;
Logiciels d’Imagerie Dentaire ;
Logiciels de Génétique ;
Lecteurs de documents marqués ;
Middleware (connexion d’automates, microbiologie sans papier) ;
Catalogues d’examens ;
Systèmes experts d’aide à la décision ;
Logiciels de prescription connectée ;
Serveurs de résultats ;
Logiciels de gestion documentaire et de qualité ;
Logiciels de gestion des stocks.

Les PACS et VNA ne sont pas éligibles à la vague 1.

Les structures en Radiologie

Liste des structures possibles en radiologie :
Cette liste n’est pas exhaustive, un radiologue peut utiliser une autre structure suivant un nouveau cadre juridique proposé par l’Administration qui est non répertorié à ce jour.

Les Structures en Radiologie :	Identification de la Structure :
Cabinets de radiologie de groupe organisés en SCM (Société Civile de Moyen)	Ces structures ne portent pas d’exercice d’une activité
Cabinets de groupe organisés en SEL (Société d’Exercice Libéral)	Ces structures sont identifiées par un SIRET
GIE (Groupement d’Intérêt Economique) identifiés par un FINESS	Ces structures sont identifiées par un FINESS et SIRET
Etablissements de Santé Hospitaliers Privés et Publics	Ces structures sont identifiées par des FINESS et SIRET

Point d’attention sur les structures SCM (Société Civile de Moyen) :

Des certificats de type RPPS-Rang sont mis à disposition par l’ANS pour que ces structures s’identifient sur les services socles.
Le RPPS-Rang permet d’identifier la structure (le cabinet de radiologie).
Il correspond strictement au numéro RPPS du médecin, auquel on ajoute un indice.

Délivré à raison d’un certificat par PS et par site pour les SCM de radiologie sur plusieurs sites.

Exemple : Un cabinet de radiologie, où exercent 6 radiologues et possédant 2 sites (1 pour l’imagerie conventionnelle et 1 pour la résonnance magnétique) : chaque radiologue doit être doté de 2 RPPS-rang (1 pour chaque site).

Périmètre fonctionnel RAD-RIS-Va1

Pour bénéficier du référencement, une Solution logicielle doit répondre à l’ensemble des exigences décrites dans le référentiel d’exigences et de scénarios de conformité REM-RAD-RIS-Va1.

Note : Les éditeurs candidats au référencement Ségur doivent prendre connaissance de l’ensemble du DSR et des référentiels associés.

Le périmètre RAD-RIS-Va1 couvre notamment les aspects suivants :

Consultation du Web PS DMP avec l’appel contextuel (TD0.9 avec contexte INS patient) ; Intégration de Pro Santé Connect (PSC), dans le respect du référentiel PSC pour les fournisseurs de service, publié fin mai 2021 ;
Implémentation de l’Identité Nationale de Santé (INS), dans le respect du référentiel INS, du guide d'implémentation INS et du référentiel national d'identitovigilance (RNIV), ainsi que :

- La gestion de l’identité entrante depuis le référentiel des identités (IHE PAM, HL7 ADT, etc.) ;

- L’appel du téléservice INSi selon le guide d’intégration, via CPx et via certificats logiciels de type organisation (CL-ORG) ;

Génération et visualisation du Compte-Rendu D’Imagerie en CDA R2 N1 avec PDF/A-1 conformément au CI-SIS, Compte-Rendu d’Imagerie avec les informations non structurées.
Envoi systématique et automatisé au DMP Version 2.4 ou supérieur, éventuellement via un connecteur partenaire (CDA R2 N1, ce dernier n’étant prévu que pour une période transitoire de 2 ans, avec, au 1er janvier 2024, l’envoi au DMP uniquement du CDA R2 N3), avec possibilité de modification / retrait.
Envoi systématique et automatisé par MSSanté éventuellement via un connecteur partenaire (CDA R2 N1 et PDF « nu ») au patient et au professionnel, avec les éventuelles versions correspondantes, depuis une boite aux lettres applicative ou nominative du RIS, avec possibilité d’envoi de correctifs et de compléments, conformément au RGPD.

Envoi par Messagerie Sécurisée de Santé citoyenne : le Référentiel socle MSSanté #2 (Clients de Messageries Sécurisées de Santé) prévois une dérogation jusqu’à fin 2022 permettant d’écrire à un usager sans avoir qualifier son INS. En cohérence avec les ambitions Ségur, cette dérogation ne s’applique évidemment pas au DSR Radiologie (ainsi qu’aux autres DSR).
Pour le contexte hospitalier et dans la perspective d’un envoi au DMP et par MSSanté éventuellement géré au travers de connecteurs et/ou du DPI/PFI, la capacité de transmettre à une PFI ou DPI faisant rôle de PFI les CDA R2 N1 à travers un flux HL7 v2 via des messages ORU/MDM, avec données de masquage et de connexion secrète pour les cas où c’est nécessaire (Patients mineurs, consultation d’annonce, etc.) ;
Utilisation des normes d’échanges de données ainsi que du Cadre d’Interopérabilité des Systèmes Informatiques de Santé (CI-SIS) pour la construction des messages, dans le respect du règlement général sur la protection des données (RGPD).
Mise en œuvre d’un appel Contextuel sortant du RIS, spécification à rédiger par l’éditeur.

L’éditeur doit aussi évaluer la maturité de la solution candidate au référencement Ségur en termes de couverture des risques de Sécurité des Systèmes d’Information (SSI).

Gestion de l’Identité Nationale de Santé (INS)

Rappel : L’identité nationale de santé (INS) est un projet au cœur de la feuille de route du numérique en Santé. Ce projet vise l’utilisation par l’ensemble des acteurs d’une même identité : l’INS. [INS3]

Description des référentiels à prendre en compte dans la Vague 1 :

Guide D’implémentation INS : Ce document a été élaboré avec la participation des référents métiers et systèmes d’informations de structures de santé et de régions (ARS et GRADeS).
Il s’adresse aux fournisseurs de logiciels concernés par le référencement des données de santé avec l’INS.
Il décline à leur attention les règles définies dans le référentiel INS et dans le référentiel national d’identitovigilance (RNIV).

Ce document a donc pour objectif d’homogénéiser, par la définition de règles de gestion communes, la mise en œuvre de l’INS à travers le territoire, dans le respect du RNIV.

Périmètre : Les actions de mise en œuvre de l’INS se concentrent sur les règles de gestion nécessaires au bon référencement des données de Santé INS dans les logiciels.
Il ne décrit pas les actions à mettre en œuvre pour s’assurer que l’usager pris en charge (physiquement ou à distance) correspond à l’identité numérique utilisée (lors de sa prise en charge administrative ou médicale). Ces actions sont décrites dans le RNIV.

Points d’attention : pour rappel, les solutions logicielles doivent être conformes avec l’ensemble du référentiel INS Version 2, y compris pour le périmètre non explicitement repris dans le présent DSR (arrêté du 27 mai 2021).

L’exhaustivité des exigences demandées dans le cadre du Référencement sont présentées dans référentiel d’exigences et de scénarios de conformité REM-RAD-RIS-Va1.

Téléservice Identité Nationale de Santé (INS) INSi [INS2] : Ce document, élaboré par le GIE SESAM-VITALE décrit tous les aspects fonctionnels et techniques du téléservice INSi.

Le téléservice INS intégré au LPS (INSi) permet aux seuls acteurs de la santé et du médico-social respectant les conditions de sécurité rappelées par le référentiel INS[INS1] d’acquérir l’INS et les traits d’identité de référence d’un patient pour répondre aux finalités prévues par les textes encadrant l’usage de l’INS.

Mise en Œuvre Certificat Logiciel (Annexe 3) : Dans le cadre de la vague 1 du Ségur, la solution RIS doit implémenter l’authentification TLS mutuelle par certificat Logiciel pour appeler le téléservice INSi.

Référentiel Identité National de Santé [INS1] : Le référentiel INS, décrit les conditions et modalités de mise en œuvre de l’obligation de référencement des données de santé avec l’identité INS.

Ce référentiel concerne notamment le référencement des données de santé avec le numéro d’inscription au répertoire national d’identification des personnes physiques (NIR) ou le numéro identifiant d’attente (NIA) uniquement pour la prise en charge sanitaire et le suivi médico-social (les autres usages du NIR ne sont pas couverts).

Data matrix INS[INS5] : A la demande d’acteurs terrains, une spécification du format de transmission des données de l’identité Nationale de Santé dans un code Data matrix sous forme d’un code à barres.

Homologation CNDA : Afin de candidater au référencement du Ségur du Numérique en Santé, le logiciel RIS doit passer une homologation CNDA.
L’homologation du logiciel sera pilotée directement par le Centre National de Dépôt et d’Agrément, un justificatif est demandé dans le cadre du référencement.

Compte-Rendu D’imagerie Médicale

Format du Compte-Rendu D’Imagerie Médicale : Le contenu du Compte-Rendu n’est pas contraint par l’appel 1 SEGUR, nous apportons uniquement quelques précisions sur l’horodatage et les informations minimales.

Le format d’export doit être le CDA-R2-N1, le Compte-Rendu sera généré en suivant le volet Structuration Minimale [CISIS1].

Le code du document doit être 18748-4. Ce numéro est référencé dans la Nomenclature des Objets de Santé de l’ANS (JDV_J66-TypeCode-DMP), il correspond au Compte-Rendu D’Imagerie Médicale.

Statut du Compte-Rendu D’imagerie : Un statut doit être mis en place au niveau du RIS sur le Compte-Rendu d’Imagerie, nous recommandons le nom du statut « Validé ».

Un Compte-Rendu est validé si le radiologue valide l’interprétation finale de l’examen réalisé.
Cette validation porte l’information date, heure de validation et signataire (Nom et RPPS du Radiologue), ces informations doivent également apparaitre dans le contenu du Compte-Rendu.

Contenu du Compte-Rendu :

Dans le cadre du référencement et de l’appel 1 voici les informations que nous jugeons nécessaire de voir sur un Compte-Rendu d’Imagerie. La liste est non exhaustive, nous ne rentrons pas dans le détail des éléments d’interprétations données par le médecin qui doivent s’afficher en plus.

INS du patient si celui-ci a le statut Identité qualifiée
Nom, Prénom, sexe du patient
Date de Naissance
Nom de Jeune fille
Date et Type d’Examen
Date et heure de la validation du Compte-Rendu
Nom du Radiologue, Fonction, RPPS
Identité du Demandeur (Spécialité et Coordonnées)

Trajectoire d’envoi du Compte-Rendu D’Imagerie : Un compte-Rendu d’Imagerie dès sa validation par le radiologue doit alimenter le DMP du patient et être échangé en MSSanté vers le PS Demandeur et Patient automatiquement en respectant les restrictions pouvant être présentes et le délai maximum, en terme d’interopérabilité cette trajectoire doit être sous la forme d’un Y (DMP et MSSanté) porté par le RIS ou le PFI (ou DPI possédant le rôle de PFI)

Point D’attention : Si dans une structure Hospitalière le demandeur est un utilisateur du DPI alors l’échange MSSanté peut ne pas être réalisé si le demandeur intervient directement sur le dossier patient informatisé de la structure et si celui-ci est centralisé pour l’ensemble de l’établissement, cette préconisation permet au clinicien de privilégier un seul accès pour consulter le Compte Rendu D’Imagerie Médicale directement sur le DPI de l’établissement.

Annonce : Si le Compte-Rendu d’imagerie comporte des informations nécessitants une annonce, un mécanisme d’annonce doit être proposé par le RIS pour rendre invisible le Compte-Rendu tant que l’annonce n’a pas été réalisée.

Dans le cas où l’annonce est réalisée par le radiologue, cette annonce doit pouvoir être horodatée et tracée dans le RIS.

Nous suggérons de voir apparaitre ces informations quand une annonce est réalisée à côté du Compte-Rendu dans l’IHM du RIS :

Date et Heure de L’annonce
Nom du Radiologue qui réalise l’annonce avec son RPPS
Champ Description pour expliquer le contexte de l’annonce

Les Comptes Rendus non validés et provisoires : Un compte rendu d’imagerie peut prendre du temps avant d’être validé si le radiologue a besoin de précisions sur l’examen ou doit s’entretenir avec ses confrères, le RIS doit proposer le statut « Provisoire » pour ces Compte-rendu.

Le logiciel doit mettre à disposition une liste de travail qui permet d’afficher sur une période donnée l’ensemble des comptes rendus non validés et provisoires.

Un compte-rendu avec le statut provisoire est un Compte-rendu qui devra passer au statut validé dès que le radiologue aura terminé son interprétation.

Un compte-rendu non validé peut-être un compte-rendu oublié ou avec une erreur, dans ce cas il ne doit pas rester avec le statut non validé mais pourra être archivé ou supprimé pour éviter de ressortir en alerte.

Un Compte-rendu peut rester avec un statut provisoire sur un délai de 48h maximum, si le délai est dépassé un mécanisme de notification doit être mis en œuvre pour rappeler au radiologue qu’il doit passer ce compte-rendu en état validé ou l’archivé.

Un paramétrage dans le RIS doit permettre de régler ce mécanisme et délai.

Appel Contextuel RIS

Le RIS doit proposer un appel contextuel sortant pour accéder par exemple aux images du PACS.

Exemple URL à paramétrer en mode GET : http://exemple?matINS=260058815400233&OID= 1.2.250.1.213.1.4.8&lowerDateTime=2013-12-02T14:01:00&DateNaissance=1999-08-07&NomNaissance=CHABERT&PrenomNaissance=ROBERT&sexe=M&CodeLieuNaissance=88154&lit=326P&user=JJM&mdp=56e94d5ac6bc64d766b299da666c84f1

A noter, il n’y a pas d’encodage de caractère en mode GET

Exemple URL en POST : matINS=260058815400233& OID= 1.2.250.1.213.1.4.8& DateNaissance=1999-08-07&NomNaissance=CHABERT&PrenomNaissance=ROBERT&sexe=M&CodeLieuNaissance=88154&user=JJM&mdpMD5=56e94d5ac6bc64d7666c84f1&

A noter l’encodage du caractère : est %3A en mode POST (RFC 3986).

Appel Contextuel Sortant : Il doit être possible de mettre en œuvre un appel contextuel du RIS vers un logiciel externe (Exemple un PACS) en passant l’INS complet avec ses traits stricts.

Cet appel sera construit sous la forme d’une URL en POST ou GET, le RIS peut aussi implémenter l’appel d’un exécutable via un batch.

Point d’attention : Une exigence est positionnée pour insérer l’INS dans les paramètres de l’appel.

L’éditeur doit proposer sa propre spécification pour la construction et l’implémentation de l’appel contextuel sortant, une vérification de la documentation de l’appel contextuel est demandée.

Volet Interopérabilité

Spécification ORU/MDM [CISIS4] :

Les structures hospitalières souhaitent majoritairement alimenter le DMP et échanger en MSSanté depuis un connecteur unique.
La trajectoire d’urbanisation est de permettre à un PFI ou un DPI possédant le rôle de PFI de concentrer tous les documents réceptionnés depuis les applications métiers comme les RIS pour ensuite réaliser l’alimentation du DMP et l’échange en MSSanté.

Afin de répondre à ce besoin nous avons rédigé une spécification sur les messages ORU ou MDM qui permet de décrire la transmission d’un document créé depuis un émetteur RIS vers un PFI (ou DPI possédant le rôle de PFI).

Point d’attention : Cette spécification s’inspire de plusieurs profils IHE mais ne rentre pas dans le détail de la construction d’un message ORU ou MDM.
Nous considérons que ces standards sont connus des éditeurs.

La spécification décrit comment le document doit être véhiculé dans le message (Compte Rendu Imagerie Médicale en CDA-R2-N1 encodé en base64), elle va décrire uniquement les données spécifiques pour alimenter le DMP et réaliser l’échange MSSanté), les autres métadonnées nécessaires aux transactions XDS ou à la création de l’archive IHE-XDM ne rentrent pas dans le périmètre de cette spécification, elles seront récupérées directement dans l’en-tête CDA par le PFI ou le DPI possédant le rôle de PFI.
Le PFI (ou DPI/PFI) doit construire le message XDS à destination du DMP conformément au guide d’intégration DMP [DMP1] et au volet Partage Documents du CI-SIS et réaliser l’échange MSSanté conformément au volet d’échange de documents du CI-SIS.

Une PFI peut assurer un rôle partage ou échange ou les 2 rôles suivant le contexte, la consultation du document n’est pas forcément nécessaire sur la PFI, elle doit par contre s’assurer de lire le message et décoder le Compte Rendu d’imagerie médicale réceptionné pour récupérer les métadonnées de l’en-tête du CDA.

Spécifications HL7 pour le Transport de l’INS :

Le transport de l’INS dans les échanges de données s’appuie sur les standards d’interopérabilité en Santé.
L’exigence 33 du Guide d’implémentation de l’INS[INS3] précise que l’INS doit être véhiculée sur les flux de données en sortie.
Dans le cadre de la vague 1, les ½ connecteurs entrants et sortants au format HL7 doivent véhiculer une INS qualifiée avec ces traits stricts suivant les règles en vigueur.

½ connecteurs Sortants : Le RIS doit savoir insérer dans le message l’INS suivant les règles de l’INS.
½ connecteurs Entrants : Le RIS doit savoir extraire du message l’INS suivant les règles de l’INS.

Le Système doit produire le Compte-Rendu d’Imagerie au format CDA-R2-N1 en se référant au volet Structuration Minimale du CI-SIS [CISIS1] qui précise le transport de l’INS.

Liste des référentiels pour les flux en HL7 v2 :

Il y a deux référentiels identifiés pour véhiculer l’INS sur un message HL7, ces référentiels peuvent être utilisés sur les versions HL7: 2.3.1, 2.4 et 2.5 et sur les différents flux HL7 du tableau ci-dessous.

- IHE_FRANCE_PAM[INS4]

- Annexe CI-SIS : Prise en charge de l’INS dans les standards d’interopérabilité et les volets du CI-SIS [CISIS2]

Ce tableau est non exhaustif des flux HL7 sortants et entrants d’un RIS, son objectif est d’aider l’éditeur à cartographier les flux qui peuvent être impactés par l’exigence de véhiculer l’INS dans les ½ connecteurs entrants et sortants du RIS.

Liste détaillée des flux HL7 pouvant transporter l’INS avec les transactions et les profils :

Flux :	Sens :	Profils et Transactions IHE :
HL7 PAM/ADT	Le sens peut-être Entrant et Sortant depuis le logiciel RIS.	RAD-1 : Pt Registration RAD-12 : Patient Update ITI-30 : Patient Identity Management ITI-31 : Patient Encounter Management
HL7 ORU	Sortant uniquement depuis le logiciel RIS	(IHE SINR) Simple Image and Numeric Report RAD-28 : Structured Report Export
HL7 MDM	Sortant uniquement depuis le logiciel RIS	(IHE DRPT) Displayable Report CARD-7 : Encapsuled Report Submission
HL7 ORM, OMI	Le sens peut-être Entrant et Sortant depuis le logiciel RIS.	RAD-4 : Procedure Scheduled RAD-13 : Procedure Update
HL7 ORM, OMG	Le sens peut-être Entrant et Sortant depuis le logiciel RIS.	RAD-2 : Placer Order Management RAD-3 : Filler Order Management
HL7 SIU	Le sens peut-être Entrant et Sortant depuis le logiciel RIS.	RAD-48 : Appointment Notification

Point D’attention : Dans le cadre du transport de l’INS le segment PID porte les traits stricts.

MSSanté

Rappel :

Le système MSSanté est un système de messagerie électronique « standard » d’émission et de réception de messages électroniques qui permet :

- D’échanger par voie électronique de façon sécurisée des données de santé à caractère personnel entre professionnels habilités (messagerie interprofessionnelle) et avec le patient (messagerie citoyenne).

- D’alimenter des systèmes d’information (SI) de l’espace de confiance à l’occasion d’échanges de messages entre acteurs de santé.

L’espace de Confiance MSSanté : il se caractérise par :

- L’annuaire national MSSanté s’appuyant notamment sur le répertoire partagé des professionnels de santé et ayant vocation à référencer l’ensemble des professionnels habilités à échanger des données de santé personnelles.

- Une liste blanche de domaines qui regroupe l’ensemble des domaines de messageries des opérateurs autorisés à échanger dans l’espace de confiance MSSanté.

- Des référentiels permettant aux industriels de développer des offres conformes et interopérables entre elles sont accessibles sur le site de l’ANS.

Dans le cadre de la vague 1 le Référentiel socle MSSanté [MSS1] doit être utilisé.

Le client de messagerie : Il s’agit d’un logiciel type client lourd de messagerie ou logiciel de professionnel de santé (LPS) intégrant des fonctions de messagerie.

Le client de messagerie peut également être porté par un PFI ou un DPI possédant le rôle de PFI.

Trajectoire MSSanté Vague 1 : La trajectoire unique d’émission MSSanté est couverte par cette vague 1.
Le document d’Imagerie médicale dès qu’il est validé par le radiologue doit être échangé sur un délai maximum de 24h en tenant compte des restrictions vers la boite mail MSSanté du PS demandeur mais également sur la boite MSSanté du patient, en Hospitalisation l’échange peut être désactivé aux PS demandeurs de l’établissement.

Les boites aux lettres (BAL) MSSanté : Il existe trois types de boîtes aux lettres sécurisées dans l’espace de confiance MSSanté. (Les Boites Applicatives, Personnelles et Organisationnelles)

Boites aux lettres applicatives : Elles sont associées à un logiciel métier ou à une machine (RIS), elles sont accédées directement par le logiciel.
La boite au lettre applicative est à privilégier pour réaliser l’émission automatisée des Comptes Rendus d’Imagerie validés par les Radiologues, sauf si la structure du radiologue ne le permet pas alors le radiologue doit utiliser une boite personnelle.
Boites aux lettres personnelles : Ce sont des boîtes aux lettres nominatives, rattachées à des personnes physiques. Elles sont réservées à l’usage d’un professionnel de santé ou de tout professionnel habilité.

Accès à l’annuaire national MSSanté : Il est demandé la capacité de vérifier l’identité des correspondants de santé et des utilisateurs auprès des couches d’exposition du RPPS (extractions publiques de l’annuaire santé).

MSSanté Patient : L’usage des adresses patient est une exigence, les informations nécessaires pour la construction de l’adresse sont décrites dans le référentiel Socle MSSanté [MSS1]

Normalisation de l’objet du message MSSanté : La normalisation des messages doit permettre d’identifier facilement le type de document, sa provenance et le patient concerné.

Un chapitre du référentiel socle MSSanté [MSS1] concerne la normalisation.

Envoi par Messagerie Sécurisée de Santé citoyenne : le Référentiel socle MSSanté #2 (Clients de Messageries Sécurisées de Santé) prévoit une dérogation jusqu’à fin 2022 permettant d’écrire à un usager sans avoir qualifié son INS. En cohérence avec les ambitions du Ségur, cette dérogation ne s’applique évidemment pas au présent DSR (ainsi qu’aux autres DSR de la vague 1).

DMP

Rappel : Le RIS ou le PFI (ou DPI possédant le rôle de PFI) doit permettre à l’utilisateur d’alimenter le DMP du patient avec les Comptes-Rendus d’Imagerie validés, la transaction TD0.9 doit également être implémentée sur le RIS

Authentification : L’authentification indirecte doit être utilisée pour la partie alimentation, la TD0.9 est en authentification Directe.

Point d’attention sur les structures SCM (Société Civile de Moyen) : L’éditeur doit gérer la mise en œuvre d’un pool de certificats de type RPPS-Rang (Voir section 2.1.2).

Il existe 2 trajectoires pour l’alimentation d’un DMP.

1er Schéma Urbanisation : Le connecteur alimentation DMP est intégré au RIS (Profil Alimentation) et Accès Web-PS Contextuel.

2ème Schéma Urbanisation : Le connecteur alimentation DMP est porté par un outil tiers (PFI ou DPI possédant le rôle de PFI) (Profil Alimentation) et mise en œuvre de la transaction TD0.9 (Accès Web-PS Contextuel).

Dans le cas du 2ème Schéma (Contexte Hospitalier) le compte-rendu d’imagerie doit être véhiculé en ORU ou MDM suivant le référentiel [CISIS4].

Homologation CNDA : Afin de candidater au référencement du volet numérique du Ségur de la santé, le logiciel RIS doit passer une homologation DMP Compatibilité sur la transaction TD0.9 pour l’appel contextuel et le profil Alimentation en Authentification Indirecte en version 2.4.0 (ou supérieure) [DMP1].

L’homologation du logiciel sera pilotée directement par le Centre National de Dépôt et D’Agrément, un certificat d’agrément doit être remis à l’éditeur par le CNDA si la DMP Compatibilité a réussi.

Pro-Santé-Connect

Rappel : Pro Santé Connect (PSC) est le fédérateur d’identités des professionnels des secteurs sanitaire, médico-social et social enregistrés au Répertoire Partagé des Professionnels de Santé (RPPS).

L’implémentation de Pro Santé Connect est demandée sur l’ensemble des structures de Radiologie.

Les exigences à respecter par le fournisseur sont décrites dans le référentiel [PSC1].

Point d’attention : La mise en œuvre du protocole OpenID est nécessaire pour l’implémentation de Pro Santé Connect.

Portabilité

L’éditeur devra s’engager à ce que le logiciel référencé permettre la mise à disposition, à la demande du Client final de l’historique des données de santé relevant du périmètre RAD-RIS-Va1.

Cet export 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 ainsi que le professionnel de santé concerné doivent être paramétrables dans la procédure.

Le format des fichiers mis à disposition doit être lisible, exhaustif, exploitable, et documenté par l’éditeur.

Il doit contenir sous une forme structurée dans le fichier ou attenant au fichier les informations nécessaires à son import : le nom, prénom, date de naissance et sexe du patient ainsi que, lorsqu’elles sont stockées dans le logiciel, l’INS, la date de production et le type de la donnée.

Les documents concernés du périmètre RAD-RIS-Va1 sont :

- Les comptes rendus de radiologie

Cette mise à disposition peut par exemple être un duplicata des bases de données avec les schémas d’explication des tables. Elle peut aussi être implémentée via une intervention manuelle ou via un mécanisme d’export automatique inclus dans le logiciel référencé (par exemple via une fonction d’export directement dans le logiciel ou via un script ou via un logiciel indépendant).

Maturité Sécurité des Systèmes d’Information (SSI)

L’éditeur doit aussi évaluer la maturité de la solution candidate au référencement Ségur en tant que RIS en termes de couverture des risques de Sécurité des Systèmes d’Information (SSI).

Où souhaitez-vous vous connecter ?

DSR RIS Sans financement

Commencez à nous écrire