Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide mechanism to consolidate several pipelines into a single report #96

Open
Bisaloo opened this issue Jun 14, 2023 · 2 comments
Open

Comments

@Bisaloo
Copy link
Member

Bisaloo commented Jun 14, 2023

Following #95, it would be good to provide a way to stitch / consolidate pipelines into a single report.

After #95, the "middle-task" pipelines, such as the transmissibility pipeline (Rt estimation) or the severity pipeline (CFR) estimation will start directly from incidence data.

But users might have linelist data instead and still want to go all the data until Rt estimation. In this situation, it would be helpful to provide a way to consolidate the "data preparation / descriptive epi" and the "transmissibility" pipeline into a single report, going all the way from linelist import to Rt estimation.

The way we achieve this has strong implications in terms of package interface and sustainability so the choice needs to be carefully thought through.

@avallecam
Copy link
Member

Hi Hugo, thanks for opening this issue.

I want to relate this discussion with the "modular" approach to generating reports, as commented in #41. A feature like this could provide flexibility to the user to join any input-package-output as needed. Splitting the current pipeline will be a great opportunity to add output connections to new and current report pieces.

In parallel, the package (or platform) can provide pre-defined pipelines, given their popularity and usability, or reuse those made by others (like in moveapps shared by @pratikunterwegs ).

@Bisaloo
Copy link
Member Author

Bisaloo commented Jun 15, 2023

Plugging here the roadmap I had in mind initially: epiverse-trace/rmdscaffold#1

I'm still considering whether that's the best option & trade-off in terms in utility vs development time or if that's overkill

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants