Sommaire. Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

Transcription

1

2 Sommaire 1 Introduction Objet du document Guide de lecture Rappel du cadre DCC/DMP Principes et enjeux des logiciels de professionnels de santé communicants Une nouvelle génération de logiciels au service des parcours de soins De la production de soins au parcours de soins Modules de spécialités communicants Une évolution cohérente avec les démarches du suivi des parcours de soins Une opportunité pour les éditeurs de logiciels Cadre juridique et référentiels applicables Le cadre juridique Les référentiels applicables Le cadre contractuel Urbanisation et architectures Module de spécialité communicant intégré à un LPS gérant toutes les interfaces nécessaires au service DCC Module de spécialité communicant non intégré à un LPS gérant toutes les interfaces nécessaires au service DCC Module de spécialité communicant local Module de spécialité communicant hébergé à l extérieur de la structure Implémentation dans un logiciel métier Implémenter les fonctions nécessaires à la prise en charge du patient Récupérer la description d une RCP de l annuaire national des RCP Récupérer les données d identification des PS participants du RPPS Récupérer les documents nécessaires à la préparation de la fiche RCP Produire une fiche RCP Partager la fiche RCP (Alimenter le DMP) Echanger la fiche RCP (MSSanté) Gérer les RCP, les sessions et les inscriptions Gérer les RCP Gérer la planification des sessions de RCP Gérer les inscriptions Préparer et gérer les sessions Extraire les données de pilotage et de suivi Extraire des données à des fins de suivi d activité Extraire des données à des fins d observation, de surveillance et de suivi épidémiologique (à terme) Glossaire Annexes Annexe 1 Standardisation des appels contextuels pour les applications Web Introduction Définition de l appel contextuel Web Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

3 7.1.3 Périmètre des recommandations Recommandations sur le passage de contexte Web Paramètres fonctionnels du MOS standardisés dans le cadre du passage de contexte Exemples Rappels sur les concepts Annexe 2 Documents de références Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

4 1 Introduction 1.1 Objet du document Ce document vise à aider les éditeurs à identifier les développements à réaliser pour rendre leurs logiciels conformes aux nouveaux enjeux des logiciels de professionnels de santé (LPS) communicants, en s appuyant sur l exemple concret du service «Dossier Communicant de Cancérologie (DCC) et Dossier Médical Personnel (DMP)». Ce document ne constitue pas une spécification fonctionnelle et technique, mais un guide. Il aide à l implémentation de nouvelles fonctionnalités pour les LPS. Il doit être lu en complément du document de référence «Mise en œuvre du service DCC Définition de la cible Présentation détaillée Septembre 2013» et s appuie sur le cadre national d interopérabilité des systèmes d information de santé (CI-SIS) publié par l ASIP Santé. 1.2 Guide de lecture Ce document est destiné principalement aux décideurs et aux techniciens des éditeurs de logiciels de professionnels de santé pour initier les développements dans leurs logiciels. Il est également destiné aux acheteurs pour les aider dans l élaboration de leurs cahiers des charges. Selon son profil, le lecteur pourra se concentrer sur certains chapitres spécifiques. Les chapitres 2, 3 et 6 sont principalement destinés aux décideurs et directeurs de projet. Les chapitres 4 et 5 sont plutôt destinés aux directeurs techniques, chefs de projets, développeurs et architectes logiciels. Outre ce chapitre 1 introductif, le document est composé des chapitres suivants : Le chapitre 2 rappelle les fondamentaux du service DCC, Le chapitre 3 introduit les enjeux et les principes d un logiciel de professionnel de santé communicant, Le chapitre 4 présente les grands choix d urbanisation et d architecture qui s offrent aux éditeurs, Le chapitre 5 décrit les fonctionnalités d un logiciel de professionnel de santé communicant et propose des recommandations d implémentation au travers de l exemple du service DCC, o o En suivant le processus mis en œuvre dans le parcours coordonné en cancérologie, En proposant plusieurs niveaux de détail par le biais d encadrés «En savoir plus», de renvois à des annexes et à la documentation technique de référence, Le chapitre 6 est un glossaire des abréviations utilisées dans ce document, Le chapitre 7 regroupe les annexes. Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

5 2 Rappel du cadre DCC/DMP Documents de référence Mise en œuvre du service DCC : Définition de la cible Présentation détaillée (septembre 2013) Le service DCC a vocation à aider les professionnels de santé à mettre en place une prise en charge coordonnée, de qualité et personnalisée pour chaque patient, en permettant à chaque acteur de disposer de la bonne information médicale au bon moment. Il se présente comme un système d information du parcours en cancérologie fondé sur un ensemble de composants urbanisés dans un espace de confiance pour faciliter la coordination et améliorer la continuité des soins. Il participe à la mise à disposition d'informations destinées à l'ensemble des acteurs de la santé publique pour améliorer la qualité de la prise en charge et répondre aux besoins de la lutte contre le cancer. Dans le cadre d une prise en charge globale en cancérologie, le service DCC doit informatiser les principaux documents de la prise en charge standardisés du parcours en cancérologie du patient, dont : la proposition thérapeutique (fiche de Réunion de concertation pluridisciplinaire Fiche RCP) sur la base, entre autres, des éléments de diagnostic (compte rendu opératoire CRO, compte rendu d anatomo-cyto-pathologie - CR-ACP) et d éléments organisationnels tels qu issus de l annuaire national des réunions de concertation pluridisciplinaire - ANRCP) ; la phase de traitement (Programme Personnalisé de Soins - PPS) ; le suivi et la surveillance partagée de fin de traitement (Programme Personnalisé de l Après Traitement). Ce service DCC permet également la transmission d'informations médicales et d'activité. Pour ce faire, il doit mettre à disposition des utilisateurs des fonctions de : production des documents clés du parcours, selon un format standardisé et structuré ; mise en partage et échange sécurisé de ces documents entre professionnels de santé et notamment avec le médecin traitant ; mise à disposition du patient des informations médicales le concernant ; soutien à la concertation pluridisciplinaire (annuaire, planification et gestion) ; recueil et de transmission des informations produites dans le cadre des prises en charge, à des fins de suivi de l activité, d observation des cancers et d'assurance qualité. Le service DCC est donc constitué d un ensemble de composants permettant de couvrir ces fonctions tout en garantissant le respect du cadre juridique et technique des systèmes d information de santé partagés : Des composants indispensables à une prise en charge globale des patients o Pour la production de documents standardisés : des modules de spécialité communicants produisant les documents clés du parcours, à commencer par la fiche RCP, suivant les modèles de contenu métier définis par l INCa conformes au CI-SIS ; o Pour le partage et l échange des données de santé à caractère personnel : le DMP et le système des messageries sécurisées de santé. Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

6 Des composants de soutien à la prise en charge en cancérologie o Pour l accès à une offre de RCP en tout point du territoire : un annuaire national des RCP ; o Pour la planification et la gestion des RCP : des modules de planification et de gestion des RCP permettant la programmation des sessions, l inscription des patients et la préparation et le suivi des sessions de RCP. Des composants de recueil de données en cancérologie o Pour le suivi de l activité nationale et régionale de la cancérologie : des modules de planification et de gestion ainsi que des modules de spécialité communicants permettant de réaliser des statistiques d'activité consolidées au niveau régional pour la réalisation de tableaux de bord à destination des différents acteurs : établissements, 3C, ARS, INCa ; o Pour l observation, la surveillance, le suivi épidémiologique et l'évaluation des politiques publiques : des modules de spécialité communicants produisant les documents interopérables, validés, supports des informations à remonter. Les échanges via messagerie sécurisée MSSanté permettront par ailleurs d anticiper la transmission de ces documents au collecteur national en cours d élaboration (Plan Cancer Action 15.3). Le schéma ci-dessous illustre les composants et les flux mis en œuvre pour produire, échanger et partager l un des documents clés du parcours de soins en cancérologie, la fiche RCP. Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

7 3 Principes et enjeux des logiciels de professionnels de santé communicants 3.1 Une nouvelle génération de logiciels au service des parcours de soins De la production de soins au parcours de soins Les systèmes d information de santé (SIS) doivent apporter une réponse adaptée aux besoins des professionnels et établissements de santé, au service de la qualité de prise en charge des patients et du système de santé dans son ensemble. Jusqu à présent la priorité était de mettre à la disposition de chaque acteur un logiciel adapté à son activité médicale ou de soins et répondant au support de sa pratique. Aujourd hui, l enjeu est d outiller efficacement la coordination des différents acteurs (structures de soins et professionnels de santé) intervenant dans le parcours de soins des patients, dans un contexte où les maladies chroniques et les pluri-pathologies sont de plus en plus fréquentes. Les SIS doivent également contribuer au suivi et à l évaluation des politiques publiques en permettant l exploitation de données à visée de pilotage et d observation. Les professionnels de santé doivent pouvoir s appuyer sur des logiciels métier à forte valeur ajoutée, adaptés aux nouveaux contextes d exercice : mobilité, prise en charge pluridisciplinaire, échanges, etc. Au-delà des fonctionnalités de production de soins (dossier patient, prescriptions, planification des soins ), ces logiciels métiers doivent intégrer de nouvelles fonctionnalités au service du suivi et de la coordination des parcours de soins : recueil des informations cliniques essentielles, communication immédiate avec les autres professionnels de santé, accès aux bonnes pratiques selon les situations cliniques via l exploitation automatique des informations médicales codées dans le dossier patient, programmation multi-acteurs des séquences de prises en charge Dans le présent document, le terme LPS (Logiciel de Professionnel de Santé) désigne tout logiciel métier ou système d'information utilisé par un professionnel de santé ou une structure de soins, pour l'assister dans la gestion de la prise en charge de ses patients. Outre les fonctions de gestion, de comptabilité, d agenda, etc, un LPS produit, gère, reçoit, émet et/ou stocke des données médicales des patients. Le terme LPS recouvre les Logiciels de Gestion de Cabinet (LGC) et les Systèmes d Information Hospitaliers (SIH) Modules de spécialités communicants Pour les éditeurs de LPS (Logiciels de Gestion de Cabinet LGC ou Systèmes d Information Hospitaliers - SIH), il s agit d une véritable opportunité de créer de la valeur pour leurs clients en complétant leur offre de «modules de spécialité communicants». Un module de spécialité communicant doit permettre à ses utilisateurs de produire, valider, lire, échanger et partager des documents structurés, dans le cadre du parcours de soins du patient, avec d autres professionnels de santé en tout point du territoire. Ce principe, mis en œuvre pour la première fois dans le cadre du parcours en cancérologie au travers du service DCC, doit être reproductible pour tout parcours de soins. Techniquement, un module de spécialité communicant repose sur 3 grandes fonctions : Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

8 1. La gestion de documents structurés conformes au Cadre d interopérabilité des systèmes d information de santé (CI-SIS).Ces documents peuvent être : o interprétés par les logiciels de nouvelle génération pour offrir des services à valeur ajoutée au PS (tri, courbes, alertes, etc.) ; o utilisés pour alimenter automatiquement d autres documents ; o exploités à des fins de pilotage et d observation. 2. L échange de documents par messagerie sécurisée de santé compatible avec le système MSSanté. Ainsi les documents peuvent être : o envoyés de façon simple, rapide et sécurisée à un ou plusieurs PS impliqués dans la prise en charge du patient ; o récupérés de façon simple, rapide et sécurisée auprès de PS impliqués dans la prise en charge du patient. 3. Le partage des documents dans le DMP. Grâce au DMP les documents peuvent être : o mis à la disposition de tous les PS qui pourraient avoir besoin d y accéder (notamment en dehors d une prise en charge programmée), en particulier le médecin traitant ; o mis à la disposition du patient. S agissant du parcours de soins en cancérologie, les modules de spécialité communicants permettent : la récupération, par le biais du DMP ou de la messagerie sécurisée, des documents utiles au diagnostic et à la proposition thérapeutique (CR-ACP, CRO ) ; la production des documents clés du parcours : fiche RCP, PPS et PPAT ; le partage des documents avec les autres professionnels de santé, dont le médecin traitant, pour le suivi du patient pendant et après la phase aiguë du traitement ; la remontée d'informations pour la production de données d'activité (cf ) ; la transmission des documents du parcours au futur collecteur national pour répondre aux impératifs de surveillance, d observation et d évaluation des cancers (cf ). De plus, centrés sur la gestion des documents et des données de la prise en charge, les modules de spécialité communicants sont complémentaires avec des modules de planifications et de gestion des RCP tournés vers l organisation de la prise en charge pluridisciplinaire (cf. 5.2) Une évolution cohérente avec les démarches du suivi des parcours de soins Les orientations définies dans le cadre de la mise en œuvre du service DCC identifient via les modules de spécialité communicants le soutien au développement systémique du suivi des parcours : chaque professionnel de santé dispose dans son logiciel de fonctionnalités servant le suivi des parcours et des outils d aide à la décision. Les travaux menés actuellement conjointement par la HAS et l ASIP Santé s attachent à définir des DataSet de Bonnes Pratiques (DSBP) sur certaines séquences de prises en charge, notamment les pathologies chroniques. Intégrés dans leurs logiciels, ils vont apporter des aides concrètes aux professionnel en étant adaptées à leur spécialité avec par exemple l accès en ligne, au cours de la consultation, de mémos, de sources de connaissances en lien avec des contextes cliniques Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

9 particuliers, de suivi d indicateurs de pratiques cliniques, d aide à la saisie de données clés pour suivre l évolution d une pathologie donnée. Les spécifications métier des DataSet de bonnes pratiques sont élaborées par la HAS, et les spécifications techniques sont réalisées par l ASIP Santé. Ces spécifications sont des composantes du Cadre d Interopérabilité des Systèmes d Information de Santé. Chaque DSBP intégré au sein d un LPS (Logiciel de Professionnel de Santé) fournit un ensemble de services (messages d alerte, indicateurs de pratique, de documents d information à destination du patient et du médecin) orientés par pathologie. Afin de fournir ces services, les DSBP sont construits sur la base de deux volets du CI-SIS : Le volet Règles d activation de mémos et d alertes (RAMA) a pour objet de décrire le format des règles permettant à un logiciel de professionnel de santé de signaler automatiquement à l utilisateur la disponibilité d informations correspondant à un DSBP (alertes, disponibilité dans une/des base(s) de connaissances externe(s) de mémos de bonnes pratiques et/ou de mémos diffusables au patient). Les règles d activation de mémos et d alertes d un DSBP se basent sur des données structurées, standardisées et codées définies dans ce DSBP. Le volet Recherche et récupération de connaissances (RCC) a pour objet de décrire le format des flux d interrogation et de récupération d information entre un LPS et une base de connaissance externe. Dans le cadre d un DSBP, les paramètres d interrogation de la base de connaissance externe sont définis dans les règles d activation de mémos et d alertes du DSBP. Même s il n y a pas actuellement de travaux programmés à court terme dans le cadre du Programme Santé Connecté sur la prise en charge du cancer, les porteurs de projets DCC peuvent prendre en compte l ensemble de ces travaux pour orienter le développement de services innovants incluant la mise en œuvre de fonctionnalités d aide à la décision médicale (SADM) notamment sur le champ des sources de connaissances. En savoir plus L espace Programme Santé Connectée est disponible sur le site de l ASIP Santé à l adresse suivante : Il contient : Le document de spécification du DSBP BPCO (Broncho Pneumopathie Obstructive Chronique) Les volets "Règles d activation de mémos et d alerte" et "Recherche et récupération de connaissances" du CI-SIS Une vidéo de présentation de la démarche 3.2 Une opportunité pour les éditeurs de logiciels L implémentation de nouvelles fonctionnalités «communicantes» concernent tous les logiciels de professionnels de santé. Pour les éditeurs de logiciels, ces évolutions ouvrent des opportunités nouvelles pour proposer à leurs clients de nouveaux services à valeur ajoutée qui ouvrent le chemin à des usages multiples. Les mécanismes techniques décrits dans ce document (DMP, MSSanté, documents structurés), à embarquer dans les modules de spécialité communicants, sont communs à de multiples déclinaisons métiers (prise en charge coordonnée du diabète, parcours de soins, etc.). Les investissements réalisés pourront ainsi être plus valorisés. Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

