Thanks to the current secured Web-based on line version of OrthoWave, all issues related to security systems in Hospitals and Clinics upon firewalls and other proxies, preventing from convenient direct access to the former on line Java Server, have been totally cleared. The current “Ajax” version actually allows for storing both program and data on the server in accordance with a “cloud computing” principle, via a secured https web system. It was then consistent to keep only the on line version on duty, this version being able to afford better management and sharing of these data dases, with respect in particular to scientific databases SDBs and “monitored” databases MDBs.

However, even if collecting data on any off line database is no longer appropriate, on the other hand, an off line version must be kept on as a “data viewer”, in order to work on the DB, carry on analyzes, prepare lectures and scientific articles, also in some locations where it is (for the time being) yet impossible to get connected to the Internet facilities via any high speed connection, be they plane, train, or again some offices or surgical theatres…

We thus have featured a specific procedure allowing for extracting the forms belonging to any on line DB on the Internet, so as to get this data base getting transferred in an off line OW version, which can be freely downloaded on any laptop. One or several on line databases or “sub databases” can be imported in this off line “data viewer”, which can be used at will while getting access to all features belonging to the on line OrthoWave, naturally under a “read only” mode.This extract procedure will thus allow for working on any OrthoWave DB under an off line mode, as a whole or in part through the multicriteria search procedure. This extract can be or not de-identified. The exported file will be stored in the hard disk of the laptop, and then needs to be first imported in the compatible OrthoWave off line version (i.e. the 6.1.1.33 version). It should be borne in mind that due to their weight, images cannot be exported as a full screen display, and will be shown only under the thumbnail mode. Conversely, access to any form, use to the multicriteria search engine, and statistical analyzes can be fully done at will.

For Macintosh users, it should be noted that this off line Java OW 6.1.1.33 version being only PC compatible, Mac users in order to make it work properly must first download an application which will allow a Windows OS getting emulated on their Mac machine. This upgrade will let them able to use either their MAC OS as usual, or switch to a Windows session to get benefit of their off line OrthoWave data viewer. This application is named “Bootcamp” and all related information can be found at the following address: http://www.apple.com/fr/support/bootcamp/  . In fact this software gets included in Mac OS X 10.5 (Leopard) or 10.6 (Snow Leopard), which are the two latest versions of Mac OS X (to be found in  Applications > Tools > Boot Camp Assistant). Then it remains necessary to get here or there a Windows CD installer (be it Vista, XP or Windows 7) to get this Windows version installed into a separate partition. It seems consistent to notice that some absolute Macintosh fans who would never support the idea of incorporating Windows on their machine, or who found a bit complicated this coexistence of two different Operating Systems on their laptop, finally chose for their work in planes, trains or any other nomadic place where they had to work on their off line version, to buy a basic PC laptop, allowing for a direct and easier use of this 6.1.1.33 OW off line version…

launch the OrthoWave "Extract DataBase" Tutorial

Anyway, while moving back to this “extract” procedure, the export is performed from the related menu item from the home on line OrthoWave window: “Import/export > Extract DataBase”. With respect to all these extraction procedures, then about following steps of import and display of these extracted files, it becomes critical to launch the related tutorial located here … This tutorial can be as well launched from the button of the “extraction” window. It works as animated slides and buttons as pause, forwards and backwards can be used at will.

1 – On a practical way, the first step consists in downloading once for all the current OrthoWave off line version, whether not already installed on the laptop. A simple click on the button at bottom left of the “DB extraction” window of your on line OW program allows for downloading this free 6.1.1.33 off line version and installing it on the hard disk of the laptop. (Please bear in mind that this version has to be used only under the “demo” mode without any registration +++). Dezip the archive is mandatory prior to store the uncompressed folder on the hard disk, then open it, find and double click on the <setupOw6_offline.exe>, then simply follow the serial installation steps. Please notice that whether a previous Java version of OrthoWave has been already installed, the so called “R” module being present, any new installation of this “R” module will not be possible… do not pay attention to the error message and click on “OK”. Later on, at any launch of the program, the same login / pass word (as <user1 / user1>) have to be used. Then after usual check of right identity, a message will ask if you want to register or continue on the “demo” version… You need absolutely to answer “No” to immediately get your extracted database displayed and used.

