dataesr/scientific-paragraphs-categorization huggingface dataset:
More patients are being enrolled entailing greater use of multisite trials, case report forms (CRFs) are more complicated, and larger budgets are necessary to accommodate for the greater volume of participants and sites involved in a RCT. Centralized statistical monitoring (CSM) is commonly used for guaranteeing data quality by detecting data issues early, such as errors, sloppiness, tampering, and fraud, before significant problems occur. Through off-site central monitoring, onsite monitoring can be more efficiently targeted. Equally important to ensuring data quality is assessing the adequacy of the trial design and performance. Design errors, if not discovered and addressed early, can largely bias study findings and make a trial difficult or impossible to interpret. Poor adherence to design and a lack of oversight can result in an unsuccessful trial with drastic ramifications, including revoking one's clinical and research privileges, funding, and leaving a tarnished reputation.
Consequently, the purpose of this research was to apply CSM to the monitoring of various aspects related to the design and performance of a clinical trial. Study design quality metrics assessed for anomalies included adherence to inclusion and exclusion criteria, recruitment, administration of treatment, blinding, visit scheduling, patient follow-up, data submission, and the reporting of safety measures. Each metric can be evaluated across sites as in a multisite RCT, or across clinicians to assist in identifying potential threats to a trial's performance. A program was developed to apply CSM for monitoring the performance of a clinical trial. CSM was applied monthly, in conjunction with regularly scheduled risk-based monitoring. For continuous measures of trial performance, modified boxplots described distributions, differences in the proportion of outliers were assessed using chi-square analyses, differences by site were examined with analysis of variance (or the nonparametric equivalent) and further assessed using pairwise tests, and homogeneity of variance and sites with outlying or inlying variance were also determined.
Confidence bands were used to provide additional monitoring of trial performance. For categorical measures, chisquare analyses and logistic regression were employed. CSM applied to study design elements can be used to assess trial performance over time throughout the duration of a study. Monitoring trial performance helps to ensure the validity of a study and its design, consistency in reporting across sites and clinicians, and that a study's hypotheses are not being compromised. Continual monitoring of study design quality metrics through CSM enables corrective action to be taken early enough to address any potential threats to the design of a RCT, while also simultaneously improving data quality and the credibility of a study and its findings.
Methods The Collaborative Studies Coordinating Center (CSCC) in the Department of Biostatistics at the University of North Carolina serves as the coordinating center for ARIC and provides the infrastructure for the data collection using the CSCC-developed, web-based data management system, Carolina Data Acquisition and Reporting Tool (CDART). Neurocognitive test data collection in ARIC began at  Visit 2 (1990-92)  and was repeated in Visits 3 (1993-95) and 4 (1996-98) using 3 neurocognitive tests. An ancillary study was conducted in 2004-06 on a subset of the ARIC cohort where the test battery was expanded. At Visit 5 (2011-13), the expanded neurocognitive test battery was collected on 6538 participants, enabling the investigators to examine cognitive function changes over 24 years, particularly in the areas of memory, language and executive function.
The behind the scenes programming calculates the Visit 6 factor scores for the cognitive areas of interest allowing for immediate determination of cognitive domain failure and generalized cognitive decline compared to Visit 5 performance, despite the fact that not all participants completed the exact same battery at each visit. The participants who show failure in at least 1 cognitive domain and significant global cognitive decline from Visit 5 will have additional data collected from a proxy or informant and will undergo a complete data review by members of the classification committee in order to determine neurocognitive status as dementia, MCI, normal, or unclassifiable.
P12 An online tool for exploring recruitment achievability for a feasibility and pilot studies in the UK Andrew Brand, Nicola Totton, Paul Brocklehurst Bangor University Correspondence: Andrew Brand Trials 2017, 18(Suppl 1):P12 The aim of our online tool, is to use openly available data to help inform researchers, in the UK, whether a given target size, is broadly achievable for a feasibility or pilot study investigating a specific health condition. Information obtained from the online tool may also further help determine a suitable recruitment period for a feasibility or pilot study investigating a given health condition. Ideally, data on the actual sample sizes obtain in the feasibility and pilot studies would have been more informative than the target size data. Unfortunately, we were unable to find an openly available source for this data.
However we feel that the target sample size data, along with the recruitment period can provide a rough guide to the achievability of recruitment targets for feasibility and pilot studies. For instance, if a pilot study had a target sample size of 60 and a recruitment period of 18 months for a study investigating a health condition you are interested in, you might want to reconsider running a similar pilot study with a target size of 100 for 6 months. We therefore believe that this data has value in making informed decisions with regard to recruitment for a feasibility and pilot studies. We identified UK Clinical Trial Gateway (UKCTG) as providing the best source of UK based data to harvest. The UKCTG was set up by the National Institute for Health Research (NIHR) to essentially help recruit people to clinical trials in the UK.
Because there were no facilities for downloading data from the UKCTG website, a web scraping methodological was adopted and implemented using R. Four searches were run on the entire trial record. The following search terms were used: "feasibility trial", "feasibility study", "pilot trial" and "pilot study" and 3039 unique trial records were identified. The unique trial records ids were extracted from the search results and then the trial records were downloaded. Data such as the trial title, target sample size, recruitment start date, recruitment end date, the longitude and latitude of the recruiting centre were then extracted from the records, using regular expressions, and collated into an Excel where openended text fields (e. g. , target sample size) were manually cleaned. Shiny, a web application framework for R, was then used to create an online tool to interrogate the data.
Aim To investigate the impact of the shared family environment on risk factors for T2D, and to determine the feasibility of conducting a fully powered study using this methodology. Design Cross-sectional feasibility study of index cases diagnosed with T2D and their first degree relatives (siblings and offspring). Index cases were recruited from the diabetes information database (DIAMOND) of a hospital in Northern Ireland. Method Sample: The DIAMOND database was screened to identify adults with T2D, aged 45-65 years, with at least two siblings and two offspring, willing to participate in the study. For this feasibility study 50 participants were sought (i. e. 10 index cases each with 4 first degree relatives, spanning two generations). Measures: A range of lifestyle factors, biochemical and clinical markers were collected for all participants.
Conclusion The feasibility study provided key insights, impacting on scaling up decisions. We now know that identifying index cases for this study through a hospital data base is ineffective and would be better suited to a primary care setting. The data gathering methods and instruments worked effectively. In light of the difficulties encountered in the feasibility study, it was agreed that a fully powered study would not be developed. Feasibility studies are routinely performed in a variety of clinical areas to help provide evidence prior to major monetary investment, human resource and patient recruitment to a large randomised controlled trial (RCT). They can assess a variety of aspects including recruitment potential, multi-centre operational coordination and logistical aspects of administering the intervention.
Methods The NIHR Health Technology Assessment (HTA) and Research for Patient Benefit (rfpb) programme databases (as available from the NIHR website) were screened for pilot/feasibility studies of surgical interventions funded between 2005 and 2015. Pilot/feasibility work was defined as: Any research undertaken before a main study intended to inform the design and/or conduct of a future main study. A surgical intervention was defined as: A diagnostic, therapeutic or adjunctive invasive intervention performed by a trained clinician, using hands, instruments and/or devices. Studies which were not pilot/feasibility work or where the surgical intervention was a co-intervention were excluded. It was rationalised that research funded by the NIHR programmes would embrace the higher quality methodological features necessary to identify the key design features of interest and will have been peer-reviewed as part of the funding process.
Protocols for all included studies and the associated data sources were collated, including, where available, published papers from the pilot/feasibility work and the consequent main trial. A data extraction form was developed and piloted a priori enabling elicitation of the pilot/feasibility work rationale, and exploration of the associations of key design features of pilot/feasibility work with the planning, conduct and outcome of any subsequent definitive main trial. Results 1341 studies funded by the HTA and rfpb NIHR programmes between 2005 and 2015 were identified and screened, with 73 (5. 4%) meeting the inclusion criteria. 30 (41%) were rcts with an internal pilot phase and 43 (59%) were other feasibility work. This included 28 (65%) randomised pilot studies, 3 (7%) non randomised pilot studies and 12 (28%) other types of feasibility study, of which 8 (66%) were systematic reviews.
Methods The COMET study sought to determine the feasibility of conducting a randomised controlled trial in young children with eczema. Children were recruited from primary care and randomised to one of four commonly used emollients. The study also explored the feasibility of both collecting and costing the data required to perform an economic evaluation in this setting. As part of this we explored whether published prescribed medication costs from the BNF and Prescription Cost Analysis (PCA) represented the true cost to the NHS. In order to estimate the cost to the NHS we identified the method by which community pharmacies are reimbursed for the medications they prescribe. Unit costs of the four intervention emollients were estimated using this method and compared to unit costs from the BNF and PCA.
Methods and interim results A pearl growing strategy was applied to identify manuscripts that contained novel extrapolation methods, with the emphasis on methods largely based on a single randomised clinical trial. Firstly, a scoping search of the PubMed database was performed to identify recent methodological papers. Subsequently, reference lists of included manuscripts were checked, and finally, a panel of experts was asked to suggest further potentially relevant published methods. Method description was extracted using a pre-defined template. Extracted information included the context that motivated method development (e. g. the need to incorporate cause-specific mortality); type of data used for the extrapolation (e. g. from an RCT, general population or a matched cohort); detailed statistical/modelling methodology; comments on generalisability and usability (e.
The system is flexible, scalable, and can be customized easily to meet the needs of individual studies. Modules included in the STS are: entry and editing via barcode scanner or keyboard, generation of shipping manifests, and receipt confirmation at the batch and sample level, with database audit trails for all modules. Automated email notifications alert laboratory/repository personnel of incoming shipments and clinical site personnel of shipments received. The STS can be implemented as a stand-alone system or integrated with a data management system. It is efficient in regard to database setup and implementation and is user-friendly and intuitive for site and laboratory/repository personnel, facilitating smooth study startup. It was designed to accommodate unlimited clinical sites, laboratory/repository destinations, sample types, and samples/aliquots with minimal setup time or expertise on the part of EDC data management personnel.
Data management personnel use administrative tools to define study name, site codes, sample types, sample names/ titles, sample states (e. g. Frozen, ambient), barcode formats, laboratory/repository names, and protocol timepoints, and to define the relationships among samples, studies, sites, and laboratories/ repositories. Optional settings are provided for default volume, volume/unit (ml, μg, slide, image), minimum and maximum volume/ unit, and earliest sample date. There are options to initialize barcodes in the database and then utilize initialized barcodes to provide validations (e. g. Site, participant ID, sample type, timepoint) at the time of sample entry. At the time of receipt of shipments, the system allows receiving personnel to resolve issues and input comments at the batch or sample level.
In addition, site pharmacies often have limited storage space and find it difficult to accommodate deliveries of large volumes of trial drugs. We propose that a more targeted approach to drug re-supply will address these issues by both reducing the volumes of drugs delivered to sites and at the same time reducing the amount of drug wastage. Utilising the central trial database allows us to identify exactly which postrandomisation visits are upcoming at each site and to assign deliveries to sites based upon this. So, if a site had a run of equal treatment allocations then our supply algorithm will dictate that drug supplies at this site six months later be weighted accordingly rather than issuing equal amounts of each drug to the site. Using this mechanism will help planners more easily determine how many drugs will be needed for a trial and allow them to reduce the amount of contingency required and hence reduce the costs of running a drug trial.
Background The Robertson Centre for Biostatistics conducts and supports collaborative research in clinical trials through the design, conduct, analysis and interpretation of clinical trials and other well conducted studies. The Centre's staff consists of biostatisticians, database managers, software developers, technicians, health informaticians, health economics, project managers and administrative staff contributing to some 120 clinical studies at present. Involvement in this volume of clinical studies has led the Centre to identify a software solution to more effectively project manage our involvement in these studies whilst supporting the requirements of the Centre's internal Standard Operating Procedures (sops) and Good Clinical Practice (GCP). Methods Over the past 6 years the Centre, in consultation with staff, has customised and developed an MS sharepoint site to manage key project information and activities relating to clinical studies including: Project planning and management; Change management; Document control; Study communication; Management reporting The MS sharepoint site has been further developed to support: Functional areas; Archival; Audit Management; Centre Communication; Risk Management Conclusion MS sharepoint has been a key tool in providing a consistent approach to managing projects however, it has been recognised that the system should continue to evolve in order to meet changing regulatory and Centre requirements.
Background The ICR-CTSU introduced electronic data capture (EDC) in 2012. This necessitated development of a solution to automatically monitor electronic case report form (ECRF) completion and track timely completion of ECRFs. Challenges Prior to the introduction of EDC, sites posted paper CRFs to the ICR-CTSU. Once received, CRFs were manually tracked onto an ICR-CTSU legacy system which also provided CRF compliance reports. With the introduction of EDC, a solution was required to record real-time completion of ECRFs within the EDC system and to calculate ECRF compliance data for review and reporting purposes. Solution A two part solution was developed: 1. Schedule forms were created within the EDC clinical database. These forms display details of ECRF expected and completed dates per trial participant for every visit and form (dependent on the participant's treatment allocation and pathway within the trial).
AKI was a major safety endpoint in the study. Different definitions of AKI based on ICD-9 codes and change of creatinine during hospitalization were applied in the CDW data searches. The search results varied significantly depending on the AKI definition applied. Likewise, hyperkalemia identified by the CDW laboratory datasets had some discrepancies from the active trial setting where diagnosis of hyperkalemia was a combination of potassium level and other clinical factors. Details of the comparisons for each safety endpoint will be presented.
Background The purpose of the data-related components of an FDA regulatory submission is to enable an FDA reviewer to understand the clinical trial data that was collected, check the consistency of the data, understand how analysis datasets were produced, and recreate selected analyses. Our experience is based on using the Clinical Data Interchange Standards Consortium (CDISC) standards (http://www. cdisc. org/) for preparing regulatory submissions for 3 trials totalling 65,000 randomized participants. Study Data Tabulation Model (SDTM) datasets represent trial data in a standardised form. Analysis Data Model (ADAM) datasets are derived from SDTM datasets, and represent data in a form that is easy to analyse and report on. 'define. xml' documents contain metadata for SDTM and ADAM datasets.
Steps The main tasks involved in producing these items are: -Assess how collected data maps to SDTM datasets and outline this in annotated case report forms (CRFs). -Decide which ADAM datasets are needed for analysis, based on the Protocol and Data Analysis Plan. -Transform SDTM data into relevant ADAM datasets. -Generate 'define. xml' metadata documents. -Validate all datasets and metadata, correcting or documenting errors. -Produce guidance notes for the SDTM and ADAM datasets. We use bespoke software tools for these steps (except validation, which is performed using industry standard software). Software SDTM and ADAM datasets are stored in a relational database. Datasets are defined and produced using a domain-specific language that permits XML elements to be associated with parameterized units of software which generally perform SQL code generation (which can be executed to perform a data transformation), but which may also do other things, such as the generation of documents.
An IDS is an important security tool however they are of limited use if a malicious party compromises a system account and performs similar actions e. g. Accessing the trial database. Worse still an IDS is entirely blind to application level activity as most web applications utilise a single system account to perform all actions. Method We propose integrating simple IDS methods into the application and database layers. By identifying simple activity rules to identify unusual usage the application and database can react in an appropriate manner based on the associated level of risk.
Problem Trialists often feel that the release of a validated database is a limiting factor in the timeline of opening a clinical trial. There is an inherent tension between (i) the desire to be able to change requirements (such as Case Report Forms, eligibility and validation checks) as late as possible and (ii) the need for those requirements to be finalised early on so that development and testing can take place. We will describe several approaches we have taken to address this dilemma. These focus initially on technical solutions, using our bespoke clinical data management system, developed using MS SQL Server and. NET. We will then expand to look at how these can be enhanced with process changes. This has led to a culture change resulting in much wider participation in the database development project, a livelier dance with more partners on the dancefloor.
Our approach The technical solution concentrates on auto-generation. In our model, Excel is used to document the user requirements as metadata. This allows users to engage with a familiar tool to specify conditions in a structured method. Once reviewed and finalised, the spreadsheet is uploaded into the database and the metadata is used to generate the database tables, triggers and procedures that provide the necessary functionality (such as audit trail, query generation, etc. ). The metadata also provides the input to a customised code generator which produces the front-end code for data entry screens and validations. Common code modules and standard field names produce a consistent interface, with core functionality and generic elements that can be easily reused across projects. The tempo of the dance for the database developers moves from a waltz to a quickstep.
Discussion Ultimately though, there is a limit to how fast you can dance. The culture change needed requires much earlier penetration into the trial project timeline, looking at team resourcing and key decision timepoints. Involving the database team at the earliest stages helps with understanding how the proposed trial flow can best be implemented, and with prioritisation of agreements needed for timely delivery of the validated database. The dance becomes a unit-wide quadrille, with multiple partners and movements. Or, maybe more appropriately for this conference, a ceilidh! P32 Presentation and publication system (PNP): a tool to facilitate efficient tracking and reporting of the presentation and publication process Tamara Haller, David E. Hallam, Sharon M. Lawlor, Ella Zadorozny University of Pittsburgh Correspondence: Tamara Haller Trials 2017, 18(Suppl 1):P32 Writing of a manuscript, abstract, or other document in a research environment is a collaborative effort which oftentimes involves individuals from academia, industry, and government agencies.
Proposal activities are grouped into pre-defined categories (e. g. Writing group, reviewers, scientific meetings, and journals); these categories are also available as individual tabs to allow reporting all manuscripts in a particular category. The PNP system was designed to allow the user to quickly configure the system based on the study's requirements through a set-up wizard. The wizard does not require that all elements be pre-defined, but allows the users to configure the system throughout the process. Reports created in Crystal Reports or SAS are supported by the PNP system and allow the users to create customized reports at the project and proposal level. Access to the PNP system is restricted according to a user's project role and permissions assigned. In summary, the PNP system is a tool that can help to organize the process of writing a manuscript, abstract, or research grant while reducing the personnel time and effort needed for communication and coordination among the collaborators.