Search

Study question Which follicle sizes on the day of trigger (DoT) are most likely to yield oocytes after different IVF treatment protocols and trigger types? Summary answer Follicles sized 11-19mm on DoT are most likely to yield oocytes in both 'long' and 'short' protocols after using either hCG or GnRH agonist triggers. What is known already On the DoT, both follicles that are too small, or too large, are less likely to yield oocytes, but the precise range of follicle sizes that are most contributory to oocyte yield remains uncertain. Knowledge of this optimal follicle size range can aid in selecting the DoT and in quantifying the efficacy of the trigger by benchmarking the expected number of oocytes to be retrieved. Machine learning can aid in the analysis of large complex datasets and thus could be used to determine the follicle sizes on the DoT that are most predictive of the number of oocytes retrieved. Study design, size, duration We applied machine learning techniques to data from 8030 patients aged under 35 years who underwent autologous fresh IVF and ICSI cycles between 2011-2021 in a single IVF clinic. The DoT was determined by 2-3 leading follicles reaching ≥ 18mm in size. Follicle sizes from ultrasound scans performed on the DoT (n = 3056), a day prior to DoT (n = 2839), or two days prior to DoT (n = 2135), were evaluated in relation to the number of oocytes retrieved. Participants/materials, setting, methods A two-stage random forest pipeline was developed, with the number of follicles of a certain size on DoT as input, and the number of oocytes retrieved as output. First, a variable preselection model to determine the most contributory follicle sizes. Second, a model to identify the optimal range of follicle sizes to yield oocytes. Both models were trained and cross-validated with fixed hyperparameters. The pipeline was run for each protocol and trigger type independently. Main results and the role of chance The machine learning pipeline identified follicles sized 11-19mm on the DoT as most contributory in IVF/ICSI cycles when using an hCG trigger. After a GnRH agonist trigger, follicles sized 10-19mm were most predictive of the number of oocytes retrieved. To mitigate the role of chance, the statistical methods were further validated by utilizing scans prior to the DoT to rerun the pipelines, as well as a comparison against the true number of retrieved oocytes with linear regression. In ‘short’ protocol cycles triggered with hCG (n = 1581), follicles sized 11-19mm on the DoT were more closely associated with the number of oocytes retrieved (r2=0.58) than either smaller (r2=0.031), or larger (r2=0.051), follicle size ranges (p

While we are witnessing rapid growth in data across the sciences and in many applications, this growth is particularly remarkable in the medical domain, be it because of higher resolution instruments and diagnostic tools (e.g. MRI), new sources of structured data like activity trackers, the wide-spread use of electronic health records and many others. The sheer volume of the data is not, however, the only challenge to be faced when using medical data for research. Other crucial challenges include data heterogeneity, data quality, data privacy and so on. In this article, we review solutions addressing these challenges by discussing the current state of the art in the areas of data integration, data cleaning, data privacy, scalable data access and processing in the context of medical data. The techniques and tools we present will give practitioners — computer scientists and medical researchers alike — a starting point to understand the challenges and solutions and ultimately to analyse medical data and gain better and quicker insights.

Key to DNA storage is encoding the information to a sequence of nucleotides before it can be synthesised for storage. Definition of such an encoding or mapping must adhere to multiple design restrictions. First, not all possible sequences of nucleotides can be synthesised. Homopolymers, e.g., sequences of the same nucleotide, of a length of more than two, for example, cannot be synthesised without potential errors. Similarly, the G-C content of the resulting sequences should be higher than 50\%. Second, given that synthesis is expensive, the encoding must map as many bits as possible to one nucleotide. Third, the synthesis (as well as the sequencing) is error prone, leading to substitutions, deletions and insertions. An encoding must therefore be designed to be resilient to errors through error correction codes or replication. Fourth, for the purpose of computation and selective retrieval, encodings should result in substantially different sequences across all data, even for very similar data. In the following we discuss the history and evolution of encodings.

Scientific WorkFlows (SWFs) need to utilize components and applications in order to satisfy the requirements of specific workflow tasks. Technology trends in software development signify a move from component-based to service-oriented approach, therefore SWF will inevitably need appropriate tools to discover and integrate heterogeneous services. In this paper we present the SODIUM platform consisting of a set of languages and tools as well as related middleware, for the development and execution of scientific workflows composed of heterogeneous services. © 2006, Authors. All rights reserved.

As the size of data and its heterogeneity increase, traditional database system architecture becomes an obstacle to data analysis. Integrating and ingesting (loading) data into databases is quickly becoming a bottleneck in face of massive data as well as increasingly heterogeneous data formats. Still, state-of-the-art approaches typically rely on copying and transforming data into one (or few) repositories. Queries, on the other hand, are often ad-hoc and supported by pre-cooked operators which are not adaptive enough to optimize access to data. As data formats and queries increasingly vary, there is a need to depart from the current status quo of static query processing primitives and build dynamic, fully adaptive architectures. We build ViDa, a system which reads data in its raw format and processes queries using adaptive, just-in-time operators. Our key insight is use of virtualization, i.e., abstracting data and manipulating it regardless of its original format, and dynamic generation of operators. ViDa's query engine is generated just-in-time; its caches and its query operators adapt to the current query and the workload, while also treating raw datasets as its native storage structures. Finally, ViDa features a language expressive enough to support heterogeneous data models, and to which existing languages can be translated. Users therefore have the power to choose the language best suited for an analysis.