10 Le service DCC (Dossier Communicant de Cancérologie) constitue ainsi un des premiers exemples de fonctionnalités à valeur ajoutée fondé sur ces bases techniques. Pour les éditeurs de logiciels en cancérologie, les professionnels de santé concernés sont les organisateurs de RCP et les médecins demandeurs prenant en charge des patients (en ville ou en établissement) qui doivent bénéficier d une RCP. Ces logiciels doivent leur permettre de produire, transmettre et partager une fiche RCP. Ces fonctionnalités doivent être communes à l ensemble des logiciels de façon homogène sur l ensemble du territoire. Selon la maturité des projets et des SI, la mise en œuvre des fonctionnalités du module de spécialité communicant s opérera soit par une intégration forte dans les SIH et les LGC, soit par l utilisation de solutions SaaS plus légères en déploiement mais également plus contraignantes du fait de leur déconnexion du logiciel métier et des logiciels «prestataires» (laboratoire, imagerie ). 3.3 Cadre juridique et référentiels applicables Le cadre juridique Le développement et l utilisation de LPS communicants doivent s inscrire dans le respect du cadre juridique qui encadre les systèmes d information de santé et de la Politique Générale de Sécurité des Systèmes d Information de Santé (PGSSI-S), dont notamment le principe posé par l article L du code de la santé publique : respect de la vie privée et de la confidentialité des informations. L ensemble des mesures qui doivent être mises en œuvre pour assurer le respect de ce principe doit être conforme aux règles de la protection des données personnelles telles que définies par la loi du 6 janvier 1978 modifiée relative à l informatique, aux fichiers et aux libertés. Les cinq grands principes de la protection des données : - Une finalité déterminée et légitime - Des données pertinentes et adéquates au regard de cette finalité - Une durée de conservation définie - L information des personnes - Des mesures permettant d assurer la sécurité des données Le respect de la vie privée consiste en l application des règles de partage et d échange des données de santé à caractère personnel telles que définies aujourd hui par l article L précité. L échange de données de santé entre professionnels intervenant dans la prise en charge du patient nécessite que ce patient ait été préalablement informé et ne se soit pas opposé à un tel échange. Si la transmission de données de santé s effectue vers le DMP, le consentement est requis à la création du DMP, puis les accès se font dans le respect des autorisations données par le patient luimême aux professionnels de santé. L échange de données de santé par mail doit être réalisé au moyen d un service de messagerie sécurisée de santé tel que l espace de confiance MSSanté. La CNIL a défini une autorisation unique pour les messageries sécurisées de santé (AU N 37) publiée au journal officiel le 16 juillet Cela constitue une simplification très importante : les établissements peuvent s y référer par un simple engagement de conformité en remplissant un formulaire en ligne accessible sur le site de la CNIL. Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

11 En cas de recours à un tiers pour héberger les données 1 collectées et traitées, il convient de s assurer du respect de la procédure telle que définie par la loi (article L du code de la santé publique) et précisée par le décret du 4 janvier L agrément du ministre en charge de la santé est requis après avis de la commission nationale de l informatique et des libertés et du comité d agrément des hébergeurs. L hébergement des données auprès d un tiers agréé à cet effet nécessite de recueillir le consentement exprès du patient pour l hébergement de ses données. L utilisation d un logiciel hébergé par un tiers suppose un accès distant de l utilisateur final au dit logiciel et aux données de santé à caractère personnel gérées par ce logiciel. Les données de santé à caractère personnel recueillies ou produites par l utilisateur final du logiciel se retrouvent ainsi hébergées chez un tiers qui doit donc être agréé à cet effet. L alternative suivante s offre aux opérateurs/éditeurs qui offrent ce type de service pour l hébergement des données de santé à caractère personnel : Etre lui-même agréé pour l hébergement de données de santé à caractère personnel ; Confier l hébergement des données de santé à caractère personnel à un hébergeur agréé à cet effet. Le respect de la confidentialité des informations correspond, conformément à l article 34 de la loi «Informatique et Libertés», à la mise en œuvre de mesures de nature à préserver la sécurité et empêcher que les données ne soient communiquées à des tiers non autorisés. Cette exigence se traduit en particulier par le principe de l obligation d utilisation de la Carte de Professionnel de Santé (CPS) ou d un dispositif équivalent agréé par l ASIP Santé et par le respect des référentiels de sécurité et d interopérabilité prévus par la loi (article L alinéa 4 du Code de la santé publique) et définis par l ASIP Santé. Les moyens d authentification utilisables sont encadrés par la politique générale de sécurité des systèmes d information de santé (PGSSI-S), plus particulièrement par le «référentiel d authentification des acteurs» validé et disponible depuis septembre C est également la nécessité du respect du cadre juridique relatif à l hébergement des données de santé à caractère personnel prévu par la loi (articles L et R et suivants du code de la santé publique) Les référentiels applicables Documents de référence Dossier de conception de l Identifiant National de Santé calculé (INS-C): Liste des logiciels référencés pour le calcul de l'ins-c Les échanges de données de santé doivent être effectués conformément aux standards définis par le cadre national d interopérabilité des systèmes d information de santé (CI-SIS) publié par l ASIP Santé et en suivant leur implémentation dans les conditions de sécurité requises. 1 L ensemble des informations relatives à la procédure d agrément ainsi que la liste des hébergeurs agréés sont disponibles sur le site esante.gouv.fr. Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

12 L identification fiable des patients en tant que porteurs de données médicales à caractère personnel est un prérequis en termes de qualité de prise en charge des patients et de sécurité des soins. En effet, des erreurs d identification (doublons, collisions, document mal attribué) peuvent avoir des conséquences graves dans la prise en charge des patients. En conséquence, l identifiant utilisé pour les patients en tant que porteurs de données médicales à caractère personnel doit être unique, univoque, pérenne et reconnu par l ensemble des acteurs de santé. Le code de la santé publique 2 prévoit la mise en place d un identifiant de santé des bénéficiaires de l'assurance maladie pris en charge par un professionnel de santé ou un établissement de santé ou dans le cadre d'un réseau de santé. Cet identifiant a vocation à être utilisé, dans l'intérêt des personnes concernées et à des fins de coordination et de qualité des soins, pour la conservation, l'hébergement et la transmission des informations de santé. Il a également vocation à être utilisé pour l'ouverture et la tenue du dossier médical personnel et du dossier pharmaceutique. Le NIR, numéro d inscription au Répertoire National d Identification des Personnes Physiques (RNIPP), est un élément d identification des personnes physiques fiable et stable attribué par l INSEE. L'utilisation du NIR est strictement encadrée par la loi du 6 janvier 1978, modifiée, relative à l informatique, aux fichiers et aux libertés. Le NIR est notamment autorisé dans le secteur de la protection sociale (pour l'essentiel les organismes de sécurité sociale, de retraite complémentaire et d'assurance chômage) et tous les acteurs en relation avec ces organismes (professionnel et établissements de santé, employeurs) pour les besoins de la gestion des prestations relevant de la protection sociale et de l assurance-chômage. Le NIR des assurés sociaux est inscrit sur leur carte Vitale et dans la puce de celle-ci. Le NIR des ayants droit du régime général n est aujourd hui pas inscrit dans la puce de la carte vitale de l ouvrant-droit. La population qui est potentiellement concernée par une absence temporaire de NIR d ayants droit en carte Vitale est majoritairement constituée des enfants de moins de 16 ans, inscrits sur la(les) carte(s) de leurs parents, mais également d adultes rattachés à un ouvrant droit (par exemple personne sans emploi rattachée à son conjoint). A partir de l'âge de 16 ans, chaque ayant droit enfant ou ayant-droit adulte - reçoit sa propre carte Vitale. Par ailleurs, sur toutes les cartes Vitale 2 (bicolores avec photographie), le NIR inscrit sur la carte est bien le NIR individuel du porteur et non pas de l ouvrant-droit. Au regard des besoins accrus d utilisation d un identifiant national unique dans le secteur de la santé, la CNIL, questionnée en 2013 sur l utilisation du NIR en INS, s est montrée favorable à la possibilité d étendre les cas d utilisation du NIR. Le projet de loi de santé de 2015 prévoit que le NIR soit utilisé comme identifiant de santé des personnes dans le cadre de leur prise en charge. Cette utilisation du NIR devra cependant recueillir un avis favorable de la CNIL qui veillera au respect de la loi du 6 janvier 1978 précitée. L impact du déploiement effectif du NIR au sein des systèmes d information de santé est en cours d instruction et fait l objet d une étude associant l ensemble des parties concernées. Les modalités d utilisation du NIR comme INS seront définies ultérieurement par un décret en Conseil d État. Dans l attente de la mise en œuvre de cette cible nationale, des mécanismes ad hoc de définition de l identité des patients pourront être définis au sein de l espace TSN. Ces mécanismes devront s inscrire dans une trajectoire compatible avec la cible nationale et préparer la diffusion du NIR. Les trajectoires régionales pourront s appuyer sur le recours à l INS dit «calculé». En l absence de décret fixant le choix de l INS, un INS dit «calculé» a en effet été mis en œuvre depuis 2009 pour favoriser l échange et le partage d informations médicales entre acteurs de santé ; il est utilisé par le DMP notamment. Il s agit d un identifiant transitoire visant à améliorer 2 Article L du code de la santé publique : etexte=&categorielien=cid Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

