Skip to content

Baseline Bronze Silver Gold

The Reusability Framework

This framework helps NHS data professionals measure how easily their code can be picked up and used by another team.

Whilst reproducibility (knowing the code produces the right results) is vital, re-usability (knowing someone else can adapt the code) is equally important for a national library.

A Note on the SUL Principle

To build highly reusable code, we encourage developers to consider the SUL principle: decoupling Structural (templates), Utility (helper functions), and Logic (bespoke project code) elements. Whilst not strictly mandatory for the lower tiers, applying SUL thinking will naturally elevate your code toward Silver and Gold standards.

Baseline: The "Discoverable" Level

At this tier, the code exists and people can find it. It might be entirely bespoke or messy, but the author has shared it so others can see how they solved a specific problem.

Requirements:

  • Catalogue Entry: The code repository is linked to the national library.
  • Metadata: The author has filled in all required library metadata (tags, language, description, author contact) so search functions can find it.
  • Code Access: The repository can be public or private. If private, the catalogue entry clearly states who to contact to request access.

Bronze: The "Transferable" Level

At this tier, the project is tidy. Another team can read it, understand it, and copy chunks of it, but they will still need to manually rewrite parts to fit their local setup.

Requirements:

  • Organised Code: Code lives in the same repository, but the author has made an effort to group generic helpers away from bespoke project steps (a first step toward the SUL principle).
  • No Hardcoding: The code contains no local machine paths (like C:/Users/name/...) or hardcoded passwords.
  • Dependency Management: The repository includes a clear list of dependencies (like a requirements.txt or renv.lock file).
  • Code & Data Permissions: The README explains exactly how to request repository access (if private) and what NHS database permissions a user needs to run the code.

Silver: The "Modular" Level

At this tier, a project is generic enough that another team can swap out the logic or data source without breaking the whole system.

Requirements:

  • Physical Separation: Developers physically separate generic utility functions from the main logic scripts (e.g., placing utilities in a distinct utils/ directory). Logic scripts import these utilities rather than defining them inline.
  • Configuration Driven: The code uses configuration files (like .yaml or .json) for variables, database connections, and parameters.
  • Adaptation Instructions: The README includes a specific "How to Adapt" section. It tells another analyst exactly which files to edit to apply the dashboard or pipeline to a different hospital or dataset.
  • Error Handling: Generic functions include basic error handling to warn new users if they input the wrong data format.
  • Streamlined Access: If the code is private, the owning team has a documented, routine process for granting access to other NHS analysts, rather than dealing with requests ad-hoc.

Gold: The "Plug-and-Play" Level

At this tier, the project acts as a generic asset for the entire health sector.

Requirements:

  • Packaged Assets: Where appropriate, developers have fully embraced the SUL principle by extracting structural and utility code into standalone, version-controlled packages (e.g., an internal R or Python package) or formal project templates.
  • Frictionless Sharing: The repository is fully public (open source). If it must remain internal for security, developers host it on a central NHS platform or internal package registry where authorised users can pull the code without waiting for manual approval.
  • Synthetic Data: Where appropriate and safe, the repository includes a small mock or synthetic dataset. This allows a new user to download the repository and test the code immediately.
  • Automated Testing: Utility functions and packages have unit tests. This proves the generic components work reliably before others build on them.
  • Comprehensive Guides: The documentation includes tutorials or vignettes showing how to use the code in different NHS scenarios.

Quality score

Each catalogue entry also carries a quality score out of 100. The tier and the score measure different things:

  • The reusability tier describes the code: how easily another team can pick it up and adapt it.
  • The quality score describes the catalogue entry: how complete and current its metadata is. Points come from criteria such as a full description, tags, a documentation link, a tier rationale, declared SUL layers, and an update within the last 18 months.

A Baseline entry can score 90 if it is well described, and a Gold entry can score 40 if its metadata is thin. Every entry page lists exactly which criteria it met and missed, so raising your score is a five-minute metadata edit, not an engineering project. See it in action on any entry in the catalogue.

Self-assessment

Tick everything that is true of your project. The checklist places it on the framework and tells you what the next tier needs. The result is advisory; maintainers confirm the tier at review.

Ready to share? Submit your code, or check the category taxonomy first to find its home.