Matching-adjusted indirect comparison is a comparative effectiveness research methodology that leverages individual level data and aggregate results when head-to-head randomized trials are not available or feasible. MAIC is growing in popularity partly because of the high costs of randomized trials and because of interest on the part of regulators for more safety and effectiveness evidence. Since the seminal papers describing the theory and application of MAIC were published just over a decade ago, the literature on how to apply this method as well as demonstrations of its applications has grown quickly. The National Institute for Health Care Excellence (NICE) in the UK released a technical document in 2016 that described MAIC best practices and provided sample R code for an example analysis. As the method has become more popular, references to the use of Stata for statistical analysis are appearing in publications yet very little documentation or code is available. We present the NICE technical documentation worked example using Stata in parallel to the original example in R and highlight the efficiencies and potential challenges of both programs.

Evaluating the out-of-sample properties of statistical models is important, especially for predictive modeling/analytics. Although Stata currently implements cross-validation methods natively for some model-fitting commands—dslogit, dspoisson, dsregress, elasticnet, lasso, poivregress, pologit, popoisson, poregress, sqrtlasso, xpoivregress, xpologit, xpopoisson, and xporegress—broader use of cross-validation is not natively supported. At last year’s conference, a user explained the challenges that students and new users face when trying to use cross-validation procedures in Stata. While it is possible to implement the four-step process of splitting the sample, fitting the model to the training sample, predicting outcomes on the validation/test sample, and computing metrics related to the fit, doing so is tedious and time consuming. Developing a program that implements the four-step process above is not a trivial task, despite what one of the authors initially thought. In this talk, we present xv, an extensible prefix command implementing cross-validation for Stata estimation commands.

Ordinary least-squares regression (OLS) estimates coefficients such that the residual sum of squares (RSS) is a minimum. Further, the R-squared between the response variable and the predictors is a maximum. The solution for these OLS coefficients is unique; that is, there is only one set of coefficients that minimizes the residuals. But what if we estimated coefficients that come within one percent (0.01) or less of the maximum value of R-squared. There can be multiple sets of coefficients that yield the same R-squared. These are the fungible regression coefficients (FRCs). How many different fungible regression coefficients are possible? What do these FRCs look like? Are these FRCs of any use whatsoever? This presentation will address these questions.

Background: Traditional Stata programming requires the mastery of syntax for tailoring program behaviors. However, the traditional programming approach is challenging in scenarios where 1) users lack familiarity with Stata syntax, 2) instructions for third-party programs are nonexistent, and 3) the program calls for complex syntax. To address these issues, we've explored a prompt-based programming approach.

Method: We used Stata's request() option under the display command to offer the user stepwise value intake prompts, establish checkpoints prior to executions, and allow modifications without termination.

Results: The request() option introduces significant advantages. It guides the user through parameter intake in a straightforward manner, reducing the efforts to understand complex syntax. Moreover, by incorporating checkpoints and allowing for modifications during processing, it substantially diminishes the likelihood and impact of errors. However, incorporating such prompt-based elements into broader programming frameworks presents challenges because of the requirement for user input.

Conclusion: Adopting a prompt-based programming approach significantly eases the learning curve and offers a practical solution for both preventing and correcting errors efficiently. Nonetheless, the potential difficulties of integrating these prompt-based elements into larger programming projects warrant careful consideration. Programmers need to evaluate application context, user's expertise, and the practicality of integration when choosing between programming methodologies.

Causal mediation analysis determines the mechanism through which a treatment influences an outcome through a mediator. The objective of this presentation is to provide a practical guide, facilitating an understanding and implementation of causal mediation analysis using Stata 18's new mediate command. We will begin by introducing the fundamental steps of causal analysis and then apply these steps to causal mediation analysis. Additionally, we will highlight the differences between causal and traditional mediation analysis. The presentation will also delve into various types of direct and indirect effects, illustrating their practical applications. Examples demonstrating how to perform causal mediation estimation within Stata, using different types of outcomes and mediators (continuous, binary, and count), will be provided. No prior knowledge of Stata is required, although a basic understanding of causal inference will be beneficial.

