# How to Build a Research Collaboration Tool Stack: A Blueprint

A research collaboration tool stack is a deliberately chosen, coordinated set of software that covers the whole life of a scientific collaboration, while a random pile of apps is whatever each teammate installed on their own, which is why one supports the work and the other fragments it. The rule of thumb for choosing between research collaboration tool stack options is simple: start from the workflow you need to support, not from the tool you liked at your last job. Map the stages of a collaboration (finding partners, planning, writing, sharing data, tracking progress, evaluating the partnership), assign one tool per stage, and only add a new tool when a stage has no owner.

This article walks through how to build a research collaboration tool stack step by step. It explains each layer of a working stack, compares the main options side by side, works through realistic scenarios, and flags the mistakes that sink most teams before they write a single line of a shared manuscript.

## Why an Ad Hoc Collection of Apps Fails

Most research groups never sit down and design their collaboration tools. The stack assembles itself: one professor swears by a chat app, a postdoc keeps the project plan in a private spreadsheet, data lives on a departmental drive, and the manuscript travels as email attachments. Each individual choice looks reasonable. Together they create gaps.

The problem is structural, not personal. Scientific collaboration is increasingly a team activity that crosses institutions, disciplines, and career stages, and it needs deliberate support rather than goodwill alone. When investigators at the Research Centers in Minority Institutions tested a structured approach called strategic team science, the hands-on workshop format, which used structured dialogue, asset sharing, and systematic exploration of collaboration opportunities, drew more than 100 participants and led participants to share 35 resources they were willing to offer for prospective collaborative projects [1]. The lesson generalizes to software: collaboration works better when the structure is explicit. A tool stack is that structure, expressed in software.

## The Core Comparison: Layers of a Research Collaboration Tool Stack

The clearest way to compare research collaboration tools is by layer. Each layer answers one question about the collaboration. The table below is the core of this blueprint.

| Layer | Question it answers | Representative options | Pros | Cons | Best fit |
|--|--|--|--|--|--|
| Communication | How do we talk day to day? | Team chat apps, video conferencing, email lists | Fast, low cost, everyone knows how to use them | Conversations scatter across channels, decisions get lost | Every stack, as the [connective tissue](/knowledge/veterinary-medicine/veterinary-anatomy-physiology/connective-tissue-types-loose-dense-and-more) |
| Co-authoring and writing | Where does the manuscript live? | Cloud document editors, LaTeX collaboration platforms, wikis | Single current version, visible edit history, commenting | Feature-rich tools can overwhelm casual contributors | Any project with multi-author writing |
| Reference and literature management | How do we share and cite papers? | Open reference managers, commercial reference managers | Shared libraries, consistent citation styles | Sync conflicts when many people edit one library | Any writing project, especially large author teams |
| Project and task management | Who does what by when? | Kanban boards, shared task lists, Gantt-style planners | Visible ownership and deadlines, fewer status meetings | Dies quickly if nobody maintains it | Multi-site projects, grants with deliverables |
| Data, code, and version control | How do we share and track files and analysis? | Repository hosting platforms, institutional data stores, electronic lab notebooks | Full version history, attribution, reproducibility | Learning curve for non-programmers, access control takes planning | Computational work, data-intensive collaborations |
| Collaboration discovery | Who should we be working with, and who already has? | Institutional knowledge graphs built on publication databases, research networking profiles | Finds non-obvious partners based on actual co-authorship and topic links | Needs institutional investment and clean data | Institutions, large consortia, new investigators mapping a field |
| Structured evaluation and reflection | How do we know the collaboration is working? | Peer assessment rubrics, weekly self-report templates, engagement evaluation frameworks | Surfaces problems early, documents process for funders | Feels like overhead if imposed without buy-in | Team science programs, teaching labs, patient-engaged research |
| AI assistance | Where can machine help accelerate the work? | Large language model assistants, AI-supported analysis tools | Speeds drafting, summarizing, and exploration | Accuracy and provenance require checking, journal policies vary | Mature stacks that already have version control in place |

Read the table top to bottom and you have the minimum viable stack for most academic teams. Read it left to right for any single layer and you have the pros and cons that decide which specific product fits your group.

## Layer by Layer: What Each Tool Type Actually Does

### Communication Tools

