As previously reported, OrthoWave aims to afford a consistent integrated computerized tool, covering all clinical and radiological outcomes in Orthopaedics, with regards mainly to Hip and Knee Arthroplasty, and soon with addition of other modules such as Shoulder, Knee Ligaments, Spine, …. The current architecture of the software addressed in fact the so-called “post-marketing” studies and publishing about personal series (”regular” data bases as RDBs) or within the frame of multicenter studies (anonymized “scientific” so called SDBs databases). It became obvious that this organization cannot specifically tailor the strict needs and recommendations devoted to the “monitored” clinical studies carried out by Clinical Affairs departments of Devices Manufacturers, and namely with respect to the so-called “pre-marketing” studies
Thus the MDBs (i.e. Monitored Data Bases) were born, which will constitute, in addition to the “Regular” Data Bases RDBs and anonymized “Scientific” Data Bases SDBs, the “Third Pillar” of the OrthoWave Outcome Study Suite. These MDBs are currently on duty, and the following lines will define again rationale, principles and running of these monitored databases, as well as dynamic links and interaction between these MDBs and the “regular” databases RDBs from which CRFs (Clinical Record Forms) have been recorded, under the global OrthoWave architecture and organization. By the way, a set of devoted tutorials will allow for highlighting the various steps of creation, settings, customization and use of these MDBs…
The always difficult balance between the rigor usually required for monitoring studies and a more or less flexibility claimed by Orthopaedic Surgeons, who are extremely reluctant to restricting EDC constraints, has been a major concern while elaborating this project. Moreover the proposed solution has to meet anyway the requirements of the specs as needed by the Clinical Affairs Department (CADs). Last but not least, take into account the rightful refusal by surgeons to waste time by any redundant double entry data (with respect to entries for on the one hand evaluations of his own and on the other hand participation in CADs studies) could be seen as an absolute prerequisite, allowing in all cases surgeons to follow up their patients after the CAD study has ended, with an eye to the future about publishing at longer follow-up the implants previously studied as CAD procedures, solely or combined with other implants.
Principles and Rationale of MDBs:
Getting started with a new MDB involves three serial steps, being said that:
– (1) The Global Administrator (ARIA) firstly create a MDB which will be devoted to a specific study (one specific MDB will be created for each particular study), then
– (2) The Local Administrator of each RDB which will get involved in the study, links all authorized users and makes them able to “send” the forms to the appropriate MDB (under a similar procedure as already in use with respect to links between RDBs and SDBs).
– (3) Finally the Local Administrator of the newly created MDB, who generally is the Data Manager of the current study, will first set up the various parameters which concern the study itself (modes of inclusions and follow-up, participation of Surgeons and Centers) and then select the clinical scores to be used, and particular settings for statistics and radiographic analyses.
1- Step 1: Creation of the MDB by the Global Administrator (GA):
Naturally several RDBs can feed a same MDB, and conversely each RDB can participate in several studies through appropriate links to several MDBs, in addition to potential links to existing SDBs.
In such a way, the GA simply creates the new MDB, and specify which existing RDBs will be authorized to get linked to this newly created MDB…
2- Step 2: Link provided to Users of a RDB to the MDB:
The Local Administrator (LA) of each RDB (which is now potentially linked to the MDB) may allow one or several users of his RDB to send forms to this MDB. In such a way, only “authorized” users will get the “send form to MDB” window displayed. This process allows for great versatility and efficiency, especially with regards to huge databases that are shared by numerous users.
By the way, as soon as inclusions are “frozen” to this MDB, this dynamic link will automatically get disconnected.
With respect to the first tutorial presented here, whether in the RDB taken as example, 6 users are present, only Users 1,4 and 5 will in fact send the forms to the MDB. Details of this procedure of creation and use of these links between RDBs and MDBs will be demonstrated further on via an additional tutorial
3- Step 3: Set up of the MDB by the LA of this MDB:
It needs to be said first that the Administrator of this Monitored Data Base (generally a manager of Clinical Affairs Department of the involved Company, i.e. the Data Manager (DM), has not to be personally a professional of Health, unlike in RDBs, since either data are anonymous, or a previous agreement has been afforded in that matter while defining the ongoing study.
– Firstly the LA registers the authorized users to get access to the MDB, being said that these users would be naturally the Surgeons who are involved in the study, or Clinical Research Assistants (CRAs), or again any authorized person, under the LA’s decision. Two levels of rights are available (without any “full rights” level as modifications/creations of forms are to be done from the RDB and not at MDB level), either read only with full private details or read only under anonymous mode. This assignment stays under the LA’s control. As commonly done in RDBs, any user can be “linked” to any of the “surgeons/centers” available in the list which is displayed in the related window of the Administrator section. In such a way, logically the Data Manager will get a login/password allowing him (her) to get access to the whole database, while conversely other users (be they surgeons or assistants or secretaries) will be linked only to the forms of their own, and so will not be able to get other forms to be shown. However the LA might decide to “attribute” to one or several users (and especially for the Surgeon who will be responsible for the group) the link which will allow getting access to the database, wholly or in part. Again this procedure is extremely versatile, user-friendly, and able to tailor any particular scenario.
– Then the LA will set up the ongoing study through the Administrator section, and namely with regards to the number and assignment of included cases, while considering the surgeons to be involved in the study, as well as frequency of visits (fully flexible). Additionally the official protocol for the study and the list of participating surgeons will be recorded in the MDB.
– Finally, clinical scores to fit the initial protocol will be selected from the global list of all available clinical and radiological scores which are all provided by OrthoWave, be they concern Hip or Knee arthroplasty. Generally the used scores will regard for Hips the HHS (and eventually the Merle d’Aubigné-Postel score), and for knees the IKS score, completed by any additional questionnaire (we would recommend the Oxford scoring system), being said that there is no limitation and any other scoring system or questionnaire stays available in OrthoWave as well, and some additional score would be customized under request… One would keep in mind that whether an evaluation of a patient at a given follow-up cannot allow for assessing all requested scores, the “visit” CRF will be notified as “incomplete”, and thus this selection of scores prior to launch the study remains critical. Anyway the surgeon who participates in the study can at any time use any other scoring system at will for his own use…
– Another feature afforded by the Administrator section of the MDB consists in choosing whether the statistics can be performed “on real time”, i.e. all along the lifespan of the study and inclusions in the MDB, or conversely whether the LA prefers waits for all clinical cases to be “frozen” after the study has come to its end.
Running of MDBs:
Details about running and use of a MDB, for its set up as well as its use upon practical matters, will be describe through a specific tutorial. Anyway it can be said right now that the main difference for users of any MDB as compared to the classical RDBs refers to addition of an additional tab entitled “Studies” leaving access to 3 sub tabs as follows:
1- The first sub tab “Protocol” displays under a read only mode the official study protocol as defined by the Data Manager.
2- The second sub tab “Status” allows for immediately checking statistics about visits and follow-up of enrolled patients, including at any follow-up period (as set up in the protocol) all “due” CRFs at the given period of time, as well as “incomplete” or “missing” CRFs, and in addition all patients who are either deceased or lost to follow-up or “out of study” for any reason to be notified in full text via the “notes” fields. In such a way, each surgeon can see his own patients and related statistics , as well as statistics of the whole group, which allows him knowing “on real time” at which level his participation can be assessed within the group. A global diagram sums up step by step the advance of the ongoing study, which is naturally printable or exportable as well.
3- The third sub tab entitled “Forms” displays for any surgeon/center participating in the study or for the whole group, a global directory of patients belonging to the MDB, with a colored label for each patient at any follow-up period. These colors, i.e. green for complete CRFs, orange and red for incomplete and missing ones, however also grey for “lost to FUp”, black for deceased patients, and finally pink for “out of study” patients, allow at a glance visualization for each patient of his advance and participation in the study, and eventually the CRFs to be complete for each of them. Related activity reports can be thus available again on real time by each surgeon/center or study managers and reviewers, being said that naturally these reports can be edited for printing or mailing as well…
It has to be highlighted that only CRFs for which all requested fields have been duly inputted can be “sent” from the RDB to the MDB, which will prevent for any further tedious review of missing fields upon the MDB. Would any modification to be performed on a given CRF, this has to be done by the “transmitter” surgeon through his own database, and automatically and instantaneously updated in the corresponding MDB, since the link is a dynamic one. By the way, whether at any time the Data Manager wishes to “cut” any dynamic link between the “transmitter” RDBs and the “targeted” MDB, an extract of the database, as a whole or in part, can be performed and used off line.
It is to be noticed that eventually some changes would need to be done at RDB level with respect to the various records belonging to CRFs of any pending study, in order to perfectly fit the mandatory fields in the corresponding MDB. In order to avoid boring procedure or double entry data, it will be sometimes appropriate, case by case with regards to the official protocol, to design and develop some specific additional tab, which will be shown under a devoted password. This additional tab will display the records which have been requested for the study, and however do not already belong to the “regular” windows of OrthoWave.
The current OrthoWave architecture
This organization is now coherent and able to tailor all expectations in the realm of outcome studies in Hip and Knee Arthroplasty, of each of actors belonging to our Orthopaedic Community. Data themselves are stored through numerous “regular” databases which remain managed by surgeons (or groups of surgeons), who keep strict control on the RDBs of their own, while being allowed :
… under anonymous mode sharing some specific results of specific implants with an eye to future publications or scientific analyses, here are the SDBs
… however in addition participating within the frame of MDBs in some strictly monitored studies, while keeping at any time the absolute control of all their data, the ones which will belong to MDBs, as well as all others…
This data sharing has been designed to remain absolutely flexible and able to tailor any situation… In such a way, through the attached tutorial as an example, the diagram shows respectively 6 RDBs, 4 SDBs and 4 MDBs: it can be seen that RDB1 has been linked at the same time at MDB1 and SDB1, while this SDB1 gets linked not only from RDB1, but also from RDB2, which RDB2 remains in addition linked to SDB3. Conversely, RDB4 gets linked only to SDB3, whilst RDB3 doesn’t share its data with any other database… Additionally, RDB5 can “send” forms at both MDB4 and SDB4, while RDB6 will be able to communicate either with MDB2 or MDB3… Gosh!…
As a conclusion, this post aimed to detail principles of management and running of these new OrthoWave monitored databases, of which we are pretty sure that they will meet at best the expectations of Clinical Affairs and Clinical Studies managers, while being of critical help in preparing and “monitoring” the implant files and related results to be presented to Health Authorities or others. Despite our analysis while developing these MDBs has been led through thorough and complete investigation about mandatory records and study features during the past 12 months, we naturally stay tuned to any additional comment or advice from specialists in Clinical Studies, CRAs, Registrars, and of course Surgeons in order to make this new OrthoWave tool better and better, since it is before all YOUR tool!
An additional “post” to be released soon via this OrthoWave-Community blog will give us the opportunity to precisely detail through a set of devoted tutorials the various features regarding settings and use of theses linked RDBs and MDBs, for Local Administrators as well as Users…
See you soon then, and more than ever… Be OrthoWaved!