OrthoWave aims to afford a consistent integrated computerized tool, covering all clinical and radiological outcomes in Orthopaedics, with respect to Hip and Knee Arthroplasty, and soon with addition of other modules such as Shoulder, Knee Ligaments, Spine, …). The current architecture of the software mainly addresses the so-called “post-marketing” studies and publishing about personal series (“regular” data bases as RDBs) or in 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.
Obviously, it becomes necessary to complete nowadays the existing architecture of OrthoWave, while taking advantage of the already available advanced routines (namely through the Ajax secured web-based platform), in order to tailor the specifications as requested by the Clinical Affairs Departments (CADs), while reducing at the most costs of development by taking advantage of the existing OrthoWave architecture.
As a matter of fact, more than 95% of these requested specs are already on use. With respect to the remaining 5%, some additional developments naturally can be planned, however must be discussed later on, as based upon the real need for such somewhere complex procedures.
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 the requirements of the specs as needed by the CADs, while limiting at best costs and related expenses in terms of developments. 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) can 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.
1- The various OW modules
OrthoWave currently provides two types of modules:
• The “Regular” Data Bases (RDBs), allowing for entry data, statistics, management of images and import/export of data. These data bases are managed by a “Local Administrator” (LA), who grants to Users their personal login/password upon three levels (full rights, read only, read only under anonymized mode). This LA also allocates, to each User, the Surgeons who will be “linked” to him, and in such a way, each User will only get access to Patients forms, statistics and images belonging to the surgeons to whom he got “linked”…
• The “Scientific” Data bases (SDBs) which allow for having access under strict de-identified procedures to the Arthroplasty forms which have been previously transmitted upon dynamic means by Users which are duly registered to be “linked” to the given RDBs.
– The Global Administrator (ARIA) creates the SDB and “links” it to one or several RDBs…
– Then each LA of the “linked” RDB can “link” any concerned User of his RDB to the available SDB(s).
– These Users will thus be able, upon a voluntary action, to use this “RSS like” feature and transmit forms to the related SDB (singly or by packs, via the multicriteria search).
– It would be borne in mind that the forms are not “physically” duplicated on the Server. In fact they are reachable through various filters which permit a specific access to them either from RDBs or SDBs, and thus enable dynamic “linkage”. By the way, any SDB User cannot modify or delete an arthroplasty form; this has to be done from the transmitting RDB, by cancelling the related tick from the given form.
We plan to add a third type of Data Base as “Monitored Data Bases” (MDBs) featuring the following specs:
• MDBs are created by the Global Administrator (ARIA), and upon the same principles as defined for SDBs, will be “linked” to one or several RDBs. We would consider one MDB by specific CAD study.
• The Local Administrator (LA) of any MDB is not necessarily a professional of health, as (this point must be notified at creation of the Data Base) either the forms belonging to these MDBs are de-identified, or a specific authorization has been provided for these “monitored” studies. In such a way, the LA will usually be the person in charge of Clinical Affairs of the concerned Company, i.e. the Data Manager (DM) of the CAD devoted to the Device Manufacturer.
• The LA of each MDB defines who will be the authorized Users of the MDB, and the protocol which will be allocated to each of them (number of cases, entry data protocol, serial visits, …); Then each User participating in the study gets a personal login/password enabling him to address only the cases of his own. Conversely, the Monitor /Data Manager gets access to all forms inputted in the MDB. It should be noted that this MDB Administrator section features the Audit Trail as well, being said that this Audit Trail can be eventually modified and extended.
2 – The MDB module
As for all other OW databases, the MDB will comprise on the one hand an “Administrator” section, to be taken over by the Data Manager, and on the other hand a “User” section, which can be described as follows:
• A “Home page”, displaying the various topics and matters of the current study, as previously defined according to the usual specifications of Clinical Affairs Studies. This page also shows the names of the surgeons involved in the study, as well as their details (address, date of first enrollment in the study, e-mail, and so on…). This e-mail notification will further on allow any piece of information to be shared between the Data Manager and Surgeons via a “private forum” of the OrthoWave web site (link to www.orthowave.net > forums > “given study” related private forum), through a specific password (In such a way, the data manager is automatically the manager of this “given study” related private forum…).
• The menu Items of this section are respectively: “Follow-Up // StatWave // Call Image // Export // Tools”, mimicking the menu items of the classic SDBs, however including a specific window named “Follow-Up”, and conversely (this point has to be discussed) no access to Patients forms. The multicriteria search on the other hand will be activated for Statistics and Image catalogue.
The “FOLLOW-UP” window comprises two tabs: “Status” and “Forms”:
• The “STATUS” Tab shows progress of the various steps according to the concerned surgeons, being said that each surgeons can get access to forms of his own only, while the Monitor/Data Manager can get all forms displayed. It should be borne in mind that the names of surgeons can be displayed under their related pseudonyms.
In such a way, we would find:
o A “Study flow chart” (as in the example below) showing for each Centre, and for each F/Up period (“baseline, 3m, 6m, 12m, 24m, 3y,…) the number of cases of the study according to the following columns “a: OK // b: DUE // c: Excluded // d: Lost to F/Up // e: Dead”, being said for each Centre, at each period of time, a=b+c+d+e, while explanations must be explicitly provided for any Lost to F/Up, excluded and dead cases.
o A graph, displaying the total number of completed forms vs. outstanding ones at each period, as in the example below:
o It should be noted that each surgeon will see only in the table the line specifically related to his activity, and only his specific graph. Conversely, the Data Manager will see the entire table as well as the global graph in addition to all other graphs related to surgeons’ activity…
• The “FORMS” tab can be defined as follows:
o A drop down list for selecting the Centre to be checked. Would the User be one of the concerned surgeons, only his name will appear in the list. Conversely, whether this User is the Data Manager, all names will be shown in this list, allowing for choosing one or other of the surgeons.
o For each participating surgeon, a table will list all patients (under anonymized mode? To be discussed…), this table comprising several columns:
? Date of inclusion in the study: as unscrambled date
? Preop examination : through colored ticks “N/A, OK, outstanding, missing” according to each situation.
? Date of surgery: as unscrambled date
? For each further examination at each F/Up period: colored tick as previously defined: “N/A, OK, outstanding, missing” according to each situation.
? A “Modification” status: Yes/No including dates/reason for modifications to be detailed in full text through a note field at bottom of the page.
? A specific notification: “Freeze” : Yes/no. As long as this “freeze” status is not duly activated (i.e. “yes”), the form will not be added to final statistics. It will be critical further on to consider whether this “freeze” status concerns the entire study or specifically each step of the study… This “frozen” situation is assessed by the Data Manager from this window. As soon as the form is defined as “frozen”, and thus participating in the statistics, no further modification via the transmitting RDB can be done.
3- Adaptations to be planned for transmitting RDBs to be linked to corresponding MDBs
The global architecture of existing RDBs is maintained…
The “regular” database from which the forms to be linked to MDBs will be created must transmit pieces of information appropriately. The global architecture of existing RDBs is maintained, which enables Surgeons to use also their database for personal evaluations, linkage to any other SDB or eventually other MDBs, according to their personal motivation… The solution as presented in this MDB project to participate in CAD studies interestingly does not imply any personal restricting obligation or any double entry data.
A specific tab will be created for each study…
A specific tab will be created for each study, reachable via a password located in the Local Administrator section of the transmitting RDB, after having been previously agreed by the global Administrator (ARIA).
This tab comprises several “sub tabs”:
• Sub Tab “INPUT MASK” listing the items belonging to the CAD Study input mask as well: some of these items are already present in the “regular” OW input masks, while some others are more specifically devoted to the CAD study. It seems agreeable to show as a whole the input mask of the CAD study including all related items.
In such a way, either entry data can be performed via the usual OW windows (the corresponding fields will be automatically duplicated in the CAD study input mask window), or conversely directly through this CAD study window for all items, which allows for inputting all study items at once. It would be borne in mind that considering the first option, would the surgeons prefer input data first in the usual OW windows, which is generally the case for OW regular users, it will be easy then to simply fill in the missing items of the CAD study window, which is already the procedure to be used for Joint Registries.
• Sub Tab “STATUS”: this sub tab lists for the current study the various pieces of information that will be transmitted to the corresponding MDB, i.e. what has been defined here above:
o The various steps of the form
– Date of inclusion in the study: as unscrambled date
– Preop examination : through colored ticks “N/A, OK, outstanding, missing” according to each situation.
– Date of surgery: as unscrambled date
– For each further examination at each F/Up period: colored tick as previously defined: “N/A, OK, outstanding, missing” according to each situation.
– A “Modification” status: Yes/No including dates/reason for modifications to be detailed in full text through a note field at bottom of the page.
o The button for the form to be transmitted to the corresponding MDB, as a button, under surgeon’s agreement