13 l identification des patients et à permettre le déploiement, au plus tôt et dans des conditions de sécurité acceptables, de projets régionaux ou nationaux mettant en œuvre de l échange ou du partage de données de santé à caractère personnel. L INS-C est calculé localement dans tout système d information de santé (LGC, SIH, réseau ) en appliquant un algorithme connu de tous les acteurs sur un nombre réduit de traits d identité extraits par exemple pour plus de fiabilité, mais pas obligatoirement, de la carte Vitale du patient. Les limitations identifiées pour l INS C sont les suivantes : doublons liés aux changements de traits d identité (NIR, prénom et date de naissance), risque non nul de collision (très faible et augmentant avec l usage et donc le temps, prévisible et réversible par construction d une table comportant l'ensemble des NIR et traits d identité (ce n est pas une qualité imposée, car l identifiant n est ni public ni secret, il est privé ; par ailleurs il n entre pas en jeu dans la sécurité du processus d authentification), ne gère qu une partie de la population. De l ordre de 71 % début 2009 du fait de l absence de NIR d ayants droit dans les cartes Vitale, seul support accepté pour calculer l INS-C (ce taux ne tient pas compte de solutions complémentaires envisageables pour l accès au NIR des ayants droit). Ces limitations peuvent être prises en compte par l identito-vigilance (informatiquement assistée ou non) au sein des différentes structures médicales. Pour garantir la qualité des logiciels au regard de la détermination de l'identifiant National de Santé calculé (INS-C), le CNDA est chargé de mettre en œuvre une procédure centralisée permettant aux éditeurs d'obtenir les moyens de tests adéquats ainsi que le référencement de leurs logiciels. Aujourd hui, 181 logiciels sont référencés 3. Enfin, il appartient aux porteurs de projets TSN d organiser l identito-vigilance à l échelle du territoire, voire de la région, notamment pour garantir la qualité de l identification des patients dans les services mis en œuvre dans le cadre du projet TSN en articulation avec l organisation actuelle impliquant les SI métiers locaux. Cette démarche peut être l occasion de consolider dans une organisation ad hoc des procédures et des circuits d informations adaptés s appuyant sur un outillage adapté. La certification de l identité des professionnels de santé est fondée sur un annuaire, le Répertoire Partagé des Professionnels de Santé (RPPS) qui permet, après vérification en amont de l identité et des titres par les autorités d enregistrement, d attribuer un numéro unique et pérenne aux professionnels de santé, le numéro RPPS. Cet enregistrement conditionne l attribution gratuite de CPS et/ou de certificats logiciels permettant de sécuriser les échanges de données Le cadre contractuel Le respect du cadre juridique et des référentiels précités conduit à formaliser de façon contractuelle les droits et devoirs de chacun des acteurs intervenant dans le parcours de soins du patient. L usage d un logiciel métier implique toujours l existence d un contrat entre l utilisateur et l éditeur. Lorsque les fonctions du logiciel sont disponibles dans un outil hébergé et/ou fourni de façon distincte du logiciel métier habituel, un contrat devra définir les droits et obligations entre l utilisateur final (le professionnel de santé ou l établissement de santé) et l hébergeur/éditeur ou le responsable du traitement. 3 au 23/01/2015 Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

14 Tout professionnel de santé qui produit des données de santé et à qui incombent des obligations de confidentialité et de conservation de ces données, doit s assurer des conditions de conservation de ces données (durée, confidentialité, réversibilité ) garanties par l hébergeur/éditeur à qui il les confie. Le LPS communicant doit être mis en œuvre de façon à garantir le respect du cadre juridique, des référentiels relatifs aux systèmes d information de santé et du cadre général d urbanisation de ces systèmes d information en matière : - de partage et d échange des données de santé à caractère personnel ; - de traitement des données de santé à caractère personnel ; - d identification des acteurs ; - de sécurité d hébergement des données de santé à caractère personnel. Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

15 4 Urbanisation et architectures Documents de référence Urbanisation : Architectures systèmes éligibles aux échanges avec le DMP. CI-SIS Transport : Volet Transport Synchrone pour Client Lourd. Dossier de Spécifications Fonctionnelles et Techniques des interfaces DMP des LPS. Dossier de Spécifications Fonctionnelles et Techniques Opérateurs de messageries MSSanté Dossier de Spécifications Techniques Clients de messageries. Dossiers de Spécifications Fonctionnelles et Techniques des Web Services du RASS. Agrément des hébergeurs de données de santé à caractère personnel : Guide du référentiel de constitution des dossiers de demande d agrément. Dans le cadre du service DCC, les modules de spécialité communicants ont à interagir avec les services sources et/ou récepteurs de données suivants : le DMP pour la mise en partage de documents médicaux (alimentation et consultation) ; la MSSanté pour l échange de données de santé à caractère personnel entre professionnels de santé ; le service de publication du RPPS via les web services annuaire.sante.fr pour les identités des professionnels de santé ; l ANRCP pour les informations descriptives et opérationnelles des réunions pluridisciplinaires; le futur composant national pour l'observation, la surveillance, le suivi épidémiologique et l'évaluation des politiques publiques, permettant le recueil et l'analyse des données en cancérologie. Schéma cible Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

16 L urbanisation du service DCC est basée sur des interactions de services gérés indépendamment les uns des autres. Les interfaces sont décrites dans les documents de référence listés dans le tableau ciavant. L intégration d un module de spécialité communicant dans cette urbanisation dépend de son architecture. Deux types d architecture de mise en œuvre sont à prendre en compte dans cette urbanisation : Le module de spécialité communicant est intégré à un LPS gérant nativement ces interfaces (i.e. LPS DMP compatible, disposant d un service de messagerie sécurisée de santé MSSanté et consommateur des web services RASS). Il s appuie sur ce LPS pour les accès au DMP, l échange de données via MSSanté, la recherche d information sur les professionnels de santé et les réunions pluridisciplinaires et se conforme à l architecture imposé par le LPS. Le module de spécialité communicant n est pas intégré dans un LPS gérant l ensemble des interactions avec les services précédents ; il doit donc mettre en œuvre lui-même les interfaces avec ces services ou être capable de communiquer avec des LPS ou des passerelles mettant en œuvre ces interfaces. Dans ce cas-là, deux choix d architecture sont possibles : o o module de spécialité hébergé localement dans la structure utilisatrice, module de spécialité hébergé à l extérieur de la structure utilisatrice en mode SaaS (software as a service). 4.1 Module de spécialité communicant intégré à un LPS gérant toutes les interfaces nécessaires au service DCC Si le module de spécialité communicant est intégré à un logiciel de professionnel de santé (LGC ou SIH) gérant toutes les interfaces nécessaire au service DCC (i.e. DMP compatible, disposant d un service de messagerie sécurisée de santé MSSanté et consommateur des web service RASS), l accès aux services se fait au travers du LPS, selon les règles de sécurité définies dans l établissement ou le cabinet. Dans le cas d un LPS de ce type en mode hébergé, il convient de rappeler que son architecture doit être éligible aux échanges (alimentation et consultation) avec le DMP Module de spécialité communicant non intégré à un LPS gérant toutes les interfaces nécessaires au service DCC Module de spécialité communicant local Si le module de spécialité communicant local n est pas intégré à un logiciel de professionnel de santé (LGC ou SIH) gérant toutes les interfaces nécessaires au service DCC, il doit être en capacité d interagir avec les services dont les interfaces ne sont pas implémentées dans le LPS : soit directement en mettant en œuvre les interfaces manquantes ; 4 telle que présentée dans les documents de référence «Architecture systèmes éligibles aux échanges avec le DMP» Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

17 soit indirectement en ayant la capacité de transmettre des données à un ou plusieurs composants locaux utilisés par les professionnels de santé pour accéder aux services concernés (LPS ou passerelle). Cette transmission dépend des capacités d import local de données par le ou les composants. Elle est spécifique à chaque composant et doit donc être spécifiée pour chaque couple Module de spécialité / composant par les éditeurs concernés Module de spécialité communicant hébergé à l extérieur de la structure Dans le cas d un module de spécialité communicant non intégré à un LPS gérant toutes les interfaces nécessaires au service DCC et hébergé par un tiers à l extérieur de la structure, deux problématiques sécurité sont à prendre en compte : l hébergement agréé des données personnelles de santé pour le module (cf ) ; l accès sécurisé aux services par le module (cf ). Par ailleurs, l utilisation d un module de spécialité nécessite la fourniture de paramètres de contexte métier (ex. identité du patient, identité du professionnel de santé utilisateur ). Dans le cas d un module mis en œuvre via une application web, afin de simplifier cette fourniture et d éviter les ressaisies, ces paramètres peuvent être intégrés lors de l appel du module à partir d une application métier exploitant un dossier local. Ce type de passage de contexte lors de l appel d une application web ainsi qu une manière standardisée de coder les paramètres associés est présenté au L accès sécurisé aux services par un module de spécialité communicant hébergé par un tiers L accès sécurisé aux services nécessaires au DCC par un module de spécialité communicant hébergé par un tiers doit respecter les contraintes d authentification définies dans le cadre des interfaces de ces services. En particulier, l authentification directe via CPS impose certaines contraintes techniques pour les modules de spécialité communicants hébergés par un tiers avec un accès par navigateur Web (établissement d un canal TLS avec le service cible en utilisant le certificat de la carte). Les architectures possibles pour un accès au DMP de ce genre sont décrites dans les documents Urbanisation : Architectures systèmes éligibles aux échanges avec le DMP. Elles sont suffisamment génériques pour être extrapolables à tout autre service imposant une authentification directe basée sur la CPS. Les architectures possibles pour un accès au DMP (alimentation et consultation) sont de trois types : A Utilisation d un composant de type applet sur le poste de travail B Déport des connexions sur le serveur C Délégation de l authentification à une application tierce La mise en œuvre de l architecture «Authentification déléguée» nécessite une évolution du DSFT des interfaces DMP des LPS pour l ajout d un nouveau mode d authentification «déléguée» et la publication d un nouveau contrat «Opérateur DMP». Ces évolutions sont prévues pour le 1 er semestre Passage de contexte lors de l appel d un module de spécialité communicant en mode SaaS Documents de référence RFC3986 : IETF - Uniform Resource Identifier (URI): Generic Syntax. RFC2616 : IETF - Hypertext Transfer Protocol -- HTTP/1.1. Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

18 Dans le cas d un module de spécialité communicant en mode SaaS non intégré à un LPS, il est possible de mettre en œuvre le passage de contexte d une application métier exploitant un dossier patient local vers le module. Périmètre fonctionnel et environnement de l appel Les applications appelante et appelée appartiennent en général à des organisations distinctes. Par exemple, l appelant est dans un établissement, un cabinet ou un 3C, tandis que l appelé est une application mise à disposition par un tiers (éditeur directement ou par l intermédiaire d un réseau régional de cancérologie par exemple). Le but est de permettre à l utilisateur de retrouver le contexte de travail de l application appelante dans l application appelée en lui évitant une ressaisie. Seules les données fonctionnelles suivantes sont utilisées pour ce passage de contexte : la fonction appelée, l utilisateur, le patient. La liste des fonctions appelées est spécifique à l application appelée, elle est donc à identifier pour chaque fonction appelée. Exemples évoqués dans le cadre du projet : «Demande d inscription d un patient en RCP». «Demande de préparation d une fiche RCP». Par conséquent, les paramètres minimums à normaliser sont les données concernant l utilisateur et les données concertant le patient. L appel est unidirectionnel : Il n y a pas de passage d information au retour de l application appelée vers l application appelante. La description technique de l appel contextuel est décrite en annexe 7.1 du présent document. Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

19 5 Implémentation dans un logiciel métier Exemple du module de spécialité communicant dans le cadre du DCC. 5.1 Implémenter les fonctions nécessaires à la prise en charge du patient Rôles [DEMANDEUR] : Dans les processus et schémas décrits ci-après, le rôle de «demandeur» correspond principalement à tout médecin spécialisé en cancérologie prenant en charge un patient atteint de cancer et souhaitant l inscrire en RCP. Ce rôle peut être délégué pour certaines tâches, à un secrétariat médical qui agit alors sous le contrôle et la responsabilité du médecin. [COORDONNATEUR] : Le rôle de «coordonnateur» correspond au médecin coordonnateur de la session de RCP ; ce rôle peut être délégué, pour certaines tâches, à un secrétariat de RCP ou un secrétariat 3C, qui agit alors sous le contrôle et la responsabilité du médecin Récupérer la description d une RCP de l annuaire national des RCP L ASIP Santé a été chargée par l INCa de mettre en œuvre un Annuaire National des RCP qui constitue le référentiel des RCP du territoire national. Cet annuaire est mis à jour par des administrateurs ou des gestionnaires régionaux ou locaux qui indiquent pour chaque RCP créée dont ils sont responsables, les principales caractéristiques de la RCP : l identifiant et l intitulé de la RCP, le type de RCP (nature de la discussion, traitements/soins ou appareil-organes selon la nature de la discussion), lieu et fréquence de réunion, moyens techniques, entité ou structure responsable de la gestion administrative, etc.). Les professionnels de santé peuvent rechercher et extraire de l Annuaire National des RCP la description d une RCP afin de l intégrer dans leur logiciel de spécialité de manière semi-automatique, en particulier pour en récupérer l identifiant national de la RCP, donnée indispensable dans la fiche RCP. Voir Récupérer la description d une RCP de l annuaire national des RCP et Saisir manuellement la description d une RCP Récupérer les données d identification des PS participants du RPPS Documents de référence Dossiers de Spécifications Fonctionnelles et Techniques des Web Services annuaire.sante.fr. Le Répertoire Partagé des Professionnels de Santé (RPPS) est le répertoire unique de référence qui rassemble et publie des informations permettant d identifier les professionnels de santé, sur la base d un «numéro RPPS» attribué au professionnel toute sa vie. C est un référentiel opposable : les données enregistrées sont réputées fiables et tiennent lieu de pièces justificatives. Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

20 A ce jour, le RPPS intègre les données d identification des médecins, chirurgiens-dentistes, sagesfemmes et pharmaciens, fournies et certifiées par les Ordres professionnels et par le Service de Santé des Armées. Deux nouvelles professions disposant d un ordre professionnel se préparent à intégrer le RPPS : masseurs kinésithérapeutes et pédicures-podologues. Par ailleurs, le Ministère de la Santé a engagé avec l appui de l ASIP Santé des travaux de refonte du système d information des ARS permettant d enregistrer, de gérer les situations d exercice des professionnels. Ces travaux permettront d intégrer progressivement dans le RPPS les professionnels de santé relevant de la compétence administrative des ARS, soit 15 nouvelles professions. Les Web Services annuaire.sante.fr permettent : d interroger le RPPS «fiche par fiche» après authentification par carte de la famille CPS ou avec un certificat serveur applicatif ; de télécharger une extraction du RPPS mettant à disposition des données sous forme de fichiers après authentification à l aide d un certificat serveur applicatif. Les fonctionnalités détaillées des interfaces d accès et leurs modalités techniques sont décrites dans des dossiers de spécifications fonctionnelles et techniques (DSFT) dédiés à chaque interface. L ASIP Santé doit s assurer que seules les personnes autorisées par l article 7 de l arrêté du 6 février 2009 modifié peuvent accéder aux données du RPPS dans le respect de ses règles de fonctionnement (ARS, GCS, Etablissements de Santé, etc.). Pour ces raisons, l accès à ces données fait l objet d une demande adressée à l ASIP Santé. En savoir plus Qui peut accéder aux informations contenues dans le RPPS et comment? Les modalités d accès aux informations contenues dans le RPPS sont décrites sur le site indiqué dans l annexe 2. Le document Annuaire.sante.fr - Accéder aux informations contenues dans le Répertoire Partagé des Professionnels de Santé (RPPS) - Octobre 2014 décrit l offre de service Annaire.sante.fr. Les modalités techniques des Web Services sont décrites dans les documents : DSFT DES WEBSERVICES D EXTRACTION DSFT DES WEBSERVICES D INTERROGATION Les liens d accès à ces documents sont disponibles dans l annexe Récupérer les documents nécessaires à la préparation de la fiche RCP Il s agit d une valeur ajoutée majeure du module communicant. Le médecin qui prépare la fiche RCP doit au préalable récupérer les documents qui seront utiles à la RCP : depuis son SI de production (SIH par exemple) : les documents ont été produits dans le même établissement que celui du DEMANDEUR et sont disponibles dans le SI de production. par un service MSSanté : les documents ont été transmis au DEMANDEUR par messagerie sécurisée de santé à partir du DMP : les documents ont été déposés dans le DMP du patient par d autres professionnels de santé. Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

21 A partir de ces documents, le DEMANDEUR peut, grâce à son module de spécialité communicant, préparer la fiche RCP. Il peut recopier automatiquement, à partir de ces documents, des données structurées dans la fiche RCP. L intégrité du contenu initial et la traçabilité sont ainsi garantis. Cela s applique notamment pour les CR Opératoires et CR-ACP à partir desquels, le module peut récupérer automatiquement les conclusions pour les insérer directement dans la fiche RCP (avec leur auteur), dès lors qu ils sont structurés. Le DEMANDEUR peut également, à titre d information, joindre ces documents à la fiche RCP lors de l envoi aux autres professionnels de santé ou les envoyer dans le DMP Récupérer les documents du DMP Documents de référence Dossier de Spécifications Fonctionnelles et Techniques des interfaces DMP des LPS. Disposer d un LPS homologué pour le profil «Consultation» DMP Pour récupérer des documents du DMP, le LPS doit être homologué pour le profil «Consultation» du DMP. Toutes les informations sur le processus d homologation à la DMP Compatibilité des LPS sont disponibles sur le site indiqué dans l annexe 2. Le Dossier de Spécifications Fonctionnelles et Techniques des interfaces DMP des LPS (DSFT DMP des LPS), décrit en particulier les transactions à mettre en œuvre pour consulter le DMP d un patient. Au minimum, les transactions à développer sont : TD0.1 Authentification sur le DMP, TD0.2 Test d existence d un DMP, TD0.3 Mise à jour de l autorisation d accès, TD0.9 Accès Web PS contextuel, TD3.1 Recherche de documents dans un DMP, TD3.2 Consultation d un document dans un DMP. Les transactions TD0.x gèrent les accès au DMP. La transaction TD3.1 permet de récupérer la liste des documents du patient (et leurs métadonnées) contenus dans son DMP. La transaction TD3.2 permet de récupérer un document particulier choisi dans la liste. Selon le statut de l INS (fourni par un tiers à vérifier, fourni par un tiers sûr, calculé par le LPS à partir de la carte Vitale), les transactions DMP sont utilisables ou pas. Pour plus de détail, se reporter au document Dossier de Spécifications Fonctionnelles et Techniques des interfaces DMP des LPS. Récupérer les documents pertinents uniquement Il est recommandé de limiter la récupération des documents aux seuls documents utiles à la RCP. Par exemple : Fiches RCP CR-ACP Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