Added-variable plots show the contribution of each data point of one explanatory variable to an outcome variable, while controlling for the influence of multiple other explanatory variables. This is a multivariate generalization of a scatterplot with a trend line. It provides an intuitive visual presentation of complex estimation results to specialists and nonspecialists alike. The plots show the marginal effect of an explanatory variable on the outcome as well as how closely the data adhere to the estimate. Observers can see outliers and the statistical significance of the estimated coefficient. The more complex the estimation method, the more helpful it is to have an accessible visual representation of the results.
Currently, added-variable plots are available only for OLS regression in Stata. I recently extended the theory of added-variable plots to all commonly used linear and nonlinear estimators, including generalized least squares, instrumental variables, maximum likelihood, nonlinear least squares, and generalized method of moments estimators. I am in the process of programming added-variable plot commands for all Stata estimators. I have started with added-variable plots for panel data (xt) estimators (SJ 2020) and will shortly add them for instrumental variables and time-series estimators.

adodown aims to make Stata packages easier for both developers to create and users to understand. For developers, adodown offers workflow commands that automate manual tasks at each stage of development. At project's start, adodown creates the necessary scaffolding for the package (folders, pkg-file, etc). For each package command, it uses templates to create necessary files (i.e., ado, documentation, unit test) and adds appropriate entries in the pkg-file. For documentation, it allows developers to draft in plain Markdown while creating standard help files in SMCL. And for publication, adodown collects the required files, puts them in proper format, and prepares a zip file for SSC submission. Also, adodown automatically deploys a package documentation website. For users, this provides an easy way to discover packages, to understand what they do, and to explore how commands work—all without installing the package. For developers, this provides packages with a welcome web presence and offers a home for additional documentation (e.g., how-to guides, technical notes, FAQs) and keeps HTML documentation up to date with SMCL documentation through continuous deployment via GitHub Actions. This talk will demonstrate how adodown works, showcase a few live examples, and seek feedback from the Stata community.

In this presentation, we introduce two novel commands, repado and reproot, as part of the Stata package repkit, designed to streamline projects package version control and management across teams. The repado command facilitates precise version control of Stata packages within projects by establishing project-specific ado-path folders. This ensures consistent usage of package dependencies among team members and enhances reproducibility by preserving access to specific command versions, vital for revisiting older projects. Moreover, repado proves instrumental in package development, enabling seamless testing of unpublished commands alongside stable versions in diverse project environments. Complementing repado, reproot offers efficient management of root paths across projects with minimal manual intervention. Unlike existing packages addressing the same inefficiency, like setroot, reproot excels in handling multirooted projects, such as those involving Git collaboration and data sharing on diverse platforms like Dropbox or network drives. Its streamlined setup ensures rapid root path identification, even when a project's roots are in different location in a project. The setup of reproot only needs to be done once per computer for all projects. This helps optimize project navigation and facilitate seamless integration across team workflows, especially in teams and organizations collaborating on many projects.

The reprun command in Stata is designed to automate reproducibility verifications for sets of Stata do-files. This session presents detailed updates to the command in the context of DIME Analytics’s repkit package, which spans a complete workflow for the reproducibility verifications. The repkit package aims to ensure that the outputs of reproducibility packages are stable and reproducible, addressing the common sources of reproducibility failures. By identifying and correcting issues, users can improve the reliability of their statistical analyses, making them suitable for sharing and publication. The reprun command performs two runs of a specified do-file, recording the state of Stata after each line’s execution during the first run and then comparing it with the state after the same line’s execution in the second run. Key states monitored include the random-number generator (RNG) state, data sort order, and data contents. If discrepancies occur between the two runs, reprun flags potential reproducibility errors, reporting mismatches in a table format, which helps in identifying and resolving issues. This tool emphasizes the importance of managing randomness and maintaining consistent data states to avoid reproducibility errors, especially when inconsistent outputs are far downstream in code from their sources.

In this case study, we examine the wage earnings of fully employed previous refugee immigrants in Sweden. Using administrative employer–employee data from 1990 onward, about 100,000 refugee immigrants who arrived between 1980 and 1996 and were granted asylum are compared with a matched sample of native-born workers using coarsened exact matching. Employing recentered influence function (RIF) quantile regressions to wage earnings for the period 2011–2015, the occupational-task-based Oaxaca–Blinder decomposition approach shows that refugees perform better than natives at the median wage, controlling for individual and firm characteristics. The RIF-quantile approach provides better insights for the analysis of these wage differentials than the standard regression model employed in earlier versions of the study.

This paper presents a new Stata command for carrying out optimal policy learning (OPL) with observational data, i.e., data-driven optimal decision-making, in multiaction (or multiarm) settings, where a finite set of decision options is available. The presentation and related command focus on three components: estimation, risk preference, and regret estimation via three estimation methods (i.e., regression adjustment, inverse probability weighting, and doubly robust estimators). After briefly presenting the statistical background of this OPL model and the related syntax of the Stata command, the paper will focus on an application related to climate-related agricultural policies.