Use cases · Research teams · Data sharing story
A data-sharing community for health and extreme weather
CAFE RCC, The Research Coordinating Center for Health and Extreme Weather
Harvard Dataverse Repository · GREI Real-World Data Sharing Use Case GREI data sharing story — Published 2026-02-04
"We've definitely benefited from the open source ecosystem, and starting from scratch anywhere else, we would not have gotten to the place that we were today. There's no question about it."
— Danielle Braun, PhD
Project Overview
Principal Investigators:
 |  |  |
|---|---|---|
| Greg Wellenius, ScD Professor, BUSPH Department of Environmental Health; Core Faculty | Francesca Dominici, PhD Director, Harvard Data Science Initiative; Clarence James Gamble Professor of Biostatistics, Population and Data Science | Amruta Nori-Sarma, PhD Assistant Professor, Department of Environmental Health, Harvard T.H. Chan School of Public Health |
Meet the Team: https://www.climatehealthcafe.org/team
Project Collection Page: https://dataverse.harvard.edu/dataverse/CAFE
Related publication: Coexposure to extreme heat, wildfire burn zones, and wildfire smoke in the Western US from 2006 to 2020 (Science Advances)
Funding: NIH, grant number U24ES035309
Interviewees
 |  |  |
|---|---|---|
| Danielle Braun, PhD (DB) Co-lead, Data Management Function | Kevin Lane, PhD (KL) Co-lead, Data Management Function | Jonathan Gilmour (JG) Data Scientist, Harvard T.H. Chan School of Public Health |
The Dataverse Team
 |  |  |
|---|---|---|
| Ceilyn Boyd Interim Director of Data Science and Product Research | Alexis Guanche (AG) Software Engineer | Emily Katz (EK) Dataverse Curation Assistant |
 |  |