22 CR-Opératoire La récupération des documents du DMP peut aussi être améliorée par d autres critères : date (ou intervalle de dates), auteur, établissement, etc. Exemple : CR-ACP produit par le CLCCC. Pour cela, le module de spécialité communicant doit permettre de saisir ces critères pour les utiliser dans la transaction TD3.1 de recherche de documents sur un DMP Récupérer les documents par MSSanté Documents de référence Dossier de Spécifications Fonctionnelles et Techniques Opérateurs de messageries MSSanté. Dossier de Spécifications Techniques Clients de messagerie. CI-SIS - Services : Volet Echange de Documents de Santé. Les professionnels de santé peuvent échanger des documents médicaux entre eux en utilisant le service de messagerie sécurisée MSSanté. Lorsque ces documents médicaux sont fournis en pièce jointe du message dans un format XDM, si l INS du patient est fourni dans les métadonnées du fichier XDM, le LPS est en capacité de rattacher automatiquement les documents au dossier du patient. Lorsque l INS du patient n est pas fourni, c est au professionnel de santé qui reçoit le message d enregistrer les documents dans le dossier du patient. En savoir plus Comment échanger des documents CDA R2 par MSSanté? Le document CI-SIS - Services : Volet Echange de Documents de Santé fait partie de la couche Service du CI-SIS. Il spécifie les modalités techniques pour échanger par messagerie sécurisée un document médical CDA R2 ou un groupe de documents CDA R2 afférents au même cas de cancer. Ces spécifications décrivent les actions suivantes : un système initiateur prépare et envoie des documents médicaux afférents au dossier d'un patient, à un système cible via une messagerie sécurisée de santé ; un système cible reçoit et importe ces documents médicaux afférents au dossier d'un patient, provenant d un système initiateur via une messagerie sécurisée de santé. Ce volet adapte au contexte français la mise en œuvre du profil IHE XDM. Cette adaptation précise la constitution par le système initiateur, d'un fichier ZIP en pièce jointe du message échangé par la messagerie sécurisée. Ce fichier ZIP, appelé IHE_XDM.ZIP, contient des fichiers d'informations éditoriales et le répertoire IHE_XDM. Ce répertoire renferme le ou les documents médicaux accompagnés de leurs métadonnées et de toute feuille de style permettant leur affichage personnalisé sur un navigateur, si besoin. Les répertoires et fichiers contenus dans le fichier ZIP suivent des conventions de nommage. Le nommage de l'objet du message, tout en suivant certaines conventions, est personnalisable par le métier. Lors de la constitution du message, le système initiateur peut demander, de manière optionnelle, au système cible d'envoyer une réponse applicative rapportant le succès ou l'échec de la réception et de l'importation des documents médicaux. A la réception du message, le système cible ouvre le fichier ZIP en pièce jointe et obtient le répertoire décompressé IHE_XDM qui contient notamment les documents médicaux et leurs métadonnées. Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

23 A l'aide de ces métadonnées, le système cible vérifie l'intégrité de chaque document médical. Tout écart constaté stoppe l'importation des documents médicaux et peut être rapporté au système initiateur par un message d'erreur (réponse applicative optionnelle). Si ces vérifications s'avèrent correctes, le système cible importe alors les documents médicaux Récupérer les documents depuis le SI de production Lorsque le professionnel de santé exerce dans une organisation au sein de laquelle une activité de soins met en œuvre un logiciel diffusant des documents de santé (biologie, imagerie ), celui-ci récupère les documents correspondants à partir des mécanismes techniques en fonctionnement dans son environnement Rattacher les différents documents au dossier du patient Documents de référence CI-SIS Couche Contenu Volet Structuration Minimale des Documents Médicaux. Identification : Moyens de propagation de l INS entre applications. Lorsque l utilisateur a récupéré les documents médicaux, il convient de s assurer que ces documents sont bien ceux du patient avant de les «rattacher» au dossier local du patient dans son LPS. Plusieurs solutions sont possibles : Avec l INS : si le document contient l INS du patient (c est le cas de tous les documents qui viennent du DMP) et si le dossier patient du LPS contient également l INS du patient, le rapprochement peut être réalisé automatiquement (le LPS peut attacher automatiquement le document dans le dossier du patient). Avec un IPP : le document peut contenir plusieurs couples d identifiants, chaque identifiant patient («IPP») étant associé à un identifiant (OID) représentant l organisme qui le gère (un établissement de santé pour chaque l IPP, ASIP Santé pour l INS). Le LPS peut rechercher dans ses dossiers patients si un couple identifiant du patient /identifiant de la structure correspond à l un des couple identifiant patient /identifiant de structure présent dans le document. Dans ce cas, le rapprochement peut être réalisé automatiquement (le LPS peut attacher automatiquement le document dans le dossier du patient). Dans les autres cas, le rapprochement doit être fait «manuellement» par l utilisateur qui s attachera à comparer les traits d identité du patient fournis dans le document et ceux contenus dans le dossier du patient dans le LPS. Cette modalité de rapprochement doit être gérée avec la plus grande attention et dans le cadre d une organisation qualité à la hauteur des risques d erreur. Lorsqu une fonction de rapprochement manuelle est mise en œuvre dans le LPS, il convient de s assurer qu au minimum ce contrôle d identito-vigilance porte sur les données «nom» (attention à bien faire la différence entre le nom de famille et le nom d usage), «prénom» et «date de naissance». Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

24 En savoir plus Comment propager l INS-C du patient entre les applications? L INS-C est calculé au moment de la lecture de la carte Vitale du patient. Un certain nombre de prestataires de services diagnostiques ne voient pas fréquemment ou jamais le patient et n ont donc pas l opportunité de lire sa carte Vitale. Les applications utilisées par ces organisations ont pourtant besoin de cet identifiant national de santé lorsqu il existe. Il faut donc que ces applications obtiennent cet INS par un autre canal, depuis les applications situées en amont de la chaîne de soins, par exemple les gestions administratives des malades (GAM), qui ont calculé cet INS, et sont en mesure de le propager vers les applications en aval, ou les applications médicales des demandeurs de ces services diagnostiques. Synthèse des solutions retenues Le document Identification : Moyens de propagation de l INS entre applications liste les cas d usage de propagation de l INS du patient (dans son chapitre 3) et les moyens standardisés à utiliser pour cette propagation (dans son chapitre 4). Le tableau ci-après synthétise les moyens préconisés en fonction des cas d usage : Cas d usage Diffusion électronique Diffusion en code barre Propagation en intra-établissement depuis la GAM vers les applications médicales et médico- techniques de l établissement. Propagation depuis une application médicale vers un prestataire externe dans le cadre d une demande d examen diagnostique. Profil IHE PAM qui diffuse les identités et mouvements des patients à l ensemble des applications abonnées. L extension française de ce profil inclut l INS du patient et le contexte DMP du patient. Standard sous-jacent : HL7 v2.5 Document électronique de demande d examen, dans la mesure où un modèle normalisé d un tel document est disponible. Etiquettes patient ou étiquettes «séjour». Demande d examens papier. L INS est imprimé en code barre sur le document. Obtention par interrogation d un serveur d identités de patients. Profil IHE PDQ. L application interroge le serveur d identités sur divers critères. Standard sous-jacent : HL7 v2.5 Non applicable Le code-barres est standardisé avec les caractéristiques suivantes, qui sont les mêmes que celles fixant les caractéristiques de l impression code-barres du n RPPS du prescripteur sur une ordonnance 5 : Mention «INS-C» Codage de l INS-C en Code 128, avec le jeu de caractères C Valeur en clair de l INS-C 5 Arrêté du 10 août 2010 fixant les caractéristiques permettant la lecture automatique des éléments d'identification du prescripteur sur les ordonnances. Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

25 Afficher la liste des documents du patient Documents de référence CI-SIS Couche Contenu Volet Structuration Minimale des Documents Médicaux CI-SIS Couche Contenu Volet Fiche RCP Dans le LPS, l utilisateur doit pouvoir identifier de manière simple et rapide pour chaque document figurant dans la liste des documents du patient : la date de création du document, le nom du document, le type de document, le nom et prénom du signataire du document, l établissement de rattachement du signataire du document, si le document est dans le DMP du patient ou pas, l origine du document (DMP, MSSanté, ). si le document a des documents liés ou pas, Il est conseillé de présenter la liste des documents en les faisant apparaître du plus récent au plus ancien et donner à l utilisateur la possibilité de modifier l ordre de tri en cliquant sur l entête de la colonne de son choix. Par exemple : Date Nom Type Signataire Etablissement Origine Doc. liés 03/02/2013 CR ACP de Madame LEGRAND Chantal CR-ACP Dr Isabelle LAZARE LABO BAYONNE SUD Non 02/02/2013 CR Opératoire de Madame LEGRAND Chantal CR-OPE Dr Pierre COLLET CH DE LA COTE BASQUE Non 25/01/2013 CR Analyses biologiques de Madame LEGRAND Chantal CR-BIO Dr Philippe NUM LABO BAYONNE SUD Non 22/01/2013 CR de consultation de Madame LEGRAND Chantal CR-CONSULT Dr Janine LOEB CABINET MEDICAL DU DR LOEB Non En savoir plus Comment lier les documents entre eux? Dans le DMP, il est possible de lier plusieurs documents à un document que l on dépose dans le DMP. Par exemple, lorsqu à l issue de la RCP, le médecin coordonnateur envoie la fiche RCP dans le DMP, il peut lier les CR opératoire et CR ACP à la fiche RCP. Cette liaison se fait dans le lot de soumission lors de l envoi dans le DMP. Le LPS peut ensuite, lors de la récupération de la fiche RCP, récupérer également le lot de soumission et vérifier s il y a des documents liés. Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

26 Consulter un document du patient A partir du LPS, une fois les documents récupérés, l utilisateur doit pouvoir facilement en consulter le contenu. Pour l'affichage d un document, le LPS peut utiliser la feuille de style de l'asip santé (fichier.xsl), qui permet d afficher tout type de document au format CDA (entête et corps du document). Document de niveau 1 (format rtf, tiff, jpeg ou pdf) Document de niveau 2 (structurés) Le LPS doit également pouvoir utiliser la feuille de style intégrée dans le document lorsque c est le cas (cas des documents auto-présentables). Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

27 5.1.4 Produire une fiche RCP Documents de référence CI-SIS Couche Contenu Volet Structuration Minimale des Documents Médicaux CI-SIS Couche Contenu Volet Fiche RCP Principes généraux La fiche RCP contient : Des informations sur l inscription du patient à la RCP ; Des données médicales utiles pour la prise de décision de la RCP ; La décision de la RCP (proposition de prise en charge). Selon les organisations mises en place sur le terrain, la fiche RCP est complétée en 1, 2 ou 3 étapes (voire plus) par des acteurs différents. Généralement se sont le DEMANDEUR et le COORDONNATEUR mais d autres professionnels de santé peuvent intervenir. Exemples de workflows possibles : Exemple 1 : en 1 étape avec confirmation d inscription et renseignement des données médicales o Le COORDONNATEUR pré-remplit les informations sur l inscription (nom du patient, RCP et date de la session, ) et les données médicales utiles pour la prise de décision de la RCP puis transmet la fiche au DEMANDEUR pour vérification. Exemple 2 : en 2 étapes avec demande d inscription et saisie des données médicales + confirmation d inscription et renseignement des données médicales o Le DEMANDEUR pré-remplit quelques informations sur l inscription (nom du patient, date de la RCP souhaitée, ) et les données médicales utiles pour la prise de décision de la RCP puis transmet la fiche et les autres documents utiles au COORDONNATEUR. o Le COORDONNATEUR complète les données de l inscription et renvoie la fiche au DEMANDEUR, confirmant ainsi la RCP et la date de la session. Exemple 3 : en 3 étapes avec demande d inscription + confirmation d inscription + saisie des données médicales o Le DEMANDEUR pré-rempli quelques informations sur l inscription (nom du patient, date de la RCP souhaitée, ) et transmet la fiche au COORDONNATEUR. o Le COORDONNATEUR complète les données de l inscription et renvoie la fiche au DEMANDEUR, confirmant ainsi la RCP et la date de la session. o Le DEMANDEUR peut ensuite compléter les données médicales utiles pour la prise de décision de la RCP et renvoie la fiche et les autres documents utiles au COORDONNATEUR avant le passage en RCP. Dans tous les cas, à l issue de la session de la RCP, le COORDONNATEUR saisit la décision de la RCP, valide la fiche RCP, l envoie par messagerie sécurisée de santé aux professionnels de santé qui interviennent dans la charge du patient ainsi qu'au futur collecteur national et la dépose dans le DMP du patient (s il en a un). Les professionnels de santé s échangent les documents médicaux par messagerie sécurisée de santé. Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

28 Compte tenu des nombreuses possibilités de workflows qu il n est pas possible de décrire dans le détail dans ce document, seules les données de la fiche RCP, et non pas l ordre dans lequel elles doivent être renseignées, seront décrites dans les paragraphes suivants Les données de la fiche RCP Certaines données de la fiche RCP sont obligatoires pour sa validation (par exemple : traçabilité documentaire), c est-à-dire à l issue de la session de la RCP (et après la prise de décision). Certaines données peuvent donc être renseignées qu au dernier moment lors de la session de la RCP. Une attention particulière doit être donnée aux items considérés comme non obligatoires au sens CI-SIS. Ces informations non obligatoires, organisationnelles ou médicales, figurent cependant parmi les items minimaux de la fiche RCP, document standardisé par l'institut national du cancer - INCa. D'un point de vue métier, ils sont nécessaires à la bonne prise en charge des personnes. Les contrôles facilitant le recueil de ces items minimaux sont encouragés. De manière générale, les modèles standardisés au niveau national pourront être complétés, selon les besoins territoriaux, d'informations organisationnelles et médicales. Pour produire la fiche RCP, l utilisateur peut : Récupérer des données de son SI de production : c est généralement le cas pour les données qui caractérisent le patient. Récupérer des données de documents existants : dans ce cas, il faut que ces documents soient structurés et conformes au CI-SIS. Saisir les données complémentaires : cette saisie est réalisée par la sélection de valeurs dans des listes déroulantes lorsque cela est possible, mais également par la saisie de textes libres (pour les commentaires essentiellement). En savoir plus Récupérer des données à partir de documents structurés existants Plusieurs données de la fiche RCP peuvent être alimentées à partir d autres documents. L utilisateur doit donc au préalable récupérer ces documents soit à partir du DMP, soit par une messagerie sécurisée de santé, soit à partir de son SI de production et les associer au dossier local du patient (voir ). Le principe de récupération automatique des données à partir d un autre document repose sur la structuration des documents (conformément aux spécifications du CI-SIS) et de recopie des sections/soussections du document source vers le document cible. Exemple : Initialiser une fiche RCP à partir d une autre fiche RCP Cette fonctionnalité permet d initialiser une fiche RCP à partir d une autre fiche RCP qui a été reçue par Messagerie Sécurisée de Santé et initialisée par un autre professionnel de santé en particulier dans le workflow en plusieurs étapes de demande et confirmation d inscription. Cette fonctionnalité permet également d initialiser une fiche RCP à partir d une autre fiche RCP validée lors d une précédente RCP pour pouvoir en reprendre les données médicales. Exemple : Récupérer la conclusion d un CR-ACP Cette fonctionnalité permet de récupérer automatiquement dans la fiche RCP la conclusion d un CR-ACP avec l auteur et la date de cette conclusion. Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