Communication is the layer teams adopt first and think about last. A shared channel beats a private inbox because it makes context available to everyone who joins later. The tradeoff is fragmentation: without channel naming conventions and a rule about what belongs in email versus chat, important decisions disappear into scrollback. Keep one canonical place for decisions (usually the project management layer or a pinned document) and treat chat as conversation, not record.

### Co-Authoring and Writing Tools

Co-authoring tools replace the manuscript version spiral, where draft_v7_FINAL_rev2.docx circulates by email. A cloud document or a LaTeX collaboration platform keeps one current version, records who changed what, and lets a senior author comment in place. The design principle that matters here comes from usability research on shared scientific tools: iterative testing with real users beats assumptions. When researchers built and evaluated CrossGenomics, a tool for comparing personal genetic reports, they ran three user studies and revised the prototype between them, and the visual comparison designs outperformed the linear one on domain comprehension [2]. Apply the same discipline to your writing stack. Watch how a new co-author actually uses the shared document in week one, then adjust.

### Reference and Literature Management

A shared reference library is a small investment with a large payoff. The choice inside this layer is mostly between open tools with strong community plugin ecosystems and commercial tools with polished sync services. What matters more than the brand is the rule that one person owns the library structure and everyone else follows it. Duplicated and inconsistent reference libraries are among the most common friction points in multi-author manuscripts.

### Project and Task Management

This layer answers the question that kills more collaborations than any technical problem: who was supposed to do that, and by when? Kanban boards work well for experimental pipelines with repeating stages. Task lists with due dates work better for milestone-driven projects such as grant deliverables. The failure mode is not choosing the wrong tool, it is maintaining none. A task board nobody updates is worse than a whiteboard, because people trust it and stop communicating.

### Data, Code, and Version Control

For computational and data-intensive collaborations, version control platforms are non-negotiable. They record every change to analysis code, support review before merging changes, and make results reproducible months later. For wet-lab and clinical data, electronic lab notebooks and institutional data stores play the equivalent role, with the added requirement of access control that matches your data governance rules.

The value of this layer extends beyond a single project. At Georgia Institute of Technology, researchers built a knowledge graph of institutional publications using the Neo4j graph database, processing data from OpenAlex, a free catalog of scholarly publications. The production database reached 471,396 nodes and 2,155,302 relationships connecting authors, co-authors, institutions, and works. That is what the discovery layer looks like when data infrastructure is done well, and it depends on the same underlying discipline: clean, linked, findable records of who did what.

### Collaboration Discovery Tools

Discovery tools help you answer "who should I be working with?" using evidence instead of hallway reputation. Publication-based knowledge graphs and research networking profiles surface co-authorship patterns and topic connections that are hard to see by hand. Georgia Tech's system, for example, links authors to the institutions they have worked at, the papers they have authored, and the outside institutions they have collaborated with, giving the university a structured view of its own collaboration effort. For a graduate student or a new principal investigator, the equivalent lightweight option is a well-maintained research profile and a habit of checking who is actually publishing at the intersection of your interests.

### Structured Evaluation and Reflection Tools

This is the layer most teams skip, and skipping it is expensive. Evaluation tools are the instruments that tell you whether the collaboration itself is healthy.

They take several forms. Peer assessment instruments such as the Peer Assessment Collaboration Evaluation tool measure how members experience working with each other, and studies of faculty acceptance of that specific tool show that structured collaboration assessment can gain real adoption among professionals [4]. Weekly self-report templates borrowed from design education, called Project Process Cards, ask each member to log activities and reflections on a short digital form. When 101 industrial design students produced 563 of these cards across studio courses, the cards served students as a self-reflection device and served instructors as a documentation and communication medium [5]. The same mechanism transfers directly to research teams: a two-minute weekly log per person creates a running record of what happened and how it felt.

Evaluation also extends to how you appraise the evidence the collaboration produces. Standardized quality assessment tools exist for exactly this purpose, and the choice among them matters. A methodological comparison of the Cochrane Collaboration Risk of Bias Tool against the Effective Public Health Practice Project Quality Assessment Tool examined how each appraises study quality for systematic reviews, and later work showed that assessments from different standard tools, CASP and EPHPP, did not align well enough to be used interchangeably when judging research intended to benefit Indigenous communities [6][7]. The practical rule for your stack: pick one quality appraisal tool per evidence type, document the choice, and apply it consistently.