2 – Now it is time to launch the extraction procedure by using the button at bottom right of the “Extract window” of the on line OrthoWave version. This button requests for the use of the multicriteria search window to define the type of database to be extracted, be it a Hip or a Knee database. It is only possible to extract one type of DB at one go, either hip or knee, being said that several DBs or subDBs can be extracted, then used alternately within the same off line OW program. Forms belonging to these “sub databases” (e.g. this or that specific implant, operated on by this or that surgeon during this or that period of time, and so on…) will be selected under the usual search procedures. Whether the selection formula is left empty, then the extract will concern the whole hip or knee database. Simply validate to launch the extraction procedure for the selected database. The downloaded zipped file gets stored in the hard disk of the laptop; check the location of storage remains of significant interest, while displaying it for import in the OW off line program…

3 – The third step consists in importing and using this extracted database. Simply launch your OW off line program (remember!… login / password are user1 / user1), and display the patient directory. Patients belonging to this demo version are listed here. Check the “DATABASE” menu item and pull down it… The second item regards the DataBase Import… Click on this choice to open a sub window, in which one must firstly type a name for this new off line DB to be imported, to get it included in the list of available databases. Then click on this DB name to highlight it, and indicate to the program where the previously extracted database has been stored (usually in the “download” folder), by using the “browse” button. Once the right DB file (ended by an extension as *.ow6) duly opened, click on “validate” at bottom to import this DB in the OW off line folder… These serial procedures can be seen as a bit complicated, so do not refrain from watching the tutorial!

4 – Here you are with your extracted database imported in your off line OW program folder… It is now mandatory each time you want to work on it, to open this DB and get it replacing the demo DB displayed “by default”, or any other DB previously opened on this program. In order to open and display any chosen (and previously imported) DB, simply use the third item of the “DATABASE” menu, i.e. “change database”… This menu item displays either the “default” database, or the list of all available databases from the off line OrthoWave folder. It is thus easy to tick off the chosen DB to get it immediately displayed. Again do not refrain from addressing the related tutorial.

As a matter of fact, would you be unable to extract your database from the on line version, and/or work on it off line, please do not hesitate to join us via the “contact us” facilities from this web site, or by phone at +33321531949, or again via a mail at info@orthowave.net … We would even, upon request and free of charge, perform the extraction of your data base on behalf of you, get it imported in an off line OW program, and keep you downloading the whole stuff at once , to make things easier than the easiest!

… Be OrthoWaved!

We already have got opportunity to detail principles, rationale and running of these new “Monitored” Data Bases MDB… It is great time right now to present upon a practical means three tutorials describing in details the three serial steps which allow for getting a MDB linked to any other existing “agreed” RDV, then for customizing this MDB as to fit the requirements of the pending study, and finally using this MDB to carry out at best the clinical study upon the regulatory commitments about follow-up for enrolled cases.

These three tutorials thus comprise: (1) Settings by the Local Administrator of the “transmitting” RDB allowing for CRFs to get linked with the corresponding MDB by those among all users of this RDB that have been agreed to participate in the study and so to include their cases. The tutorial also describes how these users can “send” their arthroplasty forms to the MDB. (2) The second tutorial is devoted to the set up of the MDB itself by the Local Administrator of this MDB (who generally is different from the “transmitting” RDB Administrator). This set up regards the various parameters of the study, and firstly the agreed users including their rights for getting access to CRFs, choice of follow-up periods to be considered, and used clinical scores, as well as any kind of administrative data allowing the Manager to get in touch at any time with any of the actors participating in the ongoing study. (3) The third tutorial at last, is in fact the most important as it details the practical use of these MDBs while carrying out any study, namely with respect to the three specific MDB sub-tabs devoted to the display of the official protocol, as well as current statistics about inclusions of CRFs and status at the various follow-up periods, and also the directory of all enrolled patients with personal status according to their participation in the study. The monitoring of any clinical study can thus be performed ideally and on real time…

These tutorials get launched by clicking on the related picture. Adobe Flash Player must have been previously installed on your computer, as for any other tutorial on this blog… Don’t refrain from using forth and back arrows, as well as the “pause” button, whether any detail needs a bit of additional time…

1- Creating the link to MDB(s) by the Local Administrator of the “transmitting” RDB

Click for launching #1 tutorial

This RDB having been previously agreed by the Global Administrator to be “linked” to the given MDB(s), the Administrator may choose among the registered users of this RDB the ones who will be allowed to send their forms CRFs (Clinical Record Forms) to the authorized MDB(s).