29 Cette opération est plus avancée qu un simple copier coller : les propriétés de la source (document source, auteur, date, etc.) peuvent être conservés. Le document CI-SIS Couche Contenu Volet Fiche RCP, au paragraphe 1 «Modèle métier élaboré par l INCa», décrit la liste des données de la fiche RCP et leur caractère obligatoire ou facultatif. Quelques informations complémentaires utiles pour la mise en œuvre de la fiche RCP par les éditeurs dans leurs logiciels sont fournies dans les paragraphes ci-dessous Le patient Les données qui caractérisent le patient sont récupérées dans le SI de production (SIH par exemple) ou saisies. Elles doivent être renseignées dès l initialisation de la fiche RCP Les correspondants du patient Il peut y avoir plusieurs correspondants : le médecin traitant et les autres professionnels de santé qui prennent en charge le patient. Les correspondants médicaux (et les données qui les caractérisent) sont sélectionnés dans l Annuaire.sante.fr. La liste des correspondants est modifiable (par l ajout ou la suppression de correspondants) jusqu à la validation de la fiche RCP à l issue de la session de la RCP. Pour chaque correspondant médical, l utilisateur doit sélectionner son rôle (médecin traitant ou autre correspondant médical) dans une liste déroulante. Exemple : Médecins Rôle Profession Spécialité Etablissement Dr Philippe TARTAS Médecin traitant Médecin Médecine Cabinet du Dr P. TARTAS (10) générale (SM54) La RCP La RCP (son identifiant et les données qui la caractérisent) est issue de l Annuaire National des RCP. La session de la RCP est modifiable tant que l inscription n est pas confirmée. Dès que l inscription est confirmée (un numéro d inscription a été attribué), la session de la RCP n est plus modifiable. Exemple d une RCP Type de cancer : RCP Identifiant de la RCP Intitulé de la RCP Réseau de Cancérologie d'aquitaine, 3C Bayonne, Digestif Nature de la discussion Type de cancer Appareil Appareil digestif Organes / Tumeurs Appareil digestif sans précision C26 - Tumeur maligne des organes digestifs, de sièges autres et mal définis C Sarcome de Kaposi digestif D017 - Carcinome in situ d'autres organes digestifs précisés D377 - Tumeur à évolution imprévisible ou inconnue d'autres organes digestifs D379 - Tumeur à évolution imprévisible ou inconnue de l'appareil digestif, sans précision Colon-Rectum-Anus C18 - Tumeur maligne du côlon C19 - Tumeur maligne de la jonction recto-sigmoïdienne C20 - Tumeur maligne du rectum Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

30 C21 - Tumeur maligne de l'anus et du canal anal D010 - Carcinome in situ du côlon D011 - Carcinome in situ de la jonction recto-sigmoïdienne D012 - Carcinome in situ du rectum D013 - Carcinome in situ de l'anus et du canal anal D373 - Tumeur à évolution imprévisible ou inconnue de l'appendice D374 - Tumeur à évolution imprévisible ou inconnue du côlon D375 - Tumeur à évolution imprévisible ou inconnue du rectum Estomac C16 - Tumeur maligne de l'estomac D002 - Carcinome in situ de l'estomac Tumeur à évolution imprévisible ou inconnue de l'estomac Foie et voies biliaires C22 - Tumeur maligne du foie et des voies biliaires intrahépatiques C23 - Tumeur maligne de la vésicule biliaire C24 - Tumeurs malignes des voies biliaires, autres et non précisées D015 - Carcinome in situ du foie, de la vésicule et des voies biliaires D376 - Tumeur à évolution imprévisible ou inconnue du foie, de la vésicule et des voies biliaires Intestin grêle C17 - Tumeur maligne de l'intestin grêle D014 - Carcinome in situ de parties de l'intestin, autres et non précisées D372 - Tumeur à évolution imprévisible ou inconnue de l'intestin grêle Oesophage C15 - Tumeur maligne de l'oesophage D001 - Carcinome in situ de l'oesophage Pancréas C25 - Tumeur maligne du pancréas Péritoine-rétropéritoine C451 - Mésothéliome du péritoine C48 - Tumeur maligne du rétropéritoine et du péritoine D483 - Tumeur à évolution imprévisible et inconnue du rétropéritoine D484 - Tumeur à évolution imprévisible du péritoine RCP de recours N RCP pédiatrique N Identifiant du RRC 72 Identifiant du gestionnaire RCP Exemple d une RCP Transversale et de soins de support : RCP Identifiant de la RCP Intitulé de la RCP Réseau de Cancérologie d'aquitaine, 3C Institut Bergonié, Douleur chronique Nature de la discussion Transversale et de soins de support Traitements / Soins Douleur RCP de recours O RCP pédiatrique N Identifiant du RRC 72 Identifiant du gestionnaire RCP La session de RCP et l inscription La session de RCP et l inscription Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

31 Les données de la session sélectionnée (date et lieu de la RCP) et de l inscription sont renseignées par le COORDONNATEUR. Le numéro d inscription à la RCP est automatiquement calculé par le module du COORDONNATEUR. Le médecin coordonnateur de session Les données qui caractérisent le médecin COORDONNATEUR sont issues de l Annuaire National des RCP. Le médecin COORDONNATEUR peut être modifié en sélectionnant un nouveau médecin dans l Annaire.sante.fr jusqu à la validation de la fiche RCP à l issue de la session de la RCP. Le DEMANDEUR peut récupérer l adresse de messagerie sécurisée de santé du coordonnateur dans l Annuaire National des RCP, ou dans l annuaire national MSSanté. Cette adresse peut être enregistrée dans le poste de travail du DEMANDEUR car en pratique il utilisera toujours les mêmes adresses pour les mêmes RCP (pour éviter d aller à chaque fois la récupérer dans l Annuaire National des RCP). Les professionnels de santé participant à la session de RCP Il peut y avoir plusieurs médecins participants. La liste des médecins participants (et les données qui les caractérisent) est issue pour partie de l Annuaire National des RCP (qui contient la liste de membres de la RCP) et pour partie, renseignée par l utilisateur (médecin demandeur et médecin présentateur). Cette liste peut être modifiée (par l ajout ou la suppression de médecins participants) jusqu à la validation de la fiche RCP à l issue de la session de la RCP. L ajout d un médecin participant se fait par recherche dans l Annuaire.sante.fr La fiche RCP Les données qui caractérisent la fiche RCP sont les données non médicales obligatoires de la fiche RCP (date et heure de la fiche, auteur, responsable légal, ). Elles n ont pas en soi de valeur ajoutée médicale et sont renseignées automatiquement par le LPS à fin de traçabilité et d imputabilité. Seul le statut du document doit être renseigné par l utilisateur pour indiquer si la fiche RCP est «en cours» (toutes les données ne sont pas encore renseignées), «complétée» (toutes les données sont renseignées et la fiche peut être présentée à la RCP), «validée» (la RCP a eu lieu, la décision de la RCP a été ajoutée dans la fiche RCP et le médecin coordonnateur l a validée) Le motif de la RCP (type de demande) Le DEMANDEUR renseigne généralement le motif de la RCP (avis diagnostique ou proposition thérapeutique), si c est une demande pour un passage en RCP de recours et/ou pour une RCP pédiatrique et le statut du cas présenté (cas discuté ou cas enregistré). Il peut également ajouter un commentaire pour préciser le motif de la RCP. Motif de la RCP Avis diagnostique Proposition thérapeutique (dont surveillance, ajustement de traitement) Statut du cas présenté : discuté Recours Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

32 Pédiatrie Commentaires / Précisions Description de la tumeur, diagnostic du cancer Il y a au minimum une occurrence du groupe de données «Diagnostic du cancer» présenté ci-dessus permettant de décrire le diagnostic de la tumeur discutée en RCP. Dans le cas où la tumeur discutée est une métastase, il y a 2 occurrences : une décrivant la tumeur primitive et une décrivant la métastase. Pour chaque occurrence «Diagnostic du cancer», il doit être possible de saisir plusieurs occurrences de «Autre stade si pertinent». Description de la tumeur, diagnostic du cancer Patient issu du dépistage Type de tumeur Localisation Précisions sur la localisation Tumeur primitive (RCP_075) D371 - Tumeur à évolution imprévisible ou inconnue de l'estomac Latéralité Précisions sur la latéralité externe (G-A112) Date du diagnostic initial 12/09/2014 Stade clinique initial (UICC version 7) T Carcinome canalaire in situ (Tis) N Présence de métastase ganglionnaire (NX) M Absence de métastase(s) à distance (N0) Autre(s) stade(s) si pertinent(s) Date Commentaires / Précisions Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

33 Antécédents médicaux, éléments cliniques, éléments paracliniques La saisie d un antécédent médical n est pas obligatoire. Il doit être possible de saisir plusieurs «Antécédents médicaux». La saisie d une comorbidité n est pas obligatoire. Il doit être possible de saisir plusieurs «Comorbidités». La saisie de l évaluation du statut fonctionnel n est pas obligatoire. La saisie du dépistage gériatrique n est pas obligatoire. La saisie d un élément paraclinique n est pas obligatoire. La saisie de plusieurs éléments paraclinique doit être possible. Antécédents médicaux Date de diagnostic Date de fin Tumeur au rein gauche soignée en /02/ /06/2010 Comorbidité Date de début Date de fin hypertension artérielle 01/01/ /01/1960 Echelle de performance OMS Stade 0 : Capable d'une activité identique à celle précédant la maladie sans aucune restriction. Date de l évaluation 12/09/2013 Outil de dépistage gériatrique (si le patient a plus de 75 ans) Indiquez le score Eléments paracliniques Saisissez votre texte ici Saisissez votre texte ici Date de l évaluation Date de l examen Commentaires / Précisions Saisissez votre texte ici Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

34 Localisation et phase clinique de la maladie La saisie de ces informations est obligatoire. S il y a progression du cancer, le type de progression est obligatoire (il peut y en avoir plusieurs cases à cocher). Localisation et phase clinique de la maladie Phase initiale du cancer Rechute Progression Oui Non Date de la rechute : / / Type de progression Progression locale Progression régionale Progression à distance Commentaires / Précisions Saisissez votre texte ici Prise en charge thérapeutiques antérieures ou en cours du cas présenté en RCP La saisie d une prise en charge thérapeutique antérieure ou en cours du cas présenté en RCP n est pas obligatoire. La saisie de plusieurs prises en charge thérapeutiques antérieures ou en cours du cas présenté en RCP doit être possible. La date de fin d une prise en charge est obligatoire uniquement si le statut est «déjà traité» et n est donc pas obligatoire si le statut est «en cours» ou «non réalisé». Type de prise en charge Statut Date de début Date de fin Thérapie ciblée hormonothérapie déjà traité en cours non réalisé déjà traité en cours non réalisé Autre type de prise en charge Statut Date de début Date de fin Saisissez votre texte ici déjà traité en cours non réalisé Commentaires / Précisions Saisissez votre texte ici Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

35 La conclusion du CR-Opératoire La conclusion du CR-Opératoire est saisie par l utilisateur. Conclusion du Compte-Rendu Opératoire Saisissez votre texte ici. Conclusion du CR Opératoire Date du CR Chirurgien ayant réalisé l opération Commentaires / Précisions / / Cherchez un professionnel de santé dans l Annuaire.sante.fr Saisissez votre texte ici La conclusion du CR-ACP La conclusion du CR-ACP est obligatoire et elle est soit récupérée automatiquement du CR-ACP, soit saisie manuellement. Cas de la conclusion du CR-ACP récupérée automatiquement du CR-ACP : Dans un CR-ACP structuré, il y a une section Conclusion Diagnostic ( / ) qui contient : o Un <author> et un <effectivetime> dans l entête du CR-ACP o un <title> et un <text>, tous 2 obligatoires, pour décrire la conclusion, o une (ou des) entrée(s) Données de diagnostic relatif à un prélèvement ( ), chacune de ces entrées contenant à leur tour : un <organizer>, Organiseur des données relatives à un prélèvement ou à un groupe de prélèvements ( ) qui contient à son tour : une date de mise en forme (<effectivetime>) qui n est pas obligatoire un (ou des) <author> qui n est pas obligatoire un élément Prélèvement acte et matériel ( ) avec : o la date du prélèvement (<effectivetime>) qui n est pas obligatoire o le préleveur (<performer>/<asssignedentity>) qui est obligatoire (sauf si le prélèvement est réalisé par le patient lui-même). Conclusion du Compte-Rendu ACP Conclusion du CR-ACP <title> de la section OID = et code LOINC = du CR-ACP <text> de la section OID = et code LOINC = du CR-ACP Date de la conclusion du CR-ACP <effectivetime> de l entête du CR-ACP Auteur de la conclusion <author> de l entête du CR-ACP Opérateur ayant réalisé le prélèvement <performer>/<asssignedentity> de l élément Prélèvement acte et matériel ( ) du CR-ACP Date du prélèvement <effectivetime> de l élément Prélèvement acte et matériel ( ) du CR-ACP. S il n est pas renseigné, l utilisateur doit la saisir. Anatomopathologiste ayant réalisé l analyse <author> de l élément Organiseur des données relatives à un prélèvement ou à un groupe de prélèvements Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

36 Date de l examen anatomo-pathologique Commentaires / Précisions ( ). S il n est pas renseigné, l utilisateur devra la saisir. <effectivetime> de l élément Organiseur des données relatives à un prélèvement ou à un groupe de prélèvements ( ). S il n est pas renseigné, l utilisateur devra la saisir. Saisissez votre texte ici. Cas de la conclusion du CR-ACP saisie manuellement : Conclusion du Compte-Rendu ACP Conclusion du CR-ACP Saisissez votre texte ici. Date de la conclusion du CR-ACP Auteur de la conclusion du CR-ACP Opérateur ayant réalisé le prélèvement Date du prélèvement Anatomopathologiste ayant réalisé l analyse Date de l examen anatomo-pathologique Commentaires / Précisions / / Cherchez un professionnel de santé dans l Annuaire.sante.fr Cherchez un professionnel de santé dans l Annuaire.sante.fr / / Cherchez un professionnel de santé dans l Annuaire.sante.fr / / Saisissez votre texte ici Synthèse du cas présenté et question posée à la RCP La saisie de la synthèse du cas présenté et de la question posée à la RCP n est pas obligatoire. Synthèse du cas présenté et question posée à la RCP Saisissez votre texte ici Autres données indispensables à l avis de la RCP La saisie des autres données indispensables à l avis de la RCP n est pas obligatoire. Autres données indispensables à l avis de la RCP Saisissez votre texte ici Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