### AI Assistance Tools

AI assistants have moved from novelty to default in many writing and analysis workflows, and your stack should decide deliberately where they are and are not allowed. The scale of adoption is visible in journal data. A retrospective analysis of 390 articles submitted to the journal Orthopaedics and Traumatology: Surgery and Research, comparing 204 submissions from January through March 2022 with 186 from the same months of 2023, documented a significant increase in AI-generated text after the release of ChatGPT, measured with a detection tool [8]. Whether or not a given submission used AI well is a separate question, and that is the point: research on human-AI collaboration shows that the quality of the interaction, not just the model, determines the outcome. A 2026 study of an interactive LLM-based research tool for scenario-based experiments found that integrating experimental variables into a dynamic chatbot setting preserved both experimental precision and realism, and validated the approach against responses from 222 mid-level managers [9]. For a research team, the takeaway is that AI tools deserve the same treatment as any other layer: a defined scope, tested workflows, and evaluation of whether the output is actually usable.

One warning applies specifically to AI-enabled measurement and analysis tools. Accuracy claims must be checked in your own setting. When clinicians evaluated PainChek Infant, an mHealth tool that uses artificial intelligence to detect infant pain from facial expression, they ran receiver operator characteristic analysis in their own immunization clinic context and reported high accuracy, with area under the curve values of 0.964 and 0.966 for the Standard and Adaptive modes [10]. That kind of local validation, not the vendor's marketing, is what justifies a tool's place in a clinical research workflow.

## How to Choose: The Criteria That Decide Real Choices

![A three-question decision path that ends in adding a tool only when a workflow stage has no owner.](/article-images/illustrations/research-collaboration-tool-stack-tool-choice-triage.webp)

Feature lists do not decide tool selections. Five criteria do.

**1. Adoption friction.** A tool nobody opens is a liability with a login page. Implementation research explains why tools fail after purchase. In a qualitative evaluation of asthma management resources in Australian primary care, focus groups with 57 participants across seven sessions found that a resource implemented passively, the Asthma Action Plan card, suffered from a significant lack of awareness, while a guideline that pharmacists already knew had better uptake, and the barriers sorted cleanly into knowledge, attitude, and behavior categories [11]. Translate that to your stack: a tool that arrives as an announcement email, with no training, no champion, and no change to anyone's routine, will fail the same way.

**2. Implementation fidelity, not just intent.** Having the tool and using the tool as designed are different things. The Australian GRACE Risk Tool Implementation Study embedded a structured risk-stratification tool in 12 hospitals and later interviewed 16 local implementation stakeholders across five of them, using the Capability, Opportunity, Motivation and Behavior model to understand what helped and what hindered use, and the process evaluation found that tool use enhanced physical capability but overall impact on outcomes was neutral, partly tied to how faithfully the tool was implemented [12]. The lesson for collaboration stacks is sobering: a good tool deployed without workflow integration can produce no measurable benefit. Budget time for integration, not just installation.

**3. Access control and data governance.** Who can see what, at which institution, under which agreement. Multi-institution projects need this answered in writing before the first dataset moves. Community-driven projects add another dimension: when the people the research serves participate in the tool itself, governance becomes part of the design. A protocol for co-creating a digital knowledge translation tool with parents of children with functional constipation explicitly set out to establish the research collaboration with patients and formally evaluate the engagement processes, because little was known about how effective patient collaborations are built, maintained, or improved [13]. If your stack will include external partners, plan their access as carefully as your own.

**4. Integration and exit.** Tools that talk to each other reduce copy-paste labor. Tools that lock your data in make departures painful. Before adopting anything, check what exports look like and whether the data format is open. This is also where open source and community-driven options earn their place. The psoriasis self-management tool developed in collaboration with an internet-based self-help community used two user surveys to gather feature requirements from community members before development, then ran a 21-day pilot with usability questionnaires, showing that community-driven development produces tools people actually accept [14]. Open, community-anchored tools tend to survive personnel turnover in a way that single-lab favorites do not.

