$$\rightleftharpoonup{xx}$$
$$\longleftharp{xx}$$,
$$\longrightharp{xx}$$,
Motivation pour un dossier de santé électronique intégré et une base de données de recherche
La recherche clinique est basée sur la disponibilité de données de haute qualité, que des méthodes statistiques classiques ou des techniques d’apprentissage automatique (ML) soient utilisées pour l’analyse1,2. En plus des données de routine (p. ex., données démographiques, de laboratoire et de médicaments), des données propres à un domaine (p. ex., données pertinentes pour la transplantation) sont requises avec une granularité élevée3,4. Cependant, les soins de routine dans de nombreux hôpitaux universitaires sont effectués avec des systèmes d’information hospitaliers (SIH) qui ne permettent pas la collecte systématique de données spécifiques à la recherche ni l’extraction facile de données de routine5,6,7. Par conséquent, les chercheurs cliniques créent des bases de données de recherche spécifiques, qui présentent divers problèmes, notamment un processus complexe de mise en place d’une base de données, la saisie manuelle des données, des questions de protection des données et une maintenance à long terme (tableau 1). La quantité limitée de données, les données manquantes et les incohérences sont un problème majeur pour la recherche clinique en général et entravent l’utilisation des technologies de ML8,9,10,11,12,13. Ces bases de données de recherche autonomes sont généralement axées sur certains aspects de la maladie ou du patient, ne sont pas connectées à d’autres bases de données et sont souvent abandonnées après une certaine période, ce qui entraîne des « silos de données » inaccessibles. En fin de compte, les données de haute qualité à long terme sur divers aspects de la maladie sont rares. À l’ère de la médecine numérique, il existe un besoin croissant d’un dossier de santé électronique (DSE) complet 7,14,15, qui permet une documentation facile des données spécifiques au domaine et la collecte automatisée de données de routine à partir des systèmes de soins hospitaliers et ambulatoires.
Ces considérations générales s’appliquent également à la médecine de transplantation16. Par conséquent, une documentation complète des antécédents médicaux du patient, y compris tous les traitements hospitaliers et ambulatoires, les données de routine clinique ainsi que les données spécifiques à la transplantation est nécessaire pour des soins de suivi réussis17,18. Étant donné que les SIH ordinaires sont statiques et axés sur le traitement des patients hospitalisés, ils ne peuvent pas intégrer de données spécifiques à la transplantation, telles que les données sur les donneurs, les temps d’ischémie froide et les données sur les antigènes leucocytaires humains (HLA). Cependant, ces données sont une condition préalable de base pour la recherche sur la transplantation19,20,21,22 ainsi que pour les soins cliniques de longue durée. Alors que le séjour initial à l’hôpital n’est généralement que de 1 à 2 semaines et que les processus ainsi que les premiers résultats après la transplantation rénale sont comparables entre de nombreux centres de transplantation, les soins post-transplantation à vie sont compliqués et manquent d’une approche structurée commune. Cela motive un DSE intégré et une base de données de recherche pour saisir le parcours post-transplantation à vie du patient. 23
Afin d’intégrer ces fonctionnalités pour les soins de routine et la recherche de KTR, un DSE nommé « TBase » a été développé avec l’idée que l’utilisation de routine pour les soins post-transplantation créera une base de données de recherche unique avec la plus haute qualité de données (tableau 2).
Design et architecture
TBase est basé sur une architecture client-serveur typique. Pour le développement, les composants et les outils de SAP High Performance Analytic Appliance extended application advanced (SAP HANA XSA) ont été utilisés. Basé sur les dernières technologies Web HTML5 (Hypertext Markup Language 5), le DSE a été développé et testé pour le moteur Google Chrome. Ce moteur Web est utilisé par Chrome et le navigateur Microsoft Edge et permet d’utiliser le DSE dans les navigateurs Web les plus fréquemment utilisés24 sans avoir besoin d’une installation locale. La technologie appliquée permet une conception Web réactive et permet d’utiliser le DSE basé sur le Web sur tous les appareils (PC, tablette, smartphone). La plateforme de développement innovante haute performance est composée de différents composants (Web IDE, UI5 et HANA DB) et nous a permis de mettre en œuvre rapidement le projet de DSE TBase avec des outils logiciels de pointe (Figure 1).
Pour la représentation des données des patients, une structure de tableau simple a été mise en œuvre pour une conception intuitive et explicite du DSE. Par exemple, la table patient avec le PatientID comme clé primaire est au centre de la structure de la table. Presque toutes les tables (à l’exception des sous-tables individuelles) sont connectées à cette table centrale via PatientID (Figure 2).
La figure 3 montre une partie de la structure de la table de TBase et les types de données utilisés plus en détail. L’utilisateur final peut accéder aux champs de données via une interface utilisateur graphique (GUI), pour laquelle un exemple est illustré à la figure 4.
Ce DSE contient toutes les données actuelles sur les patients et est utilisé pour les soins ambulatoires de routine. Les données cliniques de routine importantes (p. ex., données de laboratoire, résultats médicaux, radiologie, microbiologie, virologie et pathologie, données hospitalières, etc.) sont directement importées dans TBase via des interfaces normalisées (p. ex., sur la base du niveau de santé sept (HL7) - une norme pour la communication numérique dans le secteur des soins de santé25). Les données spécifiques à la transplantation telles que les temps d’ischémie froide, les données des donneurs, les données HLA ainsi que les notes de suivi, les signes vitaux, les rapports médicaux et la liste des médicaments sont saisies par les utilisateurs via l’interface graphique dans le DSE. Avant que les données ne soient transférées dans la base de données, un contrôle de plausibilité automatisé est effectué pour détecter rapidement la saisie de données erronées, offrant la possibilité de corriger immédiatement. En outre, la validation des données participe à la routine clinique dans laquelle les utilisateurs cliniques rédigent régulièrement des rapports et des lettres aux patients et aux médecins. Ces lettres doivent fournir des données correctes (p. ex., sur les médicaments, les valeurs de laboratoire et les remarques cliniques) pour les plans de traitement et de médication ultérieurs. En conséquence, les médecins et les patients valident et corrigent constamment les données cliniques dans leur pratique quotidienne, un processus qui se traduit par une qualité de données élevée. Si les données sont saisies via des interfaces de programmation d’application (API) ou d’autres interfaces, les contrôles de plausibilité sont effectués dans le backend de la même manière que les contrôles de plausibilité dans le frontend.
Frontend (GUI)
Pour implémenter le frontend, l’infrastructure UI5 est utilisée. Ce framework fournit une bibliothèque étendue pour les éléments frontaux ainsi qu’une variété de fonctionnalités supplémentaires telles que le multilinguisme et les bibliothèques graphiques pour la visualisation des données. Actuellement, les éléments frontaux TBase sont affichés en anglais ou en allemand en fonction du paramètre de langue du navigateur.
Une interface maître-détail est utilisée pour le frontend afin d’assurer une structure de page simple et intuitive. La partie supérieure de la page de visualisation se compose d’onglets individuels pour les pages de détails (données de base, données médicales, données de transplantation, etc.). Cette partie maîtresse reste inchangée quelle que soit la page de détails illustrée ci-dessous (Figure 4). La vue détaillée de chaque page permet une vue d’ensemble facile sur le sujet de la page.
Pour la manipulation des données, le DSE a différents niveaux de droits d’utilisateur (« lecture », « écriture », « suppression » et « administrateur »). Il existe un niveau « modifier » en plus du niveau « vue », qui ne peut être activé que par les utilisateurs disposant de droits supérieurs à « lire ». Si l’utilisateur a le droit d’écrire, tous les champs de saisie pour la saisie des données sont activés et peuvent être remplis de données. Les utilisateurs disposant de droits de suppression peuvent supprimer des données via un bouton correspondant, mais uniquement après confirmation via une fenêtre contextuelle.
Structure et interfaces de la base de données
Le développement de TBase est effectué dans la base de données de développement. Des tests approfondis et détaillés de toutes les modifications logicielles telles que les nouvelles fonctionnalités sont effectués dans la base de données d’assurance qualité. Les mises à jour logicielles qui réussissent les contrôles de qualité sont transférées au système en direct. À des fins de recherche, le système en direct est copié dans la base de données de réplication, qui peut être interrogée via des interfaces ODBC (Open Database Connectivity) standard (par exemple, via le logiciel open source R Studio). Comme il n’y a pas de connexion directe entre la réplication et le système en direct, les données du système en direct sont protégées contre la corruption, la perte ou la manipulation des données. Cette structure modulaire et la séparation claire des quatre bases de données (développement, assurance qualité, système en direct et base de données de réplication), adaptées aux besoins spécifiques des développeurs, des chercheurs et des cliniciens, facilitent la maintenance et la protection des données sensibles des patients.
Le DSE est entièrement intégré à l’infrastructure de données de la Charité et repose sur différentes interfaces pour l’importation de données à partir de diverses sources de données. L’interface avec le SIH importe toutes les données pertinentes telles que les données administratives, les examens, les médicaments, les résultats de laboratoire et les lettres de congé. Cette interface connecte les deux systèmes via une zone de transit. Ici, toutes les nouvelles données (delta de données) sont transférées du HIS vers TBase en temps réel. Les patients sont identifiés via un numéro de patient ou un numéro de cas et les données correspondantes du SIH sont importées (si elles ne sont pas déjà disponibles dans TBase).
Pour les patients ambulatoires, notre partenaire de laboratoire fournit les résultats de laboratoire via des messages HL7. Ceux-ci sont déployés dans une zone partagée du système de laboratoire et ramassés via une interface HL7 et importés dans le DSE. Pour la communication bidirectionnelle et l’échange de données avec KTR (via des applications pour smartphones) et les néphrologues à domicile, une interface HL7 Fast Healthcare Interoperability Resource (HL7 FHIR) a été mise en œuvre26. Cette interface offre interopérabilité et flexibilité pour un échange de données sûr avec d’autres sources de données (par exemple, Eurotransplant, applications pour les patients) à l’avenir.
Gestion des utilisateurs et protection des données
TBase est basé sur la gestion des utilisateurs au niveau de l’application. Ainsi, l’utilisateur ne peut accéder qu’au frontend de l’application, mais pas à la base de données elle-même. Comme décrit ci-dessus, un concept d’autorisation en quatre étapes a été choisi, réservant la gestion des utilisateurs à ceux qui ont des droits d’administration. Les administrateurs utilisent une application « Identity Management Console » pour ajouter de nouveaux utilisateurs du groupe d’utilisateurs Charité pour l’application TBase et pour gérer leurs droits d’utilisateur (Figure 5). La plupart des utilisateurs peuvent accéder à tous les patients de la base de données. Cependant, il est possible de restreindre l’accès pour des utilisateurs spécifiques tels que les moniteurs d’étude à un groupe de patients.
À l’aide de la plate-forme de base de données en mémoire commerciale, une technologie de base de données sécurisée qui protège les données avec des stratégies telles que l’autorisation au niveau de l’application, l’authentification unique (SSO), le protocole MIT-Kerberos et le langage SAML (Security Assertion Mark-up Language) est utilisée. La plate-forme sécurise les services de communication, de stockage de données et d’application à l’aide des dernières techniques de cryptage et de test. Tous les développements de la base de données sont contrôlés par des autorisations. Cela garantit la sécurité des données dès la conception à un niveau élevé. De plus, toutes les données sont conservées derrière le pare-feu certifié Charité. Conformément au dernier règlement général sur la protection des données de l’Union européenne (RGPD de l’UE), un concept robuste de protection des données a été mis en œuvre, comprenant des diagrammes de flux de données, une évaluation des risques liés à la protection des données (DSFA) et un concept d’autorisation. Tous les documents sont déposés dans un répertoire de procédures de l’Office de la protection des données de la Charité.