37 Proposition de prise en charge Pour la proposition de prise en charge : La saisie de 3 demandes d examens / expertises complémentaires doit être possible. La saisie de plusieurs traitements doit être possible. Proposition de prise en charge Dossier complet Dossier incomplet Commentaires / Précisions Passage en RCP de recours: Oui Non Examen(s) / expertise(s) complémentaire(s) Date au plus tôt Date au plus tard Evaluation Oncogériatrique Consultation génétique Autre examen/expertise complémentaire Précisez : Surveillance Oui Non Description Traitement Date au plus tôt Date au plus tard Radiothérapie 30/09/ /10/2013 Saisir un autre traitement Commentaires / Précisions Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

38 Cadre de la proposition thérapeutique Cadre de la proposition thérapeutique Ce traitement est-il lié à une recommandation ou un référentiel de pratique clinique? Oui Lequel : Non Le patient peut-il être inclus dans un essai clinique? Oui Non Enregistrer la saisie avec un statut pour la fiche RCP Le statut de la fiche RCP La création de la fiche RCP et sa saisie peuvent être réalisées par une ou plusieurs personnes, chacune apportant dans la fiche des informations complémentaires. L usage montre que cette fiche RCP s enrichit jusqu à sa présentation lors de la session de la RCP à l issue de laquelle elle sera à nouveau complétée de l avis de la RCP puis validée. Ce workflow n est pas très complexe si l on considère que la fiche est au statut : - «en cours» lors de son élaboration, - «complété» dès lors que la fiche peut être présentée à la session de RCP et - «validée» à l issue de la RCP. Le choix de ce statut est laissé à l utilisateur qui dès lors qu il modifie la fiche sait si la fiche est en cours d élaboration (en cours), prête pour être présentée lors de la session de RCP (complétée) ou validée par la RCP. Il sélectionne ce statut dans une liste déroulante. Dès lors que le statut de la fiche passe à «Validé», les contrôles de présence des données obligatoires (au sens CI-SIS) dans la fiche RCP sont réalisés par le LPS. D'un point de vue métier, l'ensemble des informations du modèle standardisé au niveau national sont nécessaires à la bonne prise en charge des personnes. Les contrôles facilitant le recueil de ces items minimaux sont encouragés (cf ) Ces contrôles ne sont pas réalisés lorsque la fiche a un statut «en cours» ou «complété» La date et l auteur de la mise à jour de la fiche RCP A chaque enregistrement de la fiche, la date et l auteur de la mise à jour de la fiche sont enregistrés. Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

39 Générer la fiche RCP au format CDA et les métadonnées XDS Documents de référence CI-SIS Document chapeau du CI-SIS et Note de version CI-SIS Couche Contenu Volet Fiche RCP CI-SIS Couche Contenu Volet Structuration Minimale des Documents Médicaux CI-SIS Couche Contenu Modèle de contenu CDA CI-SIS Couche Contenu Volet Compte rendu structuré d anatomie pathologique Pour produire la fiche RCP au format CDA, l éditeur doit s appuyer sur les documents de référence listés ci-dessus et sur les jeux de valeurs embarqués dans le standard CDA. Les éditeurs doivent s assurer que le logiciel gère l ensemble des données obligatoires à fournir dans les transactions, les documents CDA et les métadonnées XDS. En savoir plus Quelles sont les données obligatoires / facultatives de la fiche RCP? Il faut dans un premier temps bien distinguer les données à fournir : dans un document CDA, dans les métadonnées XDS du document, dans les métadonnées XDS du lot de soumission. Dans un document CDA, l information est portée par les cardinalités indiquées pour chaque donnée dans les documents CI-SIS Couche Contenu Volet Structuration Minimale des Documents Médicaux et CI-SIS Couche Contenu Volet Fiche RCP : Lorsque la cardinalité est du type [0..*], la donnée n est pas obligatoire et peut ne pas être fournie. Lorsque la cardinalité est du type [1..*], la donnée est obligatoire et doit être fournie. Lorsque la cardinalité est définie précisément comme dans [2..2], le nombre d occurrences (ici 2) doit être respecté. Dans certains cas, lorsque la donnée n est pas connue, le LPS doit permettre d indiquer, au moyen d un attribut «nullflavor», la raison de l absence de l information. Dans d autres cas, l utilisation de «nullflavor» est interdite. Pour les métadonnées XDS, il faut combiner cardinalités et code d usage indiqués pour chaque donnée dans le document CI-SIS Couche Service Volet Partage de Documents de Santé (en particulier le récapitulatif au 3.7.2) : Lorsque la cardinalité est du type [0..*] et le code d usage = O (optionnel), la donnée n est pas obligatoire. Lorsque la cardinalité est du type [0..*] et le code d usage = R2 (requis si connu), la donnée n est pas obligatoire, mais lorsqu elle est connue, elle doit être fournie. Lorsque la cardinalité est du type [1..*], le code d usage sera forcément = R (Requis). Dans ce cas, la donnée est obligatoire et doit être fournie. Lorsque la cardinalité est définie précisément comme dans [1..1], le nombre d occurrences (ici 1) doit être respecté. Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

40 En savoir plus Gestion des identifiants dans les documents CDA Les acteurs de santé, les patients, les actes et les documents médicaux sont identifiés à l aide d identifiants garantissant leur unicité dans l espace et dans le temps. Dans le standard CDA, un identifiant est porté par un élément ayant le type de données "II" Instance Identifier décrit au chapitre du document CI-SIS Couche Contenu Volet Structuration Minimale des Documents Médicaux et résumé ci-après. Le type de données "II" Instance Identifier possède la structure suivante : Attribut Type Cardinalités CI-SIS root uid [1..1] extension st [0..1] assigningauthorityname st [0..1] displayable bl [0..1] Le CI-SIS impose les restrictions suivantes au standard : tout identifiant comporte un attribut root renseigné obligatoirement ; lorsque l'attribut extension est présent, l'identifiant est alors une combinaison des attributs root et extension avec porte l OID (Object Identifier) de l autorité d affectation de l identifiant, représente la valeur de l identifiant dans le périmètre de cette autorité. l identifiant est dans tous les cas un identifiant globalement unique ; l attribut optionnel assigningauthorityname permet l interprétation humaine (la lisibilité) de l autorité d assignation de l identifiant ; la valeur de cet attribut ne doit pas être utilisée pour des traitements automatisés (pas d interprétation machine de cet attribut) ; l attribut optionnel displayable est un indicateur booléen positionné à false si l identifiant n est destiné qu à un traitement automatisé (interprétation machine seule) ou positionné à true si l identifiant est aussi visualisable ; en l absence de cet attribut, le SI consommateur doit considérer que l identifiant est visualisable. Exemple : Identifiants du patient dans la fiche RCP Les spécifications détaillées concernant l identification du patient sont données au du document CI- SIS Couche Contenu Volet Structuration Minimale des Documents Médicaux. Un document CDA doit comporter au moins un identifiant patient, éventuellement plusieurs. Un document CDA mis en partage dans le DMP comporte obligatoirement l INS comme premier identifiant du patient : <id root= ' extension=' '/> Un document CDA peut aussi comporter d autres identifiants du patient comme par exemple l IPP attribué par l établissement de soins impliqué dans la production de ce document. Les IPP attribués par un établissement de soins sont associé à un OID détenu par cet établissement, obtenu par exemple auprès de l AFNOR et qui le représente comme autorité d affectation de ces IPP. <id root=' ' extension=' ' assigningauthorityname='chu XYZ' /> Un document CDA échangé entre deux professionnels ou organisations de santé via une messagerie sécurisée de santé doit comporter au moins un identifiant du patient, qui n est pas nécessairement son INS, celui-ci pouvant ne pas être disponible au moment de l élaboration du document. Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

41 En savoir plus Description des acteurs dans les documents CDA 1 - Règles communes à l ensemble des documents médicaux Le du document CI-SIS Couche Contenu Volet Structuration Minimale des Documents Médicaux liste les différents rôles d acteurs de santé pouvant être associés à un document médical indépendamment de tout modèle spécialisé (comme le volet Fiche RCP), et précise pour chacun de ces rôles l élément XML de l entête CDA qui est utilisé, ainsi que les nombres d occurrences minimales et maximales d apparition de ce rôle. Le «Participant autre PS» précise les différentes spécialisations du rôle de participant d un professionnel de santé, à l aide de l attribut participant@typecode. Rôle de l acteur de santé participant prescripteur de l acte documenté REF commentaire PS consulté pour avis CON Le rôle est précisé par l élément fils functioncode. En particulier, parmi les valeurs utilisables figurent : PS ayant adressé le patient PS ayant reçu le patient adressé de l extérieur PS informateur ayant un rôle défini visà-vis du patient, ou dans son parcours de soins PS ayant fourni des éléments matériels pour l acte documenté REFB REFT INF DIST - APSIN = médecin participant à la RCP et faisant partie du quorum La liste complète des valeurs possibles est décrite dans le du document CI- SIS Couche Contenu Volet Structuration Minimale des Documents Médicaux. Le rôle est précisé par l élément fils functioncode. En particulier, parmi les valeurs utilisables figurent : - PCP = médecin traitant - CORRE = médecin correspondant - REMPL = remplaçant du médecin traitant Par exemple le préleveur d un échantillon biologique (sang, urine, pièce opératoire, biopsie...) PS intervenant secondaire SPRF Le rôle est précisé par l élément fils functioncode. En particulier, parmi les valeurs utilisables figurent : - APSIN = médecin participant à la RCP et ne faisant pas partie du quorum Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

42 En savoir plus Description des acteurs dans les documents CDA 2 - Les acteurs spécifiques additionnels pour la fiche RCP Le document CI-SIS Couche Contenu Volet Fiche RCP spécifie comment les acteurs de santé spécifiques au contexte de la RCP doivent être décrits dans les fiches de réunions de concertation pluridisciplinaire. Ils sont généralement décrits dans l en-tête du document CDA : Rôle de l acteur Médecin coordonnateur de RCP Médecin demandeur Médecin présentateur Autres participants Médecin traitant Autre correspondant médical Dans le CDA Entête <componentof><encompassingencounter><responsibleparty><assi gnedentity> Entête <componentof><encompassingencounter>< typecode= REF > Entête <componentof><encompassingencounter>< typecode= ADM > Entête Tous PS participants : <componentof><encompassingencounter>< typecode= CON > PS faisant partie du quorum : <participant typecode= CON ><functioncode= APSIN > PS faisant ne faisant pas partie du quorum : <participant typecode= SPRF ><functioncode= APSIN > Entête <participant typecode= INF ><functioncode= PCP > Entête <participant typecode= INF ><functioncode= CORRE > encounterparticipant encounterparticipant encounterparticipant D autres acteurs sont aussi décrits dans le corps du document, en particulier les auteurs des CR Opératoire et CR-ACP. Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

43 En savoir plus Description des actes et évènements dans les documents CDA Comme spécifié au chapitre document CI-SIS Couche Contenu Volet Structuration Minimale des Documents Médicaux, le document médical électronique est associé à un ou plusieurs actes par le biais d éléments documentationof/serviceevent de l en-tête CDA. Le premier de ces actes est l acte principal et il précise obligatoirement son exécutant et sa période de réalisation. La prise en charge dans le cadre de laquelle le document a été produit est décrite par l élément componentof/encompassingencounter de l en-tête CDA. La fiche RCP peut référencer trois aspects de la RCP : La RCP référencée dans l annuaire national des RCP, la session de RCP effective qui a traité le cas, l inscription en session de RCP. L acte principal documenté ClinicalDocument/documentationOf/serviceEvent référence la RCP dans l annuaire national des RCP et précise en outre s il s agit pour ce patient d une RCP ou d une RCP de recours. La session de RCP effective est portée par l élément ClinicalDocument/componentOf/encompassingEncounter qui horodate la réunion et identifie le médecin coordonnateur, le médecin demandeur, le médecin présentateur. Le numéro d inscription du patient en RCP est rappelé si nécessaire dans l élément ClinicalDocument/inFulfillementOf/order/id Le document CI-SIS Couche Contenu Volet Fiche RCP précise en détail ces aspects Vérifier la conformité de la fiche RCP au CI-SIS La conformité des documents CDA R2 produits peut se contrôler à partir : du schéma xml «CDA.xsd» pour la conformité au standard CDA. Tout écart détecté se traduit par la déclaration de non-validité du document. du schématron correspondant au volet fiche RCP du CI-SIS. Cette analyse produit un rapport listant les éventuelles non-conformités détectées. La présence d une seule non-conformité se traduit par la déclaration de non-conformité du document. Les jeux de valeurs sont utilisés lors de la vérification de conformité. Toute valeur étrangère détectée se traduit par une non-conformité. Il est recommandé de prendre en compte dès la conception du LPS les tests à effectuer avec les schématrons. Les schématrons sont disponibles via le lien indiqué dans l annexe 2 Santé : (télécharger le zip «Répertoire "Test contenus CDA"»). Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

44 5.1.5 Partager la fiche RCP (Alimenter le DMP) L alimentation du DMP permet au PS de déposer dans le DMP du patient les documents utiles à la coordination des soins. L objectif est de permettre un partage des documents du patient entre tous les professionnels de santé qui sont amenés à le prendre en charge. Documents de référence Processus d homologation à la DMP Compatibilité des LPS Dossier de Spécifications Fonctionnelles et Techniques des interfaces DMP des LPS CI-SIS Couche Service Volet Partage de Documents de Santé CI-SIS Couche Contenu Volet Structuration Minimale des Documents Médicaux CI-SIS Couche Contenu Volet Fiche RCP Profil «Alimentation du DMP» Pour déposer dans le DMP du patient les documents utilisés ou produits par la RCP, le LPS doit être homologué pour le profil «Alimentation du DMP». L alimentation du DMP se fait DMP par DMP avec un «lot de soumission» pouvant comprendre un ou plusieurs documents. Le Dossier de Spécifications Fonctionnelles et Techniques des interfaces DMP des LPS décrit en particulier les transactions à mettre en œuvre pour alimenter le DMP d un patient. Au minimum, les transactions à développer sont : TD0.1 Authentification sur le DMP, TD0.2 Test d existence d un DMP, TD0.3 Mise à jour de l autorisation d accès, TD2.1 Alimentation en documents d un DMP, Les transactions TD0.x gèrent les accès au DMP. La transaction TD2.1 permet de déposer dans le DMP du patient le ou les documents sélectionnés. A noter que pour lier les documents entre eux par la notion de lot de soumission, il est aussi nécessaire de mettre en œuvre la transaction TD3.1 «Consultation du DMP» (pour plus de détail voir ci-après «Groupe les documents dans un même lot de soumission».). Déposer les documents en mode «non visible par le patient» Le dépôt de la fiche RCP et des documents associés se fait généralement en mode «non visible par le patient». Ce n est qu après la consultation d annonce que le professionnel de santé rendra visibles ces documents au patient. Pour déposer un document dans le DMP en mode «non visible par le patient», voir le Dossier de Spécifications Fonctionnelles et Techniques des interfaces DMP des LPS, paragraphe TD2.1 Alimentation du DMP en documents qui indique que cette caractéristique se gère via la métadonnée XDS «condifendialitycode» du document et voir le CI-SIS Couche Service Volet Partage de Documents de Santé pour le détail précis sur la métadonnée XDS «condifendialitycode» du document. Grouper les documents dans un même lot de soumission Pour gérer le lien entre plusieurs documents, d un même «épisode de soins» par exemple, il est conseillé de les grouper dans un même «lot de soumission». Cela permettra notamment aux autres Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

