New pipeline: nf-core/musa

[davide-scognamiglio]

Pipeline title/name

musa (multi-source variant annotation)

Keywords

clinical genomics, variant annotation, ACMG classification, FAIR data

What is it about?

MuSA (Multi-Source variant Annotation) is a Nextflow pipeline designed for large-scale, multi-tool variant annotation and interpretation in clinical and research genomics.
It automates the integration of multiple annotation engines and databases to produce standardized, high-quality variant annotations, ACMG-based classifications, and VUS reclassification in a fully reproducible and scalable fashion.

MuSA bridges the gap between raw variant calls and clinical interpretation by harmonizing the outputs of different tools such as VEP, ANNOVAR, Genebe, and RENOVO into unified, standardized MAF outputs.
Its modular design supports diverse data sources, reproducible database updates, streamlining the entire variant interpretation workflow.

Please provide a schematic diagram of the proposed pipeline

I confirm my proposed pipeline will follow nf-core guidelines. Most importantly, my pipeline will:

• be built with Nextflow.
• pass nf-core lint tests and use standardized parameters.
• be community-owned and developed within the nf-core organization.
• open source under the MIT license with proper credits and acknowledgments.
• have a descriptive, all lowercase, and without punctuation name.
• use the nf-core pipeline template and predominantly use official nf-core modules.
• focus on a specific data/analysis type with appropriate scope.
• have properly maintained documentation.
• be bundled using versioned Docker/Singularity containers.

Why do we need a new pipeline?

Variant interpretation remains a major bottleneck in clinical genomics. Existing online annotation tools often process single variants, while the mentioned local tools require extensive manual setup, making large-scale or reproducible analyses difficult.
Current workflows lack integration, resulting in fragmented outputs and inconsistent ACMG classification strategies.

MuSA addresses these needs by:

• Combining complementary annotation tools (VEP, ANNOVAR, Genebe, RENOVO) into a unified, automated pipeline.
• Enabling standardized, multi-sample outputs in MAF format compatible with downstream tools like maftools.
• Providing automated ACMG classification with rule-level evidence and customizable reclassification using machine learning.
• Supporting flexible integration of patient metadata (HPO, relation to proband) for phenotype-driven variant prioritization.
• Managing database downloads automatically for full reproducibility.

MuSA therefore provides a single, modular, FAIR-compliant workflow for scalable variant interpretation — a key unmet need in the clinical genomics community.

To our knowledge, there is no nf-core pipeline specifically dedicated to comprehensive, multi-source variant annotation and ACMG-based interpretation.

While nf-core/sarek is an excellent, widely used workflow for variant calling and upstream processing (from FASTQ to VCF), its annotation component is relatively general and not designed for deep, multi-database interpretation.
MuSA, in contrast, is specifically built for annotation and interpretation, integrating dozens of external databases, over 40 VEP plugins, and dedicated modules for ACMG classification, variant prioritization, and VUS reclassification.

MuSA is therefore complementary to sarek and to many other "all in one" variant calling pipelines: it focuses exclusively on the high-resolution, clinical-grade annotation layer that follows variant calling. We believe its scope, depth, and specialized outputs go well beyond what any other pipeline is intended to provide, making it a robust standalone solution for downstream interpretation.

Who would be interested?

• Clinical genomics and molecular diagnostics researchers
• Bioinformaticians performing germline or somatic variant interpretation
• Institutions aiming to standardize annotation workflows across projects
• Developers and users of ACMG classification and variant reclassification tools

What has been done so far

A complete germline module (v1.0) is implemented and tested, integrating VEP, ANNOVAR, Genebe, and RENOVO.

The pipeline currently produces:

• ACMG-focused MAF file highlighting clinically relevant variants.
• Phenotype-based filtered MAF file, when HPO terms are provided.
• Raw MAF file with complete annotations (up to 700 columns).
• Interactive HTML report summarizing results and including maftools plots and tables.

A setup workflow for automated database downloads is already implemented; a somatic (cancer) module (v2.0) will be introduced, expanding MuSA’s scope to oncology applications. 

Note: some databases require users to provide their own free license or API access credentials prior to download.

URL to existing work (if applicable)

No response

Are there any similar existing nf-core pipelines?

sarek

[nf-core-bot]

Approval status: 🕐 Pending

Required approvals: Either 2 core team members OR 1 core team member + 1 maintainer

