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 est 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 peut 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.
Il est donc nécessaire d’adapter la structure actuelle d’OrthoWave pour tirer parti des routines informatiques extrêmement élaborées actuellement utilisées (version web-based en système Ajax), de manière à l’adapter au cahier des charges proposé par les départements des Affaires Cliniques (DAC), en minimisant au maximum les frais de développement par une optimisation judicieuse des ressources existantes.
En réalité plus de 95% de ces points sont déjà pris en charge. Pour les 5% restants, des développements complémentaires sont naturellement envisageables, mais doivent être discutés ultérieurement en fonction de leur intérêt réel compte tenu de la relative complexité de leur mise en œuvre potentielle.
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. Par ailleurs, la solution proposée devra permettre de satisfaire au cahier des charges énoncées par les DAC, tout en restant au minimum de l’investissement financier. Il convient 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 la nouvelle structure:
1 – Les différents modules:
Nous avons actuellement deux modules:
• Les bases “régulières” (RDB) qui permettent la saisie des informations, les statistiques, la gestion des images et les imports/exports de données. Ces bases sont mises en place sous le contrôle d’un “Administrateur Local” (AL), lequel attribue un code d’accès Login/Password selon 3 niveaux (full rights, read only, read only en mode anonymisé). L’AL définit également les chirurgiens qui seront “liés” à chaque utilisateur, de telle sorte que chaque utilisateur ne pourra voir que les fiches patients, les statistiques et images liées des chirurgiens auquel il est “lié”…
• Les bases “scientifiques” (SDB) qui permet de récupérer en mode anonymisé strict les fiches arthroplasties “envoyées” en dynamique par les utilisateurs “liés” à telle ou telle base RDB. L’administrateur global (ARIA) crée la SDB et la “lie” à une ou plusieurs RDB… Chaque AL des RDB concernées “relie” à son tour tel ou tel utilisateur de la RDB à la (ou les) SDB disponibles. Ces utilisateurs pourront donc dès lors de façon volontaire, utiliser cette fonction analogue à l’utilisation d’un flux RSS, permettant d’envoyer telle ou telle fiche dans la SDB (à l’unité ou en “paquets” à l’aide de la recherche multicritères). Il ne s’agit pas d’une duplication physique, mais de la mise en place de filtres d’accès, ce qui permet leur gestion en dynamique. A noter que l’utilisateur de la SDB ne peut pas modifier ou supprimer les fiches, ceci doit être réalisé à partir de la RDB émettrice, en décochant la case de liaison à le SDB.
Nous allons ajouter un troisième module de “Base de Données Monitorée” MDB selon les modalités suivantes:
• Les MDB sont créées par l’Administrateur global et selon le même principe que les SDB, sont “reliées” à telle ou telle RDB. Il y aura en principe une MDB par étude spécifique.
• L’AL de la MDB n’a pas à être un professionnel de santé puisque (ceci doit être précisé), soit les fiches de cette MDB sont anonymisées, soit elles ne le sont pas, mais il existe une autorisation spécifique pour l’étude “monitorée”. Il s’agira donc en principe du ou de la responsable des études cliniques du Laboratoire concerné, c’est-à-dire le Data Manager (administrateur du Promoteur Industriel).
• L’AL de la MDB définit les utilisateurs de la MDB et les protocoles (nombre de cas, modalités d’entrée des données, périodicité des contrôles cliniques, …) qui lui sont affectées: ainsi chaque chirurgien de l’étude se voit affecter un login/mot de passe spécifique, et l’accès uniquement à ses propres fiches. Au contraire le Moniteur/promoteur aura accès à la totalité des fiches de la MDB. A noter que cette section Administrateur inclut également l’audit trail, avec possibilité d’adaptation spécifique à préciser le cas échéant.
2 – Le module MDB
Outre la section “Administrateur” de ce module, dévolue au Data Manager, la section “Utilisateur” se définit comme suit:
• Une première page d’accueil reprenant les différents points de l’étude selon les dispositions du cahier des charges habituel pour les études cliniques. Cette page liste également les participants de l’étude, avec les détails liés (adresse, date de début de la participation, e-mail, etc…). Cette inclusion des e-mails permettra la correspondance ultérieure entre le Data Manager et les chirurgiens via un forum “privé” du site OrthoWave.net, avec accès direct à partir de cette page (lien vers www.orthowave.net > forums > forum privé “étude x” ) selon mot de passe (Ainsi le Data Manager est automatiquement le gestionnaire de ce forum privé dédié à l’étude en cours).
• Les articles du menu sont respectivement “Suivi Etude // StatWave // Call Image // Export // Tools” avec en fait les mêmes menus que les SDB classiques, mais inclusion d’un onglet spécifique “SUIVI” et par contre (ce point devra être précisé) pas d’accès aux fiches patients. La recherche multicritères sera par contre active pour les Stats et la gestion des images.
La fenêtre “SUIVI ETUDE” comprend deux onglets: “Statut ” et “Fiches”:
- “L’onglet “STATUT” reprend
o L’avancement des différentes étapes pour les différents chirurgiens concernés, en rappelant que chaque chirurgien ne voit que ses patients, alors que le moniteur/manager voit la totalité. A noter que les noms des chirurgiens peuvent être listés sous leur pseudo respectif.o Un tableau de situation, (exemple ci-dessous) avec pour chaque centre, et pour chaque délai (“baseline, 3m, 6m, 12m, 24m, 3a, etc…) le nombre de cas de l’étude selon les sous-colonnes suivantes: a:OK, b:en cours, c: exclus, d: PDV, e: DCD, en sachant naturellement que pour chaque centre à chaque délai, a doit être égal à b+c+d+e, avec explication en clair des PDV, exclus et cause des décès éventuels)
o Un graphe résumant en barres cumulées le nombre de fiches complètes vs le nombre de fiches en attente à chaque délai, selon l’exemple ci-dessous:
o A noter que si chaque chirurgien ne verra que la ligne lui incombant dans le tableau, et seulement son graphe spécifique, le Data Manager verra par contre la totalité du tableau ainsi que le graphe global et autant de graphe complémentaire que de centres concernés…
- L’onglet “FICHES” se compose :
o d’une liste déroulante pour le choix du centre à vérifier. Si l’utilisateur est l’un des chirurgiens, seul son nom apparaîtra dans cette liste, sinon (DataManager), la totalité des noms sera visible, permettant de sélectionner tel ou tel évaluateur.
o Pour chaque chirurgien choisi, un tableau va lister la totalité des patients (mode non anonymisé? A préciser), et successivement dans les colonnes du tableau:
– Date d’inclusion: date en clair
– Visite préop : avec coches en couleur “N/A, OK, incomplet, ou manquant” selon les cas
– Date intervention: date en clair
– Pour chaque visite à chaque délai: coches en couleur “N/A, OK, incomplet, ou manquant” selon les cas
– Une indication “Modif” : oui/non avec les dates/motifs de modifications énoncés en clair dans un champ de notes de cette page
– Une case “Gel” : oui/non. Aussi longtemps que la case “gel” n’est pas activée, la fiche n’est pas incluse dans les stats. A préciser si ce “gel” doit se rapporter à l’ensemble de l’étude, ou si le gel intéresse chaque étape de l’étude… Le “gel” est défini par le Data manager à partir de cette fenêtre. A partir de ce gel, aucune modification à partir de la fiche émettrice de la RDB n’est possible.
3 – Les adaptations de la base RDB pour liaison aux MDB correspondantes.
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.
Il faudra 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 comprend plusieurs sous-onglets:
• Sous-onglet “MASQUE”: Les items du masque de saisie: certains items sont déjà présents dans la base standard, d’autres sont spécifiques à l’étude. Il apparaît 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 permet 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 faisons pour les registres des prothèses).
. Sous-onglet “STATUT”: cette sous-fenêtre liste pour la fiche en cours les différents éléments qui seront transmis à la MDB, à savoir ce qui a été défini ci-dessus:
o Les diverses étapes de la fiche:
– Date d’inclusion: date en clair
– Visite préop : avec coches en couleur “N/A, OK, incomplet, ou manquant” selon les cas
– Date intervention: date en clair
– Pour chaque visite à chaque délai: coches en couleur “N/A, OK, incomplet, ou manquant” selon les cas
– Un case “Modif” : oui/non avec les dates/motifs de modifications énoncés en clair dans un champ de notes de cette page
o Le bouton d’envoi à la MDB, de type après fenêtre de confirmation.