**5. Fit to the evaluation you will actually run.** Decide up front how you will know the stack is working. Free tool options also carry a validation obligation. LIBRA, a publicly available tool for automated breast density measurement from mammograms, was validated against commercially available software and standard BI-RADS reader estimates in a case-control study of 106 cases and 318 controls, and its measures remained significantly associated with breast cancer after adjustment [15]. Free does not mean unvalidated, and commercial does not mean validated. What matters is whether validation evidence exists and fits your use case.

## Worked Scenarios

### Scenario A: Two Labs at Different Universities

A [cell biology](/blog/careers/cell-biology) lab and a computational lab start a joint project. The workflow needs are modest: shared writing, shared data, weekly syncs, clear task ownership. A sensible stack is one team chat workspace, one cloud document for the manuscript with a separate cloud document for the analysis plan, a version control repository for code with a protected main branch, a shared task board with one owner per card, and a decision log pinned in the chat. Skip the discovery and formal evaluation layers until the collaboration grows. Add a simple weekly self-report only if progress stalls.

### Scenario B: A Multi-Center Clinical Consortium

Eight hospitals coordinate a study. Here access control, governance, and structured evaluation are mandatory, not optional. Each site needs defined roles in the data platform. Standardized instruments must be chosen and documented, and the LIBRA precedent [15] shows the pattern: automated or standardized tools should be validated against an established comparator before results are pooled. Borrow the process evaluation mindset from the GRACE study [12]: plan from the start to interview site staff about how the tools are actually being used, because fidelity gaps will otherwise stay invisible until the results disappoint.

### Scenario C: Co-Designing a Tool With Patients or a Community

If the collaboration includes the people the research serves, the stack must support engagement, not just productivity. Two published examples show the pattern. The pediatric constipation protocol made the patient-researcher collaboration itself a formal object of study, cocreating a digital knowledge translation tool with parents and evaluating the engagement process [13]. The psoriasis project ran two surveys with an existing online self-help community to define requirements, then a 21-day pilot measuring quality of life with the Dermatology Life Quality Index at the start and end, followed by usability questionnaires [14]. The stack in both cases combined surveys, structured feedback channels, and outcome instruments, all chosen before development began.

### Scenario D: Adding an AI Collaborator

A team wants to use a large language model assistant for drafting and data exploration. Sequence matters. Establish the version control and documentation layers first so that AI-assisted changes are traceable. Define where AI output may appear (internal summaries yes, submitted text per journal policy). Then evaluate the human-AI interaction itself rather than assuming it works. The ecological validity research on LLM-based collaboration tools [9] demonstrates that how humans engage with AI tools can be studied rigorously, and the orthopedic journal data [8] shows that adoption can change dramatically within a single year, so treat your AI policy as a living document.

## Common Mix-Ups

![A comparison of four tool pairs, showing what each side does, what it is not, and what goes wrong when the two are mixed up.](/article-images/illustrations/research-collaboration-tool-stack-mixups-compared.webp)

Confusing these tool categories wastes money and months. The most frequent ones:

- **Discovery versus project management.** A collaboration discovery tool tells you who to work with. A project management tool tells you who does what now. A knowledge graph of co-authorship [3] will never replace a task board, and a task board will never introduce you to a collaborator.
- **Quality appraisal versus team evaluation.** Risk of bias and study quality instruments such as the Cochrane tool and EPHPP [6] judge published evidence. Peer assessment and process-card tools [4] judge your own team's working process. Teams sometimes import one vocabulary into the other and end up "assessing bias" in their postdocs or applying publication rubrics to meeting notes.
- **Communication versus record.** Chat is conversation. The decision log, the analysis plan, and the task board are the record. Teams that treat chat history as documentation lose decisions in scrollback within weeks.
- **Adoption versus implementation.** Buying the tool is adoption. Using it as designed, inside the workflow, is implementation, and the gap between them is where benefits evaporate [12][11].
- **AI detection versus AI policy.** Detection statistics such as the rise in AI-flagged text across 390 journal submissions [8] describe a trend, not a rule for your team. A written, human-owned policy on where AI may contribute is what governs your own workflow.

## Common Mistakes and Limitations

**Mistake 1: Designing the stack around the loudest person's preference.** The tool stack should follow the mapped workflow. If a layer has no clear owner, the fix is a process conversation, not another subscription.

