UK Contributors Meeting, Edinburgh - March 2009

1. Cochrane Collaboration
Register of Studies Consultation
Steve Greenaway & Myles Gorton

2. 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

3. 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

4. High Level Architecture Diagrams

5. 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

6. 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

7. 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

8. 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

9. 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

10. Requirements Prioritisation Results

11. 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%

12. 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%

13. 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%

14. 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%

15. 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%

16. 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%

17. 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%

18. Next Steps

19. 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…

20. 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?

21. 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

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

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

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

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

26. Any Questions?