These agreed Users will thus be able from the “arthroplasty” form of any patient to be enrolled in the study, to “link” this form dynamically to the related MDB, under a process already described for linking a form to a Scientific DataBase… Sending bundled forms can be done as well through lists obtained thanks to the multi criteria search.

It has to be said that a control process at source prevent from sending incomplete forms to MDBs… The various mandatory records from the “demographics” as well as regarding prosthesis related ones must have been duly populated for the form to be linked to the study. This point is critical for avoiding later on any tedious double check…

2 – Set up of the Monitored Data Base by the Local Administrator of this MDB:

Click for launching #2 tutorial

These settings are of major importance since they will allow for “customizing” any study upon the protocol that has been previously defined while being discussed at birth of the project with the involved group of surgeons. The first step of course consists in registering the Users of this MDB, and granting both their specific rights (de-identified or not, being said that the forms are under a “read only” mode in all cases, no creation or modification being possible from the MDB), and the Surgeons who will be “allocated” and of whom they will be able to get forms and statistics displayed. Of course the Manager of the study will get access to all forms belonging to the study on real time in order to monitor the advance of the data collection.

This set up will then regard the registration of the official protocol for the ongoing study, which will be later on displayed on the User section to make reference at any time. The clinical follow-up periods at which visits have to be performed will be notified, as well as all contact details about Surgeons / Clinical Centres getting involved in the study. Thes surgeons would be thus easily addressed by mail or phone with respect to any additional finding, explanation or comment about their forms, results or potential adverse effects.

Lastly the selection of clinical scores remains critical, being said that whether more than one score has been chosen among all officially registered scores available from the OrthoWave “portfolio”, each CRF will need to get all the chosen scores duly performed for the CRF being assessed as “complete”. Additionally, the Manager of the ongoing study can choose whether statistics of clinical results can be provided only for “totally complete” forms, or if they might refer to the ongoing study as a whole.

3 – The practical use of MDBs by involved actors of the study:

Click for launching #3 tutorial

This third tutorial is in fact the most critical, while detailing the practical use of the MDB to carry out the study, namely through its three specific sub-tabs, i.e. the first displaying the protocol of the study, while the second allows for watching on real time statistics of inclusions and follow-up of forms by surgeons or for the whole group, and the third sub-tab lists all enrolled patients with colored disks upon their status and advance in the study. The monitoring of the study can thus be done under a continuous control, and precise assessment of “frozen” records for the various actors of this study

Of course, any other feature commonly provided in RDBs will be available upon these MDBs, i.e. watching forms, complications and clinical results, analyzing x-rays and videos, playing with statistics as well as exporting as csv files the whole data inputted in the MDB, be they surgical reports or clinical results, to be forwarded to any specifically statistics devoted software for additional high level analyses.

Another process is provided by MDBs to automatically recall patients for due visits, which is of great help for the secretarial staff. Each surgeon in addition receives at serial periods upon Manager’s wishes the statistics of his own about inclusions of patients in the study, and related visits to get completed. Naturally, each surgeon will be able to watch only (apart from a specific choice from the Manager) his own patients’ forms and in no case the other forms from his colleagues. He nevertheless can compare his own statistics, about follow-up or clinical results, to the study as a whole.

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…

Click to launch the tutorial

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:

Click to enlarge

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):

Click to enlarge

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:

Click to enlarge

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:

Click to enlarge

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 :

Click to enlarge

… 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

Click to enlarge

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!

You have heard about OrthoWave in good words? Excellent… You have tested, analyzed, compared, assessed the various outcomes studies softwares in Arthroplasty, and the final choice is… OrthoWave! Congratulations and thanks for putting your confidence in us… Welcome aboard!

Based upon a practical way, too often prospective Users do not really know how and where they can purchase the Software, and then while receiving their access codes as Administrator of their own database (DB), get a bit lost at the time they have to settle it appropriately…

We have thus designed for you these two tutorials, devoted respectively for the first one to the means of purchasing on line the OrthoWave software suite, and for the second to setting up the prospective DB of your own, as being its Administrator. Of course, would you receive an access code as a User of an OW existing database, no specific setting is requested from your side, and you just have to be in touch with your “Local Administrator”… However, you might get interest in discovering this tutorial anyway. After all, maybe soon you will feel the call of run your own data base ?

1 – Buying OrthoWave on line

Click on the picture to launch the tutorial

