Community-level Research on Suicidality Prediction in a Secure Environment: Overview of the CLP sych 2021 Shared Task (2021)

Abstract: Progress on NLP for mental health — indeed, for healthcare in general — is hampered by obstacles to shared, community-level access to relevant data. We report on what is, to our knowledge, the first attempt to address this problem in mental health by conducting a shared task using sensitive data in a secure data enclave. Participating teams received access to Twitter posts donated for research, including data from users with and without suicide attempts, and did all work with the dataset entirely within a secure computational environment. We discuss the task, team results, and lessons learned to set the stage for future tasks on sensitive or confidential data.

## introduction in natural language processing, and in ai more generally, progress depends on data. the most significant progress on a problem takes place when an entire community is working on the same dataset at the same time; for example, the wide availability of speech recognition today is a result of decades of research using darpa benchmark datasets and evaluations for speech-related tasks @xcite . in healthcare, however, community-level activity is an enormous challenge. laws and regulations related to data confidentiality create obstacles to access, including significant administrative overhead such as data use agreements and significant technical overhead involving arrangements for secure data distribution, storage, and management @xcite . in mental health and particularly crisis detection, missteps like samaritans radar raise highly public red flags despite wellintentioned goals @xcite . all these legal, regulatory, operational, and public perception risks naturally make potential data providers skittish about data sharing. as a result, important research in healthcare is balkanized, with community efforts scattered among different datasets in ad hoc fashion as different teams work with the data they are able to gain access to. or potentially it doesn't take place at all, as talented researchers go work on other problems where obtaining data is just easier. secure data enclaves are one solution to this problem @xcite . the key idea in a data enclave is to bring researchers to sensitive data, rather than disseminating data out to researchers. a data enclave provides secure remote access to data using carefully designed statistical, technical, legal and operational controls. computation on an enclave is done using a copy of the data residing there without full networking access, meaning that nothing can be imported or exported without disclosure review. this does not replace necessary steps like irb approvals, data use agreements, and record de-identification; for example, data enclave users can still look at private data within the enclave and need to agree not to attempt de-anonymization. however, it drastically simplifies community-level access. a single, comprehensive description of security provisions can be created for data providers and ethical review boards, and data providers need to enter into data use agreements only with the enclave, rather than with individual teams. to our knowledge, the clpsych 2021 shared task is a first-of-its-kind endeavor: as far as we know, it is the first time a community-level shared task with sensitive mental health data has been conducted on a data enclave, and more generally shared tasks on sensitive data are rare in the nlp and machine learning communities. in addition, although uses of data enclaves are often centered on the use of analytics tools, in this shared task the environment was designed to support the full arsenal of nlp and machine learning methods. we accomplished this by partnering with norc at the university of chicago. since 2006, the norc data enclave ® has served u.s. state and federal agencies, research institutes, foundations, and universities by securely housing and providing remote access to confidential data. in a collaborative project with university of maryland, norc has developed the umd/norc mental health data enclave (henceforth the enclave, for short), a subset of norc data enclave infrastructure designed specifically with the requirements of mental health nlp and machine learning research in mind. data for this shared task were provided by qntfy, which runs ourdatahelps.org, an online platform that permits donations of digital life data (including social media) for the purposes of advancing research in mental health and wellbeing. individuals come from a range of lived experience with mental health, specifically related to this shared task: individuals who have survived suicide attempts, loved ones of people who have died by suicide, and people who just want to help. for this shared task, qntfy established a data provider agreement with norc, and norc executed data use agreements with the participating teams. the university of maryland, college park irb reviewed and approved a protocol for research with, and sharing of, the ourdatahelps data. the arrangement here therefore exemplifies the advantages of data enclaves discussed above. for the data provider, it was much easier to work out an agreement with just a single entity running an established secure infrastructure, which significantly lowered the bar for sharing data with multiple teams. in addition, norc's platform and processes for team access, platform security, and import/export review created a far greater level of confidence in privacy controls than sending data out to a large number of far-flung teams with heterogeneous environments. for teams, this provided a rare opportunity to work with sensitive mental health data containing actual outcomes, not proxy data as is more common in social media mental health research and which can be problematic for a variety of reasons @xcite . the shared task itself involved assessment of suicide risk via prediction of suicide attempts, based on the natural language of users on twitter. there were two subtasks: subtask 1 involved assessing suicide risk given 30 days of tweets prior to the date of an attempt (or a corresponding date when no attempt was made), and subtask 2 involved as-sessing suicide risk given the prior six months of tweets. a set of 21 teams signed up and were onboarded on the enclave. a total of five teams ultimately submitted systems by the deadline. all teams have been given several months of additional access and support on the enclave, in order to permit continued experimentation. we are hopeful that results obtained during this extended time period will lead to publications beyond clpsych. in this overview paper, we provide not only a summary overview the shared task itself, in terms of the research problem and participating teams' findings about predicting suicide risk from twitter data, but also a retrospective analysis of conducting a shared task in a secure enclave, including lessons learned and recommendations for future tasks of this kind. foot_0 ## background and related work a number of recent articles discuss the use of nlp, machine learning, and social media in service of mental health. as important motivating background, a meta-analysis by @xcite concludes that prediction of suicidal thoughts and behaviors has not improved in fifty years, encouraging a shift to algorithmic and machine learning approaches. @xcite provide significant empirical support for this view via another meta-analysis looking specifically at traditional theory-driven versus machine learning approaches to prediction of suicide risk, demonstrating that the latter are significantly more effective at prediction. foot_1 naslund et al. (2020) and @xcite provide overviews that include thoughtful, big-picture commentary on research and clinical applications for mental health taking advantage of nlp, machine learning, and social media. @xcite offer an overview of issues more specifically focused on using naturally occurring language as a source of evidence in suicide prediction. one running theme throughout discussions of this kind involves the availability of data to work with, and the interplay, or even tension, between the need for research and the need to respect privacy and other ethical considerations. horvitz and mulligan (2015) provide one short, useful discussion specifically focused on data and privacy, and @xcite and @xcite discuss ethical issues specifically with regard to social media and work on mental health. @xcite provide a valuable entry point to the concept of data enclaves as a way to balance the need for data access in order to make progress in healthcare with respect for patient privacy -this concept ties in directly with the call by @xcite for community-level mental health datasets to be easily available for research so that the predictive ability of models can be compared and research can be replicated. those kinds of comparisons and replications are instrumental in modern data-driven research because without them it is impossible to gain insight into which approaches are most promising or to rule out the possibility that apparent differences are related to idiosyncratic differences in data. related, the most current paradigms in nlp and machine learning involve both general-purpose pretraining and task-specific fine-tuning. to some extent, pre-training data may capture generalizations about language that transfer well to problems in the mental health space. however, many offthe-shelf language resources that are commonly used, such as bert @xcite , are built from sources such as books and wikipedia entries. these may translate poorly to systems dependent on social media posts from twitter, facebook, or an online discussion forum. it is well known that systems perform better when they are trained on materials similar to the materials the system will run on @xcite . therefore using task-specific data from immediately relevant sources as training data for social media based mental health tasks is a high priority that requires attention. another theme found in related literature involves the nature and quality of the variables being predicted. the sensitivity of mental health data has led to a proliferation of proxy variables taken from publicly available data rather than groundtruth clinical variables or real-world outcomes (e.g. de choudhury and @xcite @xcite @xcite . as two particularly well known and influential examples, @xcite infer mental health diagnoses of twitter users by looking for publicly self-reported diagnoses, @xcite infer mental health progressions to suicidal ideation by examining when reddit users shift from mental health subreddits to the suicidewatch subreddit. such data tend to have the advantages of being readily accessible and large in size. @xcite note a variety of problems and limitations in using proxies rather than clinically grounded variables. @xcite offer a rare exception in this kind of work, using an ethical process of data donation to obtain social media data with outcomes for research on prediction of suicide attempts; our shared task is based on a subset of their data. ## data we briefly describe our data sources, and how we constructed the shared task datasets for binary classification tasks. ## baseline a baseline system was provided to shared task participants to use or build upon. 4 baseline preprocessing includes several standard steps. first, we removed all urls, user mentions, and emojis from the tweets. whenever a user's tweet includes an image, gif, or link, the links are removed. we tokenized the tweets using the twitterspecific twikenizer and removed stopwords from the tweets' text using the default spacy @xcite stopword list. 5 last, we split hashtags into the words they are made up of: first, we try to split by camel-case or by underscores; if that fails, we use a method from hashtagsplitter, attempting to split into the smallest subset of real words. 6 the baseline classification model used logistic regression with the default parameters from scikit learn @xcite , employing unigram and bigram count vectors. ## the enclave as discussed in the introduction, data-driven research in mental health, and healthcare more generally, faces significant obstacles owing to important concerns about privacy and data confidentiality. data enclaves offer a potential solution @xcite . norc at the university of chicago, an independent, non-profit research institution, took on the operational aspects of running this shared task on their data enclave. significant time was spent working with qntfy, who were responsible for providing the ourdatahelps data, and the shared task organizers, to develop the data provider agreement, data use agreements, operational policies, supporting infrastructure, and technical and operational support for the organizers and shared task teams. all aspects of the shared task on the enclave were run using exactly the same procedures as for norc's traditional data enclave clients, such as government agencies working with confidential databases. teams that worked on the shared task executed a data use agreement with norc and then were "onboarded" to the enclave, being provided with account logins, passwords, documentation, procedures for uploading and export (both requiring human review of the material entering or leaving the enclave), and contacts and procedures for technical support. the enclave environment includes two main parts. the first part is a secure virtual desktop (using citrix), accessed via the data enclave login page through an internet browser. the second part of the enclave is norc's mental health data enclave (mhde) cluster on amazon web services (aws). from within the secure citrix desktop, participants use putty ssh to reach a gateway machine on this cluster. they can run code there or submit batch jobs using the slurm cluster management and job scheduling system. 7 the aws environment is configured to spin up a new instance for the duration of the job and then spin it down when completed, conserving compute resources to save cost. crucially, the enclave is a closed environment. the norc data enclave's data security model integrates a portfolio approach with the five safes framework @xcite to harden the security posture. this means that bringing materials in, such as code, data, or other resources, requires an import request process. each request triggers a robust review process to provide safe passage of confidential micro-data and ensure imported material does not contain any virus or code aimed at disabling the capabilities or facilitating unauthorized access. in order to set up the enclave environment and hopefully speed up this process for shared task participants, it was pre-loaded with major python packages and tools (more than 4000 of them), the shared task baseline code, and shared task data; see further discussion in section 8. similarly, as a data custodian for restricted data (e.g. confidential micro-data for federal, state and commercial clients), norc must ensure that any data leaving the norc data enclave is safe and free of inappropriate disclosures. this means that there is a request-based procedure for exporting any material from the enclave, with formal review criteria that include both dataset-specific criteria and general guidelines applied globally across all requests. ## submissions each team was permitted up to three submissions for each subtask (30 days and 6 months). in each subtask, the numbered submissions for each team distinguish the "primary" submission (numbered 1) from additional contrastive runs (numbered 2 and 3). in total, we received 30 submissions, with five teams providing three runs each for both subtasks. nusids @xcite . for the shared task, nusids designed shtm, a self-harm topic model, which combines standard latent dirichlet allocation (lda) with a self-harm dictionary. this was tested using a combination of the shared task data, along with the practice dataset and the umd reddit suicidality dataset. in their submission to the task, the team used a combination of an lstm and term feature vectors with shtm-based feasentiment5 @xcite . sentiment5 took different approaches in their submissions to explore the performance of simple traditional models versus fine-tuned deep learning models. in both subtasks 1 and 2, they submitted results from gradient-boosted classifiers. one used syntax features and the other character tf-idf features. for subtask 1, they also submitted results from a contextualized language model classifier, and, for subtask 2, a voting ensemble method. sos @xcite . team sos introduced the c-attention network, which uses latent feature information implicitly in the embeddings. this was compared with submissions using knn and svm classifiers. latent features included using doc2vec embeddings @xcite . hand-crafted features included emotion lexicons, part-of-speech tags, and a custom dictionary that models various stages of suicidal behavior. ulyalamia @xcite . in the ulyalamia submissions, the authors were motivated by real-life applicability of their model to use tweet-level classification. the team's submissions used a majority voting approach over individual tweets. in order to pick which machine learning method to use, the team experimented with multiple methods tuned on the training data using a leave-one-out strategy. their final submissions were the top methods from the leave-one-out results. ## results we evaluated each system in terms of f 1 , f 2 (favoring recall), true positive rate (tpr), false alarm (positive) rate (far), and area under the roc curve (auc). we use f 1 score as the primary evaluation metric, though it is valuable to consider all metrics for a complete view of the system performance. we present the results of the submissions in tables 3 and 4. in subtask 1, team ulyalamia ranked highest in f 1 , f 2 and tpr; however, their far was higher than the baseline and in the middle of the other team's submissions. team ulyalamia was also the only team to exceed the baseline f 1 score, with nusids being the next closest team. in subtask 2, team scylab ranked highest in f 1 , far, and auc. their strongest submission beat or met the baseline in every metric and was notably low in their far. five submissions came close or beat the baseline in f 1 score in subtask 2. the methods used by teams in the shared task had difficulties performing well in both subtasks. given shorter-term information starting 30 days prior to an attempt, tweet-specific language (ulyalamia) performed beste, but dictionary-based methods (e.g., scylab) worked best with the longer-term evidence (6 months prior to an attempt). to gain a better understanding of the differences between the submissions, we plot the ranks of each test user for both subtasks in figures 1 and 2 . from these figures, we can see that some users easily classified by most systems, while others were notably difficult. for instance, in the last positive (@xmath0, the majority of systems were (incorrectly) very confident that the user did not make a suicide attempt. nevertheless, three submissions gave this user the highest or second-highest likelihood. these results suggest that an ensemble method may be beneficial for this task. this task is notably similar to @xcite , who performed experimentation including ourdatahelps.org data with similar restrictions, matching criteria, and the same binary outcomes. they found that a longer history of tweets led to slightly better predictions, but, unlike our shared task, they did not find a significant increase in performance between using tweets 90 to 0 days prior to an attempt and using tweets 180 to 90 days prior. in @xcite , the auc score using tweets 30 days prior to an attempt is .89 and the auc score using tweets six months prior to an attempt is .93. at the same time, it is important to note that those results are not directly comparable to the present task, given differences in dataset size and composition. @xcite used more ourdatahelps data, and this was augmented with a dataset of users who had made publicly self-stated suicide attempts, building on work in @xcite . in total, @xcite performed their experimentation using a dataset containing 418 users with suicide attempts, compared to this task's 97 users. ## enclave lessons learned we solicited feedback from all registered teams (both those who submitted results and those who did not) regarding the shared task experience. this discussion and our lessons learned for the future are informed by their comments. onboarding. shared tasks are bursty by nature, the first burst involving participants getting started. in contrast, the ongoing operations of a data enclave involve a more continuous scheduling process for new user account requests. this led to challenges in the onboarding process. as noted in section 5, procedures for this shared task were identical to the procedures used when serving organizations like government agencies, with not one fewer i dotted, not one fewer t crossed. this meant that teams experienced longer than expected delays between completing their paperwork and actually being able to begin work on the enclave. we would recommend more lead time in the future, leaving significant time for account requests and also having teams prioritize which members need access first. importing code and dependencies. similarly, data enclaves require strict import policies and procedures; every import request is treated as though it could contain highly confidential data, a virus, or disabling code. again, the bursty nature of shared task activity created challenges. despite our attempts to anticipate and pre-load software and data resources that were likely to be needed (informed by an earlier survey of people engaged in clpsychrelated work), the burst of requests as teams got started created long delays as teams waited for their code and software dependencies to come online. workarounds, such as recreating code manually, were complicated by the inability to copy/paste inside the environment. time zones. the clpsych 2021 shared task received global interest, with teams participating on several continents. however, data enclaves rarely provide 24/7 support. while having a diverse set of teams work on the task is indispensable, having support concentrated in a single u.s. time zone disproportionately affected those working outside the u.s. we anticipate that these issues could be mitigated in part by greater lead time (again), and also by streamlining processes to require fewer round trips of communication. slurm and notebooks. these days, many prefer to conduct nlp research in an interactive setting using jupyter notebooks. while these were supported on the head node of the cluster, they were not available when running jobs on compute nodes, including those with gpu resources. this is worth considering. while such an arrangement would run through one's compute budget faster (as compute nodes would remain running), the interactive benefits may be a tradeoff that teams are willing to make, and this would also avoid batch-job overhead for those who do not require the capabilities offered by a scheduler like slurm. connectivity and enclave maintenance. like any well supported infrastructure, the enclave requires regular maintenance and has occasional downtime. scheduled maintenance was easy to plan for, but unplanned downtime can be a real challenge in deadline-driven activities like a shared task. despite these challenges, which certainly gave rise to some frustration, a number of teams expressed gratitude for being able to work on data that would otherwise be unavailable, and others expressed that they were pleased with the overall responsiveness and speed of the enclave. some also expressed appreciation for having had ample of compute credits for conducting their experiments. 8 if there is a unifying theme in our lessons learned, it is that the challenges we encountered are connected almost entirely with the gap between the typical flexibility of experimental computational work in nlp, particularly in the compressed time frame of a shared task, versus the more extended, carefully centralized, step-by-step, controlled processes that take place on a data enclave. but of course that's the whole point: those same careful, centralized processes are the things that guard against inappropriate use and disclosure of sensitive data. as a particular note for the future, more advance planning and communication with participants would alleviate several of these challenges, especially onboarding and importing code and dependencies. for this shared task, we chose to prioritize allowing participants to start working on the task sooner, rather than requiring teams to commit long before they would begin work and start going through a more structured and scheduled process to prepare the enclave with their specific team-level requests. we attempted to preload needed libraries and tools onto the enclave even before teams began to register -but we could not predict all of the tools and resources participants would want, so even with our efforts there was still a gap. and although we tested the onboarding process and coding experience, any new, diverse group of people is going to discover unanticipated issues when using a large production environment for a new purpose. that said, it is worth noting that a time-bounded shared task is just one model for this type of collaborative work. in other domains, it is not uncommon for community shared activity to take place over the longer term, e.g use of the mimic dataset @xcite in research on electronic health records. a shorter-term, bursty event like a shared task may be the wrong model when navigating between the requirements of flexible research and the requirements of data privacy -many challenges would be mitigated if participants were not all attempting to meet the same deadline. therefore, an alternative paradigm to consider would involve a more gradual intake of participants, reducing the backlogs and avoiding bottlenecks in account creation and handling of initial import requests. this would would also allow participants to more freely work in their own time zone, and factor in downtimes in their schedule. ## conclusion in this effort, we introduced a mental health shared task using sensitive language data in a secure data enclave that offered broad nlp and machine learning capabilities. participants conducted studies on the prediction of suicide risk based on tweets, using donated data containing actual outcomes rather than proxy data and matching individuals who attempted suicide with control users. participants built systems that were able to achieve high predictive power (up to 0.823 f 1 score), while carefully balancing true positives and false alarms. through the shared task, we learned more about the challenges of conducting such a task in an enclave environment, leading to observations that will help set the stage for future efforts of this kind.