Review Status	Team members
🕐 Pending (Core)	@ewels, @maxulysse, @mribeirodantas, @mashehu, @JoseEspinosa, @mirpedrol, @FriederikeHanssen, @kenibrewer, @jfy133, @edmundmiller, @sateeshperi, @FranBonath, @christopher-hakkaart, @nvnieuwk
🕐 Pending (Maintainer)	@pontus, @maxulysse, @lpantano, @pinin4fjords, @mashehu, @JoseEspinosa, @mirpedrol, @GallVp, @FloWuenne, @matthdsm, @FriederikeHanssen, @adamrtalbot, @mahesh-panchal, @jfy133, @atrigila, @prototaxites, @ramprasadn, @edmundmiller, @luisas, @SPPearce, @vagkaratzas, @sateeshperi, @jonasscheid, @famosab, @nictru, @itrujnara, @LouisLeNezet, @Joon-Klaps, @jasmezz, @Felix-Kummer, @sofstam, @nvnieuwk

[nf-core-bot]

Approval status: 🕐 Pending

Required approvals: Either 2 core team members OR 1 core team member + 1 maintainer

Review Status	Team members
🕐 Pending (Core)	@ewels, @maxulysse, @mribeirodantas, @mashehu, @JoseEspinosa, @mirpedrol, @FriederikeHanssen, @kenibrewer, @jfy133, @edmundmiller, @sateeshperi, @FranBonath, @christopher-hakkaart, @nvnieuwk
🕐 Pending (Maintainer)	@pontus, @maxulysse, @lpantano, @pinin4fjords, @mashehu, @JoseEspinosa, @mirpedrol, @GallVp, @FloWuenne, @matthdsm, @FriederikeHanssen, @adamrtalbot, @mahesh-panchal, @jfy133, @atrigila, @prototaxites, @ramprasadn, @edmundmiller, @luisas, @SPPearce, @vagkaratzas, @sateeshperi, @jonasscheid, @famosab, @nictru, @itrujnara, @LouisLeNezet, @Joon-Klaps, @jasmezz, @Felix-Kummer, @sofstam, @nvnieuwk

[itrujnara]

To avoid confusion: this pipeline is designed to run downstream of sarek? If so, there would be no obvious clash as far as I know. You should think more about the name, though, unless the acronym is standard in the domain, and I'm unfamiliar with it. While bioinformaticians appreciate creativity, names in nf-core should first and foremost make the purpose of the pipeline clear.

[mapo9]

@famosab , @YussAb this goes into the direction of nf-core/variantprioritization I think?

[davide-scognamiglio]

To avoid confusion: this pipeline is designed to run downstream of sarek? If so, there would be no obvious clash as far as I know. You should think more about the name, though, unless the acronym is standard in the domain, and I'm unfamiliar with it. While bioinformaticians appreciate creativity, names in nf-core should first and foremost make the purpose of the pipeline clear.

Yes, musa is designed to work downstream of various variant calling pipelines, including nf-core/sarek, Illumina DRAGEN, and Ion Torrent Variant Caller.
As for the name, while we are quite attached to musa — it has been the project’s original name since the early stages of development — we are absolutely open to considering a more descriptive alternative if the community feels it would better reflect the pipeline’s purpose.

[davide-scognamiglio]

@famosab , @YussAb this goes into the direction of nf-core/variantprioritization I think?

That’s a very good point!
While nf-core/variantprioritization deals with cancer predisposition analysis, musa is entirely centered on comprehensive germline variant interpretation.

In addition, MuSA includes a dedicated setup workflow that automatically downloads and configures a wide range of databases and VEP plugins, a process that is notoriously complex to implement manually. We carefully reviewed all available plugins, selecting only the well-maintained ones and updating the documentation for those less actively supported, effectively taking care of much of the “painful” setup work so users don’t have to.
This enables a very deep and comprehensive annotation layer out of the box.

[YussAb]

Hi everyone,
I agree with @mapo9 — this pipeline mostly overlaps with nf-core/variantprioritization.
We are currently working on developing a comprehensive annotation subworkflow that largely encompasses your steps, except for ANNOVAR + Renovo, which is new to me.
Nevertheless, we’d be happy to have a dedicated discussion to understand whether your workflow could fit within nf-core/variantprioritization.
Fell free to write on the nf-core slack at #variantprioritization :)

[davide-scognamiglio]

Hi everyone, I agree with @mapo9 — this pipeline mostly overlaps with nf-core/variantprioritization. We are currently working on developing a comprehensive annotation subworkflow that largely encompasses your steps, except for ANNOVAR + Renovo, which is new to me. Nevertheless, we’d be happy to have a dedicated discussion to understand whether your workflow could fit within nf-core/variantprioritization. Fell free to write on the nf-core slack at #variantprioritization :)