This first tutorial describes how through the www.orthowave.net site, you have first to create a personal OW account, then get access to the “OrthoWave on line store”… The first step consists in selecting the number of surgeons whose patients’ data will be inputted in the prospective DB, which determine in fact the price of the software suite.

Please notice that the definition of “Surgeons” is important within the OrthoWave organization… The so-called “Surgeon” is the one whose patients belong to the database, be him or not the “Operator”. The Operator is the one who performed the surgery, and generally this operator is the same person as the surgeon… However, in some cases, and namely in Hospitals, Operators can be Residents, or temporary Assistants who will stay in the department only a few years, while the follow-up is supposed to remain efficient in the long run… In such cases, it seems relevant to link the surgery to the Operator as performing the surgery, and to the Surgeon who will follow-up the arthroplasty, as being in charge of the patient during the whole period of time in the Department, be this Surgeon the Chief of Department, or any other Professor or permanent Doctor. On a practical means, while ordering the software, logically the number of surgeons who will really have their own patients in the DB all along the follow-up of arthroplasties must be indicated. By the way, based upon privacy concerns, it must be said that a given “User” who will be linked to a given “Surgeon” (or to several ones) will get access only to the Patient forms “belonging” to this given surgeon (or these ones). To make short, all patient data will be grouped upon their surgeon’s name, and it is thus mandatory to make this sorting by surgeons efficient to limit access to the only forms which are linked to him.

On the other hand, the number of “Users” of the Data Base is not limited, and these various users will get “linked” to one or several surgeons of the DB, and thus get access only to the Surgeon’s Patient forms (or Surgeons’ ones), upon their specific rights as defined by their Administrator (full rights, or read only, anonymously or not).

Once the number of prospective surgeons in the DB indicated, and the type of DB duly notified (Regular RDB or de-identified Scientific SDB), The next step consists in reading carefully and ticking off the boxes appropriately for the three following agreements, as first the “End User Licensing Agreement”, secondly the “Privacy Agreement as Administrator of an Health Data Base”, and thirdly the “General conditions of Sales”. Payment can be done either par secured on line purchase, or by bank transfer, after having indicated the billing details.

Once the registration duly validated, your Data base will be created, and an email indicating your access codes as the Administrator will be sent to you as well… It will be time for setting up your Data Base!

2 – Setting up your OW Data Base

Click on the picture to launch the tutorial

The “customization” of the DB starts with registration of Surgeons, Operators and Reviewers of the Medical Staff. Apart from the First and Last Names, a Pseudonym must be linked to each name, in order for surgeons’ identity to remain de-identified while sending forms to shared scientific databases SDBs. Then similarly, Institutions details must be inputted.

A critical step consists in creating the Users accounts to precisely define who is authorized to enter the DB, and get access to specific Patient forms, upon the three levels previously defined ( full rights, read only and read only anonymously). Each User will be then “linked” to one or several Surgeons, and this User will be only allowed to get access to the patients forms that “belong” to this or these Surgeons. This procedure is fancy, versatile and efficient, while staying under the absolute control of the Administrator.

Another important step regards the “customization” of the Data Base, while selecting the various specific items to be displayed during the use of this “local” DB. It mainly concerns the various components of the prostheses, for both hip and knee arthroplasty, by editing a “local” list of components from either the components of the “global catalogue”, or the specific implants of one’s own, simply added to this list… Only the selected implants which belong to this “local” list will be shown while inputting data through the User section.

Same procedures of selection of items from either the global catalogue or personal items, will be performed for editing the various key-words applied to Hip and Knee modules, i.e. 5 groups of key-words: Patients, Images, Previous Conditions, Complications, and Additional Procedures… This menu item allows as well for setting up the default values to be used as shortcuts for surgical reports, and for directly editing 200 “custom” fields (i.e. 50 customized items and 50 customized evaluations upon the Hip module and as much upon the Knee one). These customized fields can be created without any specific development and get immediately linked to statistics, multicriteria searches and exports…

Then from the “Settings” menu bar, a selection must be done within the proposed scoring systems to define what assessments and questionnaires will be shown on the menu bar of the User section. OrthoWave allows for using quite all current official scoring systems, however whether you will only use HHS and Oxford assessments for Hip survey, it seems not relevant to display in addition SF12, Womac, HOOS!… This window also allows for choosing some side options as showing help balloons, units of measurement, or other specific choices for this DB.

