COCHRANE CENTRAL ADVISORY GROUP (CCAG) REPORT

 

 

1.  How many meetings, and of what type (e.g. face-to-face, by teleconference), has your Advisory Group had since October 2004?  Is this what you expected in your previous report?

 

•           The last face-to-face meeting of the full CCAG was 3 October 2004 at the 12th Cochrane Colloquium (Ottawa, ON, Canada). The final version of the minutes to the Ottawa meeting have been circulated and approved. All CCAG minutes will be available at www.cochrane.us shortly.

 

•           A teleconference took place on 9 December 2004 with CCAG. Topics discussed included: maintenance of CENTRAL and supporting documentation; Chapter 5 of the Cochrane Reviewers’ Handbook; and Master List update mailing process. Throughout the past six months, the CCAG E-mail Discussion List has been used extensively for discussion about, and development of a consensus on, the final contents of the CENTRAL Management Plan, and the nomination of 2 more new CRG TSC representatives to serve on CCAG.

 

•           The CCAG’s next face-to-face meetings are scheduled to take place at the 13th Cochrane Colloquium in Melbourne, Australia in October 2005.

 

2.  Supply an up-to-date list of the members of your Advisory Group (as of January 14, 2005).

 

Kay Dickersin (CCAG Convenor, USCC)

Davina Ghersi (CCSG Representative, Breast Cancer Group)

William Gillespie (Coordinating Editor Representative, Musculoskeletal Injuries Group)

Elena Glatman (CENTRAL Activities Coordinator, USCC)

Diane Haughton (RGC Representative, Neonatal Group)

Carol Lefebvre (Information Specialist, UKCC)

Steff Lewis (CCSG Representative, Stroke Group)

Eric Manheimer (Field/Network Representative, Complementary Medicine Field)

Hugh McGuire (TSC Representative, Depression, Anxiety and Neurosis Group)

Marijke Moll (Field/Network Representative, Rehabilitation and Related Therapies Field)

Indy Rutks (TSC Representative, Prostate Group)

 

Andrew Cullis, Pauline Howarth, Deborah Pentesco-Gilbert, Karen Robinson, Hazim Timimi, and Susan Wieland, are ex officio members of the CCAG.


3.  Summarize any significant actions taken by your Advisory Group since your last report (for the CCSG meeting in Ottawa in October 2004), and significant actions planned for the next six months until the next meeting of the CCSG in Providence in April 2005.

 

Previous six months:

•                      Submissions for Issues 1 and 2, 2005 of CENTRAL have been processed at the USCC, and the logs on the handsearch and specialized register submissions have been sent to TSCs and CCAG. This task continues to involve extensive quality control undertaken at the USCC, though individual feedback and instructions are sent to TSCs during and after processing. One of the underlying problems resulting in errors in CENTRAL submissions each quarter is lack of training among TSCs, for example, in using a ProCite database to maintain a specialized register. Errors also result from understaffed entities (no appointed TSC), or a large TSC workload where fixing a register for CENTRAL submission is not a top priority. More detailed information on problems encountered during processing of submissions can be found on the USCC website at http://www.cochrane.us/logs.htm.

 

•                      Updating of the CENTRAL Management Plan (CMP) has been initiated.

 

•                      The Master List update mailing process was modified to meet TSCs needs.

 

Next six months:

 

•           Updated version of the CMP will be available at http://www.cochrane.us/central.htm.

 

•           Work with the Cochrane Collaboration Steering Group, the Information Management Systems Group, Wiley Interscience, the Cochrane Publishing Policy Group, and TSCs to further develop and refine CENTRAL.

 

•           Decide upon a final set of fields to include in CENTRAL for publication in The Cochrane Library; begin to standardize journal titles in CENTRAL; develop systems and rules for publishing references to ongoing and unpublished studies. Continue work on improving CENTRAL that had begun in the previous six months.

 

4.  Does your Advisory Group have any questions that you would like the Steering Group to answer?  If so, please list them.

 

Does the CCSG have any suggestions for improving the situation with understaffed entities (due to funding issues as reported by the MRG), or where TSCs work only part-time and do not have enough resources to fix specialized registers, since this problem effects the integrity of CENTRAL?

 

5.  Does your Advisory Group wish to raise any problems, and recommended solutions, which you would like the Steering Group to discuss?  If so, please list them.

 

Would there be any funding available to assist with new CENTRAL development and refinement in the future? (See pages 3-8).

 

6.  Do you foresee any problems in keeping within the budget you submitted for the current financial year (April 2004 to March 2005)?

                       

No. The CCAG budget for conference calls is adequate; however, our concerns lay with the CENTRAL budget.

 

7. What are your budgetary requirements for the period April 2005 to March 2006?  Please provide a breakdown if appropriate.  (As a reminder, the Steering Group sets the budget for each Group at its non-Colloquium meeting.)

 

A budget of £2,000 (approximately $3,000 US) requested for teleconference calls only, submitted for the financial year April 2005 to March 2006 is sufficient.

 

On January 4, 2005 the USCC submitted a request for funding to the CCSG specifically for MEDLINE retagging activities that are not covered by other sources.

 

 

Kay Dickersin, Convenor, CCAG

22 February 2005