45 médecins de les identifier et d y accéder beaucoup plus simplement. A titre d exemple, lorsqu une fiche RCP, un CR-Opératoire et un CR-ACP sont liés par le même lot de soumission, en accédant à la fiche RCP, le médecin peut voir qu il existe 2 «documents liés» (cette fonctionnalité existe déjà sur l Accès web DMP). A noter : un même document peut être référencé dans plusieurs lots de soumission. Pour lier les documents entre eux dans un même lot de soumission, deux méthodes sont possibles : Les envoyer dans le DMP en même temps dans le même lot de soumission. Par exemple, il est recommandé d envoyer dans le DMP, dans le même lot de soumission, la fiche RCP, le CR-Opératoire, le CR-ACP et tout autre document que le médecin peut juger utile à la coordination des soins. Envoyer la fiche RCP et la référence des autres documents déjà postés dans le DMP dans le même lot de soumission. Cela implique que le LPS doit d abord récupérer la référence des documents du DMP à associer à la fiche RCP (via la transaction Consultation du DMP TD3.1) Echanger la fiche RCP (MSSanté) Dès qu un professionnel de santé a terminé de renseigner la fiche RCP (totalement ou partiellement pour les éléments dont il dispose), il la transmet à un autre professionnel de santé pour la compléter, ou au médecin coordinateur lorsque la fiche est complète. Pour cela, il utilise le service de messagerie sécurisée MSSanté (voir l encadré «en savoir plus» du chapitre ). 5.2 Gérer les RCP, les sessions et les inscriptions Des modules de planification et de gestion des RCP permettent aux équipes en charge de l organisation de la RCP (COORDONNATEUR ou secrétariat de la RCP, secrétariat du 3C) de gérer : Les RCP (par récupération automatique depuis l ANRCP ou par saisie manuelle) La planification des sessions de RCP sur une période donnée ; L inscription d un patient à l une des sessions de RCP prévues ; La préparation et le suivi des sessions Gérer les RCP Dans le module de planification et de gestion des RCP, la création de la RCP est un prérequis à toute autre actions sur cette RCP (planification des sessions de cette RCP, inscription de patients à cette RCP, préparation et suivi des sessions). Dans un module de spécialité communicant (d un DEMANDEUR par exemple), n ayant pas de module de planification et de gestion des RCP, la création de la RCP n est pas indispensable mais peut être utile. Si le module de spécialité communicant dispose de la description de la RCP, le médecin qui prend en charge le patient peut indiquer dans la fiche RCP à quelle RCP il souhaite l inscrire. Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

46 Si le module de spécialité communicant ne dispose pas de la description de la RCP, le médecin qui prend en charge le patient peut quand même créer la fiche RCP du patient mais il n indiquera pas, dans la fiche RCP, à quelle RCP il souhaite l inscrire. Il enverra la fiche au COORDONNATEUR de la RCP par MSSanté en lui indiquant, dans son message, la RCP concernée et c est le COORDONNATEUR qui rattachera la fiche RCP à une RCP précise en modifiant la fiche RCP pour y ajouter la RCP (avec l identifiant national de RCP) depuis son module de spécialité communicant Récupérer la description d une RCP de l annuaire national des RCP L export de l Annuaire National des RCP est au format JSON. A partir de l ANRCP, l utilisateur peut extraire dans un fichier au format JSON, une ou plusieurs RCP. Selon les besoins du module RCP, toutes ou seulement une partie des données de la RCP fournie par l ANRCP doivent être intégrées dans le module RCP. Il convient cependant de rappeler qu au minimum les données suivantes, reprises dans la fiche RCP doivent être intégrées dans le module RCP : Donnée de la RCP dans le module RCP Donnée de la RCP issue de l ANRCP Identifiant de la RCP id_rcp Titre de la RCP Réseau de Cancérologie d'aquitaine + denomination_3c + denomination_rcp RCP de recours (ou pas) rcp_de_recours RCP pédiatrique (ou pas) rcp_oncopediatrie Nature de la discussion type_rcp Traitements et soins attendus (uniquement si categorie Nature de la discussion = «Transversale et soins de support») Appareil (uniquement si type de RCP = appareil «Appareil-Organe») Organes organe Tumeurs Valeurs pour l organe (ex : " D017 - Carcinome in situ d'autres organes digestifs précisés ") A des fins de traçabilité, l historique des mises à jour doit être conservé : date de mise à jour, auteur de la mise à jour, Saisir manuellement la description d une RCP Si le module de planification et de gestion des RCP ou le module de spécialité communicant n est pas en capacité de récupérer automatiquement la description d une (ou plusieurs) RCP, une fonction de saisie manuelle de ces informations doit être mise en œuvre. Il est indispensable d assurer une cohérence entre les informations de l Annuaire National des RCP et la description des RCP dans les modules RCP car certaines d entre elles sont utilisées dans la fiche RCP. En particulier, l identifiant d une RCP est produit par l Annuaire national des RCP. Il est indispensable de l y récupérer pour pouvoir créer une RCP dans le module de RCP. Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

47 A des fins de traçabilité, l historique des mises à jour doit être conservé : date de mise à jour, auteur de la mise à jour, Gérer la planification des sessions de RCP Contrairement a l Annuaire National des RCP, le module de gestion et de planification des RCP est local (dans le LPS) ou mutualisé et disponible en ligne par exemple couplé avec un module communicant. Dans ce module, le COORDONNATEUR doit pouvoir gérer la planification des sessions des RCP qu il gère en indiquant la fréquence, les horaires et les lieux des sessions. Pour chaque RCP, il doit donc pouvoir créer, modifier ou supprimer de manière simple et ergonomique (avec l utilisation de calendrier par exemple) des sessions périodiques ou ponctuelles. Une fonction de messagerie doit permettre d envoyer un message aux médecins participants à la session de RCP pour les informer de la planification (ou la replanification) des sessions. Lors de la suppression ou la modification d une session, si des inscriptions sont déjà attachées à cette session, le module doit alerter le COORDONNATEUR qui pourra choisir d annuler ou confirmer son action. Une fonction peut être implémentée pour rendre des jours «indisponibles» dans le calendrier des RCP, soit de façon globale (pour les jours fériés nationaux, les samedis et les dimanches), soit en sélectionnant des jours particuliers (par exemple les jours fériés spécifiques en Alsace-Moselle). Dans ce cas, un système d alerte doit être implémenté pour informer le COORDONNATEUR lorsque des sessions sont programmées sur des jours «indisponibles». Le module pourra alors lui proposer d annuler ces sessions ou de les replanifier. Un paramétrage peut permettre de gérer la limitation des inscriptions à une session de RCP : - Limiter le nombre d inscriptions par plage horaire : dès que la limite des inscriptions pour la durée de la session est atteinte (ex : 10 inscriptions «enregistrées» de 3 mn et 5 inscriptions «discutées» de 10 mn = 80 mn > à la durée de la session 60 mn). - Limiter le nombre d inscriptions total, «discutées» ou «enregistrées» par session : ce nombre maximal d inscriptions par session peut être indicatif ou bloquant. - Limiter le nombre d inscriptions par délai : Clôture automatique des inscriptions X heures avant la session (par exemple : clôture 24 heures avant la session) Généralement, une session planifiée est ouverte aux inscriptions jusqu au délai prévu dans le paramétrage ou jusqu à ce que le(s) seuil(s) des inscriptions soit atteint(s). Le COORDONNATEUR peut clôturer les inscriptions à une session à tout moment, y compris si un délai ou des seuils sont prévus dans le paramétrage de la RCP. Il peut aussi rouvrir une session clôturée, y compris si le délai ou les seuils prévus dans le paramétrage sont dépassés. A des fins de traçabilité, l historique des mises à jour doit être conservé : date de mise à jour, auteur de la mise à jour, Gérer les inscriptions Dans le module de gestion et de planification des RCP, le COORDONNATEUR doit pouvoir consulter et gérer les inscriptions des patients dans les sessions des RCP qu il gère. Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

48 Une fonction de recherche doit permettre au COORDONNATEUR de trouver une inscription ou un patient à partir de différents critères. Le médecin doit également pouvoir accéder directement à la liste des demandes d inscription en attente de planification. Le médecin doit pouvoir créer, modifier (replanifier une inscription sur une autre session, éventuellement sur une autre RCP qu il gère) et supprimer une inscription. Certaines restrictions contextuelles peuvent interdire l inscription d un patient à une RCP. Par exemple, si la session est clôturée parce que la date limite d inscription ou l un des seuils maximum des inscriptions (total, discutées, enregistrées) prévus dans le paramétrage sont atteints. L inscription d un patient doit s appuyer sur les informations contenues dans la fiche RCP transmise au COORDONNATEUR par le DEMANDEUR : - Si la fiche RCP contient la RCP concernée, le COORDONNATEUR n a plus qu à choisir une session de cette RCP. - Si la fiche RCP ne contient pas la RCP concernée, le COORDONNATEUR doit identifier la RCP (soit l information a été transmise dans le message par le DEMANDEUR, soit le COORDONNATEUR s informe auprès du DEMANDEUR) puis choisir une session de cette RCP. Un système d alerte doit être implémenté pour informer le COORDONNATEUR que : - des demandes d inscriptions sont en attente de planification. - Le(s) seuil(s) limite(s) des inscriptions va être bientôt atteint ou a été atteint. - la date limite des inscriptions est atteinte. - Lors de la validation de l inscription du patient, le module doit mettre à jour la fiche RCP (créer une nouvelle version) pour y insérer les informations relatives à la RCP, à la session (date, lieu, ) et à l inscription du patient (un numéro d inscription est calculé). Le module doit permettre de contrôler que les données indispensables de la fiche RCP sont présentes. Si ce n est pas le cas, une alerte informe le COORDONNATEUR que des données sont manquantes et qu il doit compléter la fiche RCP. Un système de messagerie permet d envoyer aux médecins participants à la RCP et aux correspondants médicaux du patient un message pour les informer de l inscription, de la reprogrammation ou de l annulation de l inscription d un patient à une session de RCP. A des fins de traçabilité, l historique des mises à jour doit être conservé : date de mise à jour, auteur de la mise à jour, En savoir plus Identification des patients Lorsque la structure de soin du COORDONNATEUR ne prend pas en charge le patient, ce dernier n a pas d IPP dans cette structure. Si le patient a un INS, l INS est utilisé et il n est pas nécessaire d associer un nouvel identifiant (IPP) à ce patient. Si le patient n a pas d INS : soit le module du COORDONNATEUR génère un IPP déconnecté de la structure de soin, soit il génère un IPP en lien avec la structure de soin (patient non facturable), ce qui permettra de faire le Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

49 rapprochement avec d autres données du patient si ce patient était amené à fréquenter la structure de soin ultérieurement. Voir également le sur le rattachement des différents documents au dossier du patient Préparer et gérer les sessions Il est recommandé d indiquer le «niveau de remplissage» d une session, quantitativement (par exemple : 15 / 24 pour 15 inscriptions sur 24 maximum) et visuellement (par exemple : vert pour session ouverte pour les inscriptions, rouge pour session clôturée, orange pour session presque complète) Vérifier et ordonnancer les inscriptions d une session Par défaut, les inscriptions sont classées par date de création : premières crées, premières dans l ordre de passage. Le COORDONNATEUR de la RCP peut consulter la liste des inscriptions d une session et modifier l ordre de passage des cas présentés dans la session. Des fonctions d aide à l ordonnancement selon certains critères peuvent être implémentées pour faciliter le travail du COORDONNATEUR : ordonnancement par type de cas (discuté ou enregistré), par médecin présentateur, A partir de cette liste, le COORDONNATEUR peut aussi modifier une inscription. Le COORDONNATEUR peut télécharger et/ou imprimer la liste des inscriptions à une session Vérifier et gérer la liste des médecins participants Le COORDONNATEUR peut ajouter ou supprimer des participants. Il peut ajouter des participants à une session qui ne présentent pas nécessairement de patient, ce qui permet d atteindre le quorum dans le cas d une absence imprévue de membres permanents. La suppression d un participant donne lieu à une notification d information vers celui-ci. En cas de suppression d un médecin présentateur, un message est affiché à l utilisateur pour lui indiquer qu il faut nommer un nouveau médecin présentateur pour une liste d inscriptions (les inscriptions ne sont pas supprimées) et une confirmation est demandée. A la confirmation, les inscriptions concernées sont modifiées pour remplacer le médecin présentateur d origine par le COORDONNATEUR. Une notification est envoyée au médecin présentateur supprimé et aux DEMANDEURS Editer un justificatif de temps passé en RCP Le COORDONNATEUR doit pouvoir fournir aux participants qui le demandent un justificatif du temps passé en session(s) de RCP. Le module doit permettre de : sélectionner un participant et éditer de manière individuelle son justificatif, pour une RCP spécifique ou pour toutes les RCP, sélectionner l ensemble des participants de la RCP et éditer des justificatifs pour chaque participant de la liste, pour une RCP spécifique ou pour toutes les RCP. Le justificatif comporte les données administratives du participant, la (ou les) RCP à laquelle (ou auxquelles) il a participé (identifiant, intitulé, ), le récapitulatif des différentes sessions auxquels le participant a assisté (dates, lieux, heures passées) et le total cumulé en heures. Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