The “Log” item of the “TOOLS” menu bar has not to be set up… It refers to the “audit trail” procedure, which will automatically, all along the use of the Data Base, keep stamped traceability of each creation, import of image, or modification on any form, with name and reference of the User and access rights to the DB data.

Hopefully, these two tutorials would allow each prospective Administrator of any OW database for easier and fancier conditions for getting started… In case of any additional request or question, it remains strongly recommended to directly address the OrthoWave hot line by phone (0033321531949), email at info@orthowave.net , or of course via the “contact” section of this www.orthowave.net web site.

Soon be in touch then for setting up your database… Be sure we will do more than our very best for you and your whole staff being more and more comfortable while running this outcome study tool !…

As this New Year comes up, it is our pleasure on behalf of the entire OrthoWave Staff, to present to each of you our very sincere wishes of happiness and fruitfulness. Be sure we will do more than our very best, all along this coming year, to make you taking advantage of the huge work we have been achieving during the past 12 months. In the course of 2009, we have afforded enormous resources in order to take up the challenge of making OrthoWave stay as the “ultimate tool in outcomes studies in Orthopaedics”, while fulfilling on the one hand strictness of legal duties with respect to privacy and computerized safety, and on the other hand resorting to the most powerful and modern computer systems.

These critical developments regard firstly the new “web-based” platform to get access to the DataBase, then the “OrthoWave Orthopaedic Community” through a totally redesigned OrthoWave web site, and finally a necessary adaptation to extremely changing regulations about clinical studies with the development of a third group of OW databases, i.e. the “MDB” monitored Data Bases…

A sound change can be anticipated, willingly or reluctantly, regarding mentality among Orthopaedic Surgeons, with respect to their participation in clinical studies and scientific reports. OrthoWave then has to be empowered to meet with these various changes at best, while staying in accordance with its concept of software designed by surgeons for surgeons, under the aegis of Scientific Societies, and in conformity with legal related recommendations by Health Departments…

1 – THE “WEB-BASED” PLATFORM

The first change regards the “web-based” OrthoWave interface calling for the novel Ajax concept (Asynchronous Java scripts and XML), announced by the beginning of this year, and currently available for our OW users. This “web-based” platform does not mean any new version, simply a new interface to reach our Global Server, faster, better working, and moreover making reference to the modern concept of “cloud computing“, under which the User has no longer to download any program on his computer unit, while data are similarly stored on the global secured server. In such a way, anybody can get access to and use OrthoWave from any computer provided that it is connected to Internet through a high speed connection via the secured https://web.orthowave.net web site, exactly as anyone can check on line his bank account. This became critical as it was an absolute need for OrthoWave to be easily used in Hospitals and Clinics, which was often complicated and sometimes impossible due to the access restrictions to our Java platform via the open 8080 port.

At present, OrthoWave can be launched upon two platforms, i.e. Web-based and Java, which can be used in parallel, by using the same login/password, as both of them address the same Server. Moreover, we have redesigned all web pages to make them become more attractive and user-friendly. This Web platform will be soon the only one to be maintained on duty, because of its numerous assets as compared to the java one: it is no longer necessary whatever the platform Windows or Mac is used, to download programs or various updates and patches, collection of data (EDC) is faster, multicriteria search is improved, and above all easy access is gained from any computer unit without any interference with local restrictions about administrator rights or complex procedures of firewall, proxies and others… By the way, we strongly recommend the use as Internet browser of Mozilla Firefox or Google Chrome, rather than Internet Explorer, which is significantly less performing and reliable than its competitors.

Please notice that the off line Java version will be maintained solely as a free “viewer” in order to allow Users for working off line after previous transfer of their data, wholly or in part, from their related web database. Former off line Java databases will be converted to on line databases upon request, in order to take benefit of technical improvements of OrthoWave.

2-THE VERY NEW ORTHOWAVE WEB SITE

The second major advance refers to our web site www.orthowave.net : thanks to our talented developers and graphic designers from Adspring Company, the OW web site has been fully re-designed, enhanced, completed, offering now a truly professional “look & feel”. This site goes on with the four classic themes (1) firstly of presentation and guided tour of the software suite, (2) then allowing for free trials and on line purchase of licenses. (3) A very efficient section of support features FAQs, tutorials, public and private forums and on-line help. Finally (4) the Community section gives access to the existing blog, through personal accounts and profiles. The “look & feel” looks great and appealing. Hopefully each of the present and future OrthoWave Users will be enthusiastic to join our “OrthoWave Community”!…

