SPIKE Investigate moving analysis code into Reusable Actions

[lucyb]

Integrating OSIv2 into Job Server would be made easier if the code was stored externally in one or more repos. Conveniently, Reusable Actions provides this option, as well as allowing others to benefit from the work we've done.

This ticket covers the investigation to look at what Interactive actions would be useful as Reusable Actions.

Acceptance Criteria:

• A decision about whether each action could become a Reusable Action and identification of any pain points, etc.

[LFISHER7]

The post cohort extraction analysis pipeline contains the following steps (example project.yaml here):

• Measures generation
• Calculating a table of the top 5 most commonly used codes for a set of codelists
• Deciles charts
• Time series plots of measures with demographic breakdowns
• Event count summary across multiple cohort extractions
• Notebook creation
• Notebook conversion to html

To be appropriate for conversion to a reusable actions, these should be able to be split into logical units of code (they already are) and these units should solve a problem that occurs in multiple studies. I've outline below whether I think that is true for each step.

• Measures generation - For flexibility, this currently uses a scripted action, but could easily be converted to use the existing measures framework.
• Top 5 tables - This is a logical follow up step from measures generation. It requires extraction of the code attached to a clinical event/medication and subsequent calculation of a measure for each code, but this could be documented appropriately. Similar code has been used for SRO and the renal short data report so I think this would be useful as a reusable action.
• Deciles chart - Already a reusable action!
• Time series plots - Again, this is a logical follow up from measures calculation. Given a measure over time, it plots a line graph over time, with optional breakdown (if your measure includes a groupby). We need to do this all the time in service analytics work. It hasn't been converted to a reusable action yet as it would require some thought as to how much flexibility would be needed (e.g. axes label frequency/size, colours), but I think we could provide sensible defaults as part of a reusable action. It's also worth considering a panel plot action that @ccunningham101 has ready to go as a reusable action - this produces a set of subplots given multiple measures.
• Event count summaries - This provides useful context with the top 5 table and could perhaps be folded into a combined reusable action. I'm not convinced this would be useful enough on its own.
• Notebook creation - This step programatically creates a jupyter notebook. We need this for interactive because we have to dynamically add sections based on user input. I don't see this being used outside of interactive. We should consider whether notebooks are the best approach for interactive over something like jinja.
• Notebook conversion - There is some discussion on the appropriateness of this as a reusable action in opensafely-core/interactive-templates#25.

[bloodearnest]

To be appropriate for conversion to a reusable actions ... these units should solve a problem that occurs in multiple studies.

I don't think this is quite correct.

That's what the idea is for community contributed "reusable actions", yes.

We have a generic mechanism in project.yaml/job-runner to allow action code to be defined outside the project. Technically, that's all "reusable actions" are (modulo some details).

The policies we have around what an "reusable action" should be, and who should be able to write to one, is specifically about this idea of shared community maintained code.

Our use case for the more generic concept of "external actions" is not about reusablity, but security and isolation.

Under the hood, they would use the same syntax and mechanism as "reusable actions", but the policy about them would be very different. For example, I don't see any reason why the shouldn't just live in the opensafely-core repo, as I would expect only Bennett staff to write to them.

So, I think it is completely fine for us to have specific, one use code in an external action code base for the purposes of an OSI action. It shouldn't be in the opensafely-actions org, as it's not intended to be reused, at least initially.

[lucyb]

I'm going to close this SPIKE for now thanks to Louis's comprehensive investigation. We're going to put the analysis/report code into a separate repo within the opensafely-core organisation. This will allow people to contribute to the code without having to get a job-server development environment working, which was the original reason for asking the question, but also allow us to move towards reusable actions where appropriate in future.