Comme publié dans un post précédent, l’objectif d’OrthoWave est de fournir un “intégré” englobant la totalité du suivi Clinique et radiologique en chirurgie orthopédique, et notamment des prothèses de hanche et de genou, en sachant que d’autres modules viendront compléter les modules existants (épaule, ligamentoplastie genou, rachis, …). La structure actuelle était jusqu’alors essentiellement tournée vers les études dites “post-marketing” et les publications à propos d’implants analysés de façon personnelle (bases dites “régulières” RDB) ou dans le cadre des études multicentriques (bases anonymisées “scientifiques” dites SDB). Il est apparu évident que cette organisation d’OrthoWave ne pouvait s’appliquer directement aux impératifs stricts des études cliniques “monitorées” par les départements des Affaires Cliniques de l’Industrie, notamment pour les études dites en pré-marketing.
Ainsi devaient naître les MDBs ou “Bases de Données Monitorées”, lesquelles vont donc constituer, aux côtés des bases “régulières” RDBs et les bases anonymisées “scientifiques” SDBs, le “troisième pilier” de la suite logicielle OrthoWave. Ces MDBs sont à présent opérationnelles, et cet article se propose de redéfinir les principes et fonctionnements de ces bases monitorées MDBs, et les liaisons dynamiques entre ces bases et les bases régulières RDBs d’où proviennent les informations, selon l’architecture globale d’OrthoWave. Un ensemble de tutoriels permettra ensuite de visualiser les différentes étapes de création, paramétrage et utilisation de ces bases monitorées.
La toujours difficile balance entre la rigueur exigée pour le monitorage des études et une relative souplesse nécessaire pour ne pas “infantiliser” les chirurgiens orthopédistes, a été une constante dans la rédaction de ce projet. Mais par ailleurs, la solution proposée devait permettre de satisfaire pleinement au cahier des charges énoncées par les DAC (Départements des Affaires Cliniques). Il convenait en outre de respecter la volonté de tout chirurgien de ne pas perdre de temps avec des entrées redondantes entre sa propre évaluation et la participation à ce genre d’études, avec possibilité de poursuivre ultérieurement l’étude pour son propre compte, notamment en vue de publications à des délais plus importants, isolées ou combinées à d’autres implants.
Principe de création des MDBs:
La mise en route d’une MDB correspond à 3 étapes successives: en sachant que
– (1) l’Administrateur Global (ARIA) crée la MDB relative à une étude spécifique (il existera une MDB par étude), puis
– (2) l’administrateur de chaque RDB concernée relie chacun des utilisateurs autorisés pour cette RDB à “envoyer” les fiches dans telle ou telle MDB (selon un processus similaire à ce qui est déjà en route avec la liaison entre RDBs et SDBs).
– Enfin (3) l’administrateur local (AL) de la MDB, qui est en général le Data Manager de l’étude, va paramétrer successivement l’accès à cette MDB selon un mode de lecture seule en anonymisé ou non, puis sélectionne les paramètres qui vont régir l’étude (modalités d’inclusion et de suivi, participation des chirurgiens) avant de préciser les scores à utiliser et les particularités souhaitées pour les études statistiques et les analyses radiographiques.
1 – Etape 1 : Création de la MDB à partir de l’AG
Il est évident que plusieurs RDBs peuvent “alimenter” un même MDB, et par ailleurs chaque RDB peut participer à plusieurs études par une liaison à plusieurs bases MDB, en complément des liaisons potentielles avec des SDBs existantes.
Il suffit à l’Administrateur Global AG de créer la base MDB, et de spécifier quelles seront les RDBs existantes autorisées à créer des liaisons avec cette MDB nouvellement créée…
2 – Etape 2 : Liaison des Utilisateurs d’une RDB à une MDB
L’Administrateur Local AL de chaque RDB ainsi potentiellement “reliée” à la MDB peut attribuer à un ou plusieurs utilisateurs de sa base l’accès à la MDB. C’est ainsi que seuls les utilisateurs “autorisés” verront apparaître la fenêtre d’envoi des fiches. Ce système permet une grande souplesse d’utilisation, surtout pour les bases importantes partagées par de nombreux utilisateurs.
A noter que lors du “gel” des inclusions dans la MDB, cette liaison dynamique d’envoi de nouvelles fiches sera automatiquement déconnecté.
Dans le diaporama ci-contre, si dans la base RDB prise en exemple, nous avons 6 utilisateurs, seuls les utilisateurs 1,4 et 5 pourront effectivement envoyer les fiches à la MDB. Le tutoriel ci-dessous permettra de visualiser ces différentes procédures de liaison aux MDBs.
3 – Etape 3: Paramétrage de la MDB par l’AL de cette MDB
Il faut d’emblée noter que l’administrateur de cette base de donnée “monitorée” (Il s’agira en principe du ou de la responsable des études cliniques du Laboratoire concerné, c’est-à-dire le Data Manager, et donc administrateur du Promoteur Industriel) n’a pas à être un professionnel de santé, contrairement aux RDBs, car soit les données sont anonymisées, soit un agrément a été délivré au préalable en vue de la réalisation de l’étude en cours.
– Il faudra d’abord que l’AL enregistre les utilisateurs agréés pour utiliser cette MDB, ce peuvent être naturellement les chirurgiens affectés à l’étude, ou les Assistants de Recherches Cliniques (ARL), ou encore toute autre personne autorisée, sous la responsabilité du Data Manager. Deux niveaux d’accès sont alors possibles, en lecture seule, bien entendu, c’est-à-dire en anonymisé ou non. Ceci reste à la discrétion du Data Manager. Tout comme pour les RDBs, il est possible d’attribuer à un utilisateur un ou plusieurs “chirurgiens/centres” listés dans la base. Si le Data manager logiquement s’attribuer un login/mot de passe l’autorisant à visualiser la totalité des chirurgiens, les autres utilisateurs, s’ils sont chirurgiens, ne seront “liés” qu’à leurs propres fiches et ne pourront donc pas visualiser les autres, sauf décision de l’AL qui peut, par exemple pour le chirurgien responsable du groupe d’études, attribuer la possibilité de visualiser toutes les fiches de tout ou partie du groupe.
– Puis il lui faut paramétrer l’étude en cours, avec notamment le nombre et la distribution des inclusions en fonction des chirurgiens impliqués dans l’étude, ainsi que la périodicité des visites (entièrement modulable). C’est ainsi que seront repris à la fois le protocole officiel de l’étude, et la liste des chirurgiens participants.
– Enfin il suffira de sélectionner les scores cliniques prévus dans le protocole à partir de la liste des scores disponibles, qu’il s’agisse de prothèses de hanche ou de genou. En général les scores en vigueur seront pour la hanche le HHS et le PMA, associé à un questionnaire (le score Oxford est recommandé), mais tout autre score ou questionnaire peut être choisi sans limitation de nombre… Il faudra se souvenir que si une visite de patient ne permet pas une évaluation selon la totalité des scores prévus, la fiche sera notifiée en “incomplète”, il faut donc être vigilant sur les scores affichés. Toutefois bien naturellement le chirurgien qui a envoyé cette fiche à partir de sa propre RDB peut en complément utiliser tout score à sa convenance… Une autre particularité de ce paramétrage est de spécifier si les statistiques peuvent être utilisées ou non “en temps réel”, c’est-à-dire au fur et à mesure de leur inclusion dans la MDB, ou si l’AL préfère n’effectuer ses statistiques que pour les cas cliniques “gelés” après finalisation de l’étude.
Mise en route d’une MDB:
Les détails de fonctionnement des MDBs à la fois pour la mise en route de la base monitorée et pour son utilisation en pratique, feront l’objet d’un tutoriel dans un prochain post de ce blog. On peut toutefois d’ores et déjà signaler que la grande différence pour l’utilisateur de cette MDB par rapport à une RDB classique est l’ajout d’un onglet “Etudes” ouvrant 3 sous onglets:
1- Le premier sous-onglet “Protocole” reprend en fait en lecture seule le protocole officiel de l’étude
2- Le deuxième sous-onglet “Statut” permet la visualisation des statistiques de suivi des patients, avec affichage pour chaque délai prévu dans l’étude, des fiches “dues” au délai sélectionné, des fiches “incomplètes” ou “manquantes”, de même que les patients décédés, perdus de vue ou “hors étude”, tous les commentaires étant naturellement possibles en texte libre. Chaque utilisateur ne voit que ses propres patients ainsi que la globalité de l’étude, ce qui permet de se situer par rapport au groupe. Un diagramme récapitulatif imprimable et exportable permet en un seul tableau de visualiser l’état de l’étude et son degré d’avancement.
3- Le troisième sous-onglet “Fiches” permet d’afficher pour tel ou tel chirurgien/centre ou pour la totalité du groupe, la liste des patients enrôlés dans l’étude, avec des pastilles de couleur dans chaque colonne de suivi clinique (correspondant à chaque délai prévu lors du paramétrage de l’étude). Ces couleurs, vertes pour les évaluations complètes, orange pour les scores incomplets ou rouge pour les évaluations non réalisées, mais aussi grises pour les “perdus de vue, noires pour les DCD et roses pour les “exclus de l’étude”, permettent en un instant de visualiser pour chaque patient son degré de participation à l’étude. Des rapports d’activités peuvent être ainsi adressés “en temps” réels aux différents centres d’études/chirurgiens. Ces rapports sont naturellement exportables et imprimables…
A noter que seules les fiches complètes à partir de la RDB peuvent être “liées” à la MDB, ce qui permet d’éviter toute vérification fastidieuse secondaire à partir de la MDB. Si des modifications sont à faire au niveau de telle ou telle fiche, elles sont naturellement sous la responsabilité du chirurgien “émetteur”, et automatiquement prise en compte puisqu’il s’agit d’une liaison dynamique. En supposant que le Data Manager, à un moment donné, souhaite couper tout lien dynamique avec les RDBs “émettrices”, il lui suffit d’extraire la MDB pour la consulter en off line.
L’architecture d’OrthoWave est à présent tout-à-fait cohérente, avec un ensemble de données incluses dans les différentes bases de données “régulières” des chirurgiens (ou groupes de chirurgiens), lesquels peuvent partager en mode anonymisé certains résultats d’implants spécifiques en vue de publications ou analyses scientifiques, ce sont les SDBs, mais aussi participer dans le cadre des MDBS à des études plus strictes monitorées tout en conservant la parfaite maîtrise de la totalité de leurs données, celles qui participent à telle ou telle étude, et toutes les autres…
La liberté de partage des données est extrêmement flexible et peut s’adapter à toutes les situations… Ainsi dans l’exemple du diaporama ci contre, le diagramme définit à titre d’exemple 6 RDBS, 4 SDBs et 4 MDBs: la RDB1 est associée à la fois à la MDB1, mais aussi à la SDB1, laquelle SDB1 reçoit des fiches à la fois de cette RDB1, mais aussi de la RDB2, laquelle RDB2 est aussi liée à la SDB3. Par contre la RDB4 n’est associée qu’à la SDB3, la RDB3 ne partageant ses données avec personne… De la même façon, la RDB5 est liée à la fois à la MDB4 et à la SDB4, tandis que la RDB6 enverra ses fiches selon le cas à la MDB2 ou à la MDB3 … Ouf!
A signaler le cas échéant certaines adaptations de la base RDB pour liaison aux MDB correspondantes. C’est ainsi que la base “régulière” d’où seront issues les fiches à “lier” à la MDB doit envoyer les indications appropriées. La structure globale est conservée, ce qui permet aux utilisateurs d’utiliser cette base pour leurs évaluations personnelles, liaison à d’autres SDB ou d’autres MDB le cas échéant, selon leurs motivations personnelles… Il n’y a donc aucune obligation contraignante et pas de double saisie. Toutefois il sera peut-être nécessaire pour “coller” totalement au cahier des charges de l’étude, de prévoir pour chaque étude prévoir un onglet spécifique, visualisable uniquement sous mot de passe à partir du module AL de la RDB, après agrément de l’administrateur global (ARIA). Cet onglet listera les items prévus par le protocole de l’étude en cours: certains items sont déjà présents dans la base standard, d’autres sont spécifiques à l’étude. Il peut apparaître intéressant de présenter le masque de saisie avec la totalité des items, avec possibilité de saisie soit depuis les fenêtres habituelles (avec duplication dans la fenêtre “étude”), soit au contraire la saisie directe dans la fenêtre “étude” (et duplication dans la fenêtre habituelle), ce qui permettra de tout saisir en même temps (Dans la première option, si le chirurgien choisit de remplir d’abord les fenêtres habituelles, ce qui est généralement le cas pour les chirurgiens déjà utilisateurs d’OrthoWave, il lui suffira ensuite de compléter les items manquants (c’est ce que nous avons prévu pour les registres des prothèses).
Au total, cet article avait pour but de détailler les principes de fonctionnement de ces bases OrthoWave Monitorées, sont nous sommes certains qu’elles répondront aux attentes des professionnels des Etudes Cliniques et permettront au mieux de préparer et “monitorer” les dossiers de présentation des implants et leurs résultats. Une analyse très complète des pré-requis et des fonctionnalités a pu être entreprise durant les derniers mois pour élaboration des MDBs actuelles, en sachant naturellement que nous demeurons à l’écoute des professionnels des Etudes Cliniques, Assistants de recherches cliniques, et naturellement Chirurgiens, pour améliorer encore cet outil qui est avant tout le vôtre…
Un très prochain “post” de ce blog permettra sous forme d’un ensemble de tutoriels de détailler “en live” les modalités de paramétrage des bases RDBs et MDBs, de même que l’envoi des fiches depuis les RDBS vers les MDBs, et enfin l’utilisation de ces bases monitorées au travers de ses trois onglets spécifiques…
A bientôt donc et plus que jamais… Be OrthoWaved!