**Mistake 2: Skipping the evaluation layer entirely.** Teams that never measure their own collaboration discover dysfunction only when a manuscript stalls or a grant report is due. Lightweight instruments such as weekly process cards [5] and peer collaboration assessments [4] exist precisely to catch this early.

**Mistake 3: Passive rollout.** Announcing a new tool and expecting adoption mirrors the passive implementation that left the Asthma Action Plan card largely unknown among the very professionals meant to use it [11]. Every layer needs a named champion, a short training moment, and a change to an existing routine.

**Mistake 4: Assuming one tool fits all evidence types.** The finding that CASP and EPHPP quality assessments did not align and could not be used interchangeably [7] applies by analogy across the stack. Tools encode assumptions. Match the instrument to the purpose and stick with it consistently.

**Mistake 5: Adopting AI without traceability.** An AI assistant used outside a version-controlled, documented workflow produces work nobody can audit or reproduce. Sequence the AI layer last, after the foundation layers hold.

**Mistake 6: Ignoring maintenance cost.** Every layer has a maintenance owner. Reference libraries need curation, task boards need grooming, knowledge graphs need data pipelines like the OpenAlex-based feed behind Georgia Tech's system. If nobody owns maintenance, the stack decays into the ad hoc pile you started with.

**Limitations.** Tool ecosystems change quickly, so specific product recommendations age faster than the layer structure presented here, which is why the blueprint emphasizes categories and criteria. Multi-institution data governance, human-subjects protections, and institutional information security policies impose requirements this general blueprint cannot anticipate, and individual projects need input from their own compliance and data stewardship offices before any tool touches regulated data.

## Frequently Asked Questions

### What is a research collaboration tool stack?

It is a coordinated set of software tools that together cover the full life cycle of a scientific collaboration, from finding partners to writing, data sharing, task tracking, and evaluating the partnership. The key word is coordinated: each layer has one tool, one owner, and a defined role.

### What is the best research collaboration tool stack for a small lab?

The smallest stack that covers every workflow stage: a team chat workspace, one co-authoring platform, one shared reference library, one task board, and a version control repository if any analysis is computational. Add layers only when a real need appears, because every additional tool carries adoption and maintenance costs.

### How do I choose between research collaboration tool stack options?

Score each option on five criteria: adoption friction, implementation support, access control and data governance, integration and exit paths, and fit to the evaluation you plan to run. A tool that wins on features but loses on adoption friction will not deliver value, as implementation research on health tools repeatedly shows [11][12].

### How many tools should a research collaboration stack have?

Between five and eight, one per layer, with communication and co-authoring counted as the mandatory core. More than that and context fragments across apps. Fewer than that and some workflow stage, usually evaluation or version control, goes unsupported.

### Can AI tools be part of a research collaboration tool stack?

Yes, as a defined layer with boundaries. Set a written scope for where AI output may appear, keep AI-assisted work inside version control so it stays traceable, and validate AI-enabled tools in your own setting before relying on them, as clinical evaluations of AI assessment tools demonstrate [10]. Expect the landscape to shift quickly, given how fast AI text appeared in journal submissions between 2022 and 2023 [8].

### How do I evaluate whether my collaboration tool stack is working?

Use lightweight, structured instruments rather than impressions. Weekly self-report cards from each team member create a running process record [5], peer collaboration assessments capture how members experience the teamwork [4], and periodic process interviews with team members reveal fidelity gaps between intended and actual use, the approach used in the GRACE implementation evaluation [12].

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is a research collaboration tool stack?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "It is a coordinated set of software tools that together cover the full life cycle of a scientific collaboration, from finding partners to writing, data sharing, task tracking, and evaluating the partnership. The key word is coordinated: each layer has one tool, one owner, and a defined role."
      }
    },
    {
      "@type": "Question",
      "name": "What is the best research collaboration tool stack for a small lab?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "The smallest stack that covers every workflow stage: a team chat workspace, one co-authoring platform, one shared reference library, one task board, and a version control repository if any analysis is computational. Add layers only when a real need appears, because every additional tool carries adoption and maintenance costs."
      }
    },
    {
      "@type": "Question",
      "name": "How do I choose between research collaboration tool stack options?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Score each option on five criteria: adoption friction, implementation support, access control and data governance, integration and exit paths, and fit to the evaluation you plan to run. A tool that wins on features but loses on adoption friction will not deliver value, as implementation research on health tools repeatedly shows."
      }
    },
    {
      "@type": "Question",
      "name": "How many tools should a research collaboration stack have?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Between five and eight, one per layer, with communication and co-authoring counted as the mandatory core. More than that and context fragments across apps. Fewer than that and some workflow stage, usually evaluation or version control, goes unsupported."
      }
    },
    {
      "@type": "Question",
      "name": "Can AI tools be part of a research collaboration tool stack?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes, as a defined layer with boundaries. Set a written scope for where AI output may appear, keep AI-assisted work inside version control so it stays traceable, and validate AI-enabled tools in your own setting before relying on them, as clinical evaluations of AI assessment tools demonstrate. Expect the landscape to shift quickly, given how fast AI text appeared in journal submissions between 2022 and 2023."
      }
    },
    {
      "@type": "Question",
      "name": "How do I evaluate whether my collaboration tool stack is working?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Use lightweight, structured instruments rather than impressions. Weekly self-report cards from each team member create a running process record, peer collaboration assessments capture how members experience the teamwork, and periodic process interviews with team members reveal fidelity gaps between intended and actual use."
      }
    }
  ]
}
</script>