Development of a New and Improved CENTRAL

 

A.  Introduction

 

In February, 2004 the Cochrane Collaboration Steering Group (CCSG) approved development of a new study-based Cochrane Central Register of Controlled Trials (CENTRAL) and its integration into the new Information Management System.  Review groups and others would enter their trial report records online directly into a database, which in turn would be submitted to the CENTRAL publisher.

 

The aim of rebuilding CENTRAL would be to develop a regularly updated, clean, non-redundant study-based database of controlled trials, containing all relevant records from the 50+ Cochrane specialized registers, as well as records indexed as CONTROLLED CLINICAL TRIAL [PT] and RANDOMIZED CLINICAL TRIAL [PT] in MEDLINE.  (Note MEDLINE is the subset of PubMed in which records are indexed using Medical Subject Headings [MeSH]).

 

In March-April, 2004 the US Cochrane Center performed a series of pilot investigations of methods proposed for rebuilding CENTRAL.

 

B.  Methods

 

            B.1  Database

 

            The proposed database would be relational and study-based.  We propose using Oracle

            (9.2 or 10g) for the new CENTRAL repository due to the anticipated size and projected

            rate of growth.  Compared to other options (e.g., Access, FoxPro), Oracle offers the best

            flexibility, speed, and built in data integrity mechanisms to ensure current and accurate

            data.  For testing purposes Oracle 9.2 was used.  The server is a Dell PowerEdge 2600

            with 136 Gigs disk space, 1 gig of RAM, and a single Xeon processor running at 3.06

            GHz.

 

            B.2  Populating Database

 

            We anticipate rebuilding and updating CENTRAL by downloading MEDLINE records

indexed as RCT (PT) or CCT (PT), tagged as human, and importing them.  PubMed provides scripts (e-utilities) for this purpose.  There are advantages to rebuilding CENTRAL via the PubMed utilities.  For one thing, all 62 fields are able to be downloaded from PubMed’s website.  This will eliminate all duplicates from PubMed (based on importing into a preliminary table with PMID as the primary key) and any other typographical errors will also be eliminated.

 

            For the records that are either not part of PubMed (Embase, etc.) or do not have any ID,

            we will do an import of those records directly into Oracle.  To eliminate duplicates,

            queries against the PubMed data will be based on the author and title fields.

 

B.3  Process

 

The process comprises two major functions, non PubMed data and PubMed data1.  The non-PubMed data process begins with the extraction of all data from the specialized registers.

 

Importation of the specialized registers is done in multiple phases to ensure no data loss and to try to eliminate duplicates during the import phase, as opposed to trying to remove duplicates after an import is complete.

 

                        B.3.1  Extraction of registers from existing registers

 

                    The Cochrane Eyes and Vision Group (CEVG) was used as a specialized register for a

                    pilot project.  The CEVG sent two different versions of their specialized registers, and

                    both were used for the pilot.  One is the complete register and the other is the subset of

                    information sent to the US Cochrane Center for CENTRAL.  We analyzed data

                    extraction from both files.

 

A.  The initial extract was based on the most current Procite file (subset of fields in complete register) sent to the US Cochrane Center for Issue 2, 2004 The Cochrane Library. 

             a.            Step 1: All fields were extracted (13) based on the mapping file modified for the CEVG database to place fields in a comma delimitated file with quotation marks indicating text.  Further modification of the extract was completed via a text editor for a global search and replace to input “\n” in the appropriate location.           

B.  The second extraction was based on the Procite database and the complete register, sent to the US Cochrane Center by the CEVG for the pilot.  This database included all fields in the CEVG specialized registers.

                             a.     Step 1: Determine extract configuration.

                             b.     Step 2: Select all records, extract, into a text delimitated file.

                             c.     Step 3: Modify the extracted text in generic text editor to allow correct

                                                importing processing.

________________________

1 Please refer to process flow diagram

 

 

            B.3.1.2  Import of records into MS Access

 

            After extraction from the Procite files, all records were imported into MS Access for

            preliminary processing.

 

            A.            Each table column was converted to the correct size (i.e., data type) to ensure no data were truncated.

 

            B.            After import, the maximum length of each column was found and compared to the Procite file.  This provided further assurance that no data were lost during the import phase.

 

            C.            Determine CEVG register-specific issues. We determined that ̃ 70% of the MEDLINE records had a “19" appended to the beginning of the PubMed ID1.

 

            D.            Export all data to a new table within MS Access.

           

            B.3.1.3  Export of records from MS Access

 

            Copy newly created table to a new MS Access database.  This step is completed due to a

            limitation in the Access Oracle migration utility.  For each converted database, all tables

            are imported directly into Oracle onto their own tablespace.  To ensure consistency we

            wanted to limit the import to only the single table.  The ID field of the table was cleaned

after import.  Many ID fields contained text as well as numeric values.  A new column (dbtype) was created, and any text was imported into the new column and removed from the ID field.

 

            B.3.1.4  Import of MS Access records into Oracle

 

            Several different alternatives were tested, and we looked at a variety of factors including

            speed of import, compatibility of software, and the amount of time needed to integrate

            the process.  The alternatives included:

 

                 1.     Linking tables directly from Oracle to MS Access

                 2.     Creation of SQL Loader scripts