Transcript “Offline” mode in Africa and rural United States

OC Global Conference ’13
Boston, MA
21st June 2013
An Alternative Approach to using
OpenClinica in “Offline” mode: A case
of WHO Buruli Study.
Raymond Omollo
&
Michael Ochieng
Presentation Outline
•
•
•
•
•
About DNDi
Introduction
Methodology
Challenges
Conclusion
About DNDi
• A collaborative, patients’ needs-driven, not-for-profit
research and development (R&D) organization that
develops safe, effective & affordable treatments for
neglected diseases (www.dndi.org).
– Afflicting the worlds poorest people
– HAT (Sleeping sickness), Leishmaniasis, Chagas disease,
Paediatric HIV, Filaria & Malaria
• Headquartered in Geneva, Switzerland with 7 regional &
support offices in Kenya, New York, Brazil, India,
Malaysia, Japan and Democratic Republic of Congo
• Objectives:
– Develop 11 to 13 new treatments by 2018
– Use & strengthen capacities in disease endemic countries
– Raise awareness about the need to develop new drugs for
neglected diseases & advocate for increased public
responsibility
Introduction:
• The DNDi Data Centre (DC) located in Nairobi, Kenya
– Data Management
– Statistical Analysis
• The DNDi - DC supports the DM component of the Buruli
Ulcers (BU) trial in West Africa (Ghana & Benin)
• WHO BU Study
– Randomized controlled trial comparing efficacy of
8 weeks treatment with Clarithromycin and
Rifampicin versus streptomycin and Rifampicin
for buruli ulcer (m. Ulcerans infection)
– Sample Size (n=430)
– Ghana (4 Sites), Benin (1 Site)
Sites Geographical Distribution
Togo
Benin
Pobe
Tepa
NkawieToase
Dunkwa
Agogo
Other DNDi Sites
BU Site Assessment
• Site users had no prior experience with
OpenClinica before
– Previous usage of other web based systems
• php based database surveillance system
– Need for training & retraining including Data
Management principles
• All sites access internet through modems
– Cell phone service providers
• Internet Connectivity
– Limited or unstable in some instances (remote
sites)
Implementation Scenarios:
Case 1: OpenClinica Installed in a Server at the
DC and access provided to Data Managers/Data
Entry Personnel at the sites.
•Pros
•Cons
• Data is available in real • Reliable internet
time
connectivity needed at
– Cleaning and extraction done
the sites.
as soon as entry at site is
• Understanding of the
done.
database by site users is
• More efficient
a must.
– movement of paper CRF’s
from sites eliminated.
• Data entry may slow
• Data management
down with time
capacity at the site.
– Database size as it grows
Implementation Scenarios:
Case 2: Local installations at each study site
followed by synchronization with the central
database in Nairobi.
•Cons
•Pros
• No need for Internet at • Complex
data entry.
synchronization done
– Only periodically for
periodically
synchronization.
• Faster data entry
– No internet bandwidth related
issues.
• Helps develop data
management capacity
at the sites.
– Program scripts
• Remote data support
needed
– Troubleshoot the database
– Technical person may be
needed to help with this.
Implementation Scenarios:
Case 3: OpenClinica installed in Nairobi with data
entry done in Nairobi.
•Pros
•Cons
• No need to have data • Movement of Paper
CRF’s between the sites
entry personnel at the
and DC cumbersome
sites.
– May lead to other risks such as
• No internet and
loss and increase in expenses.
computers needed at • Missed opportunity for
the sites.
the Development of Data
management capacity at
the sites.
Methodology:
• Issues:
– OC does not support offline use as currently
developed
– Need for timely data entry and availability
(EDC)
– Work in areas with limited or unreliable internet
connection
• Developed an alternative approach to benefit from
OC in our setup
– Database set-up and deployment
– Data collection at site
– Synchronization with central database
Methodology: User Training
Methodology: Site Activities
• At the sites
– OC installation on the study laptops.
• Central DB is replicated on all site
computers.
– Data Entry and Reconciliation
• Fast since no internet is needed during
data entry.
• More users can do entry on the study
computer through LAN.
Methodology: Data Sharing
– Study data back up
• Daily data backups on the study laptops.
• Automated Weekly backups saves in the
Dropbox.
–Postgre database
–.data folder;Attached Files
–dataInfo.PROPERTIES file
Methodology: DC Activities
• At the DC
– Retrieval of backup data from the Dropbox for
synchronization with the central database.
• Site Database dump is restored on the
Server.
– OpenClinica Event Scheduler script is run
• Automatically creates and schedules new
subjects in OC by Comparing Site DB with
Central DB.
– http://en.wikibooks.org/wiki/OpenClinica_User_Manual/O
fflineDistributions
Methodology: DC Activities
– Data Import through OC Web services
• Python Data Import Script imports data into
OC through Web Services interface.
– Sample script to be circulated to OC Community
• Log file automatically generated
showing import status.
Implementation in offline mode
Site Activities
Entry into source
documents and patient
files
Data Entry into
OpenClinica
Discrepancy Notes in
OpenClinica for Query
Management
Source Data Verification
(SDV)
Data Centre Activities
Synchronization into Central
Database
Restore Site DB on the
server
Data Extraction into STATA
for further Query
Management
Run OC Event Scheduler
Script
Query Processing in Query
Management System
(QMSPlus)
Run OC Data import
Script;
Imports data through WS.
Run site Data Backup &
Save in Dropbox
10% Verification of Central
Database data against the
Site Database
Clean Dataset for Analysis
OC Event Scheduler
OC scheduler pseudo-code
• Plug in the site database dump on the same server as
the central database.
• Fetch all the subject from the subject table in site
database.
– For each subject record in the site DB, check if it
exists in the Central DB and if not add the subject.
• Fetch all subject’s Study Events from the Study_event
table.
– For each subject’s study_event fetched, check if
exists in the Central DB and if not add the study
event.
Subject Data Import
• Site DB is plugged on the same server as Central DB.
• Executed after scheduling has been done.
• Uses OC Web Services interface:
– The SOAP Messages are dynamically enveloped
from subjects site data.
– Each SOAP Envelop request is sent for each CRF
assigned to an event.
• Data Import overwrites previously imported data.
• Data import is done on weekly basis.
Data Import Log
Challenges:
• Site user training and assessment
– Initially done at Agogo (Ghana) and Pobe (Benin) for all
site users
– Understanding of how OC works to reduce user support
workload
• Implementation of CRF changes
– Possible during study lifetime (protocol amendments)
– Maintain same database structure at the DC as well as
sites
• Data transfer and synchronization
– Internet still necessary at some point to effect transfer of
data
– Data is encrypted and password protected during
transfer; does this affirm security?
Challenges:
• Large Data imports
– Takes much time; scheduled to run over the weekend
• Standardize OC installation between sites and DC
– Any change on the central DB is replicated across all
site DBs.
• OC is designed to work in online mode
– One of the world’s preferred software of choice for
clinical trials
– Limited use and acceptance in the presence of poor
and unreliable internet infrastructure
• A number of processes are involved
– Most of them automated making the whole process
feasible
Conclusion
• Automated most processes involved
• Promotes EDC capabilities of OC in areas with
limited or unreliable internet infrastructure
• The Data Center has developed an interface to
have OC working in offline mode;
– The process is automated through python
scripts.
– Use of Dropbox makes site data sharing
faster and safer.
• This is unique addition by the Data Center
Asante Sana