## Sources

1. [Strategic Team Science Promotes Collaboration and Practice-Based Research at the Research Centers in Minority Institutions](https://pubmed.ncbi.nlm.nih.gov/36981709/)
2. [Exploring Genetic Data Across Individuals: Design and Evaluation of a Novel Comparative Report Tool](https://pubmed.ncbi.nlm.nih.gov/30249582/)
3. [Research Collaboration Discovery through Neo4j Knowledge Graph](https://doi.org/10.1145/3626203.3670539)
4. [Faculty acceptance of the peer assessment collaboration evaluation tool: a quantitative study](https://doi.org/10.1007/s11423-020-09742-z)
5. [Project Process Cards: A Self Evaluation Tool for Design Studio](https://doi.org/10.21606/learnxdesign.2019.01125)
6. [Assessment of study quality for systematic reviews: a comparison of the Cochrane Collaboration Risk of Bias Tool and the Effective Public Health Practice Project Quality Assessment Tool: methodological research.](https://pubmed.ncbi.nlm.nih.gov/20698919/)
7. [Comparison of Study Quality as Determined by Standard Research and Community Engagement Metrics: A Pilot Study on Breast Cancer Research in Urban, Rural, and Remote Indigenous Communities](https://pubmed.ncbi.nlm.nih.gov/35564401/)
8. [Evaluation of the impact of Large Language Learning Models on articles submitted to Orthopedics & Traumatology: Surgery & Research (OTSR): A Significant Increase in the Use of Artificial Intelligence in 2023.](https://pubmed.ncbi.nlm.nih.gov/37866509/)
9. [Enhance ecological validity of scenario-based experiments on human-AI collaboration: evidence from an interactive LLM-based research tool](https://doi.org/10.1108/jrim-09-2025-0531)
10. [The Clinical Suitability of an Artificial Intelligence-Enabled Pain Assessment Tool for Use in Infants: Feasibility and Usability Evaluation Study](https://pubmed.ncbi.nlm.nih.gov/36780223/)
11. [A qualitative evaluation of the implementation of guidelines and a support tool for asthma management in primary care](https://pubmed.ncbi.nlm.nih.gov/27965776/)
12. [Objective risk assessment vs standard care for acute coronary syndromes-The Australian GRACE Risk tool Implementation Study (AGRIS): a process evaluation](https://pubmed.ncbi.nlm.nih.gov/35317816/)
13. [An Evaluation of Parents’ Experiences of Patient Engagement in Research to Develop a Digital Knowledge Translation Tool: Protocol for a Multi-Method Study](https://pubmed.ncbi.nlm.nih.gov/32663147/)
14. [A German Smartphone-Based Self-management Tool for Psoriasis: Community-Driven Development and Evaluation of Quality-of-Life Effects](https://pubmed.ncbi.nlm.nih.gov/35797109/)
15. [Preliminary evaluation of the publicly available Laboratory for Breast Radiodensity Assessment (LIBRA) software tool: comparison of fully automated area and volumetric density measures in a case-control study with digital mammography](https://pubmed.ncbi.nlm.nih.gov/26303303/)