|---|---|
| Sonia Maria Barbosa Associate Director, Dataverse Support and Data Curation, and the Murray Archive | Robert Treacy Technology Architect and Senior Software Engineer, Consilience, Data Science |
Tell us more about your research project that generated this collection. Please briefly describe the data that was shared.
(DB): CAFE RCC is a Research Coordinating Center jointly funded by the NIH, Boston University, and the Harvard T.H. Chan School of Public Health. The goal of the CAFE Dataverse collection is to have a home and share data related to environmental exposures and health. It's both data that was generated internally by the team and data that has been deposited over time by the research community.
Our community of practice includes over 3,100 individuals, many of which have accessed the data, or downloaded and used the data, as well as deposited datasets of their own into the collection.
The open collection is designed to support and enhance global research initiatives focused on understanding and mitigating the health impacts of environmental exposures.
More information about CAFE RCC's data management can be found on their data management page. To learn more about CAFE, please visit their homepage.
Data and Coding Resource Hub (GitHub)
A collection of code, software, and tutorials on GitHub allowing researchers to contribute, share, and reuse existing code and software for data processing and analysis to facilitate reproducibility and reusability. This will include commonly used data processing and analysis tasks such as spatial aggregations, data harmonization, and analysis.
The BUSPH-HSPH CAFE RCC Documentation Site
How would you describe the potential impact of this work to someone outside of your field of study?
(DB): I think there are multiple ways in which data sharing has had a positive impact on research in this space of environmental exposures and health. This specific community historically has not had a place where they can find all datasets in one location. Having a repository has been a game changer in accelerating the pace of research in this field. Also, having datasets that were not only hosted on Harvard Dataverse, but also harvested from other data sources being findable within our collection has really created a home for anybody looking for environmental health data.
(JG): As someone who often goes looking for data, to know that there's a first place to look for datasets is so helpful because the data ecosystem is so spread out. It's such a boon to data scientists and anybody who works with data, to be able to go to one place first to check to see if they can find what they need.
(DB): To add to this, the data ecosystem has also been rapidly changing over time, and we were able to incorporate those changes by having (Harvard Dataverse Repository) be the home for this type of research and data.
The CAFE collection on Harvard Dataverse: https://dataverse.harvard.edu/dataverse/CAFE
Can you describe the synthetic data? How does that get used in your field?
(DB): We've actually taken synthetic claims data from Medicare, and we merged it in with environmental exposures, so it's a ready-to-use dataset for the community where the health outcomes are actually linked with environmental exposures.
Researchers can use it to apply their methods, do different testing and understand the data structure and data processing and what this data would look like if they did, for example, have their own data use agreement with the Centers for Medicare and Medicaid Services.
It allows researchers to get a feel of how to work with the data without having the data yet.
We've also used it for benchmarking datasets that have been used to study and assess different kind of statistical modeling approaches and biases and come up with scenarios, realistic scenarios, and assess how methods are able to overcome those statistical challenges.
Have either of you deposited your own datasets into CAFE?
(DB): I'm a co-author on a few datasets.
(JG): Some of the work that I've done has included making aggregations of pre-existing gridded data and aggregating it to polygonal data at the county level or the ZCTA level, and so I've done that and then deposited it, and one of the great things about Dataverse is I can then link back to the original dataset, I can link to the code that I used, to make the process and the underlying input's really easily accessible to someone who is interested in that dataset.
(DB): As an example, we've actually taken synthetic claims data from Medicare, and we merged it in with environmental exposures, so it's a ready-to-use dataset for the community where the health outcomes are actually linked with environmental exposures data or code which is really critical for our community.
How has data sharing evolved over the past decade in your research field?
(DB): Data sharing has evolved a lot and in a good way, but we're not there yet.
Ten years ago, and especially before the implementation of the NIH data management and sharing plans and that requirement, there was greater hesitancy by the community to share. Even on regulated data, there was a feeling of ownership, that people have invested a lot of time in curating and modeling this data, and some resistance to share it more broadly.
We do see a shift, I think, which has been really positive for many reasons, including both the NIH requirements and other funders requiring the shift. Also, the realization that if you do deposit data on Harvard Dataverse, it's citable. People are reusing your work and you're amplifying the impact of your initial studies.
We've definitely seen a shift in attitude towards data sharing in the community over the last few years, but I don't think we're fully there, but we have seen that.
Do you feel there are adequate standards and resources for data management and sharing in your field in particular?
(DB): As part of CAFE, we were tasked with creating those resources, so I think NIH identified this specific need, and I completely agree that there was a need, that there weren't standards.
But part of our role in CAFE was to develop those standards and metadata that would be beneficial for the type of research that we do, and to develop guidelines and handhold, and walk researchers through to make data management and sharing as easy as possible.
Currently, with the resources that we provide, yes, there's definitely more guidelines than there used to be.
Before coming to a generalist repository, like Harvard Dataverse, where were you sharing your data?
(DB): Wearing my researcher hat, broadly, we weren't sharing data. I can say that the people in our group shared Dropbox links, Drive links. I've seen personal websites in the community. I still see personal websites in the community, unfortunately.
Yes, I still see all of those, and some GitHub. There was minimal sharing. So this explains the little sharing that we used to do before our team migrated to Dataverse.
(JG): Another place where I've often found data is on government sites, so when I'm using data from the federal government, or state governments, or other countries, I often find those on government, purpose-built FTP servers, or through APIs, or through direct data downloads, and there's a wide variety in types of data dissemination infrastructure, and also the ease of use. It's quite a spectrum.
(DB): And just to reiterate that I think before CAFE, there both wasn't a home for this type of data, but also, it wasn't like people were necessarily even trying to find alternative homes, they just weren't sharing data.
And when they did (share data), again, there's no topic-specific repository that we see datasets in. We don't in this space. When it's mostly driven by journal requirements, we'll see a Zenodo deposit, but when I read publications, not often. Not often is it shared elsewhere in a different FAIR repository.
48 published subcollections within CAFE
How could the data repository landscape evolve to better support data sharing and reuse?
(DB): One thing we've really been struggling with—and I've tried to be thoughtful about, with lots of conversations inside CAFE over the last two years of funding—is how to make datasets from multiple locations findable in one place. And I keep coming back to whether that's supposed to be the job of a generalist repository like Harvard Dataverse, where you'd harvest from other sources, or whether it's really more like a separate data catalog—like the NIH/NLM catalog that does a great job pointing out to other repositories.
Our goal was to be the place where data is findable, but the hard part is balancing "make it findable within Dataverse" versus "point to everything else," without just turning into a data catalog—or maybe accepting that we do become a data catalog and risk overlapping with work that already exists. I don't know if there's a clean solution. It's great that there are so many places and so many people contributing data, but that just brings us back to the same question: how do we harmonize it, and how do we make it findable?
(KL): In addition to CAFE, I also work on the Gateway Exposome Coordinating Center, which is an effort for the National Institute on Aging to harmonize environmental and climate-based datasets so that they can be shared more easily amongst researchers in the Alzheimer's and dementia space overall.
And we've done some of that work—trying to harvest across platforms—but the problem is, not everything is here, right? Cross-platform searching is currently tedious—having to repeat the same search across multiple repositories (like Figshare, DesignSafe, ArcGIS Online, etc.) to get a full view of what's out there.
So this is kind of a pie-in-the-sky, big-picture place this could go, but with the expansion and proliferation of metadata—people choosing different ones, like whether you use CEDAR or something else—how do we make these things more harmonized? I'm out of my depth on the actual answer, but it's like the National Library of Medicine does this. It'll send me articles I need from environmental engineering journals and all these other places. So why can't we have something harmonized like that for data?
I'm trying to help people who've never shared data in Zenodo or Figshare—or anywhere—get over that initial gap. The moment I have to start explaining, "we need to pick which platform," or why one is more common in our field, I can see them losing interest because they don't understand that piece, and then they're less likely to share at all.
If discovery and metadata were harmonized across platforms, you'd bring in people who currently think, "If I choose one, how do I point people to it?" or "If I share in one place, do I now have to do it in all of them?"
Anecdotally, I've heard that this fear—having to duplicate everywhere, plus being told it's not good to duplicate—becomes a real barrier. And then you get into things like "create a data card," and these are folks who don't even know what a data card is. They're outstanding researchers in their own domain, but they're not going to pick this up without the system meeting them where they are.
Kevin Lane, PhD (Co-lead, Data Management Function)
"The CAFE project afforded the Dataverse curation and development teams a fantastic opportunity to collaborate with biomedical researchers working to develop tools, resources, and community standards for sharing climate and health research data. During the project, our Dataverse development and curation teams helped establish the popular CAFE data collection, and designed and developed new geospatial, UI, metadata support, and other Dataverse software features benefitting users in the Dataverse Community, as well as within the CAFE community."
— Ceilyn Boyd, Interim Director, Data Science and Product Research
Related resources:
CAFE Dataverse and Coding Resources: https://www.climatehealthcafe.org/cafe-dataverse-and-coding-resources
Custom metadata block
Harvested Collection: DesignSafe Data Depot Repository Harvested Subcollection
Can you describe your experience sharing data via a generalist repository?
(DB): Positive. Very easy to deposit data in terms of the logistics and filling out of user-friendly metadata forms. Easy to create an account. There are not a lot of barriers in the process, I would say, from a user perspective.
I think one of the advantages of this partnership and why it was so successful is because Harvard Dataverse is open source, and we were able to customize those features and make them specific for our community and our collection, and I think we really benefited also from the open source community aspect of Dataverse, and the developer in our team has tremendously benefited from that, and also the ability to think of ways to improve our collection that we haven't initially thought, because we do see what other people are doing, and people are being very creative at ensuring that the data is as findable, accessible, reusable, and contains as much information as they can.
I think we've definitely benefited from the open source ecosystem, and starting from scratch anywhere else, we would not have gotten to the place that we were today. There's no question about it. So I think the fact that we were able to leverage everything that exists.
The reason I said from a user perspective, things are easy, is because (you) have decades of experience with that process, and I think it's felt both for me and for us, like partners in creating this sub-collection, but also for the user experience.
Columbia Climate School Center for Integrated Earth System Information (CIESIN) collection
"The CAFE team has been a lifesaver for the SEDAC data collection. Their careful attention to details has given us confidence that the collection is being handled in a trustworthy manner."
— Alex de Sherbinin, PhD, Director and Senior Research Scientist, Center for Integrated Earth System Information (CIESIN), the Columbia Climate School
Featured publication: Coexposure to extreme heat, wildfire burn zones, and wildfire smoke in the Western US from 2006 to 2020 (Science Advances, Vol. 11, Issue 18, 2025).
The dataset and code are publicly available and citable as follows:
Hu, Kate; Trisovic, Ana, 2023, "Co-exposure patterns of heat, wildfire, and wildfire smoke in Western US," https://doi.org/10.7910/DVN/9VDUAP, Harvard Dataverse
(KL): I'll start off with my experience in relation to using Dataverse first. I actually found it very easy to use overall, and specifically, I put up a few datasets myself, as well, and I think the first one maybe took me about 20 minutes to get through. And that was one of my larger datasets, from an India subcollection on air pollution (see CHAIR).
It was a really large dataset, and some of that time might have been the process and overall, I found the metadata really straightforward and easy to follow. I didn't need to use the tutorial from our team, I actually just wanted to try and practice it, and it was no problem for me at all.
In follow-up ones, I've actually posted a couple other ones that are related to some of the Google work that I've done, in terms of sharing our data that measures things like the time use of parks. That's two different examples of datasets, and it's quite simple to do. Once you've created the login, it's easy to do.
In terms of data uploading, I found it even a little bit easier than other generalist repositories. My prior combination of working with generalist repositories is predominantly only sharing through Figshare before working with Dataverse. I've used Dataverse prior to this in terms of extracting data. And that's what I can talk about next. So the sharing piece, I actually found it to be easy and very straightforward.
Now, in terms of pulling this dataset, I've been using Dataverse for over a decade, and I've actually been using it in my classes as well, where I also teach GIS. And one of the reasons why is because it's keyword term searchable, which makes it easy, and then you can start to navigate and use other terminology to break it down, through the filter and base process on its own. It's actually a resource that I've recommended my students use, to find data for projects, including the class I'm teaching right now, Introduction to GIS for Public Health Decision Making. Because researchers will put up usable datasets in this environment, and it's been sort of, like, a go-to place to find data. So, well before I ever even put.
CHAIR collection: https://dataverse.harvard.edu/dataverse/CHAIR
What could have made using the repository easier?
(KL): Some other generalist repositories that I commonly use as well are not purely open source, so that's the key distinction, and that's ArcGIS Online, where they're specifically built towards geospatial data because that's their environment, that they want to work in. This is something that I think Dataverse could improve, the spatial search engine component.
I've shared a lot of data through ArcGIS Online in the past and with that in mind, I was looking for my bounding box? Where do I tell it that this data is only specifically for Massachusetts or for one area in India? And you had to fit that metadata into things like keyword terms or other areas.
There weren't a lot of geospatial metadata options. And I didn't recognize the back end when I searched for data; it is more difficult for me to determine if this is a dataset that's built specifically for my area? Is this a country-wide dataset or something else? Which, naturally, is built into a lot of the geospatial repositories that are out there. You have to put up a dataset that explains explicitly the location and what the spatial scale is. You have to use keyword terms to search for spatial scale.
(JG): Earlier in 2025, I had the interesting experience of leading a number of Datathons where we developed processes, with the CAFE team, and sought to develop clear instructions for folks who had potentially never heard the words "generalist repository", never been on Dataverse, and maybe only had limited experience with data. And the fact that there's so much standardization on Dataverse made it so much easier to train people on how to upload data, how to input metadata, and made a process that would have been excruciating, feasible.
We were able to motivate folks who had limited experience interacting with data like this to help populate our collection and we're now at over 1,000 datasets in the CAFE data collection. Those (dataset deposit) templates come in handy.
Extracted Data Efforts
What was the motivation for using a generalist repository, and were there reasons for choosing the Harvard Dataverse Repository? Do you use it in combination with any other repositories?
(DB): The motivation was really, from a landscape analysis, realizing that there aren't a lot of alternatives, or there aren't any alternatives for topic-specific repositories in this space.
But that's not the only reason. The other reason is maybe more important, but our Community of Practice and the scope of CAFE as a coordinating center is extremely broad. It includes researchers that are doing pure environmental exposure modeling, those that are more focused on the health sides, those that are in kind of a very wide range of topics.
I think a generalist repository allows you to bring those together in a way through the collection. You can see that in our collection, there's really a large variety of data. I think that was a very strong motivator.
In terms of Harvard, specifically, we already had a partnership and history of collaborating with the IQSS team at Harvard, and it was wonderful to continue that work. We were funded before CAFE. We were funded on an administrative supplement with the Harvard Dataverse team, so we already have that established partnership, and we're able to continue with that, and it's been a wonderful experience. We don't use any repositories in combination with Harvard, but we do harvest data from other sources, so I think that's really important to know.
Why is it important that your data be made available, and how has sharing the data impacted your collaborations?
(DB): It's definitely accelerated our collaborations. I think it allowed collaborations that wouldn't have existed, to exist without barriers. And in terms of the impact of the research, it's amplified a lot of that impact. I would say it impacted the reproducibility of our research 100%. There's no question about it, especially with version controls.
(JG): It's so important for open science, and being on the internal data team, I don't have extensive research collaborations the way that Danielle does, but it certainly helps to be able to point potential collaborators to the repository of data, and it has been really gratifying to hear comments in the wild about the importance of initiatives like the CAFE collection.
(DB): I do want to say that I'm less involved with the conference dissemination side of this work, but Kevin Lane, who co-leads the data management function with me, has been super involved in that, and it's led to many cases where groups that he's meeting want to replicate this type of infrastructure and work.
And so even if initially they were proposing to host the data on their website, or to create a new portal, they're seeing how useful this is, and it's leading to a desire for others to use Dataverse. I think that in terms of collaboration, that also gives us opportunities to collaborate in that space. (Kevin) definitely has cases where projects didn't have Dataverse on their radar, and they saw this, and they all of a sudden do.
Has any reuse of the collection resulted in publications or trends? Trends in data access? CAFE data access?
(DB): We've definitely seen more of a peak in the last 6 months as we're establishing ourselves as a coordinating center, and as the needs of the community have changed, and the landscape of data in our community has changed. I think we are seeing that because we're seeing just the number of datasets increase, which is wonderful.
A good example of a reused dataset is one of our colleagues out of UW, Marissa Childs, Daily local-level estimates of ambient wildfire smoke PM2.5 for the contiguous US dataset.
https://dataverse.harvard.edu/dataset.xhtml?persistentId=doi:10.7910/DVN/DJVMTV
Please describe your experience submitting and sharing data via the repository.
Interview with Alexis Guanche and Emily Katz (Dataverse Team)
(AG): I love the (software) documentation, because everything is well documented, and every time I need to do something for the first time, or invest in researching how to do something, I always find the information.
As a developer, I have worked with tons of applications. Here, it was very helpful.
The API is my lifesaver and a game changer, because I always use the API to improve the workflow. For example, right now, I need to create 300 datasets, migrate data, so the API is very complete and robust, and allows me to do most of the work.
From my experience, I think one of the main challenges is the metadata. All the groups want specific metadata, and if we try to give them all the metadata they want, it could be complicated to manage. I have been learning about new AI process tools, and I started learning about generative UI, using AI to generate the interface for users. I think in the near future, we can implement some kind of custom metadata generated with AI, so we don't need to pre-generate or define the metadata and apply it and install it. Just having a tool, installed in the application to allow the team to ask for those metadata and define it, and create it.
With the geospatial (metadata) block—we already have one, and the team wants to use it, but they don't want to use it exactly how it's defined. They need to personalize it, change a few things, but we can't just change the standard block because it's a general block used across all the installations and collections.
Then the option becomes: create a custom block. But now we've got a custom block with basically the same fields we already have in the original one—just with a few tweaks.
And that's the balance we're trying to find: avoiding a proliferation of custom blocks and repeated metadata. Because it's not only extra work for us to build and maintain those blocks, it's also a burden on users—they end up filling out the same information again and again in different places.
(EK): For the most part, using the repository is pretty easy. You can upload a lot of data, which is nice, and the software allows you to change the file sizes the collection can support to upload large files.
In terms of the custom blocks that were created for CAFE, I think that it definitely offers a lot of extensive information, and I know that they modeled it after metadata that their researcher community was specifically targeting.
With geospatial data—and this is partly what we run into with custom metadata—I think it's really a metadata block issue. The coordinates are in the standard (metadata) block, sure, but the problem is that different programs measure and represent coordinates differently. If the metadata is just like, "here are the four coordinates," and then we try to map datasets across the board, it's not even on the same scale. And that's a real pain point for usability, because it's just not specific enough.
(AG): And that's exactly one of the problems I found migrating the coordinates between SEDAC and our system.
(EK): Another pain point for data sharing is the responsiveness of researchers. I think a lot of researchers don't include READMEs or data dictionaries, and that's a pretty common pain point that we're needing to go back and ask them for it.
Curation and development tasks specific to supporting data sharing for CAFE (GitHub)
- Visibility controls for dataset creation (major feature)
- Metadata improvements and custom blocks
- Ongoing operational support for the CAFE team
- "Metadata About Data Sources" redesign + full migration
- Previewers restored and deployed (H5Web + NcML)
- CAFE backup/mirroring research
- CIESIN/SEDAC subcollections ingest and rollout
- Compound metadata readability improvements
- Quality checklist custom block
- Metadata field usage analysis (SQL)
- Technical feasibility reviews
Connect with GREI
Stay in touch with the GREI repositories — ask questions, provide feedback, get updates, learn about future events:
- Join the GREI mailing list: groups.google.com/g/contactgrei
- Read the GREI blog: medium.com/@blog-grei
- GREI GitHub Repository: github.com/NIH-GREI/grei-pm
- GREI GitHub Community Discussion Board: github.com/NIH-GREI/grei-pm/discussions
Access all published GREI resources via the GREI Zenodo Community:
2026 Webinar Series — Streamlining Data Sharing: Practical Tools and Researcher Stories from the NIH GREI
A collaboration among Dataverse, Dryad, Figshare, Mendeley Data, OSF, Vivli, and Zenodo. Register for one or all, and share with researchers at your institutions!
| Webinar | Topic | Date |
|---|---|---|
| 1 | Simplifying Repository Selection with GREI's Flowchart and Comparison Chart | Wednesday, January 28, 2026, 1pm ET |
| 2 | Improving Data Sharing with GREI's Submission Checklist | Wednesday, February 11, 2026, 1pm ET |
| 3 | Strengthening Your DMS Plans with GREI's Practical Guide | Wednesday, February 25, 2026, 1pm ET |
Register here: bit.ly/GREIWebinars2026
GREI Use Cases are supported by the National Institutes of Health (NIH) Office of Data Science Strategy / Office of the NIH Director pursuant to OTA-21-009, "Generalist Repository Ecosystem Initiative (GREI)".