With respect to the free trials and purchase of licenses, please notice that from now on, all is done via the web-platform. There is no longer any need for downloading the program, simply get connected with either the trial “Demo” database or purchasing licenses to settle and use one’s own database. By the way we would point an important modification while ordering OrthoWave: to date, the maximal number of licenses addressed the maximal number of registered Users of the given data base, with no limitation about the number of surgeons. However, in some cases, numerous different persons got connected to their database by using the same login/password, which can cause a major problem with respect to the traceability of data inputs and global audit trail. It seemed logical in such a way to respect regulations and prevent from any legal issue, and thus from now on, the number of licenses will refer to a maximal number of surgeons, with an unlimited number of Users. Pricing procedures remain identical, and can be addressed on the Web Site, the difference solely refers to the mode of allowed licenses, based upon the Surgeons belonging to the database, be it a RDB or a SDB.

3-THE NEW MONITORED “MDB” DATA BASES

A third change appeared to be critical, while bearing in mind the new regulations about Clinical Studies carried out by Orthopaedic Devices Manufacturers, which are no longer under the realm of marketing departments, but nowadays depend on the Clinical Affairs Departments, upon an evolution which can be seen as similar to clinical studies about pharmaceutical drugs. As a matter of fact, Orthopaedic Surgeons have not been used dealing with so strict rigour while collecting and analyzing data and clinical results. A necessary adaptation to new policy and behavior facing these clinical studies will have to be settled among the Orthopaedic Community, which would lead to much gnashing of teeth, for sure…

While considering these new facts, OrthoWave had to be adapted appropriately to the coming new procedures of carrying out studies, although retaining its very main aim, which consists in publishing clinical series and findings, be they related to “pre-marketing” or “post-marketing” studies in the very long run. We also wanted to preserve what constitutes the real novelty of OrthoWave, i.e. the permanent control by each surgeon of all data of his own via the “Regular” Data Bases RDB and the ability to get dynamically linked (under a de-identified mode) to the selected “Scientific” Data Bases SDBs. We have thus got the project started of creating a third type of databases, i.e. the “monitored databases” MDB, devoted to these very regulated clinical studies, which must be very strict in terms at any step of the given study. We have taken advantage in that matter of numerous meetings and advices from Clinical Study coordinators and managers from Pharmaceutical Companies, to whom we would like to express our warmest thanks. Details about this MDB project can be found in a recent article of this blog…

More than ever, thanks to this third type of databases, OrthoWave will thus merit more again the label of “integrated data processing software”, embracing all matters related to clinical outcomes studies in Arthroplasty, for Surgeons facing the patients of his own, for specific studies in the view of regulations matters about brands and devices systems, as well as for multicenter studies and participating in global Joint Registries.

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.

Study Flow Chart

o A graph, displaying the total number of completed forms vs. outstanding ones at each period, as in the example below:

Global Follow-Up Graph

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

The Annual Congress of the Orthopaedic French Society (SoFCOT) in Paris from 16th to 19th November is an absolute must within the French Orthopaedic Community to get opportunities to meet, exchange, share ideas and skills, as well as establishing new contacts.

We will thus be pleased to present the numerous additional developments to the OrthoWave software suite, on which we have be working hard during the past months, in order to make OrthoWave more friendly-user and efficient while following up patients and analyzing results…

The very new “Web-based” interface is right now on use… It naturally participates in the same OrthoWave software, which can be now reachable by using the same credentials either through the “java-Based” or “Web-based” platforms. Both of them point on the same Data base, of course. This rewriting of a new platform in order to make OrthoWave reachable directly on the Web, as announced by the beginning of this year, represents an outstanding improvement as follows:

- This platform is a highly secured web connection, under a valid https type certificate, as used here and there to get access to bank accounts, as an example…

- No longer problems while installing the program thanks to the very new “cloud computing” concept, or potential conflicts with IT departments upon firewalls and proxies, no longer the need for leaving the 8080 port open, which was systematically poorly accepted in Hospitals by security managers, and last but not least, faster display of windows and easier entry data and images, thanks to highly performing new servers…

- Almost all OrthoWave features have been yet carried out to the web platform… the remaining side features will be implemented witin the coming weeks (automatic recall for patients’ visits, editing documents and letters, video uploads…). However the simultaneous use of both the Java and Web platforms is already possible, based upon the current tasks to accomplish.

