dataesr/scientific-paragraphs-categorization huggingface dataset:
Twelve-Month Patient Support Program The aXess program is based on a 12-month phone follow-up of patients. The program is coordinated by three nurses specifically trained to care for XLH patients. These nurses oversee conducting phone calls, completing surveys, performing motivational interviews, and coordinating all health care providers (pharmacists, physicians, home care nurses, and medical analysis laboratories). Importantly, coordinating nurses oversee educating home care nurses about the disease and treatment of XLH patients. Outbound calls from a coordinating nurse were provided at enrollment and thereafter at regular intervals to evaluate patients' compliance, tolerance to the treatment and to collect their lifestyle habits through an interview. The call schedule and frequency were tailored to meet the patient's needs (patient initiating targeted therapy or already on targeted treatment).
Statistics The height and BMI z-scores (height-for-age Z and BMI for age Z) were calculated using a SAS macro and reference database (by age and gender) provided by the CDC (Centers for Disease Control and Prevention) on the CDC website (https://www. cdc. gov/nccdphp/dnpao/growthcharts/resources/sas. htm), including the most recent update on 15/12/2022. There were N=143 assessments (D0, M6, and M12) in all 59 patients for the calculation of the PedSQL score. Scores and sub-scores were described using frequency, mean and standard deviation (SD). The change from baseline scores (from D0 to M6; from D0 to M12) was tested using a paired t-test and presented using the mean of difference with a 95% confidence interval of the difference and p-value. The effect of treatment initiation timing (Yes vs No), XLH type (familial vs de novo) was tested using a linear mixed model with a period (as a continuous parameter), tested effect, and period x tested effect interaction as fixed effects; the patient ID was included as a random effect.
Participants' Characteristics and Enrollment A total of 59 patients agreed to participate in the aXess patient support program. The mean ± SD age of participants was 9. 8 ± 3. 8 years, and two-thirds were female. All patients were diagnosed with XLH. 22% of participants had de novo XLH, 61% had familial XLH, and 17%, diagnosed with XLH, had no information provided concerning inheritance. The inclusion in the aXess program occurred on average 8. 8 years after the diagnosis of XLH (Table  1 ). Heights z-scores are on average lower than the norm (negative average of -0. 90), and the outcomes are comparable whether therapy is initiated or not. The BMI z-scores are generally higher than the norm (a positive average of 0. 68), especially in patients starting therapy (0. 95) vs the others (0. 57).
Impact of the Patient Support Program on the Quality of Life of Young XLH Patients PedsQL Results Tables 3-5 summarize the means and SDS of the PedsQL Generic Core Scales for all children and subgroups of children initiating treatment and children already receiving treatment at the time of enrollment. The overall data (all patients) is shown in Figure  2. Patients already receiving treatment reported higher QOL scores than patients just starting treatment; these differences did not achieve statistical significance. Notably, after 6 months, patients who initiated therapy demonstrated significant improvement in all four components of QOL. This significance did not persist after 12 months except for the school functioning domain. Improvements in all domains were significant in patients already receiving therapy at months 6 and 12.
At month 12, while patients starting treatment reported a greater benefit in their physical functioning (a 13% rise in score globally and 100% of patients reported that doing chores around the house, lifting something heavy, and taking a shower or a bath by themselves, was never a problem after 12 months), patients already on treatment reported a greater improvement in their school performance (16% score increase, 61% at D0 versus 83% at month 12 reported that paying attention at school was never a problem). PedsQL scores were further analyzed by (1) whether the patient was in pre-or post-puberty, (2) according to their genetic status (de novo or familial XLH disease). These two variables did not significantly affect mean total QOL scores (data not shown).
Patients' Satisfaction Overall, patients were very satisfied with the patient support program. At month 6, participants reported a highly positive impact on their quality of life (patients rated their global satisfaction as 9. 8 ± 0. 6 on the 1-10 numerical scale) and a very favorable influence on treatment adherence from having access to the aXess program (Table  6 ). At month 12, participants rated their global satisfaction as 9. 2 ± 1. 5 on the 1-10 numerical scale. The decreased anxiety of living with XLH was evident for 52% of participants reporting reduced stress levels from being on the aXess program, and 97% were satisfied with the frequency of follow-up calls (Table  7 ).
In addition, any chronic condition has the potential to have an influence on the family's quality of life. However, little is known regarding the impact of XLH on children's everyday lives. Therefore, we sought to assess the potential impact of a patient support program in assisting patients and their families in adherence to therapy and their condition management. Over the period of 2019-2021, the aXess program enrolled 59 patients. Significant improvements in patient challenges were observed over the course of the patient support program. This study describes the benefit of the aXess patient support program on HRQOL in young patients with XLH, as reported by patients on the PedsQL-2. Not surprisingly, the majority of patient-requested calls came from patients who were just starting targeted therapy at the time of enrolment, suggesting a greater reliance on the support service.
Conclusions According to this study, patients value support from patient support programs like aXess when coping with XLH with a mean overall satisfaction score of 9. 8 ± 0. 6 (on a scale from 0 to 10) at month 6 and 9. 2 ± 1. 5 at month 12. This patient support program was associated with improved patient quality of life in all examined dimensions by month 12 (physical, emotional, social, and school, 85. 4 ± 0. 2 at month 12 versus 75. 6 ± 0. 3 at enrollment, p<0. 05) and constitutes a cornerstone of the young patient's care pathway. Assistance with treatment initiation and compliance, understanding their disease, reducing anxiety, and assisting them in becoming self-sufficient contribute to overall  Our observations suggest that this program provides important information regarding children's and their families' perceptions on living with XLH and their reported positive experiences with the aXess program.
FORMAL METHODS Formal methods can be used at diferent stages of a software system life-cycle, from its conception to its use. This section gives an overview of these stages and the methods that can be used during each of them. We present each method independently, but there is an important trend promoting the combination of techniques for the veriication of industrial systems. Some software frameworks embody this trend, such as Frama-C  [47, 85]  a framework for the analysis and veriication of C programs. Note that we omit deductive veriication of programs such as Why3  [27] , Dafny  [100]  and VCC  [46]  that are not used in the contributions studied in this survey.
g. , message passing) and data types, while they internally rely on more basic models for veriication. Most of these models and speciication languages can be extended with real-valued time  [9, 70]  or probabilistic features  [81] , with corresponding veriication algorithms. Model-checking has been successfully used to verify many concurrent systems, algorithms and protocols. SAT, SMT, and CSP. The Boolean satisiability problem (SAT) consists in determining whether there exists an assignment of truth values to variables that satisies a given Boolean formula. Despite the problem being NP-complete, modern provers regularly manage to solve problems with thousands of variables, thanks to a combination of advanced backtracking techniques, eicient data structures and tuned heuristics. This has made them a standard tool to solve, via reduction, many NP-complete problems, in particular those arising in the context of hardware and software veriication, for example in the Alloy Analyzer  [76].
Although software engineering has neglected the life-cycle aspect for a long time, many DevOps tools and languages have emerged in recent years that have enhanced the design of management procedures and life-cycles, their maintainability and re-usability compared to ad hoc scripts. For instance, tools such as Ansible, Puppet, Chef, Juju or Kubernetes adopt a component-oriented way of designing the life-cycle and management of distributed software (mainly containerized service-and microservice-oriented software systems). As a result, nowadays, deployment is handled almost exactly as the development aspect: deployment and installations procedures are designed for each component individually, and then composed. This task is typically carried out by DevOps engineers, whose role lie between those of application developers and system administrators.
Coqcots  [32] , that relies on Dynamic Software Update (DSU) to change the internal behavior of a component, ofers the associated reconiguration operation hotswap. Concerto  [41, 42]  or Aeolus  [54]  abstract the internal behavior of components through programmable ine-grained life-cycle, their reconiguration languages respectively ofer the operations pushB to apply a speciic subset of the life-cycle, and stateChange to move from one step to another in the life-cycle. The reconiguration language of Reo  [14]  stands apart: although it ofers operations for structural modiications that are analogous to the other models, these operations target connectors instead of components. Speciically, reconigurations in Reo modify the internal structure of connectors, which governs their behavioral semantics.
One solution is to reason on an abstraction of the behavior. For example, Concerto  [41, 42]  and Aeolus  [54]  abstract the internal behavior of components through programmable life-cycles, and respectively ofer in their reconiguration language the operations pushB to execute a specifc subset of the life-cycle, and stateChange to move from one place to another in the life-cycle etc. In the domain of theorem proving,  [68]  uses Isabelle/HOL to prove a theorem on the replacement of a component and its efect of the internal semantics of the component; this can also be seen as an abstraction of the component behavior, but from a diferent perspective. Reasoning on more complete behaviors and reconiguration seems achievable but requires a signiicant formalization efort. For example,  [11]  is able to verify a rich application with a complex behavior, but focuses on the binding of new components to provide redundancy in a fault-tolerant application.
For the highest level of genericity in veriication, one must turn to interactive proof assistants. Buisson et al. propose a development process for reconigurations based on the Coq proof assistant  [32]. The process is centered around a concrete component model called Pycots, and an abstract component model called Coqcots. Pycots ofers Dynamic Software Update (DSU) mechanisms to reconigure components without completely stopping, as well as introspection features that allow translation towards the abstract model Coqcots. Conversely, the code extraction features of Coq can be used to obtain a Pycots implementation of a system that was previously designed and veriied in Coqcots. This bidirectional translation is automated, but the veriication process is largely carried out inside Coq. Some correctness properties of the model are proven in the framework, notably the preservation of some structural invariants by the reconiguration primitives of the model, and the tool ofers features to automate some repetitive proofs steps, but application-speciic properties must be proven manually, making this technique suitable only for developers that are well-versed in interactive theorem proving.
Instead of verifying a given reconiguration program, automated techniques can be used to generate programs that satisfy a given speciication, yielding correct-by-design reconigurations. Kikuchi et al. leverage the Alloy Analyzer for this purpose  [84] , using it to solve a constraint satisfaction problem and extracting a reconiguration from the solution. No reference model is used, but a very simple component model is assumed, and the user is expected to specify constraints that model components and the semantics of reconiguration operations. The component model is based on diferent relationships between components, including łmember of" that can encode some hierarchy, but also usage of resources, etc. We call the component model ład-hoc" because there it has, to the best of our knowledge, no formal deinition.
AR4: INFERENCE OF TARGET CONFIGURATION Fully automating a reconiguration requires a mean to determine its target state. Zephyrus  [53]  is a tool developed in the context of the Aeolus project  [52]  that aims to solve this problem. Zephyrus takes as input (i) a speciication of components based on the Aeolus component model  [54] , (ii) a description of the current state of the system that covers both the infrastructure and component themselves, and (iii) a high-level speciication of the targeted state, i. e. , a set of constraints and possibly some optimization criteria. From these, Zephyrus generates a Constraint Satisiability Problem (CSP) using the constraint modeling language MiniZinc. This problem is solved with the constraint solver of GeCode, and Zephyrus uses the solution to output a new correct-by-design target coniguration  9.
Kikuchi et al. develop a similar idea  [84] : from a description of the current state of the system and a set of goal conditions formulated by the diferent stakeholders of the reconiguration, a new valid coniguration is inferred. Whereas Zephyrus uses a CSP as an intermediate representation, here the constraints are expressed in the Alloy speciication language. The Alloy Analyzer is then used to solve these constraints. Unlike Zephyrus, this solution is not limited to inferring a target coniguration, but produces at the same time a plan to reach it (see  Section 8). Engage  [59]  is another tool that relies on some form of constraint satisfaction to generate a target coniguration. However, the scope of Engage is more limited, as the user is expected to provide a partial target coniguration as input, and the aim of the tool is merely to complete it by computing missing dependencies.
POSITIONING The topic of Dynamic Software Update (DSU) was briely mentioned in this survey, particularly in the presentation of Coqcots  [32] , which ofers a speciic reconiguration operation to apply dynamic substitution of the code of a component, and uses DSU mechanisms to this end. Although DSU is related to reconiguration, we chose to exclude it from the scope of our classiication. Indeed, in Figure  1 , DSU amounts to updates in the modular behavioral modeling and modular life-cycle modeling, outside of the scope of this survey, which is denoted by the purple dashed line. DSU is an important research topic to address dynamic adaptation of distributed software systems and is complementary to contributions studied in this survey. In the interest of completeness, we briely mention two contributions related to AR4 that do not conform strictly to the component-oriented scope of this survey: ConfSolve  [73]  is a declarative language for system conigurations (a narrower concept of łconiguration" than the one used throughout this survey) with some capabilities for coniguration inference, and BtrPlace  [72]  tackles the problem of virtual machines consolidation with the help of constraint solving.
BtrPlace has itself been formally speciied and veriied by random test generation (based on the formal speciication)  [71]. More broadly, many papers that explore components or virtual machine placement, as well as task scheduling, are outside the scope of this paper because they do not focus on component models, generic reconiguration problems, or veriication. Most of them exploit mixed linear solvers and heuristics to solve optimization problems. This study focuses on component-based software engineering. Another related composition models is the concept of ensembles  [93, 124]. Ensembles provide very dynamic composition of systems where elements of the composition discover each other, and interactions are decided based on many criteria, potentially including physical measures (e. g. , spatial distance).
Verified reconfigurations of component-based applications in real-life systems Beyond the scientiic questions listed in this survey, some practical challenges will have to be addressed to implement real-life systems with veriied reconiguration. Monitoring. Fully automating reconiguration in a component-based system requires monitoring both the component system and its environment in order to detect triggering events. Some component models, such as DR-BIP or Fractal, have introspection capabilities that provide crucial information regarding the structure of the component system and some of its internal state. Another approach is to combine a model with existing monitoring solutions. One example is  [83] , which uses a Coniguration Management Database to obtain an accurate description of the system state, and translate it into a irst-order logical description, prior to synthesis of the reconiguration procedure.
We test accuracy of PHOENIX in a series of in silico experiments benchmarking it against several currently used tools for ODE estimation. We also demonstrate PHOENIX's flexibility by studying oscillating expression data from synchronized yeast cells and assess its scalability by modelling genome-scale breast cancer expression for samples ordered in pseudotime. Finally, we show how the combination of user-defined prior knowledge and functional forms from systems biology allows PHOENIX to encode key properties of the underlying GRN, and subsequently predict expression patterns in a biologically explainable way.
Fig. 1  and Supp. Table  2 ). However, given that the prior can be interpreted as soft biological constraints on the estimated dynamical system  [24] , an important question is whether PHX 0 (as well as OOTB models) makes accurate temporal predictions by correctly learning elements of the causal biology, or whether the lack of prior information results in an alternate learned representation of the dynamics, which -despite predicting these particular trajectories well -does not explain the true biological regulatory process. To this end, we recognized that the parameters of a trained PHOENIX model encode an estimate of the ground-truth gene regulatory network (GRN) that causally governs the system's evolution over time. We therefore inferred encoded GRNs from trained PHOENIX models and compared them to the ground truth networks GRN 350 and GRN 690 used to synthesize SIM350 and SIM690 respectively (see Supp.
This performance on oscillatory dynamics is indicative of the high flexibility of PHOENIX, which inherits the universal function approximation property from NeuralODEs, allowing it to deviate from Hill-like assumptions when necessary, while still remaining explainable due to the integration of prior knowledge. To test the biological explainability of the learned dynamical system, we extracted the encoded GRN from the trained PHOENIX model (with optimal λ prior = 0. 10 as determined by the validation set) and compared to a validation network of ChIP-chip transcription factor (TF) binding data  [37]. PHOENIX had impressive accuracy in predicting TF binding (AUC = 0. 86), indicating that it had learned transcription factor binding information in the process of explaining temporal patterns in expression (Figure  4 , bottomright).
PHOENIX infers genome-wide dynamics of breast cancer progression and identifies central pathways Although there are a number of tools for inferring dynamics of regulatory networks, most do not scale beyond a few hundreds of genes, falling far short of the 25,000 genes in the human genome (Table  1 ). Given the performance improvements we saw that were driven by PHOENIX's use of soft constraints, we wanted to test whether PHOENIX could be extended to human-genome scale networks. Due to the dearth of longitudinal human studies with genomewide expression measurements, we used data from a cross-sectional breast cancer study (GEO accession GSE7390  [38] ) consisting of microarray expression values for 22000 genes from 198 breast cancer patients, and ordered these samples in pseudotime. For consistency in pseudotime ordering, we reused a version of this data that was already preprocessed and ordered (using a random walk based pseudotime approach) in the PROB paper  [8].
We found that the more computationally manageable systems (n g = 500, n g = 2000) yielded an incomplete picture of gene-level influences, since the the method used in constructing these subsets hinders the mechanistic explainability of the resulting regulatory model. Certain genes exhibit relatively low variability in expression but are still central to disease-relevant genome-level dynamics; compared to methods that exclude such genes to make computation tractable  [4, 6, 12] , PHOENIX can correctly identify such as central because of its ability to model subtle but important genome-scale dynamics. PHOENIX Finally, we performed a pathway-based functional enrichment analysis by translating these gene influence scores to pathway influence scores using permutation tests on the Reactome pathway database  [51]  (see Methods 3.
We display both the predictive performance (R 2 on the test set) and the explainability performance (AUC from comparing encoded GRNs from trained models against a ChIP-seq validation network  [39] ). (main panel) We used the trained PHOENIX models to extract permutation-based influence scores for pathways in the Reactome database  [51]  (see Methods 3. 3 and 3. 4), and visualized influence scores for a collection of the most central pathways. See Supp. Table  6  for detailed results. PHOENIX.
Methods 1 Testing on simulated data 1. 1 Defining a ground truth dynamical system We created a ground truth gene regulatory network (GRN) by sampling from S. cerevisiae (yeast) regulatory networks obtained from the SynTReN v1. 2 supplementary data in simple interaction format (SIF)  [57]. The SynTReN file provides a directional GRN containing 690 genes and 1094 edges with annotations (activating vs repressive) for edge types; we defined this GRN to be ground truth network G 690. To obtain G 350 , we sampled a subnetwork of 350 genes and 590 edges from G 690. We used the connectivity structure of G 350 and G 690 , to define systems of ODEs (SIM350 and SIM690) with randomly assigned coefficients. This entire pipeline was executed using SimulatorGRN  [33] , a framework used extensively by the R/Bioconductor package dcanr  [29].
Methods 2). PHOENIX 2 Testing on experimental yeast cell cycle data 2. 1 Data processing and normalization GPR files were downloaded from the Gene Expression Omnibus (accession GSE4987  [35] ), and consisted of two dye-swap technical replicates measured every five minutes for 120 minutes. Each of two replicates were separately ma-normalized using the maNorm() function in the marray library in R/Bioconductor  [58]. The data were batch-corrected  [59]  using the ComBat() function in the sva library  [60]  and probe-sets mapping to the same gene were averaged, resulting in expression values for 5088 genes across fifty conditions. Two samples (corresponding to the 105 minute time point) were excluded for data-quality reasons, as noted in the original publication, and genes without motif information were then removed, resulting in a expression data-set containing 48 samples (24 time points in each replicate) and 3551 genes.