I had a look at the variantprioritization repository, and from what I can see, I don’t think there’s a significant overlap.
Could you please share more details about the specific steps, tools, and databases included in your annotation workflow? That would help us better understand where the two pipelines might intersect.

From the current description, the germline component of variantprioritization appears to focus mainly on cancer predisposition analysis (“nf-core/variantprioritization offers germline SNVs/INDELs interpretation and annotation using the Cancer Predisposition Sequencing Reporter (CPSR)”).
Even if the annotation layer is being expanded, the pipeline still seems primarily oriented toward cancer-related genes.

Musa, on the other hand, is designed for a more comprehensive germline interpretation scope, providing a deeply detailed annotation layer that extends well beyond cancer predisposition and can operate as a standalone post-calling annotation workflow.

As for Renovo, you can find a detailed description of how it works here:
https://www.sciencedirect.com/science/article/pii/S000292972100094X

[YussAb]

As I wrote before, “We are currently working on developing a comprehensive annotation subworkflow that largely encompasses your steps.”
If you would like more details, feel free to reach out to us on Slack in the #variantprioritization channel. There you’ll find plenty of information about what we’re currently developing.
We’ll be happy to clarify any of your doubts and hopefully cooperate and work together in a common direction.

[mapo9]

Maybe to clarify a little what the initial idea of nf-core/variantprioritization was:
When we started the draft of variantprioritization the idea was to build a pipeline that is extensible to different prioritization approaches, which is also why we kept the name so open.
So, the focus of the pipeline isnt AMP guidelines based cancer analysis, it was the first part that @YussAb integrated in the last months.
From what we discussed I think it would be great to combine the approaches in seperate subworkflows of the pipeline as an ACMG guided, cancer unrelated variant prio workflow, is definitely missing.

[Emanuele992]

Together with Davide I’m developing musa, and I’d like to address your points.
We didn’t see your nf-core pipeline before starting, and to be frank, even if we had, its current scope wouldn’t have matched our needs.
Musa is not just an annotation/prioritization flow: it includes a substantial setup and testing workflow (not visible in the current diagram—we’ll add it shortly) that isn’t straightforward to integrate into another pipeline. Our emphasis is on deep annotation and VUS handling, not only classification. We systematically reviewed VEP plugins, selected and integrated the most relevant ones, and we also incorporate tools like ANNOVAR and RENOVO.
Given where musa stands today, it’s more practical for us to extend it to somatic analysis than to build a sub-workflow within your pipeline from scratch.
In short, even if both projects touch annotation and prioritization, the design, goals and architecture differ, so a direct comparison isn’t very meaningful, and integration doesn’t seem viable at this stage.

[itrujnara]

Given the complexity of the situation, I suggest that you arrange a meeting of the 2 teams, have an in-depth discussion on each project's priorities, and provide a joint opinion on whether there should be 1 or 2 pipelines.

[kenibrewer]

Hi @davide-scognamiglio and @Emanuele992 . Thanks for your submission. We're excited that you are interested in contributing a project to nf-core. I'm a member of the nf-core/core team on call this week, and wanted to step in with some guidance on this proposal.

The risks of developers working on overlapping, non-compatible pipelines is the main reason we advise developers to bring pipeline ideas to nf-core as early as possible. As a reminder, nf-core isn't a pipeline publishing warehouse; it's an open-source community where the principles of building in the open and working collaboratively are just as important as the quality of the pipelines we maintain.

Things are missing from this application that will be required for us to make a decision on your pipeline:

• Please publish your existing pipeline code in a personal code repository and provide a link here.
• Please provide the updated schematic diagram with the setup and testing workflows that distinguish your pipeline from nf-core/variantprioritization.
• Please suggest a name that meets nf-core standards for clearly communicating the purpose.
• As suggested by @itrujnara, please have a meeting with the developers of nf-core/variantprioritization to discuss the vision and directions of your two projects and try to come to a consensus about whether it makes sense to join forces.

To set expectations, given the substantial overlap with the scope of nf-core/variantprioritization, I personally would be unlikely to support this as a separate pipeline. Even if your pipeline is further along than the community's existing pipeline, we would likely support the development of our existing project because, based on our experience, pipelines developed through this community-first approach have significantly better longevity than those developed by a team at a single institution.

For me, the one exception where I personally would support an additional pipeline in this area would be if you and nf-core/variantprioritization decide to tackle somatic and cancer separately. We've seen from nf-core/sarek that adding too many different purposes to a single pipeline can result in challenges around maintainability and extensibility. That would be a reasonable rationale in my view for why two pipelines might be justified.