50 5.3 Extraire les données de pilotage et de suivi Extraire des données à des fins de suivi d activité La cible décrite dans le document de référence Mise en œuvre du service DCC : Définition de la cible Présentation détaillée (septembre 2013) prévoit que : «Les données d activité proviennent des modules de planification et de gestion ainsi que des modules de spécialité communicants, qui doivent être capables de les extraire de façon standardisée.( )» Les informations produites doivent permettre de réaliser des statistiques d'activité consolidées au niveau régional de façon homogène, fréquente et automatisée pour la réalisation de tableaux de bord à destination des différents acteurs : établissements, 3C, ARS, INCa Par exemple, les informations collectées dans le cadre de l enquête nationale, annuelle des tableaux de bord de l INCa, réalisée par l ensemble des réseaux et centres de coordination de cancérologie. Certaines informations déclarées dans le cadre de cette enquête pourront être traitées de façon automatisées dès la mise en œuvre du composant national, soutien des missions et actions de lutte contre le cancer et les politiques d organisation des soins Extraire des données à des fins d observation, de surveillance et de suivi épidémiologique (à terme) La cible décrite dans le document de référence Mise en œuvre du service DCC : Définition de la cible Présentation détaillée (septembre 2013) prévoit que : «Un composant doit permettre de collecter les données à des fins d observation, de surveillance et de suivi épidémiologique à partir des modules de spécialité communicants, en s appuyant sur l'ensemble des documents structurés (Fiche RCP, PPS ), support de l information à remonter. L information collectée participe à optimiser et à développer le système de surveillance.» Les contenus et le nombre de documents de la prise en charge pouvant évoluer, l analyse centralisée de ces documents assure l adaptation et le traitement homogène des données pour l ensemble du territoire. Par exemple, le suivi de la montée en charge des nouveaux modèles standardisés pourra être réalisé. Dans un premier temps, la fonction de transmission via messagerie sécurisée MSSanté des documents de la prise en charge standardisés doit être prévue et systématisée depuis le module garantissant leur validité. En particulier, la Fiche RCP sera transmise une fois validée et finalisée pour la réalisation du PPS. De même, le PPS sera transmis une fois accepté par le patient. Cette fonction sera activable dès la mise en œuvre du collecteur national (Plan cancer Action 15.3). Des travaux ont été initiés et doivent être poursuivis concernant les modalités de recueil et de mise à disposition de ces données nominatives, notamment dans le cadre du Plan Cancer Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

51 6 Glossaire ANRCP ASIP Santé CCC CDA CI-SIS CPS CR-ACP CRO DCC DMP DSFT FRCP HAS INS LGC LPS MSSanté OID PPAT PPS PS RCP RPPS RRC SIH UICC Annuaire National des RCP Agence des Systèmes d Information Partagés de Santé Centre de Coordination en Cancérologie Clinical Document Architecture Cadre d Interopérabilité des Systèmes d Information de Santé (publié par l ASIP Santé) Carte de Professionnel de Santé Compte rendu d anatomo-cyto-pathologie Compte rendu opératoire Dossier Communicant de Cancérologie Dossier Médical Personnel Dossier de Spécifications Fonctionnelles et Techniques Fiche de Réunion de Concertation Pluridisciplinaire Haute Autorité de Santé Identifiant National de Santé du patient Logiciel de Gestion de Cabinet Logiciel de professionnel de santé (abréviation générique désignant une application utilisée par un professionnel de santé, dans ou hors structure de soins) Système de messagerie sécurisée MSSanté Object Identifier (identifiant d objet) Programme Personnalisé de l Après Traitement Programme Personnalisé de Soins Professionnel de santé Réunion de Concertation Pluridisciplinaire Répertoire Partagé des Professionnels de Santé Réseau Régional de Cancérologie Système d Information Hospitalier Union for International Cancer Control Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

52 7 Annexes 7.1 Annexe 1 Standardisation des appels contextuels pour les applications Web Version du 24/04/ Introduction Ce document a pour objectif de définir des recommandations en termes de standardisation des appels contextuels d une application Web depuis un logiciel dans le périmètre du secteur Santé. Les contextes techniques d exécution et les périmètres fonctionnels des appels contextuels sont divers et non maitrisés par l ASIP Santé, par conséquent recommandations de l ASIP Santé ne peuvent aborder l ensemble du périmètre des passages de contexte attendus par les différentes applications Web. Plus précisément un appel contextuel permet d invoquer aisément une application cible (http GET) ; les paramètres fournis dépendant strictement des exigences de cette application cible. Les appels contextuels sont donc standardisés par les applications cibles et ne peuvent être généralisés indépendamment des cibles (end-point). Ils sont aussi dépendants des éventuelles évolutions des applications cibles. Ainsi, ce document n aborde, à ce stade, que le transfert contextuel de deux objets fréquemment échangés et définis dans le Modèle des Objets de Santé (MOS). Cette définition pour les échanges de paramètres correspondant à des objets de santé référencés est globalement indépendante des modes d échanges (SOAP ou REST en l occurrence). La même démarche pourrait être étendue à d autres paramètres dès l instant où les applications cibles s engagent sur une définition commune des objets gérés définition provenant du MOS. Par ailleurs les systèmes cibles et appelant doivent aussi s engager sur une conformité, dans le temps, au MOS dans le cas d une évolution de l objet ou des interfaces de l application cible Définition de l appel contextuel Web L appel contextuel d une application Web est le fait d ouvrir une application Web cible à partir d une application appelante, en utilisant un navigateur Web. L application appelante possède un contexte applicatif qui lui permet de passer un certain nombre de paramètres attendus par l application web cible. L appel contextuel correspond donc à un contrat d interface mis à disposition par l application cible, qui détermine les conditions d accès à ses fonctions. L appel contextuel peut être fait par plusieurs types d applications, comme par exemple : - Une application Web qui fonctionne déjà dans un navigateur, et qui, par exemple, met à disposition un lien hypertexte permettant d accéder à l application cible dans un nouvel onglet du navigateur, - Une application de type «client lourd» ou application mobile, qui au besoin ouvre une fenêtre de navigateur sur l application cible. Par rapport à d autres types d interfaces, comme par exemple les Web Service, l appel contextuel Web ne permet pas nativement de transfert d informations en retour à l application appelante. Le retour d information à l application appelante peut éventuellement se faire par d autres moyens, comme l appel d une fonction «callback» par appel contextuel Web ou par l appel d un Web Service Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

53 mis à disposition par l application appelante. Dans tous les cas c est l application appelante initiale qui donne la méthode et les paramètres permettant de lui retourner les informations, ce qui correspond à un contrat d interface mis à disposition par cette application appelante initiale Périmètre des recommandations L ouverture de passage de paramètre à une application Web doit répondre à un certain nombre de contraintes : - Les protocoles standards définis par le Web, regroupés généralement dans des RFC, et implémentés par les navigateurs du marché, - Les paramètres nécessaires au fonctionnement de l application cible, et répondant à ses contraintes fonctionnelles et ses exigences de sécurité (notamment l authentification des utilisateurs). Les recommandations de ce document abordent donc plusieurs aspects : Les aspects techniques : L ASIP Santé peut rappeler les protocoles standards et les bonnes pratiques en vigueur au sein de l industrie. Les aspects fonctionnels : L ASIP Santé n est pas en mesure de standardiser ni l ensemble des fonctions accessibles depuis un appel contextuel, ni l ensemble des paramètres pouvant être passés aux applications, ceux-ci dépendant du contexte fonctionnel des applications ciblées. Cependant, en tant qu organisme en charge du cadre d interopérabilité des systèmes d information de santé (CI-SIS) et de référentiels d identité du secteur de la santé, peut être en mesure de standardiser certains paramètres fonctionnels, en particulier sur des objets qui ont vocation à être définis au sein du Modèle des Objets de Santé (MOS). Concernant la mise en œuvre de l authentification dans des applications Web, qui entre dans le cadre du passage de contexte à une application Web, l ASIP Santé envisage de mener des travaux de standardisation dans le cadre des travaux autour d un Portail d Authentification Multi-Canal, travaux non encore engagés à ce stade. Ces travaux se dérouleraient probablement en plusieurs phases : mise en œuvre d un portail unique pour les services gérés en propre par l ASIP santé, fourniture de composants d authentification pour les téléservices opérés par des acteurs publics, fourniture aux industriels de composants d authentification (sans bien sûr aucune obligation d usage), réflexion sur un portail national d authentification en lien bien évidemment avec les réflexions en cours sur France Connect et IDENUM par exemple Recommandations sur le passage de contexte Web Aspects techniques Syntaxe générale de l appel L appel est réalisé au moyen d une requête de type HTTP GET avec une URL de la forme <protocole>://<point d entrée de l application appelée>?<paramètres d appel> où <point d entrée de l application appelée> est une chaîne représentant l adresse valide d un point d entrée (ou endpoint) dans l application appelée, correspondant à une fonction exécutable par cette application. C est donc sous cette forme, et non sous celle d un paramètre, qu est représentée la fonction appelée. Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

54 <paramètres d appel> est une chaîne de caractères appartenant au jeu de caractères valides pour une URL, concaténant les paramètres d appel, selon la syntaxe générale : param1=valeur1&param2=valeur2&param3=valeur3& Protocole utilisé Le protocole recommandé est HTTPS, avec l utilisation du protocole de chiffrement TLS 1.0 ou supérieur. L utilisation de HTTPS permet d assurer à la fois l authentification de l application cible, la confidentialité, l intégrité des échanges entre le navigateur Web et l application cible Encodage des paramètres Les URL passées en paramètre doivent respecter le jeu de caractère ASCII standard. De plus, les caractères «&» ou «=» servant respectivement à séparer les arguments et les paires paramètre/valeur, il ne faut pas les utiliser dans les paramètres non encodés. Lors d un appel contextuel, l application appelante doit d encoder les paramètres URL en respectant les règles d encodage des URL. Les caractères non affichables ou réservés sont restitués avec un code précédé d un caractère d échappement «%». Ainsi par exemple le caractère espace est encodé en "%20". Tous les langages de programmation intègrent des fonctions d encodage et de décodage des URL. Les applications cible doivent appliquer une fonction de décodage de l URL sur les valeurs différents paramètres passés en entrée Exigences de sécurité Les paramètres d appel contextuel doivent être protégés en intégrité et en confidentialité. L URL et ses paramètres ne doivent pas être altérables entre l appelant et l appelé. Les paramètres d appel ne doivent pas être interprétables par un système tiers interceptant l appel. Ces exigences seront à compléter et à affiner dans le cadre d une analyse des risques SSI du système cible et du moyen d authentification qui sera mis en place Transformation des objets du MOS dans des paramètres http GET Le MOS décrit les objets de santé dans la forme de diagrammes de classes UML. Par exemple, la classe Telecommunication décrit les adresses de télécommunication à laquelle une personne ou une organisation peut être contactée (téléphone, fax, , URL, etc.). Cette classe est composée notamment de l'attribut obligatoire adressetelecom qui représente la valeur de l'adresse de télécommunication dans le format induit par le canal de communication, par exemple un numéro de téléphone, une adresse de courrier électronique, une adresse URL, etc. Tout objet du MOS décrit en UML peut être transformé dans une syntaxe d'échange, notamment XML, JSON, etc. Dans le cas de l'appel contextuel, la syntaxe de l'échange des paramètres n est pas hiérarchique. Dans cette syntaxe «http», les paramètres sont échangés en série. Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

55 Par ailleurs, les valeurs des attributs sont représentées sous forme de chaines de caractères, quel que soit le type de base UML d origine. D'après les règles de transformation UML-http, la transformation d'un attribut d'une classe UML en paramètre http est la suivante: Un attribut d'une classe UML devient en http: «Nom de la Classe UML».«Nom de l'attribut» = «valeur de l'attribut». Le seul cas d exception concerne l attribut «valeur» qui est omis dans le cadre de la sérialisation ( «Nom de la classe UML»= «valeur»). Dans l'exemple, la transformation de l'attribut adressetelecom (numéro de téléphone) de la classe Telecommunication est la suivante: Telecommunication.adressetelecommunication La valeur de l'adresse de télécommunication étant égale à " , elle est représentée de la façon suivante dans la syntaxe http: Telecommunication.adressetelecommunication=" " Paramètres fonctionnels du MOS standardisés dans le cadre du passage de contexte Les paramètres proposés respectent la syntaxe du Modèle Objet de Santé en cours de formalisation au sein de l ASIP Santé. Aucun de ces paramètres n est obligatoire, leur usage dépendant du contexte fonctionnel de l application Identification du Professionnel de Santé Ce paramètre identifie le professionnel de santé concerné par l appel contextuel (qui peut être l utilisateur). Le paramètre donne à la fois le type d identifiant et l identifiant lui-même. Nom du paramètre : PS_IdNat, identification nationale principale du professionnel (personne physique). Valeur : Cette identification est obtenue par la concaténation du type d'identifiant national de personne (provenant de la nomenclature TRE_G08-TypesIdentifiantsPersonnes) et de l'identifiant de la personne physique provenant, selon le type d identifiant, soit d un référentiel national, soit d un référentiel local propre à la structure d exercice de la personne physique: 0 + N ADELI du professionnel Ex : : identification nationale d un professionnel identifié par un n ADELI = Identifiant cabinet ADELI/identifiant interne du professionnel employé au sein d un cabinet Ex : /00001 : identification nationale d un employé dans un cabinet libéral: o le titulaire du cabinet est un PS identifié par un n ADELI = o le cabinet est identifié par un ADELI-rang : o l identifiant interne de l employé dans la structure = N SIRIUS de l'interne en médecine, chirurgie-dentaire ou pharmacie (anciennement N DRASS) 3 + N FINESS/identifiant interne du professionnel employé au sein d une structure FINESS Guide d aide à la mise en œuvre du service DCC 03/08/ / 62

56 4 + N SIREN/identifiant interne du professionnel employé au sein d une structure SIREN (NB: pas d'utilisation identifiée de cette construction) 5 + N SIRET/identifiant interne du professionnel employé au sein d une structure SIRET 6 + Identifiant cabinet RPPS/ identifiant interne du professionnel employé au sein d un cabinet 8 + N RPPS du professionnel Ex : : identification nationale d un professionnel identifié par un n RPPS = N Etudiant (identifiant ordinal dont les règles de génération sont propres à chaque ordre) 10 + Adresse MSS (adresse MSS d'un professionnel sans identifiant national (assistante sociale, médecin non inscrit, etc.); cet identifiant est utilisé uniquement pour la messagerie sécurisée de santé). A terme, les étudiants seront enregistrés dans le RPPS, cela impliquera la disparition de "2+N SIRIUS" et "9+ N Etudiant" au profit de "8+ N RPPS" Identification du Patient Ce paramètre permet de donner l identifiant du patient ciblé. Remarque : La définition de l identifiant du patient est à ce stade restreinte à l échange et au partage (DMP, MS Santé, ). Le projet de loi de santé 6 prévoit de définir le Numéro d'inscription au Répertoire des Personnes Physiques ("NIR") comme INS. Un décret d'application pris en Conseil d'etat après avis de la CNIL est prévu. Dans l'attente de la publication des textes, tout nouveau traitement de données personnelles utilisant le NIR reste soumis à l'autorisation prévue à l'article 27 de la loi n du 6 janvier 1978 dite loi Informatique et Libertés délivrée par décret en Conseil d'etat, pris après avis motivé et publié de la Commission nationale de l'informatique et des libertés. Les classes associées à l identification du patient sont les suivantes : 6 projet de loi de santé en cours d examen par le Parlement au premier semestre 2015 Guide d aide à la mise en œuvre du service DCC 03/08/ / 62