Cochrane Collaboration - Register of Studies Consultation

Cochrane Collaboration Register of Studies Consultation Steve Greenaway & Myles Gorton

Register of Studies Consultation • Objectives of the consultation – Clarify & prioritise the business & technical requirements for a new Cochrane Register of Studies Database System – Produce a Request for Proposal Document – Produce a Scoring Guide for responses to the RFP from potential solution providers

Register of Studies Consultation • Our approach – Document review of existing requirements (and RFP) in order to categorise into functional & non-functional – Production of the Requirements Catalogue – Production of High Level Architecture Diagrams – Prioritisation of all requirements via selected interview process using MoSCoW rules – Requirements priorities collated & aggregated • Here today to present the findings

High Level Architecture Diagrams

As-Is High Level Architecture Users (WORLDWIDE) Wiley-Blackwell (UK / USA) Network The Cochrane Library Users Cochrane Users Reviews CENTRAL CDSR Internet Users File Transfer Server Database Server Other Specialised Medline Resources Register Records Handsearch Embase Files Records Users Users Client Software IMS (DENMARK) Reference ProCite EndNote Network Manager Transfer of Files MeerKat RefTrak Other Contacts Archie Specialised EMBASE Documents RevMan Register Database Server MEDLINE Handsearch Files The Cochrane Collaboration As -Is High-Level Architecture

To-Be High Level Architecture Cochrane Collaboration Wiley-Blackwell (UK / USA) Users (WORLDWIDE) Records Marked for Network The Cochrane Library Publication Users Cochrane Users Reviews Register of CENTRAL CDSR Studies Internet Users Web Server Database Server Other Resources Specialised Embase & Registers Medline Potential Users Handsearch Records Link Files Users Client Software IMS (DENMARK) RevMan Network Contacts Archie Documents Database Server The Cochrane Collaboration To -Be High-Level Architecture

Conceptual Solution for Register of Studies Reports Entities Governance Standard Regular Exception Reports Reports CRGs TSCs Cochrane Register of Studies Front End(Web Form Input) Publication Reports Graphical Reports Reviewers Authors Cochrane Register of Studies Centres Report Wizard TSC Generated Specialised Hand-search Other Other Trials EMBASE MEDLINE TSCs Registers files Records Registers Records Records Reviewers Authors Report Wizard Export Reports Study-based Reference-based records records Fields Cochrane Register of Studies Database TSCs Publishing Reviewers Integration Authors Records to be Published CENTRAL IMS WILEY EMBASE / Cochrane Future RevMan Archie CENTRAL MEDLINE Library Projects External Systems Conceptual Solution for Cochrane Register of Studies

Example Technology for Register of Studies Web browser – IE, Firefox etc Web Forms – ASP, JSP etc Windows Workflow Infopath Database driven Channel Directory Integration Web Services Services Integration Product Active Directory Orchestration Hyperlink LDAP etc. Data level Workflow Rules Services Services Security Integration Data Reference Study Data Report Data Data Services Services Infrastructure Directory Web Database Application Server Server Server Server Database – SQL Server etc Hardware to host & run solution Example Technology for Cochrane Register of Studies

Example Architecture for Register of Studies Hosting Environment Load Balanced Servers Primary/Standby Database Servers Users Application Database Database Web Server Web Server Internet Server Server Server Users Network Cochrane Register of Studies Users Users Clustered Web Client Application Server Database Server Servers Web Browser IE, Firefox Etc. Directory Services, IIS, .Net Framework, Integration etc. SQL Server etc. ASP, HTML, XML etc. Example Architecture for Cochrane Register of Studies

Requirements Prioritisation Results

Overall Prioritisation Overall Prioritisation • Using the MoSCoW rules 0% 6% – Must Have – the requirement is essential for the solution to work 11% – Should Have – the requirement is very important for the delivery of an efficient or cost effective solution – Could Have – the requirement is a “nice to have” and may enhance the solution, Must Have but it is not essential for functionality or Should Have efficiency. The requirement could be Could Have delivered later as an enhancement of Will Not Have the solution – Will Not Have – the requirement is of little or no benefit to the solution 83%

Web Application & Search Functionality Web Application & Search Functionality 2% • Requirements related to 9% the web application for the Cochrane Register of Studies, its functionality, 18% Must Have look and feel, accessibility Should Have Could Have and search functionality W ill Not Have 71%

Data Migration & Import Validation Data M igration & Import Validation 3% • Requirements related to 4% the importing of data from the Specialised Registers, 20% in particular relating to data migration and data Must Have validation processes Should Have Could Have Will Not Have 73%

Database Design & Reports Database Design & Repo rts 2% • Requirements related to the structure of database 20% tables, data types and data entity relationships. • Also requirements related Must Have to database reporting Should Have Could Have W ill Not Have 52% 26%

Interfaces & Integration Interfaces & Integration • Requirements related to 0% interoperability with existing 17% systems within and external to the Cochrane Collaboration 8% Must Have Should Have Could Have Will Not Have 75%

Workflow & Process Automation Workflow & Process Automation • Requirements related to 9% human-to-system workflow and system-to-system process automation. 16% • This area is related to Must Have Should Have interfaces and integration 46% Could Have Will Not Have 29%

Non-Functional Non-Functional • Non-business function 3% 1% requirements such as: – Accessibility 28% – Availability Must Have – Scalability Should Have Could Have – Performance Will Not Have – Resilience – Security 68%

Next Steps

Request for Proposal • Finalise Requirements Catalogue and High-Level Architecture diagrams for inclusion as Appendices in Request for Proposal – Produce the RFP – Produce the Scoring Guide – Publish the RFP • Obtain responses, score & rank suppliers • However…

Are There Other Options? • Based upon our understanding of the requirements, our findings so far and our experience – Many requirements = complex RFP = complex system – The solution has the feel of a “Rolls Royce” – Would a “Ford” or “Mini” suffice? – Is this the best use of the funding available? • Back to basics – what is the problem that we are trying to fix?

What are the problems? • Look of the data • Data duplication • Reference vs. Study based • Complete rebuild of CENTRAL with each publication • Searching • Workflow • Benefits of a centralised solution

Our Thoughts Users Cochrane Wiley/Blackwell SR’s CENTRAL Register of Hand-search Studies DB Etc. Publication ProCite Cochrane EndNote Library Etc.

Our Thoughts Users Cochrane Wiley/Blackwell SR’s CENTRAL Register of Hand-search Studies DB Etc. Publication Cochrane Library ProCite EndNote Etc.

Our Thoughts Users Cochrane Wiley/Blackwell SR ProCite CENTRAL Register of EndNote Studies DB Etc. Publication Cochrane Library

Our Thoughts Users Cochrane Wiley/Blackwell SR Web Front CENTRAL Register of End Studies DB COTS Publication Commercial Off The Cochrane Shelf Package Library

Any Questions?

http://www.cochrane.org	60
http://www2.cochrane.org	14

Cochrane Collaboration - Register of Studies Consultation

by Cochrane.Collaboration on Apr 06, 2009

Accessibility

Categories

Upload Details

Usage Rights

2 Embeds 74

Statistics

Cochrane Collaboration - Register of Studies Consultation — Webinar Transcript