All through the 9 past months, this rewriting of the web platform has called upon the full resources of the whole OW team… At present, it will be time to go forth on the other projects, nowadays faster to develop thanks to the web interface. We mean the Arthroplasty shoulder and the Knee ligaments modules. We do not forget the “OW Lite” version to be used on iPhones, Blackberry and Note-Books, this Lite version being to be previewed at the coming New Orleans AAOS meeting newt March 2010. On the other hand, with respect to connections to registries, the various issues related to the bulk upload procedures taken over by the NJR team while upgrading their National Joint Registry to the MDS version, are to be soon cracked, which will allow OrthoWave to get connected with this MDS3 NJR version. In addition, regarding the OW connection to the French Joint register (FJR), mamaged by IEFO, we are still in touch with their developers to finalize the direct input of the FJR feeds through OrthoWave, while avoiding any double entry, which would be beneficial in terms of better compliance of this registry.

It is also our pleasure to announce the coming release of the new “official” OrthoWave web site, which has been fully redesigned by our graphic designers and friends from the Adspring Company. This new site will group all features which are linked to the OrthoWave software suite, i.e. information, on line help, tech support, the “orthoWave Community”, as well as private and public forums… We are dying to let you discover this new site, within from now a few weeks !…

The OrthoWave Software calls for the “SaaS” major principle, as “Software as a Service”… As a matter of fact, entry data is not simply for the sake of doing, the most important aim being to collect, treat and publish them. We can offer at OrthoWave Centre a broad fan of “scientific services”, which can allow everybody to keep unburdened of these tedious tasks of treatment, classifying, presentation of data, from the simple editing of analyses up to scientific articles in Journals on a “turnkey basis”. Do not refrain from asking us about any proposal or estimate.

We finally have not hire any OrthoWave booth this year, in order to be more mobile and available to meet you at any time in any location during the meeting in the Palais des Congrès. We will be reachable by phone at 0033(0)321531949, for any demo, information or proposal as well.

We look forward to meeting each of you through this congress in Paris. With the best regards of the entire OW team, and … Be OrthoWaved!

The OrthoWave Data transfer on our new Global Servers Wednesday, October 7 has been successfully done. Thanks to these new servers, OW connections and EDC procedures will be even faster and easier ! Some adjustements are simply due now regarding images storage on the two different Java and Web servers.

The final transfer of the Servers has been scheduled on October, Wednesday 21st early in the morning, which might lead to slower response to get access to images and data, due to this scheduled maintenance window.

On the other hand, the OW users who get access to the DataBase through the online Java interface through firewalls and proxies, et who need a manual setting in order to appropriately monitor the entry port, must right now modify the settings according to the following:

1 – Within the “config” file, the “java.orthowave.net” address must be used instead of the currently used IP address…

2 – regarding network connection, through the 8080 port the IP address 80.93.82.24 must remain unlocked, in addition to the existing 213.246.42.56, as follows:

<url_Servlet>http://java.orthowave.net:8080/ow6/servlet/dataServlet</url_Servlet>

<url_download_version>http://java.orthowave.net:8080/ow6/update_versions/</url_download_version>

Feel free to address us at any time at 0033(0)321531949, via mail or this message to get any additional comment or online help… Again thanks for your strong support and our apologies for any inconvenience caused by these major maintenance works.

The OrthoWave Computer System currently available can right now lead to development of other modules, and namely the Shoulder Arthroplasty (TSA) and Knee Ligaments Injuries (KLI), while waiting for Spine, Ankle Replacement, or any other type of Surgery within the realm of “Evidence-based Medicine”…

As a matter of fact, the recent release of the Hip and Knee modules upon the new Ajax Web-based interface allows us at present to envision these new branches of OrthoWave, being said that any new development implies a heavy burden in terms of time and human resources. In such a way, since these new modules are extremely time and money consuming, they must in principle be of interest for a significant number of surgeons and future users, as well as meeting at best the expectations of these future users.

Thus before envisioning such a development, several conditions are mandatory:

- Firstly a consistent outline plan summing up the various entry data forms, as well as a clear approach of the new subject (windows, scoring assessments, graphs and schematics) and their particular specifications as compared to the existing Hip and Knee modules. This project is then adapted to the OrthoWave graphic chart upon a power point presentation…

