OHDSI Home | Forums | Wiki | Github

What Are Best Practices for Quality Control of Research Packages?

General
#1

Hi all,

I am currently working on my first ( :grin: ) network study. Super happy to be here and part of the community! I have a background in open source software development and in biomedical engineering. In many projects I have worked on in the past, especially software related ones, there was often a best practice I could follow, adopt, or adapt to my projects.

After perusing studies on the OHDSI Studies organization is there any sort of centralized best practices to ensure quality control of the creation of network packages for the OHDSI Community pertaining to testing, documentation and style guides, and dependency management? I could not immediately find something that is centralized - did I miss it somewhere?

Thanks all!

~ tcp :deciduous_tree:

CC: @Jake @schuemie and @Christian_Reich

#2

Yes, writing more documentation about this is on our to-do list, but hasn’t materialized yet.

Some disjoint resources:

Most study packages are (initially) generated using the ATLAS Estimation and Prediction tools, which generate study packages.

In general, the Book of OHDSI is a good place to start if you’re new to OHDSI.

#3

Thanks for the insight here @schuemie.

Currently, there is a package in the R ecosystem called styler which does automatic formatting of your R scripts. The command I would suggest to use from this library is:

library("styler")

style_file(path = "myfile.R", scope = "tokens", style = tidyverse_style)

Which will automatically format your script of choice but also matches exactly the HADES coding style guide.

#4

Awesome! I’ve been wresting with tidyr for a long time (even made my own wrapper). But styler seems to be much better! I’ll play with it for a bit, and this may become our new standard.

1 Like
#5

Hey @schuemie, on the topic of standards, is there any interest in a work group or discussion centered around creating centralized standards that give guidance on best practices in package development, steps to enhance reproducibility, and user experience? It seems that there is a slowly emerging critical mass of discussions that could intersect well based on the discussions here:

And this current discussion we are having. What do you think Martijn? I’d be happy to chat more certainly.

#6

The discussion on standards for research packages have so far taken place in the HADES workgroup. This workgroup has decided the research packages fall under its care, although we’ve also been busy with lots of other stuff. I’m unsure whether having a separate workgroup for this is a good or a bad idea.

#7

Ah didn’t know that was how the governance worked for the packages. Thanks @schuemie - I will plan on coming to the workgroup as as I can. But I lean more towards if HADES is already in charge of best practice, it is best to keep it to the HADES workgroup and not spawn off another workgroup.

t