- Secondly this project must be presented to as many groups of future users as possible, and duly analyzed by scientific experts in the related domain, ideally within the realm of Scientific International Societies. This protocol would allow for providing the widest consensus with respect to the analyzed items, the clinical scores, and the drawing up of surgical details… While this testing period comes to its end, the leadership of the current project must be defined, shared between several surgeons or surgical teams, who will be in charge of final selection of the most appropriate items, scores, organization of windows to be displayed in the module. This final outline would be at best submitted to the related Scientific Societies as well.

- The last step logically consists in transcription in computer language and routines of the given finalized outline, and their connection to the other functionalities and features of OrthoWave, be they statistics, image catalogue, export facilities, text editing or any type of reports. At each step of the development, a formal validation by the “Chiefs of project” allows for going forward appropriately while ensuring the most efficient and fast release of the new OW module.

Click on the thumbnail pour launch the slide show

With respect to the “Shoulder” module, it became obvious that shoulder replacement would be separated from pure trauma lesions or isolated ligament injuries, which would later on lead to specific new developments. Similarly, a second “new module” is already on trails which will be devoted to Knee ligament injuries. By the way, we will have to be extremely cautious while defining a further Spine module, about potential selection according to pathology (degenerative vs. traumatic) or topography.
In such a way, it’s our pleasure to propose the here attached first outline of this Shoulder Arthroplasty module (TSA). Just click on the thumbnail to launch the slide show, while going forth and back by using the arrows of the navigation bar. It is absolutely critical that each surgeon or clinical research person, who could be potentially interested in that Shoulder module, addresses us as soon as possible to deliver his comments, modifications, suggestions, and to make short, any useful information enabling us to go forth at second step of the process. We also need to appoint a Chief of project for this module, as well as to settle a certain number of “Key Centers” in order to validate it, in several countries. So do not refrain from getting in touch with us about whether this project looks of interest for you, and thus becoming an (enthusiastic!) contributor to OrthoWave. Hence your name would forever belong to the “Hall of Fame” of OrthoWave Stars and Stripes!…
We thus are eager to receive back your comments and suggestions in order to really launch the project, being said that once having been finalized the outline will only need a few weeks of development to be released as well. Your posts can be directly sent as an answer to this message, or by getting in touch with the ARIA Centre by phone (0033321531949) or by mail (mailto: info@orthowave.net) .

See you soon to help providing OrthoWave new clothes in order for it to be more and more “the ultimate reference for outcomes studies in Orthopaedics”, and… Be OrthoWaved!

OrthoWave features a unique concept which allows exporting anonymously any Arthroplasty form from any “Regular DataBase” to linked “virtual Scientific DataBases” so as to analyze results of particular studies while preserving the privacy of both Patients and medical Staff…

Click on the thumbnail to launch the first Tutorial (Use arrows to go forth)

This procedure of dynamic linkage between these two varieties of Data Bases is quite difficult to explain, and we have tried to sum up the main principles of these Scientific Data Bases while coupled with regular DB, through a first tutorial entitled “Main specifications of Scientific Data Bases in OrthoWave”. This explanation of principles have been followed by a second tutorial devoted to a practical demonstration of the use of these Scientific Data Bases… i.e. how to settle them, how to make a User of any RDB get connected with one or several SDBs, how to send forms from any RDB, and get access to these forms via the SDB for scientific purposes…

Roughly speaking, one can define 7 steps to embrace this procedure, detailed in that second tutorial “OrthoWave,About RDBs and SDBs”, as follows:

1. Register the “Regular Data Base RDB” as being linked to the “Scientific DataBase” SDB to make it appear in the list of available SDBs for the given RDB.

2. Link any User of the given RDB with any SDB available upon the displayed list…

Click on the thumbnail to launch the 2nd Tutorial

3. So any “authorized” User of the given RDB, while recording any Patient’s surgery will be able to send this arthroplasty form to his referred SDB (or SDBs…). This procedure can be performed form after form or as a batch processing via the multicriteria selection…

4. After any form has been sent to the referred SDB by the RDB User, any “authorized SDB User” will be able to watch it … This User can be the same or can be another User.

5. In such a way, when the authorized SDB User logs in the SDB, he can view all the forms that have been sent to…

6. These de-identified forms that have been sent as well now belong to the initial SDB, and stay dynamically linked to the initial RDB (modification, deletion,…).

7. The de-identified forms of SDBs can be watched and analyzed, including images, statistics and multicriteria search…

Hope these pieces of information will be of help on this quite difficult-to-grasp matter at first glance… Do not hesitate to reach us at any time for additional information or explanation.